I learned the disassembly challenges from this link. The following six challenges are listed in that article:Data embedded in the code regionsVariable instruction sizeIndirect branch instructionsFunctions without explicit CALL sites within the executable's code segmentPosition independent code (PIC) sequencesHand crafted assembly code.However, I am thinking about the following disassembly method which seems to solve the above challenges. Assuming we have an executable to be disassembled, an input set that can has 100% coverage of the code, and an emulator (e.g. QEMU). Then, we can instrument the emulator to output each instruction executed by the emulated CPU and the corresponding memory address. After that, we can translate each instruction to assembly instruction, and the whole program is now disassembled. Could you please tell me why this idea will not/will work?
Disassemble using an emulator
disassembly;emulation
an input set that can has 100% coverage of the codeThis may be very difficult to achieve, especially if the code behavior depends on something that you don't directly control (time, memory, OS version/environment, random number generator etc.). Additional observations:actually executing all that code may take more time than you can affordexecuting some parts of the code may require conditions you cannot satisfy (e.g. a specific hardware peripheral)you will miss code which is present in binary but never executes (dead code). In some cases such code can reveal additional information about the binaryyour approach may discover all code, but it will likely miss a lot of data.However, it does not mean that the approach is completely useless. In fact there's already been some work in this area. For example, check out the S2E (Selective Symbolic Execution) project:https://sites.google.com/site/dslabepfl/proj/s2eConceptually, S2E is an automated path explorer with modular path analyzers: the explorer drives the target system down all execution paths of interest, while analyzers check properties of each such path (e.g., to look for bugs) or simply collect information (e.g., count page faults). Desired paths can be specified in multiple ways, and one can either combine existing analyzers to build a custom analysis tool, or write new analyzers using the S2E API.S2E helps make analyses based on symbolic execution practical for large software that runs in real environments, without requiring explicit modeling of these environments.