This looks nice. From the layout of some of the menus, it seems like it was written by fans of OllyDbg, maybe because OllyDbg still has no 64-bit support. OllyDbg is great, so hopefully I can get some use out of this tool as well.
Hey, great work! It's a little bit unfortunate it doesn't work for Linux, since I've been looking for something like that for a long time and haven't found one, yet.
How hard would it be to port this to Linux? What would need to be ported? I don't have much free time, but I might be able to contribute to a port for Linux, given enough free time.
1. Visual Studio is not free. Yes there is Visual C++ express but for a while it didn't have C99 support because in general it was only a C++ compiler. I believe C99 support was added with VS2013.
2. It's just really nice to use the same compiler on Linux, BSD and Windows. This is possible with GCC and LLVM but not Visual C++.
Microsoft tools are not bad (in fact I like SQL server over MySQL or Postgres) but because they aren't cross platform it's very difficult to adopt. them.
Perhaps worth noting that there is a difference between MinGW [1] and MinGW-w64 [2] - namely, the latter supports building 64-bit applications. In combination with msys2 [3], its pacman port [4], and mingw-builds [5] the toolchain has become very easy to install, and quite pleasant to use.
I had previously commented [6] on stability issues using mingw-w64. After some snooping using vmmap, Dependency Walker, and PE Explorer, I found that disabling the Windows Superfetch service dropped memory usage significantly. It turns out that this has been observed by cygwin devs [7]. I also disabled the Program Compatibility assistant, and my system now stays stable even after rebuilding LLVM and OpenBLAS multiple times.
There's generally very little call for binary-level debuggers in linux. So everything is oriented towards source-level debuggng. Which makes sense since normally source code is available.
IMO gdb isn't very good for binary-level debugging, which is pretty much a euphemism for reverse-engineering anyway. It'd be nice to have something like that. I tinkered around with building such a thing years ago[0] but I wanted it to be cross-platform (I was using PPC at the time). But found libdisasm to be a bit limited as a disassembler suitable for such a thing.
> So everything is oriented towards source-level debuggng. Which makes sense since normally source code is available.
Maybe it's just the way I use debuggers, but I don't find this to be a particularly compelling reason; I use instruction-level debugging quite often even when I have the source (debugging a program I wrote, when simpler methods fail), to [1] verify that the high-level language statements are doing the expected, [2] ensure that the compiler is generating the expected instructions, and [3] to observe where exactly the bug is.
> IMO gdb isn't very good for binary-level debugging
Having come from a Windows background, I'd say using gdb for that is an absolute nightmare - it appears to almost be designed to actively make it harder to do instruction-level debugging, despite the fact that the implementation of a debugger for source code is far more complex than one that doesn't. E.g. the "disassemble" command absolutely requires a symbol table, and will still complain if there's no "function" at some address, when all it really needs to do is start reading the bytes at the address it's given as a parameter - which could be the name of a symbol - and interpret them as instructions. Instead the somewhat unintuitive "workaround" is to use "x/i".
IDA Pro is available on Linux, but I think you were looking for a free option. Although the shareware version of IDA Pro works very well under WINE (the shareware version is an old release that is missing some features and is before they added Linux support)
It's really good to see such a lightweight interface, like Ollydbg. I stopped using Ollydbg back then when I had to debug some x64, but didn't find anything free with such a minimalist and powerful UI. I guess you guys made it, good job :)! I wish it was available for Mac too thought - not using Windows anymore.
For OSX there is now hopper, a binary debugger and reverse Engineering tool. Something between Olly and IDA with a nice interface. Can work on x86 as well as ARM binaries. Hopper is not open source.
http://www.hopperapp.com
I'm really really hoping Hopper can catch up to IDA. I'm still not good enough with assembly to make much use of either, but the free version of IDA can make some really nice flowcharts which are pretty helpful.
How does this compare to WinDBG, which already seems fairly mature? Why would I switch to this? (if you ask me, the problem of FOSS doesn't come into play here, since Windows itself is a closed platform).
And indeed, a similar GUI-based debugger for Linux would be awesome as well.
> if you ask me, the problem of FOSS doesn't come into play here, since Windows itself is a closed platform
There are many Windows users who prefer to use FOSS despite the OS itself not being so, and have more pragmatic reasons for using Windows over some other (possibly FOSS) OS.
To me the strength of windbg is not the 1990s style Multiple Document Interface UI. It's the fact that the commands are so terse and powerful. Once you get over the (steep, I'll admit) learning curve, you get a lot done without typing very much. I find gdb a lot more painful to get around for even simple stuff.
The remote debugging support is also phenomenal, though you need a culture to support it. I've only seen it work really well on the MS campus.
Windbg was broken on Win 7, in that it no longer is able to walk the stack by following [EBP]. If I want to get a call stack, I have to use Windbg on Windows XP.
Hey look, it's GPLv3. So the only people using it are probably writing malware. I don't expect any commercial windows shops or anyone at MS will use this tool. That said, seems like a pretty cool project.
Minor nitpick: X32 is not "32-bit x86", it's an entirely different ABI[1], using 32-bit pointers but the (faster) 64-bit instructions.
You're better of just calling it x86 to describe the 32-bit instruction set.
I love the connections between jumps and landing sites though, very helpful!
[1]: https://en.wikipedia.org/wiki/X32_ABI
This looks nice. From the layout of some of the menus, it seems like it was written by fans of OllyDbg, maybe because OllyDbg still has no 64-bit support. OllyDbg is great, so hopefully I can get some use out of this tool as well.
Yeah exactly what I thought, too, seems to have feature parity with OllyDbg? As well as extras?
This 64-bit version of Olldbg is in the works
http://ollydbg.de/odbg64.html
Hey, great work! It's a little bit unfortunate it doesn't work for Linux, since I've been looking for something like that for a long time and haven't found one, yet.
How hard would it be to port this to Linux? What would need to be ported? I don't have much free time, but I might be able to contribute to a port for Linux, given enough free time.
No need to port anything, you can use edb: http://codef00.com/projects#debugger or https://code.google.com/p/edb-debugger/
I've used it for some time and don't really like it much.
What don't you like? I know the author, and I'm sure he'd appreciate feedback offline
This is based on the TitanEngine. http://www.reversinglabs.com/resources/open-source/titanengi...
Is there a word for open source that has no revision history? (there's just a .rar file on that site). 7zip does it too and it drives me crazy.
> Is there a word for open source that has no revision history?
Open Crap?
Source Dump.
We completely rewrote TitanEngine into TitanEngine Community Edition: https://bitbucket.org/mrexodia/titanengine-update
That looks awesome, is there something like this for linux as well? Or what is the current way linux programmers debug x86?
GDB or LLDB?
Linux standard debugger is gdb.
You can use GDB on Windows too - MinGW have Windows versions of the usual set of tools(gcc, gdb, objdump, grep, etc.).
I highly recommend MinGW if you do any serious work on a Windows machine.
why not visual studio?
Since this is an article about an open source debugger, it's probably because Visual Studio is not free (except express), Free, or Open Source.
Two reasons:
1. Visual Studio is not free. Yes there is Visual C++ express but for a while it didn't have C99 support because in general it was only a C++ compiler. I believe C99 support was added with VS2013.
2. It's just really nice to use the same compiler on Linux, BSD and Windows. This is possible with GCC and LLVM but not Visual C++.
Microsoft tools are not bad (in fact I like SQL server over MySQL or Postgres) but because they aren't cross platform it's very difficult to adopt. them.
Unless they've recently and very quietly changed their policy, the Express versions also don't support plugins.
Perhaps worth noting that there is a difference between MinGW [1] and MinGW-w64 [2] - namely, the latter supports building 64-bit applications. In combination with msys2 [3], its pacman port [4], and mingw-builds [5] the toolchain has become very easy to install, and quite pleasant to use.
I had previously commented [6] on stability issues using mingw-w64. After some snooping using vmmap, Dependency Walker, and PE Explorer, I found that disabling the Windows Superfetch service dropped memory usage significantly. It turns out that this has been observed by cygwin devs [7]. I also disabled the Program Compatibility assistant, and my system now stays stable even after rebuilding LLVM and OpenBLAS multiple times.
[1] http://www.mingw.org/ [2] http://mingw-w64.sourceforge.net/ [3] http://msys2.github.io/ [4] http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ [5] http://sourceforge.net/projects/mingwbuilds/ [6] https://news.ycombinator.com/item?id=7740930 [7] https://cygwin.com/ml/cygwin/2011-12/msg00058.html
Can you recommend a good way to get GUI for gdb on Linux? I played a bit with xgdb, but it was very primitive in my experience. Thank you.
There's generally very little call for binary-level debuggers in linux. So everything is oriented towards source-level debuggng. Which makes sense since normally source code is available.
IMO gdb isn't very good for binary-level debugging, which is pretty much a euphemism for reverse-engineering anyway. It'd be nice to have something like that. I tinkered around with building such a thing years ago[0] but I wanted it to be cross-platform (I was using PPC at the time). But found libdisasm to be a bit limited as a disassembler suitable for such a thing.
[0]. http://www.scaramanga.co.uk/stuff/debugger/l33t-debugger.png
You don't always have the code, check out edb here: http://codef00.com/projects#debugger or here https://code.google.com/p/edb-debugger/
Check out radare2 (http://radare.org/), which is one of the best tools for binary reversing available on Linux.
radare2 is incredibly powerful but is a nightmare when it comes to usability though.
> So everything is oriented towards source-level debuggng. Which makes sense since normally source code is available.
Maybe it's just the way I use debuggers, but I don't find this to be a particularly compelling reason; I use instruction-level debugging quite often even when I have the source (debugging a program I wrote, when simpler methods fail), to [1] verify that the high-level language statements are doing the expected, [2] ensure that the compiler is generating the expected instructions, and [3] to observe where exactly the bug is.
> IMO gdb isn't very good for binary-level debugging
Having come from a Windows background, I'd say using gdb for that is an absolute nightmare - it appears to almost be designed to actively make it harder to do instruction-level debugging, despite the fact that the implementation of a debugger for source code is far more complex than one that doesn't. E.g. the "disassemble" command absolutely requires a symbol table, and will still complain if there's no "function" at some address, when all it really needs to do is start reading the bytes at the address it's given as a parameter - which could be the name of a symbol - and interpret them as instructions. Instead the somewhat unintuitive "workaround" is to use "x/i".
IDA Pro is available on Linux, but I think you were looking for a free option. Although the shareware version of IDA Pro works very well under WINE (the shareware version is an old release that is missing some features and is before they added Linux support)
IDA Pro running on Windows can connect to GDB server running on Linux, even to embedded platforms like ARM/MIPS.
It's really good to see such a lightweight interface, like Ollydbg. I stopped using Ollydbg back then when I had to debug some x64, but didn't find anything free with such a minimalist and powerful UI. I guess you guys made it, good job :)! I wish it was available for Mac too thought - not using Windows anymore.
in case anyone missed it, there is Olly for x64: http://www.ollydbg.de/
You might want to check that again. There is no x64 olly available to anyone other than the author. It's been a "work in progress" for a decade or so.
For OSX there is now hopper, a binary debugger and reverse Engineering tool. Something between Olly and IDA with a nice interface. Can work on x86 as well as ARM binaries. Hopper is not open source. http://www.hopperapp.com
I'm really really hoping Hopper can catch up to IDA. I'm still not good enough with assembly to make much use of either, but the free version of IDA can make some really nice flowcharts which are pretty helpful.
How does this compare to WinDBG, which already seems fairly mature? Why would I switch to this? (if you ask me, the problem of FOSS doesn't come into play here, since Windows itself is a closed platform).
And indeed, a similar GUI-based debugger for Linux would be awesome as well.
> if you ask me, the problem of FOSS doesn't come into play here, since Windows itself is a closed platform
There are many Windows users who prefer to use FOSS despite the OS itself not being so, and have more pragmatic reasons for using Windows over some other (possibly FOSS) OS.
To me the strength of windbg is not the 1990s style Multiple Document Interface UI. It's the fact that the commands are so terse and powerful. Once you get over the (steep, I'll admit) learning curve, you get a lot done without typing very much. I find gdb a lot more painful to get around for even simple stuff.
The remote debugging support is also phenomenal, though you need a culture to support it. I've only seen it work really well on the MS campus.
Windbg was broken on Win 7, in that it no longer is able to walk the stack by following [EBP]. If I want to get a call stack, I have to use Windbg on Windows XP.
The site is quite broken on my Nexus 4.
http://i.imgur.com/H72QriT.png
I don't think that's a major issue.
The link to the downloads page is broken. Anyone?
Hey look, it's GPLv3. So the only people using it are probably writing malware. I don't expect any commercial windows shops or anyone at MS will use this tool. That said, seems like a pretty cool project.