Messages in this thread | | | Date | Sat, 18 Apr 1998 17:49:09 -0400 (EDT) | From | ADAM Sulmicki <> | Subject | Re: 2.0.33 off-by-one |
| |
On Sat, 18 Apr 1998, Andrea Arcangeli wrote:
->>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
| |