Thanks to the poll results (see TODO.poll file in r2 repo) I was able to see the points where people is more interested on having support for.
Nibble and me were discussing about them and splitted the tasks to design a little roadmap for the next release that will be in a month. Here I'm going to discuss the points 1 33 decompilation -- we need better code analysis, but basic decompilation will be in 0.5 nibble has been working on full x86 code analysis support and enhacing the engine to handle more information per opcode, so the function detection, basic block splitting and so on is working much better. I plan to write a r2 plugin in Vala to add support for decompilation. I have the basic design in mind, and will start working on it the next week. 2 29 bindiffing (graph) -- nibble is working on this too, pancake has some binary diffing in C if you follow our twitter you will probably notice that nibble has managed to implement a first code diffing algorithm using some prime numbers properties. It will be good if nibble can send a mail explaining this feature when it's done and give some examples. I'm sure that basic code diffing will be done for the next release. About data binary diffing...There's an implementation taken from mercurial and you can find it in 'ired' repository. It's working for some examples, but fails in some situations, it will be good if somebody can review bdiff.c and send us a patch. Any volunteer? 3 26 better code analysis -- nibble is mainly working on this now Yeah, already in progress, big refactorings will come..but it's actually better than r1. We are using now the x86im engine from 'pluf' (Thanks men!) it give us a full x86 code analysis information, manipulation and disassmbler/assembler engine. We are also using it to generate byte-level binary masks for function signatures. I still have to documentate this O:) But it's kinda easy to generate a signature from a function by maskerading the bytes related to relative addressing values which can be changed between different compilations of the same function. (static bins ..) 4 25 windows support -- please report bugs, pancake will not much work has been done.. it's already working, but the debugger is not usable and needs much love. I'm pretty sure that having a w32 build of r2 with python bindings would hardly benefit the r2-w32 community. Any volunteer? I will try to work a bit on this, but I would prefer to work on other areas. Another solution would be to organize a hackaton by irc and try/implement/fix/test as much the support for w32. 5 22 gdb remote support -- not prioritary atm (volunteers?) linked to bochs/qemu doing some copypasta from r1 it will be possible to implement it, but needs some redesign of the debugger api. still low priority, but would be interesting for the release after the next release 6 20 hardware breakpoints -- no plans for next release..will probably be in 0.6 I have been thinking about how to 'deprecate' r1 in a saner way..and end up thinking that it would be easier to implement all the features of r1 as plugins for r2, so we can keep core libraries clean, by having all the features of r1 ported and then we will have time to review and integrate those plugins into core apis. It makes the development faster to get features, without damaging the core and will give us the possibliity to enumerate which options we want and how we will merge them in core. As hardware breakpoints are only working on x86 and x64 it should be harmless to make it as a plugin. just for testing. Any volunteer? 7 18 code emulation -- some work has been done in r_vm, but needs much more refactoring Thanks to x86im we can implement a better code emulation engine, but the plan is to have a generic engine which is already working in r_vm, but i dont plan to work much on it, it's low priority at the moment. we still have to work on the process backend migration. 8 18 Debug programs in isolated environment 9 -- this is simple issue, any volunteer? This task is really simple to do, and does not needs to interact with radare. The idea is to implement a program in C to launch other programs using execve. Allowing to setup argv using a external file (it's simpler to pass contents of files as arguments than ultra-long arguments), set fd0/1/2 to point to another terminal, change uid/gid, set chroot...etc.. this is quite simple to do and can be done without touching the core. Any volunteer to develop this? Another feature would be to run the debugger in another terminal which would be simple and can allow the user to specify the debugger (gdb, radare, ...) 10 14 threaded debugger -- some work will be done, but dont expect big changes we are quite busy working on code analysis engine and internal refactoring, this will probably be implemented in 2 releases. not prioritary at all. 11 13 radare scripting like in r1 -- please, report issues in mailing list or privmail same as above.. but I can point a bug in r_cons which makes grepping features fail. any volunteer to fix it? this is the reason of the main incompatiblity of r1 commands. 12 13 dalvik (android) -- no plans, no hw, any volunteer? please ask for things to be done if you want to help on this still looking for volunteers :) 13 11 write support for RBin -- nibble will work on this, but code analysis is prioritary atm at the moment there's support to resize sections and remove rpath entry from elf header. 14 11 bochs and qemu support -- very low priority, this depends on gdb support still low priority, when adding support for gdb i'll review this point. 15 9 pdb support -- any volunteer to convert pdb into radare script I have been investigating a bit on this and I think that the best way to do this would be natively on windows, because the format has changed many times and it's not simple to parse. there are already some open source parsers but all of them fail in some or other manner. The only way to do it is by linking against the microsoft library and use the API to extract the dbueging information from the pdb file and print it to stdout as radare commands. If somebody can do this program I can modify it to fit with r2. 16 9 RLine with autocompletion -- no plans atm, but this feature will come eventually nothing changed. 17 8 signature support -- DONE (volunteers to generate database Nibble and me have been working on this, it's actually implemented in the 'z' command. You can generate signatures, search them in programs and set flags in matching signatures. i have partiallyd ocumented this, but 18 6 web interface -- volunteers? we have fixed many bugs in the bindings generation and vala bindings. But nothing has changed in the r2w side.. somebody to work on it? $ hg clone http://radare.org/hg/r2w 19 5 floating point debugger -- very low priority at this point no plans atm, this will be done eventually when we focus on debugger. 20 3 osx support -- x86-32 and x86-64 hardware required, volunteers? read doc/osx fmi i'm currently fixing the build of r2 in OSX. not much work has been done, but I have only powerpc and arm osx-based devices 21 3 extended dwarf support -- zero priority for next release :) using libdwarf it would be easy to add support for it, i would prefer to implement some features of it as a plugin. any volunteer? --pancake _______________________________________________ radare mailing list [email protected] http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
