I have pushed a commit adding support for proc/pid/mem memory reads for radare1.
The thing is that proc/pid/mem is only accessible by the own process and their childs. this is why you can only use this when forking, or ptracing a process. AFAIK in solaris this is not in this way. The patch adds an eval variable named 'dbg.procpidmem' that enables this mode when setting it to 'true' or '1'. I have performed a simple benchmark and it results in 25% faster executions. It doesnt seems to be any specific lag for memory reads now. (when comparing no reading (return0) or procpidmem readings is near 0 the difference of time. So it seems like a good solution :) Can somebody check in which other OS do the proc/pid/mem trick works? It is mandatory to remove the #if __linux__ check in debug_os_read_at() I should port this IO backend to radare2. Another trick you can use to do faster searches in memory is by making the block size bigger: > b 4M > /x 8028394820 > b 128 --pancake On Wed, 12 May 2010 22:31:44 +0200 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 :) > > > -- > 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 > _______________________________________________ radare mailing list [email protected] http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
