>It reminds me old days when I would run games under Borland's debugger
>and 'patch' it so that I would win them in 15 min or so.
Nice but was simpler since the memory was not protected.
>As I see the biggest problem is that the patched code is one operand (add)
>longer than the old one (Allan's patch).. I think it is around 15 bytes.
>So it may be necessary to put it in some other place in memory and
>in original place put undonditional jump.
I can be complely wrong on that but I think you had to get a free page,
sing that page as used by kernel, add it to the kernel page table (I don'
t know how it is implemented in Linux) and then put the new code there.
Then you should simply replace the old code with a jmp to the new virtual
location and a jump to after the code after that.
>Also, I'm not sure how to get opimized diff of the old code since
>patch/diff operate on source not binary filse, the only util I
>saw was XDELTA, but it is still not exactly what I want.
If I had to do that I probably work with only objdump and a hex editor (or
directly in c). I think you should find the exacty locaton of the opcodes
in /dev/mem, then simply replace it with a jmp, when you will have solved
the problem of where the new code is.
>Once I get the string to search in running kernel and the string
>to replace with, how I would do that? /proc/kcore ? any utils to do
>that?
I think kcore is the same of /dev/mem except some data to allow kcore to
be used as a core gdb file. So I think it' s better to use /dev/mem for
that.
Andrea[s] Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu