[cret]

hi, can someone, who has an ida-pro-version tell me how it works for gameboy?
I'm developing a gb-analysis-plugin for r2, and it's pretty good. I spent a lot of time and love to it. It would be great if I can beat the ida-gb-stuff.         

[FAST6191]

Can't say I have done Z80 with IDA but the idea of beating IDA is kind of similar to a lot things we see in forums like this that use the word "just" (as in "just" disassemble it and rewrite it in C). IDA is a seriously powerful tool and though I doubt its z80 capabilities are as good as its X86* (my usual suggestion for a sort of primer on X86 IDA is http://www.youtube.com/watch?v=a7vTTspWcTE ) I imagine it is around what its ARM abilities are at.

*if nothing else embedded single program on simple processor vs full OS and X86 security will make sure there is not even the potential.

To that end you are going to need at least
Disassembly, basic static disassembly is obvious. Ability to assign nice names to memory locations is also necessary, you may or may not wish to include logic far enough to handle pointer maths in the disassembly)
Instruction generation. Single instruction and small run. You can kick full code to an external assembler. Back on nice names thing I will be wanting pointer maths type things with my nice names.
Code injection help. Free space finders are hard, especially if you are already dealing with MBCs, but such things are available for embedded processors. However if I tell you something is free space and the location of my jumps/returns then I would like that sorted.
Code running. Obviously this is not full emulation, though the ability to speak to BGB or something, even if you just snatch the memory out of the program's memory space on the PC would be nice. However the ability to set register values and run the routine and spit out results will be sought.
Maybe some kind of bounds checking. The GB/GBC memory map is pretty full but not entirely, you might also try to code in a warn if a read/write/injection goes beyond the thing it looks like it is fiddling with.
Back on the disassembly you are going to want almost full IDE (or at least notepad++ level) where you can section off things (this is my [blah] function, this is not running code....) and have a nice minimise button to shrink it down.

IDA is a serious tool, there is a reason they can ask for and get paid the good money for their tools. More generally a lot of it is just nice to have, I would focus less on beating IDA (for my next trick....) and more on getting what you reckon is useful in there.

[cret]

well, I'm concentrating on the analysis itself for now, not on the IDE.

Disassembly works
A internal assembler is planed (sure those naming stuff might be hard, but maybe r_parse might help. I don't know, i didn't work with it before)
Code injection-help: '/R' searches for rop-gadgets, this should be enough for the start
Code running: radare2's internal representation of an opcode is an esil-string (see https://github.com/radare/radare2/wiki/ESIL) the gb-plugin gives a basic esil-support. this must and will be improved, so that you can emulate short code-sequences.
       -> I'm still developing ramulate, this aims to be a remote-debug-server and r2 is the debugger-frontend.

right now i'm coding on a new command, which analyses the cycle-lenght of instructions, so that you might predict interrupts on debugging. Next would be some magic for data-detection.

[henke37]

Don't forget cross reference detection. Both data and code. A lot of people like that in IDA.

[tryphon]

What is r2 ?

[FAST6191]

What is r2 ?

There is a link to part of the project above, however it is a generic looking term and I got confused before when cret referred to it (cret, you may wish to state what it is in future posts, even a "radare2, henceforth R2," arrangement). It is a program called radare2, http://radare.org/doc/html/contents.html and http://radare.org/doc/html/Section22.8.html#forumintro (for an older version but worth a read anyway). It is something of a generic reverse engineering tool and a lot better than some of the alternatives. It does seem more aimed at more complex systems but it looks like it is turned towards stuff like this easily enough. Personally I do not reckon it is the path to the land of milk and honey but there are worse frameworks you can try playing with.

Back on the matter at hand. I am not sure I can divorce the IDE/programming side of IDA from the analysis side of IDA that easily.

[tryphon]

Thanks for the link.

I agree with the fact that it looks much less user-friendly than IDA.

A nice and intuitive GUI would be a must.

[cret]

r2 is an alias for radare2. its important to say that radare2 is not radare. radare2 is a rewrite of radare. most features are the same, but there are some new in radare2. radare2 is plugin-enlargeable and quite faster than radare.
@FAST6191: what do you think can be done better? did you try r2? found new bugs?

If you want a gui, open the visual mode with 'V' and then presse 'W'. this starts a webserver (and your webbrowser). now go to http://localhost:9090
or you can use bokken (gui written in python)



Well my personal opinion to a GUI here is, that if you're doing reverseengineering, in most case you are skilled enough to live without GUIs.

[tryphon]

Well my personal opinion to a GUI here is, that if you're doing reverseengineering, in most case you are skilled enough to live without GUIs.

That's totally true.

But when you're given the choice to use a powerful and intuitive program and another that forces you to eat some hundreds pages of documentation, not being sure it's bug free nor it have as much as useful functionnalities, skilled or not, the choice is quickly done.

[cret]

well, you don't need eat some hundreds pages of documentation to understand the r2-commands. They are mostly tree-like structured:

If a command starts with 'p' it's in most cases a print command ('p' stands for print) .
or if a command starts with 'a' it's an analysis command ...
f - flag
c - compare
C - code metadata
d - debugger
i - info (from opened file)
s - seek
e - eval
l - log
w - write
y - yank
b - block size
P - project management
? - help and math
...
the rest works similar: 'pd' stands for print disassembly, 'aa' -> analyse all, 'af' -> analyse function (at current offset), 'pdf' -> print disassembly of function at current offset



quite often programms with nice GUIs have less features. according to this https://www.hex-rays.com/products/decompiler/news.shtml#131213 ida is not bugfree.

