->>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.
Advantage of this solution (over modifying code directly) was
that you would by-pass all protections put in source code against
modifying/hacking/copying it.
->Nice but was simpler since the memory was not protected.
Yeah. I was never to successfully hack King's Quest VI, since it
was using VMDX (sp?), but I think I won it anyways :-)
->I can be complexly 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.
Now that I think about it, it is even simpler. the buggy function
is ip_glue, and it is used only once in ip_defrag.
I think I could just make an module which could have inside of it the
ip_glue() extracted (and fixed) from ip_fragment.c. I could use Source.map
to find out where the original ip_glue is in kernel. and then either:
-make first instruction in ip_glue() to call my ip_glue_new()
which when done would return to old ip_glue(). the 2nd instruction
in old ip_glue() would be return.
or
-just find the only place in kernel where ip_glue is being called
and replace it with call to my new ip_glue.
I think it could be handled by init_module() part of module
and cleanup_module() could restore it back to original state.
Now I'm wondering how I could find out where ip_glue is in system
w/out having to resort to System.map as it is pretty much system
dependent, and on some systems it is /System.map and on others
/boot/System.map. Advantage of it could be that the module
could be system independent and work almost with any 2.0.3x
(at least).
-Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu