Architectural design and research of current work

[Fare9]

For the development of an easily extendable library, it will be necessary to focus on creating an appropriate architecture. Some of the ideas for shuriken includes:

• Writing APIs for other languages (Python, Lua, Rust...), an idea could be using a shim in C from the C++ classes.
• Writing a plugin for ** and works as backend for structures like DEX or CLASS.
• Write simpler classes from the parser that also allows to rewrite the data back to a file in a proper way.

Also it would be nice to start researching current state of the art, and current work done in the area, write it as comments into this issue.

[Fare9]

In opposite to Kunai, the design of the architecture I think it must change, in Kunai the project was designed with the next architecture:

• DEX/
  • Parser/
  • Disassembler/
  • Analysis/
• APK/
  • ...
• MjolnIR/
  • IR/
  • Lifter/

Shuriken should follow another architecture design following the advice from @robert-yates , that I think it will make the tool easier to modify and easier to scale and include new formats.

• Parsers/
  • Dex/
  • Class/
• Disassemblers/
  • Dex/
  • Class/
• Analyses/
  • Dex
  • Class/
• MjolnIR/
• Lifters/
  • Dalvik/
  • Class/

[Fare9]

For the Smali/Baksmali code, we will better follow the next repo: https://github.com/google/smali, which is a maintained fork of the original tool. A good idea would be to understand the instructions format and generate the instructions according to the format.