[tryphon]

Have you used ida ?

[cret]

yes, I tried the demo-version. both, ida and r2 have 1 big issue: too much features for users, who didn't ever use the program before.

There are a lot of thing, which are not intuitive to me. for example: how can I perform hash-algorithms on data with ida?


bokken: http://inguma.eu/attachments/download/118/bokken-dasm.png

[FAST6191]

Yeah I gave it a go. I am always on the lookout for such things, especially free ones. I can not say I would like to give a go at teaching someone it tomorrow but I certainly gave it a spin, likewise I reckon I have used enough of these sorts of things that I can tell if something is going to be a hassle/has been cobbled together into something that kind of works but will never be easily extended. As far as generic extensive frameworks go it is good though naturally the focus seems to be towards PC type environments*, I would probably still look to the debugging options of my general dev environments, language/system specific, technique specific or the sort of things we usually deal with around here (and IDA of course). Now I am certainly not inclined to discourage your use of it like I might be if someone suddenly decided something like http://stealth.hapisan.com/ROMulan/ was their way forward, your work may even serve to raise it up in my estimation. However if someone asked me whether they should learn say python (or some equivalently capable scripting language) or radare2, solely for hacking purposes, I would probably still point them at python (and probably the downloads/docs section of here) and command line/shell scripting.

*this may be a good thing as time goes on. For the SNES and co knowledge of C is not that useful beyond tool making, for newer systems knowledge of the relevant high level programming setups for the systems help so much.

My gold standards for domain specific scripting and command line based things are usually found in the video world. Avisynth ( http://avisynth.nl/index.php/Main_Page#Usage and http://avisynth.org.ru/docs/english/ ) being especially worthy of comment, probably also further comment here as every negative I am about to bring up might well be levelled against Avisynth.

Similarly I am not sure a lack of a GUI is a good or otherwise inconsequential thing for reverse engineering. Now I will certainly hold the lack of a scripting or command line interface against you should you make such a program (probably in general but especially for reverse engineering work) so there is that. However most modern RE techniques

Too many features is not a thing for me, give or take the amount of features making for resource requirement issues, and I do not necessarily share your focus with bugs (squash em, squash em good and try to avoid them but they are an inescapable part of programming remotely useful tools). It is certainly possible to make a GUI (or even UI) that appears daunting to new users, even those versed in the field you are dealing it, but that is a different matter. Now very few people, especially in the more speciality skills areas of computing, practice good GUI design so this may be similar to the discussions of coding styles that people have (interesting and theoretically a fantastic idea so very far from the real world where we get to deal with legacy things).

[cret]

For the SNES and co knowledge of C is not that useful beyond tool making, for newer systems knowledge of the relevant high level programming setups for the systems help so much

I totally disagree with that. Highlevel-programmers often forget how the lowlevel-layer under their highlevel-stuff works. Later they get exploited or segfault in hell  . Therefor esspecially on newer systems it is important to have knowledge about lowlevel-stuff.

according to GUI please see the main developers tweet https://twitter.com/radareorg/status/448055685495144448


one thing I just wanted to say is, that r2 is scriptable and that there are language bindings for python, java, ruby, perl, go ... even for php. I just can recommend using libr as a basic lib for any kind of binary-analysis you want to implement.

[FAST6191]

I may have been a bit vague there.

Radare 2 -- nice enough for reverse engineering things made using high level programs (file open hooks, exports, linked libraries, strings, standard executable formats..... the usual stuff for PC work). Also about the closest I usually get to a proper binary grep type affair.

I held that such concepts, at least those that directly translate from C family and beyond, did not really exist for the SNES and other older consoles. See also part of the reason dynamic recompilation did not do so much before the N64 and co. However if we are going to hack a .net program tomorrow then if you did not know a C# family language then we would probably be spending time learning that. If we are going to hack a networked game tomorrow then I will probably be busting out my big book of SQL, something on encryption/obfuscation or something on general networking before I reach for my opcodes list or treatise on say word safe decompression in 16 bit architectures. More generally if you look at things on the DS or consoles around that age and newer and do not see C style format definitions/workflow then you are probably doing it wrong, or do not know C I guess. Granted that will probably become XML before too long but for now it holds. Radare2 slots directly into that world quite well, I was less enthusiastic about its potential for the older consoles which lack that in favour of a good old mess of binary and raw access to everything.

I am always happy to see coders learn the lower level concepts and would be happy to see more do it, the only times I am not inclined towards that is you might not need to bog down the people just learning the scripting type languages.

[henke37]

The thing about "too many features" is that while it might be scary for the first hour, you quickly learn the important parts if you actually sit down and use the application.

[cret]

yes, that's true for every tool. this is how I learned gdb

[cret]

can ida debug gameboy?

[FAST6191]

Not sure what exists in the stock version right now. There are certainly plugins that do the job, or will at least mark off the various areas of the header and whatever else as not binary. You will be hard pressed to find any commonly known game system without an IDA plugin for at least one version of it, indeed IDA may be the best non emulator disassembler for a given system a lot of the time. Page search GBC on http://www.woodmann.com/collaborative/tools/index.php/Category:Disassemblers
I know most here would not but before someone says "but plugins" then know plugins to IDA are what programs are to an operating system.

Likewise with most game systems using common processors then most disassemblers for those processors will also be able to have offsets set in IDA itself giving a functional equivalent most of the time (compressed/encrypted binaries did not come into vogue until later in the day after all, and even then it is usually a well known encryption/compression).