简体中文 / [English]


Reverse Engineering a University Running Check-in App for Cyber Running

 
Exploration › Reverse Engineering

This article is currently an experimental machine translation and may contain errors. If anything is unclear, please refer to the original Chinese version. I am continuously working to improve the translation.

For Android reverse engineering study only. Sensitive data has been anonymized.

Recently, a university introduced a mandatory running check-in system for students. Although the pace requirements aren’t particularly strict, one must complete 24 runs per semester, each at least 2,400 meters… which is still slightly challenging for me. So, I decided to dive into the app and see how it works.

0x00 Preliminary Observation & Information Gathering

By analyzing the package name of relevant Activities, I discovered that the running feature isn’t developed in-house by the university, but rather integrated from a third-party vendor into the school’s official app. According to the software documentation, it likely checks several factors: step frequency (via accelerometer), GPS location, pace, and device integrity.

Searching the CoolApk forum for discussions about this app, I found many users rely on Fake Location apps to spoof their runs. But that’s clearly not elegant at all—and some users reported that newer versions detect such tricks and invalidate the results. The app also includes anti-emulator detection. (Lucky for me, I’ve got a real device—no worries here~)

0x01 Packet Capture

When in doubt, start with packet capture. On newer Android versions, using Http Canary for HTTPS interception requires an Xposed module to bypass SSL pinning. Since my daily driver runs GSI-based AOSP + Magisk + LSPosed, capturing packets was a breeze. I quickly intercepted the HTTP traffic. (Irrelevant headers omitted, sensitive data replaced with *.)

1
2
3
4
5
POST /v3/api.php/Run/getTimestampV278 HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Host:  kwpb.***.edu.cn

version=927&version_name=9.0.27&mobileModel=M2104K10AC&mobileDeviceId=48f45996-d20a-45f5-b724-488bc9b1a031&mobileOsVersion=13&ostype=3&student_num=*********&token=&uid=*******&timestamp=1680081429&nonce=824310&sign=a716e5e57430cc30eef9317f1dee6dee
1
2
3
4
5
6
7
8
9
HTTP/1.1 200 OK
Content-Type: text/json; charset=utf-8

{
    "data": "LsUKkEjPvbNJr8FzUOs408n+t9DAO4o9ukqbLnuimVf6ZyJ5D2yMFUEMWe\/pfwhDZg97yywJelFcXU\/pH0bKCfVy9Z91qT8oj4dn6VL9aH92qFWqkyAlGfZXDYNN0kSAYYFaQSVeFF7T3Rxk+sgjsw==",
    "status": 1,
    "info": "",
    "is_encrypt": 1
}

Looking at the request and response, we can see the request includes timestamp, nonce, and sign. The response is obviously encrypted, so to simulate requests successfully, we first need to crack the signature and decryption mechanisms.

0x02.0 Decryption Method 1: Hook Crypto APIs to Intercept Keys

The laziest (and often most effective) way to reverse engineer encryption is to simply hook relevant APIs and extract the keys—provided standard crypto/hashing algorithms are used, and the key is either static or follows a predictable pattern (and isn’t user-specific).

While these conditions might sound strict, in practice, many apps with signing/encryption meet them, making it easy to mimic requests and decrypt responses.

You can find plenty of Frida scripts online for hooking crypto APIs, but I personally used Inspeckage, which hooks a wider range of interfaces.

Of course, many such tools don’t support the latest Android versions. A Google Pixel device is almost essential for modern reverse engineering. After setting up the environment, running the target app, and filtering ADB logs with grep, I quickly found the following critical info:

(btw. Our school’s app is such a mess—it integrates so many third-party (garbage) services… The crypto calls are all over the place. It’s like running a survival-of-the-fittest experiment on my phone.)

1
2
3
Inspeckage_Crypto:SecretKeySpec(****************,AES) , Cipher[AES/CBC/PKCS5Padding]  IV: ****************

Inspeckage_Hash:Algorithm(MD5) [mobileDeviceIdc44ba680-311d-44aa-a306-07c0d485b5f4mobileModelAOSP_on_BullHeadmobileOsVersion8.1.0nonce707812ostype3student_num*********timestamp1679995802tokenuid********version927version_name9.0.27************ : 68431b948342f6ee9352a6f680f0f869]

