6 ms·
All the information is in the binary, sure, but IDA makes the process a lot less tedious. objdump doesn't give you the pretty "graph view," showing the basic b
by swolchok 16y ago
All the information is in the binary, sure, but IDA makes the process a lot less tedious.
objdump doesn't give you the pretty "graph view," showing the basic block structure of the code. (In particular, this is really nice for switches and other jump tables.) It doesn't make it trivially easy to see where certain rather important-looking strings are referenced in the code. It doesn't show strings that are being referenced right next to the assembly instruction that references them, like changing
push 0x8049808
to
push offset aD ; "%d"
It doesn't let you mark up
mov eax, [ebp-0x4]
to
mov eax, [ebp-first_number_I_entered]
and have that renaming automatically propagated through the entire function, so that you can easily track accesses to the same variable.
In addition, the Hex-Rays decompiler (http://www.hex-rays.com/decompiler.shtml http://www.hex-rays.com/decompiler.shtml) produces C-like output. I don't have a license for it, but I imagine it would make short work of the bomb lab.
- scott_s 16y agoThe Hex-Rays decompiler would probably make short work of the bomb lab, but I don't think IDA Pro would make much of a difference. For disassembling a large program, sure, but the program and the functions themselves are relatively small. They already know the basic structure of the bomb because we give them a C skeleton that calls all of the functions. The string pointer fetching would probably be the most useful, but once they figure out how to do it once, they only need to do it four or so more times.