Well, the non-using-ptrace feature is only useful in special situations, when building local exploits from a secured computer, etc ..
That's what i think about: * The ERSI language's usability is poor, radare perl r00lz. * The external call tracing looks interesting to do reverse ingenieering. * libelfsh let's inject a section to redirect the calls for revesing purposes, looks interesting. regards, sha0 2007/5/12, pancake <[EMAIL PROTECTED]>: > > I have read a presentation from the ELFsh people talking about what they > are > implementing inside ELFsh. Looks like they are following in the same > direction > as radare :P > > elf editor -> elf loader -> execution -> debugger > > What they have done is a new approach in the debugging (at least on *NIX > systems) > because they are not using ptrace(). Just sigaction(), I'm really > interested to > know how they are achiving this to make a 'step'. > > They have written an awesome well designed API for disassembling and > analysing > ELF programs on x86 and SPARC (mips in future too). So i recommend you all > to take > a look on this paper and watch the source code. May be we can take ideas > from them > to implement a better debugging layer for radare or implementing a > remote-debugger > plugin to use radare as a frontend for elfsh. > > PDF presentation: > > http://news.nopcode.org/pdf/ERSI.pdf > > Source code: > > http://news.nopcode.org/elfsh.tar.gz > > (They have no public snapshot or cvs) I have grabbed this tarball with a > small > perl script to fetch cvstree's from a cvsweb via http. > > > --pancake > _______________________________________________ > radare mailing list > [email protected] > https://lists.nopcode.org/mailman/listinfo/radare > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.nopcode.org/mailman/private/radare/attachments/20070514/13cb8183/attachment.html _______________________________________________ radare mailing list [email protected] https://lists.nopcode.org/mailman/listinfo/radare
