GSoC 2022 milestone: introduce r2

[chinggg]

In my proposal for GSoC 2022, I have shown a demo to make r2 available to qiling as its "analyzer". To organize concepts like symbol and function, I even add a bin folder to represent binary layer. Users can get static analyze functionalities by using APIs like addr = ql.analyzer.addr_of("main").

But after discussion with @wtdcode, I find it more reasonable to make r2 extension independent of qiling's core. Just like the ELF class in pwntools, R2 provide direct access to function, symbol got andplt. (The last two may not exist for binary formats other than ELF). And the last three are just mappings from name to address since most time we do not care about details.

from qiling.extensions.r2 import R2

r2 = R2(ql)
ql.hook_address(callback=func, address=r2.functions['main'].addr)

# high level analysis results will be added in the future
r2.CFG()
r2.xref()

I am working on it. Feel free to make suggestions.

[wtdcode]

For new loader API, I suggest two references:

1. pwnlib

https://docs.pwntools.com/en/stable/elf/elf.html

But note this only makes sense for an ELF file, which doesn't have enough information about the image loaded in the memory.

2. qemu-usermode loader

https://github.com/qemu/qemu/blob/dcb40541ebca7ec98a14d461593b3cd7282b4fac/linux-user/qemu.h#L25

Look back to the ELF loader of QEMU usermode, it provides a better representation of image info which might be helpful.

[chinggg]

IMO, now the qiling loader seldom expose its API to user scripts. I only see some calls of QlLoaderELF and QlLoaderPE_UEFI in the examples. Since the different loaders have little in common and auto completion cannot detect the runtime type of QlLoader, it is also inconvenient to use loader API directly.

So do you want to improve current loader API with information provided by r2 or just want some refactoring without r2?