cea-sec / miasm

Reverse engineering framework in Python
https://miasm.re/
GNU General Public License v2.0
3.47k stars 474 forks source link

Relative symbols in disassembly listing #344

Open commial opened 8 years ago

commial commented 8 years ago

This issue continues the debate of #343 .

From the current state, a few steps are needed before applying the described solution:

  1. move dis_bloc and dis_bloc_all into disasmEngine, and remove their use outside of disasmEngine (as in jitter...)
  2. add wrapper in Containerto its internal bin_stream
  3. modify disasmEngine and their caller to always use Container, and no more pool_bin, symbol_pool, ...
  4. add a method in Container to gen a label from its symbol_pool, and use it in dis_bloc

Once these steps are done, we can override the gen label method in ContainerELF to use symbols and relative symbols. In addition, once these work done, we also can introduce a ContainerIDA mapping symbols to the one of IDA, arch to the IDA architecture, ...

Junraa commented 8 years ago

Hi,

If we use Container as a wrapper over disasmEngine, we could just use disasmEngine.symbol_pool as Container's symbol_pool. That would look like this:

def __init__(....):
        .....
        self.disasmEngine = Machine(self.arch).dis_engine(self.bin_stream)

and then:

@property
def symbol_pool(self):
        "asm_symbol_pool instance preloaded with container and disasmEngine symbols (if any)"
        return self.disasmEngine.symbol_pool.

Container could also have a dis_multibloc function that only call dis_multibloc from its disasmEngine, resolve addresses if asked, and then return disassembled blocks.

I have started to think about it (see my fork), but as I am relatively new on miasm, I'm trying to figure all the side effects that could bring.

commial commented 8 years ago

Well, following this thinking, we may end with a Container wrapping all API like a "catch all" object, which seems a bad implication for the maintainability and the usability of the code. I prefer having different classes doing one thing, and doing it well (or at least, trying to do it well).

We are currently testing a few other way of doing, such as instantiating a crafted symbol_pool from Container and using it instead of wrapping symbol_pool API in Container; and the opposite way, that is to say replacing all symbol_pool uses by call on Container...

So, to be continued :smile: