There is also no reference to external functions (either libc or other libraries), and there is no syscall that directly calls the kernel (like Go). All of them are unnamed, and there are no string references that you can find. If you use other tools, such as binary ninja which will try to do some linear sweep, you can see a lot of methods. It’s just native code, right? If you use IDA, initially, you will only see this bunch of bytes.
#Codejunkies gotcha code
You may wonder: what actually happens if you try to open a libapp.so (Dart code that is AOT compiled) using a standard disassembler. The main code consists of two libraries libflutter.so (the flutter engine) and libapp.so (your code).
#Codejunkies gotcha android
In this post, I will only give examples for the Android platform, but everything written here is generic and applicable to other platforms. The app that I just tested uses an extra layer of encryption on top of HTTPS, and that’s the reason that I need to do actual reverse engineering. If the app is very simple and uses a simple HTTPS connection, you can test all the functionalities using intercepting proxies such as Burp or Zed Attack Proxy. If you are extremely lucky, which is what happened to me the first time I needed to test a Flutter App: you don’t even need to reverse engineer the app. As of now, if you are lucky, you can dump the classes and method names of a flutter app using darter or Doldrums if the app was built with a specific version of Flutter SDK. It is not easy to reverse engineer a release version of a flutter app because the tooling is not available and the flutter engine itself changes rapidly.