Reverse Engineering Tools on Linux - Security & Cryptography
kirby
Hey guys I made a big update to the OP, completely rewritten. I thought I'd just save the original here for prosperity.

So for the past few weeks I've been diving into the field of reverse engineering, both as a hobbyist and in preparation for an upcoming internship I have at a security firm. I've been mainly reading the book Reverse Engineering for Beginners. I hit a snag where I'd wanted to test an example given, but the example was given in OllyDBG, a Windows application. I discussed with xero about the situation, and after concluding that Windows had all the good stuff (and with good reason), I decided to look into what was available on Linux and write a post in the style of venam.

My test is simple and entirely unscientific - to run this sample code and watch the memory to prove to myself why the program outputs what it does. The expected value is "a = 1, b = 2, c = 3", but this varies from system to system. This is not a particularly in-depth examination, but I felt it would give me a decent overview of regular usage and some way to compare between different applications.

Unless it wasn't already clear, I am a complete novice in this field. If I say anything incorrect, please feel free to comment on it. Forums are for discussion after all, and this has been as much a learning experience for me as I hope it is for you.

gdb

The first and most obvious is gdb. Installation is easy as it should be in every package manager ever, and the binary (at least on my system) comes in at about 6.2M. Accomplishing the task, while possible, was distracted by the lack of a window to view the memory at all times. Instead I had to print the memory at certain points in the program. This worked fine for my small example, but I feel like for larger projects it would get quite unmanageable having to juggle all the addresses. I'd probably need at least a pen and paper to jot down things. Nonetheless, gdb is useful for smaller projects, and can often be used as a backend for larger programs, so it's worthwhile at least tinkering with it a bit. I wanted to use gdb as a 'base' to compare against the other programs, so I made a painfully slow WebM to try and demonstrate.

radare2

Next on my list was radare. The site had a notice recommending radare2, so I used that. I had to compile this but the process was a simple './cofigure' followed by the usual 'make' / 'make install'. Final binary size came out as 96K. The website had screenshots of GUIs so I was very confused when I ran 'radare2 a.out' and was given a command line. I still don't really understand what's going on with any graphical radare interface, I think it's 'in development'. The application provides a shell like gdb and various 'visual' modes. I ended up flicking between both while trying to perform my analysis. The application was a tad confusing at first, but it is well documented both online and within the program itself, and this got me up to speed quite quickly. I ended up quite liking radare - it feels like a souped up gdb, and that's not a bad thing. I'm still not entirely sure how good a command-line interface would be for larger projects, but it's the probably the best you can get, and it certainly tries to cram in as many features as it can. I'd recommend it.

edb

The first graphical application, Evan's Debugger took me surprise. It was a massive pain to install - it's a Qt4 app, and not in the Debian repos. This means I had to install all the dependencies by hand, including a couple from unstable because the versions in stable were too old, though that's not really his fault I guess. What was his fault was the lack of any indication that I also had to install Qt5 libs. I'll be honest I don't really know what's going on with Qt, but cmake complained when I didn't have them installed and worked once I did. The final binary was 4.1M.

Opening the application and running my test binary gave me an obnoxious black window, which further hampered my first impression. It turns out however this was their console output and it was dwm that was resizing the window. I imagine the default size is sane. This is one of the many features it borrows from OllyDBG and it's clear this program is trying to emulate it as closely as possible. Despite my lackluster first impression, it was actually very pleasant to use. It gives me all the features I would expect, and I was able to accomplish my specific task even easier with explicit 'goto RBP' instructions in the stack viewer. I did have to toggle the word length, but this was an easy task as well. There are a couple of design choices I don't fully understand - I don't see what 'analysing' a region does, for example - and documentation is very sparse. He does mention this is why it is still in version 0.x. I would highly recommend this tool if you're fine installing the Qt libraries that come with it.

ddd

I didn't spend very long on ddd - I'd already used it briefly once and discarded it for being useless, and the same holds true now. It featured some nice windows, but they didn't display anything you couldn't watch with 'gdb -tui', and at the end of the day I just ended up entering gdb commands anyway. It looks incredibly dated and there's basically no reason to use it over gdb, which it's just a frontend for anyway.

OllyDBG

As an aside, I installed OllyDBG on my Windows partition to give it a look. At first I found it quite hard to get to grips with, but I'm not really sure if that's the fault of OllyDBG or Windows' EXE format. Once I got to grips with it it was the best application I used, and offered useful features such as text descriptions of what each memory address was. It's a shame it isn't on Linux, and it might be worth spinning up a Windows VM for if none of these other options do what you need. The experience also showed how much edb is 'inspired' by it however, so that's the best replacement in my opinion.

Conclusion

Beyond these specific apps, there are a lot of command-line tools available in *nix that can prove useful in reverse engineering - things like 'strings' or 'strace'. For the kind of reverse engineering I was looking for, I feel edb was the best, with a shout out to radare for being a very full featured command-line alternative. I hope this has been a useful guide to anyone interested, and feel free to comment on any of the apps I've mentioned or suggest more below.
venam
Now, this is quite a good descriptive post from someone who knows what he needs.
Thanks a lot of the update!
jkl
(08-04-2016, 10:06 AM)io86 Wrote: Olly is a must have on Windows, I guess.

Actually, x64dbg is the better OllyDbg already.
xero
great update kirby. now i have a whole new suite of tools to checkout ;D
thlst
There is also lldb, it's kind of a replacement for gdb.

This is a quote from the page:

Quote:In order to achieve our goals we decided to start with a fresh architecture that would support modern multi-threaded programs, handle debugging symbols in an efficient manner, use compiler based code knowledge and have plug-in support for functionality and extensions. Additionally we want the debugger capabilities to be available to other analysis tools, be they scripts or compiled programs, without requiring them to be GPL.
venam
Kirby can you do a review of PINCE.
It's a frontend to gdb.
kirby
This is a long time coming, sorry.

angr

angr is a Python symbolic execution engine framework. Symbolic execution is a very interesting field and not one that any of the other tools here provide to my knowledge. The Wikipedia page likely explains it better than I can, but in essence it involves traversing a program and storing values as expressions of of other values. This allows the user to perform constraint solving to obtain possible values for unknown variables.

As an example, say you're doing a CrackMe. Instead of reversing the entire algorithm, you could work out how the stack is setup and replicate this in angr. You could then point angr at a start address and tell it to reach a certain end address - the 'success' one. Once it gets there, you have the state of the program stored as a Python object and can tell angr to solve for what the input that lead to this state - the key - was. There are plenty of examples of exactly this.

This is a very powerful tool when used correctly. That's the catch though - learning angr is no simple task outside of the most basic of examples such as what I provided, and the angr documentation is very lacking at the moment. It is being worked on, however, and in my 5 week period I spent with it, the documentation was actively updated and improved. Definitely worth a look at.

-------

I will look at PINCE in a week or two, it tries to download a newer version of GDB and I'd rather not mess around with my Debian install just for that, and my internet is too bad for me to bother setting up a VM at the moment.




Members  |  Stats  |  Night Mode