Analysing Flutter Applications

Reading time ~3 minutes

Intro

Having had to recently reverse an android application that was built using the flutter framework I figured this is as good a time as ever to record my thoughts now that I acheived what I wanted roughly out of exercise.

Goal(s)

The primary goal was to figure out what type of api the app was using and then extract the api out into a library so that it could be used for another automation project.

Aside from that I wanted to know if the app was possibly leaking any sensitive info.

Issues

The issues encountered below were basically encountered over the course of the project and were not really known to me up front.

The app was compiled with flutter and presented a number of issues listed below.

  • Code is compiled and executed using the dart vm when in release mode (this should be the case with a black box test).
  • The application does not use the system proxy.
  • The application does not use the user installed ca certs as it has a number of certs compiled into the app.
  • What ever java code is included is usually in kotlin (though this may not always be the case).
  • In the case of a black box app, it will likely have only been compiled with arm binaries and such cant be used in an emulator (unless you have the patience of a saint).

Initial plan of attack and subsequent updates

Initially I had planned to simply disasemble the apk, convert everything to classes and pull out the required http calls from the code. This is an approach that has worked fairly well before for me but because of the amount of compiled code this approach wasnt viable this time.

While I had the app unpacked some basic recon showed that the app was likely built with the flutter framework by google and suplemented by some native code which talked to a number of google services (firebase and a few others popped out based on their config).

It should be noted at this point that I didnt have a rooted device with which to test the application (most guides require a rooted phone to use the applications that force an apps traffic through a proxy).

With the disassembly not giving up any clear distinct api calls, I procceeded to try some dynamic analysis. This ended up being one of those sad yak shearing moments with me trying one emulator after another trying to find one that worked decently and let me run the application. In the end, this proved to be pointless as I couldnt get an arm image running and the binaries within the application was compiled for arm only and would not run within any of the emulators. I did not go down the route of using the arm avd images as they were just frustratingly slow.

What worked

After wasting a bunch of time trying to get the app analysed on an emulator I finally dug out an old android device went through the pain of rooting it and then followed the guide below.

https://hackmd.io/-kYFBsKiQleqrIyXR1eQFA?view

If you dont feel like reading the entire guide , the tldr; is to root your device, install your proxy cert as a system cert setup a gateway device on your network and then setup a transparent proxy on that gateway. In the end this actually worked and I finally managed to intercept the calls for the app. Luckily I did not have to deal with root detection in the app or I would have needed even more time to analyze it.

Conclusion, follow up research and other notes

In the end I managed to get the api calls I wanted, but this entire process felt like a pain of note. One other means of analysis that I brifly did while trying to get the app running in the vm was to pull down multiple older copies of the app to find a version that wasnt using flutter. This sort of worked and I managed to get some extra actionable intelligence about the app but it felt like another yak shearing session as the api code seems to be generated from a definition file of sorts. Translating that to useable felt like it woudl have taken too long and would have still required me to figure out the config params from the kotlin code which was driving me crazy in its decompiled form.

Thankfully though, now that this is all setup I can easily reuse the setup for further analysis.

If I get some time in the future I would like to setup a small project so that I can try and reverse the AOT compiled dart code and see if that could prove useful.

Embracing the ultra

# IntroThis past month marked the latest iteration of the 360one MTB and the culmination of months of training. In the end, it wasn't jus...… Continue reading

Cyber Apocalypse 2021 CTF

Published on April 24, 2021

Covert Login Alerting

Published on June 01, 2020