.webp)
Being a responsible adult means dealing with tasks we'd rather avoid but know are essential. From tidying up that catch-all kitchen drawer to visiting relatives during the holidays, it's part of the routine.
Similarly, in the life of a responsible software developer, there are equally crucial but often overlooked responsibilities – like testing and addressing security issues. We might understand their importance but don't always give them the attention they deserve.
Hopefully, after reading this blog post you will want to take better care of your software’s security posture!
A quick introduction to cyber security
Cyber security is a subject as broad as software development itself since every branch of software development faces different security threats. Network security, viruses, hacking, phishing, ransomware, botnets… The list goes on and on.
However, there is one systemic division pertaining to every type of cyber security work, namely the blue team, the red team, and the purple team. This basic division will help you understand what to expect from a blog post, a podcast episode, etc.
Blue team
Blue team means defensive security. Topics related to the blue team include network administration or software architecture focusing on security. I know “defensive security” sounds a lot like “security security,” but there’s good reason to make the distinction from “offensive security,” aka the red team.
Red team
Red teamers are ethical hackers, professional pentesters or social engineers. They are always the attacking side whose aim is to break through cyber security controls.
Purple team
The purple team is a creative mix of blue and red - as you might expect if you’ve ever mixed paint as a kindergartener. It’s a team taking on the role of the red and blue teams.
Writing in blue, red, and purple
A blue team article might talk about the newest security patches for Linux servers, or about the newest security patches to a popular <rte-code>npm<rte-code> library. A red team article might be a walkthrough for website pentesting, or an account of social engineering feats. The article you are currently reading is a purple team article, as we will employ offensive techniques to be better defenders.
Reverse engineering
Have you ever looked at a piece of technology and wondered how it works? If you have, that’s the first step into reverse engineering. This broad term can describe anything from taking apart your iRobot, to work done by Google’s Project Zero. By the way, Project Zero was able to analyze the functionality of a famous surveillance tool called Pegasus.
Let’s narrow down this topic to reverse engineering of mobile apps. Even working full time on creating mobile apps, they may seem inaccessible for analysis. I write my JS code, I run a command in my terminal to build the app, and I’m presented with an `apk` and `.ipa` files. These files can’t be installed directly on any phone, as apps on regular phones can be installed ONLY through the Play Store and App Store. So is it possible to reverse engineer and analyze a mobile app? It surely is!
The first step in checking how an app was built is using another app called LibChecker. Thanks to LibChecker, you will discover what languages and libraries were used to build any given app. If you were a bad guy - or in cyber security terms, a “threat actor” - you might use this knowledge to search for security vulnerabilities in this app. But you aren’t, are you? So let’s just poke around without causing any harm.
In order to actually see the files included in an app, you can use, for example APKMirror, APKCombo or APKPure. These are examples of websites where you can find `.apk` files ready for download. And what is `apk`? It’s just a fancy way of packaging and compressing files.
Once you’ve downloaded an `apk` (e.g. this apk from a very old app I created), you can change the file extension from `.apk` to `.zip` and unzip it. Voila! All the files are magically visible.
You may notice no React Native folder and no `.js` files. However, if you look inside the assets folder you should see the following:
Files named “index” look quite familiar for React and React Native devs. All right, let’s look inside:
At first sight, this looks like gibberish, but at closer inspection, you may notice familiar words, like `var` or `METRO.` This is a compressed JS file. For it to be humanly readable, we need to beautify it. There are different ways to accomplish this, one is using your IDE, and another would be to use online beautifiers.
My favorite way of inspecting this code is also the most fun way. You start by creating an HTML file where you import this `index.android.bundle` file:
<rte-code><script src="./index.android.bundle"></script> //save as index.html<rte-code>
Then open this HTML file in your browser. You will see a blank page. But if you inspect it…
…you will see beautified and readable JS code!
You are now free to look around the functions, the hooks, the context or the variables.
Other ways to get to JS code are described in detail in a Security Queens’ blog post. The author says that analyzing React Native apps built with Hermes requires using additional tools. I have used the hermes-dec tool with success and I can happily recommend it.
If you prefer to play around with iOS apps, the route is slightly bumpy, but very interesting nonetheless. A great resource to start is this GitHub repo.
There is much more digging that we can do: we could search for strings (strings like API_KEY), we could try to get to the database, and we could try to defeat authorization. For example, did you know that a misconfigured DB on Firebase can lead to some catastrophic breaches? You can learn more about it from a very interesting case study of a Donald Daters app.
Summary
I hope you feel a thrill of excitement and terror at this point. NO app is safe. Just because it takes a few more steps to look at your code than just clicking “inspect” on a website, does not mean your code is inscrutable.
What can you do about it? I’m happy you asked that question! Learning about reverse engineering gives you a good idea of what an attacker might do, so you have a bigger chance to defend your app and your users against those scary “threat actors.” I hope next time you’re working on an app, you will keep this blog post in mind. Let’s create some safe(r) apps!
