BotConf 2026 Android Workshop: A Practical Android Malware Analysis Playbook

Overview

The BotConf 2026 Android workshop was not a bag of random “look how clever this sample is” tricks. It was a workflow: learn how the APK is put together, figure out where the malware is hiding, watch what it does at runtime, and then automate the boring rabbit chase once the pattern starts repeating.

That progression matters. A lot of Android reversing goes sideways because the analyst dives straight into strings or decompilation and never gets the bigger picture. This workshop does the opposite and treats the whole stack as layered:

• foundations and APK structure
• advanced static reverse engineering
• dynamic analysis and instrumentation
• native libraries and JNI
• automation and batch processing

The result is a practical method that works on real samples, not just clean demo APKs that behave nicely for the slides.

From APKs To Analysis Targets

The early modules start with the unglamorous truth: an APK is basically a ZIP archive with expectations, rules, and a long memory. That sounds boring until malformed entries start breaking tools in interesting ways.

Once you understand local file headers, the central directory, compression methods, and why malformed archives matter, the APK stops being a sealed box. Corruption becomes a hint. Packing becomes suspicious. Weird ZIP metadata starts looking like a breadcrumb trail.

The workshop also spends time on droppers and delivery. You are figuring out how the payload gets staged, how the sample dodges analysis, and where the real code path hides until the right conditions show up.

Static Analysis Is About Structure, Not Guessing

The static-analysis section is really about turning a messy artifact into something a human can read without needing three coffees and a miracle.

The slide material pushes the usual workflow:

• find the entry point
• identify obfuscation layers
• recover strings and constants
• trace control flow
• rename aggressively so the code becomes navigable

That is the difference between staring at bytecode and actually reversing malware. Once the names and structures are fixed, the sample stops looking like a wall of method soup and starts looking like a plan.

One of the useful recurring themes is that obfuscation is usually repetitive. String fogging, packed resources, mangled class names, and corrupted APK metadata are annoying, but they are also mechanical. Once you spot the pattern, you can make a script do the work for you.

Dynamic Analysis Fills The Gaps

Static analysis tells you what the sample could do. Dynamic analysis tells you what it actually does when nobody is watching too closely.

The workshop slides spend time on realistic lab setup, emulator and sandbox detection, timing checks, root detection, and anti-debugging. That part matters because malware almost never behaves honestly in a hostile environment. If you do not account for emulation checks, the sample may never show the good stuff.

The practical message is simple: dynamic analysis is not just clicking through an app until something interesting happens. It is about watching when the sample changes state, what it reads, which files it touches, and what network activity is gated behind specific conditions.

That is also where hooking becomes useful. Once the sample starts hiding behavior behind API calls, instrumentation lets you watch values move through the app instead of trying to infer the whole story from the smoke.

Native Code Changes The Game

A lot of Android malware hides meaningful logic in native libraries. The workshop treats that as a separate skill track, not a weird footnote nobody wants to read.

The core lessons are practical:

• import JNI types early so exported methods are readable
• identify the Java-to-native boundary
• use strings and stack traces to recover configuration quickly
• expect crypto, packing, and anti-analysis logic to live in .so files

That is a major shift in workflow. Once the sample crosses into native code, Java decompilers are no longer enough. You need an assembly-aware mindset and the patience to reconstruct intent from JNI exports, stack strings, and runtime behavior.

Automation Is Where The Workflow Pays Off

The final module is the most honest one: once you have done the same analysis steps enough times, you should stop pretending that repetition is a personality trait and automate them.

The slides on automation focus on the repetitive work that slows analysts down:

• resolving strings in bulk
• tagging samples consistently
• extracting configuration at scale
• validating results against a known corpus
• keeping the pipeline testable

That is the right end state. Malware analysis should not stay artisanal forever. If a sample family uses the same obfuscation scheme across dozens of binaries, you want one script, one harness, and one test suite keeping the whole thing honest.

How The Workshop Maps To The Challenge Writeups

The CTF challenges from the workshop fit neatly into this framework.

The Mole is a good example of what happens when network analysis, dynamic observation, and decompiled logic all point at the same control flow. You recover a session cookie from traffic, confirm the heartbeat behavior, and then tie it back to the decompiled APK. That is the kind of rabbit trail worth following.

Pizzeria shows the same workshop logic applied to a different kind of target: instead of malware strings or packed binaries, the key signal is agent behavior. The reconstruction still follows the same pattern: identify the entry point, confirm the actual request shape, and then use the decompiled logic or scripts to reproduce the attack precisely.

That is what makes the workshop useful. The exact sample changes, but the method stays stable.

Takeaways

The strongest part of the workshop is that it treats Android malware analysis as a process rather than a pile of tools someone threw into a slide deck and hoped would become wisdom.

The recurring ideas are the ones worth keeping:

• start with structure before interpretation
• expect obfuscation and make it mechanical when possible
• validate static assumptions with runtime observation
• treat native code as a first-class reversing target
• automate the boring parts once the pattern is clear

If you work through Android samples regularly, that workflow matters more than any single trick. Tricks are fine. Processes are what keep you from chasing your tail for six hours while the sample quietly laughs in ARM64.