Disassembler Download
Raingarda Krzynowek
Assembly language source code generally permits the use of constants and programmer comments. These are usually removed from the assembled machine code by the assembler. If so, a disassembler operating on the machine code would produce disassembly lacking these constants and comments; the disassembled output becomes more difficult for a human to interpret than the original annotated source code. Some disassemblers provide a built-in code commenting feature where the generated output gets enriched with comments regarding called API functions or parameters of called functions. Some disassemblers make use of the symbolic debugging information present in object files such as ELF. For example, IDA allows the human user to make up mnemonic symbols for values or regions of code in an interactive session: human insight applied to the disassembly process often parallels human creativity in the code writing process.
Writing a disassembler which produces code which, when assembled, produces exactly the original binary is possible; however, there are often differences. This poses demands on the expressivity of the assembler. For example, an x86 assembler takes an arbitrary choice between two binary codes for something as simple as MOV AX,BX. If the original code uses the other choice, the original code simply cannot be reproduced at any given point in time. However, even when a fully correct disassembly is produced, problems remain if the program requires modification. For example, the same machine language jump instruction can be generated by assembly code to jump to a specified location (for example, to execute specific code), or to jump a specified number of bytes (for example, to skip over an unwanted branch). A disassembler cannot know what is intended, and may use either syntax to generate a disassembly which reproduces the original binary. However, if a programmer wants to add instructions between the jump instruction and its destination, it is necessary to understand the program's operation to determine whether the jump should be absolute or relative, i.e., whether its destination should remain at a fixed location, or be moved so as to skip both the original and added instructions.
Another challenge is that it is not always possible to identify which parts of the binary correspond to executable code, and which correspond to data. While common executable formats like ELF and PE divide the binary into executable and data sections, other formats such as flat binaries do not, so any given location in the binary may contain either executable instructions or non-executable data, making it difficult to decide whether it should be disassembled as instructions or left as data. Since CPUs generally allow dynamic jumps computed at runtime, it is not always possible to identify all possible locations in the binary that may be jumped to and therefore contain instructions.
Encryption may be used on some computer programs, particularly as part of Digital Rights Management to thwart reverse engineering and cracking. This poses an additional challenge to disassembly as the code must be decrypted before being disassembled.
A disassembler may be stand-alone or interactive. A stand-alone disassembler, when executed, generates an assembly language file which can be examined; an interactive one shows the effect of any change the user makes immediately. For example, the disassembler may initially not know that a section of the program is actually code, and treat it as data; if the user specifies that it is code, the resulting disassembled code is shown immediately, allowing the user to examine it and take further action during the same run.
Any interactive debugger will include some way of viewing the disassembly of the program being debugged. Often, the same disassembly tool will be packaged as a standalone disassembler distributed along with the debugger. For example, objdump, part of GNU Binutils, is related to the interactive debugger gdb.[1]
A dynamic disassembler can be incorporated into the output of an emulator or hypervisor to 'trace out', line-by-line, the real time execution of any executed machine instructions. In this case, as well as lines containing the disassembled machine code, the register(s) and/or data change(s) (or any other changes of "state", such as condition codes) that each individual instruction causes can be shown alongside or beneath the disassembled instruction. This provides extremely powerful debugging information for ultimate problem resolution, although the size of the resultant output can sometimes be quite large, especially if active for an entire program's execution. OLIVER provided these features from the early 1970s as part of its CICS debugging product offering and is now to be found incorporated into the XPEDITER product from Compuware.
A length disassembler, also known as length disassembler engine (LDE), is a tool that, given a sequence of bytes (instructions), outputs the number of bytes taken by the parsed instruction. Notable open source projects for the x86 architecture include ldisasm,[8] Tiny x86 Length Disassembler[9] and Extended Length Disassembler Engine for x86-64.[10]
for my studies I'm learning x86 assembler and in general how a computer works at that level. So far I've used the standard tools, objdump and gdb. But reversing even small programs for practice is very tedious with the aformentioned tools. Are there any better alternatives? I've heard good things about IDA on Windows, is it any good on Linux? I'd prefer to use open source programs of course, if they are decent.
What do my fellow Arch users use?
Trent, that's not the worse way to learn ASM you know...But I agree, without any base of ASM programming, learning from disassemblies (alone) will be near damn impossible.
To be a bit more constructive, GDB! Best disassembler/debugger out there (for Linux anyway). If you're a GUI fellow, try Insight, a rather nice GDB frontend.
A nice guide to GDB >
Well, as I stated in the OP, I am using gdb. I just find it tedious to work with, because I can't see all my information (registers, stack, stuff stack and registers reference to, etc.) in a nice, formatted way at one glance. I'd just like to be able to concentrate on what the app is doing instead of searching for all the data I need after each and every step. "display" makes it a bit easier, of course, but it's not really sufficient. It feels like I'm using stuff from the 80's. And no, ddd doesn't cut it, IMO.
Maybe I should have elaborated a bit more on what I'm doing in the first place im my original post: this is homework from the semester course "Computer architecture and system programming". We didn't start with disassembling of course. I do have some knowledge of asm and some coding/calling conventions on this level. The recent task was to defuse a "code bomb", which I had to disassemble, of course. After some hours in gdb you can get frustrated, so please excuse my rant above
Googling brought me to Kdbg, but it seems unmaintained, although the page says they're working on porting it to KDE4. I might check that out again sometime when they're done. In the mean time, Insight seems usable judged by the screenshots, showing the registers, stack and so on in windows.
While you are reversing statically (disassembling), I recommend a VM with Windows XP/2k(3) and IDApro.
Considering debugging, GDB with or without a graphical frontend is more or less the way to go, even though EDB seems worth a try.
Things have settled down a bit on my end, as I'm not disassembling alot this week. I played around a bit with most of the mentioned applications. Especially EDB seems like it has a lot of potential, but the last update was in 2007, so I guess development has stalled
On the debugging front, nemivr looks good, but is very Gnome-ish, with dependencies and all. Not very KDE friendly. Presumably, I'll just stick to DDD and the console, with some input from EDB here and there. It's really a pitty that there are so many projects that had a good start and got abandoned.
The source states a "b" command for "branch endless", but the window shows some random tokens which dont really make sense. While stepping into, it shows that the "branch endless" loop is actually executed. So the disassembler seems to be wrong.
Perhaps the range of memory being displayed by the disassembler has been trashed somehow. I suggest you use the View Memory Browser feature of CCS to inspect memory starting at address 0x00014b50. Look right after a successful load, and then again after hitting this breakpoint. I bet it changed, even though it shouldn't.
The first instruction of __TI_decompress_rle24 is supposed to be MOVS R2, #0x1, which for R4 thumb mode has opcode 0x0122, as shown in your screenshot. However, the disassembler inside CCS is decoding it as a different instruction. I don't know enough about ARM opcode encodings to take a guess at what's wrong here.
Okay, I've looked at the pristine rtsv7R4_T_be_v3D16_eabi.lib from ARM compiler version 4.9.7, and as expected, the first instruction in __TI_decompress_rle24 is the Thumb 2 instruction "MOVS R2, #0x1", which is 16 bits long. This shows up in raw memory as 2201, just as it does in your snapshot of memory as raw data. The memory at that location is correct, but for some reason the disassembly window gets the instruction wrong. My first thought was that the disassembly window is configued to use the wrong endianness or CPU architecture, but I can't figure out how it could be interpreting it as an "LSL". The standalone disassembler that comes with the compiler (dis470) correctly disassembles it, so this problem seems to be specific to the CCS disassembler. We will likely need to move this thread to the CCS forum for further analysis.
7fc3f7cf58