Lift to LLIL

[austin-ralls-cs]

This is currently not a priority because

1. I don't see a big use case. Smali is already pretty high-level.
2. It would be a lot of work, and I'm not positive it would be possible to lift every instruction due to Dalvik being a VM.

I've never done anything with lifting before though, so please leave a comment if you think otherwise.

[voider1]

Correct me if I'm wrong:

1. When you have native components you can lift those and your Dex to the same IL. When done right it seems it could make cross binary analysis easier (xref between Dex and native and read in the same IL?).

2. It'd be a lot of work, especially because the instructions are pretty high-level compared to Binja's IL instructions. But for the instructions which are too high-level we could take a similar approach IDA takes (IIRC) which is to introduce functions which represent a higher-level instruction instead of mapping it to a binja instruction.

One thing that's important to me (I perform Android application pentests) is that I can read the decompiled code and based on only this can write correct hooks using Frida.

[austin-ralls-cs]

That's a really interesting idea; I hadn't even though of lifting dalvik and native code to the same representation in the same view. I'm not sure how feasible it is though, because dalvik is at a higher level of abstraction than native code, and I'm not sure how well binja could handle mixing files and architectures like this.

I would be happy to take pull requests for work on a lifter; it's just not something on my priority list right now.

Thanks for the comment btw. It reminded me that I have a bunch of uncommitted documentation that I've been sitting on. I'll try to push it in a week or so.

[utkonos]

I don't know that having the native code and the DEX in the same view is the best way to go about it. There are external links that can allow for cross references between libraries, and this would make sense when implementing DEX to .so. One of the points made by the BN developers when I asked about this was: does the .so native code and the DEX share the same address space? If yes, then putting them in the same view using memory map makes sense. But if they do not share the same address space in memory, then using external links makes more sense. I am still learning btw.

https://docs.binary.ninja/guide/projects.html#external-links

https://docs.binary.ninja/guide/index.html?h=memory+map#memory-map

I am much more familiar with PE, so I'll give an example for PE that makes sense. When a PE malware sample loads a shellcode into memory allocated via VirtualAlloc, I create a segment with the same base address as my debugger session via memory map. and then map the shellcode bytes to that new segment. If I have to re-run the malware I can always rebase just that segment by editing it to match what the call to VirtualAlloc returned that time.

So, in android world, does the .so library get loaded into a segment of memory with the DEX?

[utkonos]

Please correct me if I am wrong about this: but the dex references code in a native library via Java Native Interface. It would come down to how that reference works. I have only worked on malicious DEX that does not call native code so far, so I am not familiar with JNI yet.