Clearly, AES/CBC/PKCS5Padding is used for encryption, and we now have the Key and IV—allowing us to decrypt all request/responses. The signature is generated by concatenating all HTTP parameters (sorted by key), appending a secret string, then applying MD5.

0x02.1 Decryption Method 2: Unpacking + IDA Pro

Originally, Method 1 had already achieved the goal. But since I happened to use FART, I accidentally unpacked the app… Well, since it’s done, might as well analyze the code and see if we can locate the keys directly.

Opening the unpacked DEX with jadx, I found that although the app was packed, it wasn’t obfuscated at all—so all logic and variable names were crystal clear. A quick keyword search revealed the final encryption call:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class JNIUtils {
    public static String decrypt(String str, String str2, String str3, String str4, String str5) throws NoSuchPaddingException, NoSuchAlgorithmException, InvalidAlgorithmParameterException, InvalidKeyException, BadPaddingException, IllegalBlockSizeException {
        return AESUtils.decrypt(str3 + str, str2, str4, str5);
    }

    public static String encrypt(String str, String str2, String str3, String str4, String str5) throws NoSuchPaddingException, NoSuchAlgorithmException, InvalidAlgorithmParameterException, InvalidKeyException, BadPaddingException, IllegalBlockSizeException, UnsupportedEncodingException {
        return AESUtils.encrypt(str3 + str, str2, str4, str5);
    }

    public static native String myDecrypt(String str, String str2, String str3, String str4);

    public static native String myEncrypt(String str, String str2, String str3, String str4);

    public static native String myGetAppKey(String str);

    public static native String myGetDbKey(String str);

    static {
        System.loadLibrary(StubApp.getString2(24957));
    }
}

The keys are clearly stored in native code. Extract the relevant .so file and drop it into IDA Pro.

IDA Pro Reverse EngineeringIDA Pro Reverse Engineering

No obstacles at all—immediately found the required keys. (Honestly, you might not even need to unpack—the keys could probably be found by just grepping the APK’s .so files. This JNI protection is weaker than the packer. At least the packer hides strings. 🤡)

0x03 Full Packet Analysis Workflow

Now that we’ve figured out the signing and decryption, we can write Python code to simulate requests and decrypt responses.

1
2
3
4
5
6
7
8
9
10
def sign(ret):
    str2sign = "".join(map(lambda x: str(x[0]) + str(x[1]), sorted(ret.items(), key=lambda x: x[0]))) + SIGN_KEY
    return hashlib.md5(str2sign.encode()).hexdigest()


def aes_decrypt(b64_data):
    enc = base64.b64decode(b64_data)
    cipher = AES.new(RESP_KEY, AES.MODE_CBC, RESP_IV)
    unpad = lambda s: s[:-ord(s[len(s) - 1:])]
    return unpad(cipher.decrypt(enc)).decode('utf-8')

We can now also decrypt the requests captured via Http Canary. So I took my phone, fired up Http Canary, went for a short run, and整理ed the captured traffic. It wasn’t hard to identify the full sequence of requests during a single run:

  1. /User/User — Retrieve current logged-in user info. (Login uses OAuth from the school’s main app.)

  2. /Run2/beforeRunV260 — Returns run-related constraints, such as speed, time, and location requirements.

  3. /Run/getTimestampV278 — Fetch a timestamp and a “record_str”, which is needed when ending the run.

  4. During the run, /Run/setRunLocationRecord is called every ~1–2 minutes to upload current GPS coordinates.

  5. Before ending the run, /Report/getOssSign is called to get a signature for uploading two files to Alibaba Cloud OSS.

    • One file is a screenshot of the phone screen during the run.
    • The other is an AES-encrypted JSON file containing all GPS coordinates and phone-recorded pace data, sampled every 2 seconds.

  6. Finally, using all the above (start/end time, duration, distance, URLs of uploaded files, record_str, step frequency per minute, etc.), the app calls /Run/stopRunV278 to submit the full run record to the server—completing one “legitimate” run.

0x04 Writing the Simulation Script

After mapping out the entire flow, writing a Python script to generate a plausible-looking run record and send the requests in order becomes straightforward—voilà, a successful cyber run. 😎

Running resultRunning result

This article is licensed under the CC BY-NC-SA 4.0 license.

Author: lyc8503, Article link: https://blog.lyc8503.net/en/post/nju-cyber-run/
If this article was helpful or interesting to you, consider buy me a coffee¬_¬
Feel free to comment in English below o/