dex2jar VS MMKV

App tampering and repackaging can be performed by using reverse engineering or tampering tools, such as Apktool, dex2jar, etc.

A week ago I purchased a bluetooth device that takes some measurements. You require an Android or iOS application. The first thing the iOS app did was request permission for your location. Immediate fired up MITMproxy [1] running in transparent `--mode wireguard` and installed it's certificate in the iOS trust store. It was sending a whole bunch of data to China and HK. Since I don't have a jailbroken iPhone, it's off to Android.

For BLE scanning, Android does require permissions for location, but this application is using a Chinese branded tracking SDK and sending encrypted (within already encrypted TLS). So it's time to start reversing and instrumenting the runtime.

Well - not so easy, they used a commercial packer that encrypts their compiled bytecode and decrypts and runs it within a C++ library. I managed to bull the Dalvik out of memory using Frida[2], covert it to java bytecode with dex2jar[3] then into decompiled java with jadx [3].

Since the developer relied on the packer to hide/obfuscate their software, it's quite easy to follow. The libraries that do the location tracking on the otherhand are obfuscated so now I'm at the stage of identifying where to hook before the encrypted blobs are sent to servers in China.

I've sunk about 8 hours into this so far. The message here is that to understand what some applications on your phone does you need to really invest time and effort. The developers increase the cost to the consumer to know what their application is doing by obfuscation, encryption and packing. It's asymmetric.

[1] https://mitmproxy.org/posts/wireguard-mode/

[2] https://frida.re/docs/android/

[3] https://github.com/skylot/jadx

[3] https://github.com/pxb1988/dex2jar

I think they forgot to google translate the disadvantages of JEB Decompiler

I haven't used JEB to comment, but I've gotten a lot of mileage out of https://github.com/pxb1988/dex2jar#readme and then feed the normal Java jars it produces into https://github.com/mstrobel/procyon#readme and (of course) one shouldn't overlook picking your favorite tool for dealing with AndroidManifest.xml which often has fun things hiding in it

While digging up those links, I was reminded that some folks enjoy https://github.com/Konloch/bytecode-viewer#is-there-a-demo because it can be easier to "try out" a few of the decompilation engines, but I don't use it because it's hard to do batch things with it, versus dex2jar into procyon is automation friendly

Take a look at apktool: https://ibotpeaches.github.io/Apktool/ and dex2jar: https://github.com/pxb1988/dex2jar

react-native-mmkv is a wrapper around MMKV that allows you to easily implement secure storage in your app. It is arguably the fastest key-value storage for React Native apps

This library uses MMKV key-value storage and JSI to communicate between the JS side and the native side very quickly and synchronously. It is a suitable replacement for slow AsyncStorage. Follow this guide to migrate from AsyncStorage and get 30x faster on read and write operations in your app.

For those unfamiliar with MMKV, here's a link to their GitHub - https://github.com/Tencent/MMKV. Used in many mobile applications, such as Discord.

SWR library works great with React Native. By default, SWR library uses global cache store, but you will lose your cache when you reload your app. Here is a super-easy way to sync SWR cache with MMKV.

This library aims to provide a fast & reliable solution for you data storage needs in react-native apps. It uses MMKV by Tencent under the hood on Android and iOS both that is used by their WeChat app(more than 1 Billion users). Unlike other storage solutions for React Native, this library lets you store any kind of data type, in any number of database instances, with or without encryption in a very fast and efficient way. Read about it on this blog post I wrote on dev.to