On 12 May 2010 17:31, mobi phil <[email protected]> wrote: >> I don't know why (this was a long time ago), but reading some >> addresses from /proc/[pid]/mem falied and with ptrace() not. Maybe you >> could do some tests (could be a bug and is fixed now). > I will do an experiment soon > >> In that case you need to keep track of memory changes (maybe hooking >> mprotect() and mmap()/munmap()/etc), you can trust in the actual >> protections of the memory. On the other hand you don't need to cache >> the whole mem, you could use a small cache and do caching on demand so >> you wont have problems with huge applications. I think not syncing the >> cache contents always could lead to confusion nd problems to the user. > That would be an idea. On linux: Is it not possible to protect the > memory of the traced process with ptrace alla mprotect from the > debugger? Is it possible to capture page fault signal (sigsegv). If > both would be possible then what you propose would work like charm.. > If not ... again ... linux is tooo too much primitive :)
Actually I made a patch to do that once (never submitted it), you can find it here: http://patan.svn.sourceforge.net/viewvc/patan/patch?revision=2&view=markup Is for 2.6.18 so is not very useful today. A better approach could be using a syscall-proxy (setting up a call to mprotect in the context of the debugged process from ptrace) that way you don't need any kernel modification. > > > -- > rgrds, > mobi phil > > being mobile, but including technology > http://mobiphil.com > _______________________________________________ > radare mailing list > [email protected] > http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org > -- There is a crack, a crack in everything. That's how the wine gets in. _______________________________________________ radare mailing list [email protected] http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
