1

I am currently disassembling quite a large file >100MB. And I was wondering what factors reduce the amount of time needed to disassemble a large file completely.

  • Is it a higher core count?

  • Increased CPU frequency?

  • More RAM?

  • Faster IO reads and writes |SSD|M.2|?

5
  • Which tool are you using for disassembly ?
    – w s
    Commented Nov 27, 2016 at 7:06
  • The tool I'm currently using is IDA v5 Free
    – user36278
    Commented Nov 27, 2016 at 7:07
  • 1
    Perhaps you should edit that into your question – unless you are willing to switch to a faster tool.
    – Jongware
    Commented Nov 30, 2016 at 9:49
  • I must ask this: are you sure that your single 100MB is all code? The last time I saw something approaching that – an 80MB .exe file –, after some trivial checking turned out to be a mere unpacker of 0.5MB, and the rest was an entire folder of PKZIP compressed files.
    – Jongware
    Commented Dec 1, 2016 at 9:59
  • @RadLexus The program is about 80MB of code.The dissembled file is about 2.5 - 3.5 GB. As for the tools I used, I was not really concerned about the specifics, I just wanted to know what factors influence the speed of disassembly, which I believe yaspr answered beautifully.
    – user36278
    Commented Dec 3, 2016 at 8:26

1 Answer 1

4

First, there are many algorithms used to disassemble a binary stream. The two most used ones are : linear sweep and recursive traversal (sometimes a hybrid), which present different performance and precision/reliability issues (how much code isn't disassembled properly : bad opcode, data interpreted as code, ...).
So before you tackle implementation related performance issues you should check the computational complexity of the disassembler you're using.

Second, more RAM and faster I/O is - almost - always a performance enhancer. If you are disassembling a +100MB binary file, you'll need all the help you can from the hardware. Therefore, having a fast SSD could reduce the I/O overhead experienced with a traditional HDD. For RAM, the larger the size the better, but keep in mind that the differences in performance between DDR, DDR2, DDR3, ECC, ... are quite substantial.

Now with regard to the CPU core count and frequency's effects on disassembly performance, it is pretty hard to evaluate. Why? Well, you must ask yourself the following set of questions :

  1. Does the disassembler you're using implement a parallel disassembly algorithm ?
  2. If yes, how does the performance of the disassembler relate/scale with the core count ? If no, then one core will suffice.

FYI, a high core frequency (each core can have a frequency domain of its own separate from his neighbor's) could lead to disastrous performance if RAM is too slow. In the industry we usually settle for a core frequency of at most 1.8x the frequency of RAM. Otherwise, some serious performance bottlenecks (bandwidth, memory access latency, ...) start to tighten up and choke the running stream of instructions.

From what I know, IDA doesn't perform any parallel disassembly - I might be wrong, always check. Therefore, the first two points you cited in your question don't really matter.

The simplest way to answer your question would be to say that : the complexity of the disassembly algorithm and the way the implementation takes advantage of the underlying hardware are the key factors for performance.

Edit :

[Bonus]

If you wish to program a parallel disassembler you can do so this way :

  1. Choose a disassembler library (Udis86 for example)
  2. Extract the sections and add them to a hashtab which contains a boolean variable - for each section - referring to its state (disassembled '1', not disassembled '0')
  3. Write a threadable function which task is to pick a section in the hashtab and disassemble it (you'll have to manage the sections order, ...). Once the task is done, update the state (you'll have to use a lock : a mutex) and pick another one if there are any left.

This might look easy to do, but in fact it is a bit challenging for that it depends on the flexibility of the disassembly library. Honestly, +100MB binaries are quite rare and commercial/available tools aren't usually designed to handle that much code/data optimally.

If you need any additional/more technical details let me know, I'll be glad to develop some points.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.