The Crime Lab — ALEAPP Mobile Forensics Walkthrough
Scenario:
We’re investigating a murder where the victim’s Android phone was recovered. Witnesses reported he was heavily into trading, in debt, and traveled before his death. Our goal was to parse the phone’s artifacts with ALEAPP, reconstruct events, and answer six key investigative questions.
Step 1 — Evidence Intake & Hashing
We created Evidence and Reports directories to structure the case. The original 138-The-Crime.zip was hashed with PowerShell (Get-FileHash -Algorithm SHA256) and logged into hashes.txt.
Hashing locks the evidence in time, ensuring chain-of-custody. If altered, the hash changes which would make tampering obvious. Separating Evidence and Reports keeps working data isolated. This is a fundamental step in any forensic examination.
Step 2 — Extracting Evidence
Using WinRAR, we extracted 138-The-Crime.zip into Evidence\138-The-Crime\. This gave ALEAPP access to /data and /system.
Extraction creates a safe copy to work from while preserving the original archive. This ensures parsing doesn’t alter intake files. Proper extraction provides a stable base for parsing and preserves evidence integrity.
Step 3 — Installing ALEAPP CLI
We cloned ALEAPP, created a Python virtual environment, installed dependencies, and verified with python aleapp.py -h.
A virtual environment keeps dependencies isolated for reproducibility. Testing with the -h flag confirmed readiness. This ensured our forensic toolchain was validated before parsing evidence.
Step 4 — Parsing the Android Dump
We ran ALEAPP with:
python aleapp.py -t fs -i "...\Evidence\138-The-Crime" -o "...\Reports"ALEAPP produced index.html and artifacts.sqlite.
What we just did was run ALEAPP in CLI mode against the extracted Android evidence. By using -t fs, we told ALEAPP to treat the input as a raw folder structure instead of a compressed archive. The -i flag pointed directly to our extracted 138-The-Crime dump, while the -o flag gave ALEAPP a safe output location under our Reports folder, keeping evidence and results separate. This separation is critical for chain-of-custody, since we never alter the original evidence — we only read from it. Running the CLI ensures our process is easily repeatable, since the exact command can be logged or rerun by another examiner for verification. The benefit of this workflow is that ALEAPP parsed dozens of SQLite databases and XMLs in seconds, producing a consolidated HTML dashboard (report.html) and a master SQLite file, so all of the victim’s apps, messages, and movements are now organized and searchable. With this report, we can now confidently start answering our investigation questions one by one.
Investigative Questions
Q1 — Based on the accounts of the witnesses, the victim was interested in trading. Can you identify the SHA256 of the trading application the victim primarily used on his phone?
ALEAPP > Installed Apps (GMS) listed Olymp Trade.
Answer (Q1): 4F168A772350F283A1C49E78C1548D7C2C6C05106D8B9FEB825FDC3466E9DF3C
Identifying Olymp Trade validated witness accounts. Hashing gave a binary-level fingerprint, proving the app version installed. This ties subjective testimony to objective cryptographic evidence.
Q2 — According to the victim’s best friend, he avoided calls from someone he owed money. How much does the victim owe this person?
- ALEAPP > SMS/MMS Messages > searched “owe.”
- Message revealed: “I owe you 250000 …”
Answer (Q2): 250000
The SMS artifact directly provided the numeric debt amount. This matched testimony and provided hard proof of financial stress. ALEAPP’s parsed interface made keyword searching straightforward.
Q3 — What is the name of the person to whom the victim owes money?
- Call Logs > repeated calls from
+201172137258. - Contacts (GMS) > mapped to Shady Wahab.
Answer (Q3): Shady Wahab
Correlating logs to contacts resolved a number to a person. This transforms raw metadata into an attributable actor. It reinforced Shady Wahab’s role as the financial connection.
Q4 — On September 20, 2023, the victim left home without saying where he was going. Where was he located at that time?
- Google Location History > Semantic > entry: The Nile Ritz-Carlton, Cairo.
- Image Cache photos confirmed via reverse search.
Answer (Q4): The Nile Ritz-Carlton
Semantic logs and cached images gave corroborating proof of location. This aligns digital traces with family testimony. Using two artifact types strengthens defensibility.
Q5 — After speaking to hotel staff, investigators learned the victim had booked a flight. Where was he intending to travel?
- Emulated Storage Metadata > Files >
Plane Ticket.png. - Ticket details + context > Las Vegas.
Answer (Q5): Las Vegas
Metadata revealed a saved ticket proving travel intent. This filled the gap where Wallet/Passes wasn’t parsed. Cross-referencing with Discord confirmed Las Vegas as destination.
Q6 — After examining Discord conversations, can you determine where the victim planned to meet his friend?
- Discord Chats → conversation mentioned The Mob Museum.
- This tied directly to Las Vegas travel.
Answer (Q6): The Mob Museum
Discord gave the final link, showing intent to meet at a specific venue. This validated the travel evidence and completed the timeline. Such chats show clear human intent.
Final Narrative
Our forensic analysis reconstructed the victim’s timeline. He was using Olymp Trade (SHA256 confirmed), owed 250000 to Shady Wahab, and avoided repeated calls. On Sept 20, 2023, he stayed at The Nile Ritz-Carlton, Cairo, then saved a ticket bound for Las Vegas. Discord confirmed he planned to meet at The Mob Museum there.
By parsing and correlating multiple artifacts, we built a defensible, timeline-driven narrative connecting financial motive, travel, and planned social contacts.
