> Well, the non-using-ptrace feature is only useful in special situations, > when building local exploits from a secured computer, etc ..
Yes i think this is cool. But I think is more interesting for reverse engineering, because it allows you to bypass some antidebugging ptrace- related tricks. btw, the thing i like from this project is that it brings a new way for debugging programs from userland, and with a clean code (gdb source code really sux). > That's what i think about: > * The ERSI language's usability is poor, radare perl r00lz. hehe, well. They have different aims. ERSI have an api for hooking functions, etc... and radare scripts and perl is just 'the language itself', and you have to do everything by hand. Would be cool to have a perl module to ease all these kind of things. But IMHO keeping the raw interface as a first instance is better, because it gives a better perspective for a low-level guy. > * The external call tracing looks interesting to do reverse ingenieering. The ELF load is done entirely in userland by ELFsh, so hooking functions is merely simple (but slower than the system's one). IMHO radare needs an interface to ease these kind of hooks. > * libelfsh let's inject a section to redirect the calls for revesing > purposes, looks interesting. Just a idea... dumping with radare the 'mapped' symbols of lib* inside the binary (where they longjmp to the real library). Modifying it 'offline' and poking it again will be cool, and having a frontend to parse and support the modification of this is almost simple. This can be an easy way for hooking functions, but...i think that to provide a complete environment for radare we will probably have to implement a frontend for it. Like the 'gtk' one, to ease and automatize complex or repetitive tasks and so. --pancake _______________________________________________ radare mailing list [email protected] https://lists.nopcode.org/mailman/listinfo/radare
