Mobile App Assessment

MobSF, the Mobile Security Framework, takes an Android or iOS package you are allowed to assess and produces a first report: permissions, exported components, trackers, certificate details, and strings that look sensitive. Treat that report as a lead list. It is automated and it is incomplete. It does not prove a business-logic flaw, and a scary permission is not automatically a finding if the app needs it and the platform gates it.

Apktool unpacks an Android package into resources and smali so you can read the manifest, the component declarations, and string resources in the form the package actually shipped. You use it when you need the structure: which activities exist, which are exported, what the app says in its own resource files. This lesson stops at reading. Rebuilding and re-signing a package is a separate, explicit lab decision and is not taught here.

JADX decompiles Android bytecode into Java-like source so you can read how the app calls its API, how it stores data, and how it decides what to show. It is the tool you open when MobSF hands you a class name and you need to understand the branch. Decompiler output is an aid. It can be wrong at the edges. You confirm important behavior against what the running practice app does, later, on a device or emulator you control.

Frida is a dynamic instrumentation toolkit. In a mobile lab it attaches to a process on a device or emulator you administer so you can observe which functions run and what the app checks while you use it normally. That is a reading tool in this curriculum. Observation is not the same as a bypass, and this module does not include scripts, hook lists, or steps that disable a control.

Objection is a higher-level console on top of Frida for exploring a mobile process without writing instrumentation from scratch. Same boundary: it is in the catalog so you know the name and the job (interactive runtime exploration on an authorized test build). The tool page may mention workflows you will see in the wider industry. The lesson path here does not repeat them and does not add commands.

A proxy such as Burp or ZAP still matters. Much of a mobile API is ordinary HTTP. Runtime instrumentation is for behavior you cannot see in the traffic alone, such as how the app handles its own checks. If the practice app's documentation tells you how to trust your lab proxy's certificate, follow that practice-app documentation. Do not invent a general bypass.

You assess a build the owner gave you, or an intentionally vulnerable app whose license invites practice. You do not pull a bank's production app from a store and start unpacking it for sport. Store listings are not authorization. Employer apps are not yours because you installed them on a phone the employer issued, unless security testing is in your written brief.

Devices and emulators used for instrumentation are lab devices. Keep personal accounts off them. Snapshot or factory-reset when the lab ends. A rooted or jailbroken test device is a lab choice with extra risk; do not use it for everyday mail and banking.

Report language names the control gap: sensitive data in an insecure local store, an exported component with no permission, an API that trusts the app to hide a function. The fix is the platform control or the server-side check. A transcript of a tool session is an appendix at most.

Fair practice apps include the OWASP MASTG crackmes and the apps those guides name for training, plus well-known teaching packages such as DIVA (Damn Insecure and Vulnerable App), InsecureBankv2, and InjuredAndroid. Their authors published them so students can study weak designs. Read each project's license and warnings. Run them on an emulator or a spare device, off your everyday network profile.

A client's test build is the other fair target, when the statement of work names that build, those test accounts, and that window. Production store binaries of companies you do not have a contract with are not on this list, even if the download is public.

Before you install anything, write the lab rules the way Module 1 taught you: what you will install, where it will run, what you will not connect it to, and how you will wipe the emulator when you are done.

Start with MobSF on the practice package. Read the permission list, the component list, and the strings it flagged. Write three questions, not three exploits. Example questions: where does this app keep a session, which component is exported, which host does it call.

Open the same package in JADX and answer those questions by reading. When the decompiler is confusing, use Apktool's unpacked manifest and resources to confirm component names and strings. You are building a map: entry points, storage, and network hosts.

Install the practice app on an emulator you control. Use it as a user. If the project documents a lab proxy, follow that document so you can see the app's own tutorial traffic. Note what the server, not the user interface, appears to decide. Many teaching apps fail object-level checks or store data carelessly on purpose. Your note should say which control is missing.

Only after the map exists should Frida or Objection come out, and only on that emulator, to observe a behavior you could not settle by reading. Stop when the question is answered. This course does not provide instrumentation scripts. If you later study them from the tool's own documentation, do it against the practice app, in private notes, not as material you paste into a client deliverable.

Write one finding in the same shape as the reporting module: title, what the practice app does, why that would matter in a real product, and the fix. Fixes you should be ready to say out loud include server-side authorization, platform-secure storage instead of a world-readable file, certificate validation left intact, and exported components that are not exported.

Reset the emulator or restore a clean snapshot. Remove the package from your notes archive if the client build was not yours to keep. Teaching apps can stay if the license allows.

If you want a grade for yourself, explain the sequence to someone else without showing a tool transcript: why MobSF came first, what JADX added, why runtime was last, and what you refused to do.