Exporting dex metadata, external or integrated in apktool?

[nitanmarcel]

While working on a LSP server I've hit a blocking point, that being type checking where I had 2 options, manually get them from the generated .smali files or generate them directly from dex which is easier and effective. Now I've created a fork that does this using apktool but I came to the conclusion that might burden the tool with something which I don't think has many other use-cases.

I have a separate tool too but I thought I should still ask if this has some place in apktool before reinventing the wheel myself.

What do you think?

[iBotPeaches]

How much do you think the Apktool change supports others without these other components you probably have that wire it all together?

[nitanmarcel]

Looking at the smali source code, specifically at writer/pool, it internally exposes a lot about the dex files that could be use for reverse engineering tools. One real-life example where this could be useful would be radare2, which could use the metadata for visual disassembly, having access to cross-references and only have to handle method body extraction.

There is already a PoC based on jadx but it could take advantage of this to also modify the small code, since jadx is made only for analysis and can't produce re-usable builds.

So far this is the only real life example, excluding my work, which could make use of these exposed things.

To summarize, the flow would be, apktool extracts information about the decompiled apk, others will just have to parse those informations without having to write everything together using an parser or ast

[nitanmarcel]

An small update. While useful it does not seem optimal in the long run since the metadata gets pretty big. Big enough that you either have to heavily split everything in a directory or export them in a format that's fast enough. Definitely not yaml or json 🤔