mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Add content from: ELEGANTBOUNCER: When You Can't Get the Samples but Still Nee...
This commit is contained in:
parent
2c09db2658
commit
c01eee5608
@ -41,6 +41,7 @@
|
||||
- [Anti-Forensic Techniques](generic-methodologies-and-resources/basic-forensic-methodology/anti-forensic-techniques.md)
|
||||
- [Docker Forensics](generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.md)
|
||||
- [Image Acquisition & Mount](generic-methodologies-and-resources/basic-forensic-methodology/image-acquisition-and-mount.md)
|
||||
- [Ios Backup Forensics](generic-methodologies-and-resources/basic-forensic-methodology/ios-backup-forensics.md)
|
||||
- [Linux Forensics](generic-methodologies-and-resources/basic-forensic-methodology/linux-forensics.md)
|
||||
- [Malware Analysis](generic-methodologies-and-resources/basic-forensic-methodology/malware-analysis.md)
|
||||
- [Memory dump analysis](generic-methodologies-and-resources/basic-forensic-methodology/memory-dump-analysis/README.md)
|
||||
@ -61,6 +62,7 @@
|
||||
- [Office file analysis](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/office-file-analysis.md)
|
||||
- [PDF File analysis](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/pdf-file-analysis.md)
|
||||
- [PNG tricks](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/png-tricks.md)
|
||||
- [Structural File Format Exploit Detection](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/structural-file-format-exploit-detection.md)
|
||||
- [Video and Audio file analysis](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/video-and-audio-file-analysis.md)
|
||||
- [ZIPs tricks](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/zips-tricks.md)
|
||||
- [Windows Artifacts](generic-methodologies-and-resources/basic-forensic-methodology/windows-forensics/README.md)
|
||||
|
@ -23,6 +23,33 @@ malware-analysis.md
|
||||
if you are given a **forensic image** of a device you can start **analyzing the partitions, file-system** used and **recovering** potentially **interesting files** (even deleted ones). Learn how in:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
partitions-file-systems-carving/
|
||||
{{#endref}}# Basic Forensic Methodology
|
||||
|
||||
|
||||
|
||||
## Creating and Mounting an Image
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../generic-methodologies-and-resources/basic-forensic-methodology/image-acquisition-and-mount.md
|
||||
{{#endref}}
|
||||
|
||||
## Malware Analysis
|
||||
|
||||
This **isn't necessary the first step to perform once you have the image**. But you can use this malware analysis techniques independently if you have a file, a file-system image, memory image, pcap... so it's good to **keep these actions in mind**:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
malware-analysis.md
|
||||
{{#endref}}
|
||||
|
||||
## Inspecting an Image
|
||||
|
||||
if you are given a **forensic image** of a device you can start **analyzing the partitions, file-system** used and **recovering** potentially **interesting files** (even deleted ones). Learn how in:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
partitions-file-systems-carving/
|
||||
{{#endref}}
|
||||
@ -44,6 +71,60 @@ linux-forensics.md
|
||||
docker-forensics.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ios-backup-forensics.md
|
||||
{{#endref}}
|
||||
|
||||
## Deep inspection of specific file-types and Software
|
||||
|
||||
If you have very **suspicious** **file**, then **depending on the file-type and software** that created it several **tricks** may be useful.\
|
||||
Read the following page to learn some interesting tricks:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
specific-software-file-type-tricks/
|
||||
{{#endref}}
|
||||
|
||||
I want to do a special mention to the page:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
specific-software-file-type-tricks/browser-artifacts.md
|
||||
{{#endref}}
|
||||
|
||||
## Memory Dump Inspection
|
||||
|
||||
|
||||
{{#ref}}
|
||||
memory-dump-analysis/
|
||||
{{#endref}}
|
||||
|
||||
## Pcap Inspection
|
||||
|
||||
|
||||
{{#ref}}
|
||||
pcap-inspection/
|
||||
{{#endref}}
|
||||
|
||||
## **Anti-Forensic Techniques**
|
||||
|
||||
Keep in mind the possible use of anti-forensic techniques:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
anti-forensic-techniques.md
|
||||
{{#endref}}
|
||||
|
||||
## Threat Hunting
|
||||
|
||||
|
||||
{{#ref}}
|
||||
file-integrity-monitoring.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
## Deep inspection of specific file-types and Software
|
||||
|
||||
If you have very **suspicious** **file**, then **depending on the file-type and software** that created it several **tricks** may be useful.\
|
||||
@ -93,4 +174,3 @@ file-integrity-monitoring.md
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
@ -0,0 +1,132 @@
|
||||
# iOS Backup Forensics (Messaging‑centric triage)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
This page describes practical steps to reconstruct and analyze iOS backups for signs of 0‑click exploit delivery via messaging app attachments. It focuses on turning Apple’s hashed backup layout into human‑readable paths, then enumerating and scanning attachments across common apps.
|
||||
|
||||
Goals:
|
||||
- Rebuild readable paths from Manifest.db
|
||||
- Enumerate messaging databases (iMessage, WhatsApp, Signal, Telegram, Viber)
|
||||
- Resolve attachment paths, extract embedded objects (PDF/Images/Fonts), and feed them to structural detectors
|
||||
|
||||
|
||||
## Reconstructing an iOS backup
|
||||
|
||||
Backups stored under MobileSync use hashed filenames that are not human‑readable. The Manifest.db SQLite database maps each stored object to its logical path.
|
||||
|
||||
High‑level procedure:
|
||||
1) Open Manifest.db and read the file records (domain, relativePath, flags, fileID/hash)
|
||||
2) Recreate the original folder hierarchy based on domain + relativePath
|
||||
3) Copy or hardlink each stored object to its reconstructed path
|
||||
|
||||
Example workflow with a tool that implements this end‑to‑end (ElegantBouncer):
|
||||
|
||||
```bash
|
||||
# Rebuild the backup into a readable folder tree
|
||||
$ elegant-bouncer --ios-extract /path/to/backup --output /tmp/reconstructed
|
||||
[+] Reading Manifest.db ...
|
||||
✓ iOS backup extraction completed successfully!
|
||||
```
|
||||
|
||||
Notes:
|
||||
- Handle encrypted backups by supplying the backup password to your extractor
|
||||
- Preserve original timestamps/ACLs when possible for evidentiary value
|
||||
|
||||
|
||||
## Messaging app attachment enumeration
|
||||
|
||||
After reconstruction, enumerate attachments for popular apps. The exact schema varies by app/version, but the approach is similar: query the messaging database, join messages to attachments, and resolve paths on disk.
|
||||
|
||||
### iMessage (sms.db)
|
||||
Key tables: message, attachment, message_attachment_join (MAJ), chat, chat_message_join (CMJ)
|
||||
|
||||
Example queries:
|
||||
|
||||
```sql
|
||||
-- List attachments with basic message linkage
|
||||
SELECT
|
||||
m.ROWID AS message_rowid,
|
||||
a.ROWID AS attachment_rowid,
|
||||
a.filename AS attachment_path,
|
||||
m.handle_id,
|
||||
m.date,
|
||||
m.is_from_me
|
||||
FROM message m
|
||||
JOIN message_attachment_join maj ON maj.message_id = m.ROWID
|
||||
JOIN attachment a ON a.ROWID = maj.attachment_id
|
||||
ORDER BY m.date DESC;
|
||||
|
||||
-- Include chat names via chat_message_join
|
||||
SELECT
|
||||
c.display_name,
|
||||
a.filename AS attachment_path,
|
||||
m.date
|
||||
FROM chat c
|
||||
JOIN chat_message_join cmj ON cmj.chat_id = c.ROWID
|
||||
JOIN message m ON m.ROWID = cmj.message_id
|
||||
JOIN message_attachment_join maj ON maj.message_id = m.ROWID
|
||||
JOIN attachment a ON a.ROWID = maj.attachment_id
|
||||
ORDER BY m.date DESC;
|
||||
```
|
||||
|
||||
Attachment paths may be absolute or relative to the reconstructed tree under Library/SMS/Attachments/.
|
||||
|
||||
### WhatsApp (ChatStorage.sqlite)
|
||||
Common linkage: message table ↔ media/attachment table (naming varies by version). Query media rows to obtain on‑disk paths.
|
||||
|
||||
Example (generic):
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
m.Z_PK AS message_pk,
|
||||
mi.ZMEDIALOCALPATH AS media_path,
|
||||
m.ZMESSAGEDATE AS message_date
|
||||
FROM ZWAMESSAGE m
|
||||
LEFT JOIN ZWAMEDIAITEM mi ON mi.ZMESSAGE = m.Z_PK
|
||||
WHERE mi.ZMEDIALOCALPATH IS NOT NULL
|
||||
ORDER BY m.ZMESSAGEDATE DESC;
|
||||
```
|
||||
|
||||
Adjust table/column names to your app version (ZWAMESSAGE/ZWAMEDIAITEM are common in iOS builds).
|
||||
|
||||
### Signal / Telegram / Viber
|
||||
- Signal: the message DB is encrypted; however, attachments cached on disk (and thumbnails) are usually scan‑able
|
||||
- Telegram: inspect cache directories (photo/video/document caches) and map to chats when possible
|
||||
- Viber: Viber.sqlite contains message/attachment tables with on‑disk references
|
||||
|
||||
Tip: even when metadata is encrypted, scanning the media/cache directories still surfaces malicious objects.
|
||||
|
||||
|
||||
## Scanning attachments for structural exploits
|
||||
|
||||
Once you have attachment paths, feed them into structural detectors that validate file‑format invariants instead of signatures. Example with ElegantBouncer:
|
||||
|
||||
```bash
|
||||
# Recursively scan only messaging attachments under the reconstructed tree
|
||||
$ elegant-bouncer --scan --messaging /tmp/reconstructed
|
||||
[+] Found N messaging app attachments to scan
|
||||
✗ THREAT in WhatsApp chat 'John Doe': suspicious_document.pdf → FORCEDENTRY (JBIG2)
|
||||
✗ THREAT in iMessage: photo.webp → BLASTPASS (VP8L)
|
||||
```
|
||||
|
||||
Detections covered by structural rules include:
|
||||
- PDF/JBIG2 FORCEDENTRY (CVE‑2021‑30860): impossible JBIG2 dictionary states
|
||||
- WebP/VP8L BLASTPASS (CVE‑2023‑4863): oversized Huffman table constructions
|
||||
- TrueType TRIANGULATION (CVE‑2023‑41990): undocumented bytecode opcodes
|
||||
- DNG/TIFF CVE‑2025‑43300: metadata vs. stream component mismatches
|
||||
|
||||
|
||||
## Validation, caveats, and false positives
|
||||
|
||||
- Time conversions: iMessage stores dates in Apple epochs/units on some versions; convert appropriately during reporting
|
||||
- Schema drift: app SQLite schemas change over time; confirm table/column names per device build
|
||||
- Recursive extraction: PDFs may embed JBIG2 streams and fonts; extract and scan inner objects
|
||||
- False positives: structural heuristics are conservative but can flag rare malformed yet benign media
|
||||
|
||||
|
||||
## References
|
||||
|
||||
- [ELEGANTBOUNCER: When You Can't Get the Samples but Still Need to Catch the Threat](https://www.msuiche.com/posts/elegantbouncer-when-you-cant-get-the-samples-but-still-need-to-catch-the-threat/)
|
||||
- [ElegantBouncer project (GitHub)](https://github.com/msuiche/elegant-bouncer)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
@ -35,6 +35,11 @@ pdf-file-analysis.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
{{#ref}}
|
||||
structural-file-format-exploit-detection.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
{{#ref}}
|
||||
png-tricks.md
|
||||
{{#endref}}
|
||||
@ -50,5 +55,3 @@ zips-tricks.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
@ -0,0 +1,183 @@
|
||||
# Structural File‑Format Exploit Detection (0‑Click Chains)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
This page summarizes practical techniques to detect 0‑click mobile exploit files by validating structural invariants of their formats instead of relying on byte signatures. The approach generalizes across samples, polymorphic variants, and future exploits that abuse the same parser logic.
|
||||
|
||||
Key idea: encode structural impossibilities and cross‑field inconsistencies that only appear when a vulnerable decoder/parser state is reached.
|
||||
|
||||
See also:
|
||||
|
||||
{{#ref}}
|
||||
pdf-file-analysis.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
## Why structure, not signatures
|
||||
|
||||
When weaponized samples are unavailable and payload bytes mutate, traditional IOC/YARA patterns fail. Structural detection inspects the container’s declared layout versus what is mathematically or semantically possible for the format implementation.
|
||||
|
||||
Typical checks:
|
||||
- Validate table sizes and bounds derived from the spec and safe implementations
|
||||
- Flag illegal/undocumented opcodes or state transitions in embedded bytecode
|
||||
- Cross‑check metadata VS actual encoded stream components
|
||||
- Detect contradictory fields that indicate parser confusion or integer overflow set‑ups
|
||||
|
||||
Below are concrete, field‑tested patterns for multiple high‑impact chains.
|
||||
|
||||
---
|
||||
|
||||
## PDF/JBIG2 – FORCEDENTRY (CVE‑2021‑30860)
|
||||
|
||||
Target: JBIG2 symbol dictionaries embedded inside PDFs (often used in mobile MMS parsing).
|
||||
|
||||
Structural signals:
|
||||
- Contradictory dictionary state that cannot occur in benign content but is required to trigger the overflow in arithmetic decoding.
|
||||
- Suspicious use of global segments combined with abnormal symbol counts during refinement coding.
|
||||
|
||||
Pseudo‑logic:
|
||||
|
||||
```pseudo
|
||||
# Detecting impossible dictionary state used by FORCEDENTRY
|
||||
if input_symbols_count == 0 and (ex_syms > 0 and ex_syms < 4):
|
||||
mark_malicious("JBIG2 impossible symbol dictionary state")
|
||||
```
|
||||
|
||||
Practical triage:
|
||||
- Identify and extract JBIG2 streams from the PDF
|
||||
- pdfid/pdf-parser/peepdf to locate and dump streams
|
||||
- Verify arithmetic coding flags and symbol dictionary parameters against the JBIG2 spec
|
||||
|
||||
Notes:
|
||||
- Works without embedded payload signatures
|
||||
- Low FP in practice because the flagged state is mathematically inconsistent
|
||||
|
||||
---
|
||||
|
||||
## WebP/VP8L – BLASTPASS (CVE‑2023‑4863)
|
||||
|
||||
Target: WebP lossless (VP8L) Huffman prefix‑code tables.
|
||||
|
||||
Structural signals:
|
||||
- Total size of constructed Huffman tables exceeds the safe upper bound expected by the reference/patched implementations, implying the overflow precondition.
|
||||
|
||||
Pseudo‑logic:
|
||||
|
||||
```pseudo
|
||||
# Detect malformed Huffman table construction triggering overflow
|
||||
let total_size = sum(table_sizes)
|
||||
if total_size > 2954: # example bound: FIXED_TABLE_SIZE + MAX_TABLE_SIZE
|
||||
mark_malicious("VP8L oversized Huffman tables")
|
||||
```
|
||||
|
||||
Practical triage:
|
||||
- Check WebP container chunks: VP8X + VP8L
|
||||
- Parse VP8L prefix codes and compute actual allocated table sizes
|
||||
|
||||
Notes:
|
||||
- Robust against byte‑level polymorphism of the payload
|
||||
- Bound is derived from upstream limits/patch analysis
|
||||
|
||||
---
|
||||
|
||||
## TrueType – TRIANGULATION (CVE‑2023‑41990)
|
||||
|
||||
Target: TrueType bytecode inside fpgm/prep/glyf programs.
|
||||
|
||||
Structural signals:
|
||||
- Presence of undocumented/forbidden opcodes in Apple’s interpreter used by the exploit chain.
|
||||
|
||||
Pseudo‑logic:
|
||||
|
||||
```pseudo
|
||||
# Flag undocumented TrueType opcodes leveraged by TRIANGULATION
|
||||
switch opcode:
|
||||
case 0x8F, 0x90:
|
||||
mark_malicious("Undocumented TrueType bytecode")
|
||||
default:
|
||||
continue
|
||||
```
|
||||
|
||||
Practical triage:
|
||||
- Dump font tables (e.g., using fontTools/ttx) and scan fpgm/prep/glyf programs
|
||||
- No need to fully emulate the interpreter to get value from presence checks
|
||||
|
||||
Notes:
|
||||
- May produce rare FPs if nonstandard fonts include unknown opcodes; validate with secondary tooling
|
||||
|
||||
---
|
||||
|
||||
## DNG/TIFF – CVE‑2025‑43300
|
||||
|
||||
Target: DNG/TIFF image metadata VS actual component count in encoded stream (e.g., JPEG‑Lossless SOF3).
|
||||
|
||||
Structural signals:
|
||||
- Inconsistency between EXIF/IFD fields (SamplesPerPixel, PhotometricInterpretation) and the component count parsed from the image stream header used by the pipeline.
|
||||
|
||||
Pseudo‑logic:
|
||||
|
||||
```pseudo
|
||||
# Metadata claims 2 samples per pixel but stream header exposes only 1 component
|
||||
if samples_per_pixel == 2 and sof3_components == 1:
|
||||
mark_malicious("DNG/TIFF metadata vs. stream mismatch")
|
||||
```
|
||||
|
||||
Practical triage:
|
||||
- Parse primary IFD and EXIF tags
|
||||
- Locate and parse the embedded JPEG‑Lossless header (SOF3) and compare component counts
|
||||
|
||||
Notes:
|
||||
- Reported exploited in the wild; excellent candidate for structural consistency checks
|
||||
|
||||
---
|
||||
|
||||
## Implementation patterns and performance
|
||||
|
||||
A practical scanner should:
|
||||
- Auto‑detect file type and dispatch only relevant analyzers (PDF/JBIG2, WebP/VP8L, TTF, DNG/TIFF)
|
||||
- Stream/partial‑parse to minimize allocations and enable early termination
|
||||
- Run analyses in parallel (thread‑pool) for bulk triage
|
||||
|
||||
Example workflow with ElegantBouncer (open‑source Rust implementation of these checks):
|
||||
|
||||
```bash
|
||||
# Scan a path recursively with structural detectors
|
||||
$ elegant-bouncer --scan /path/to/directory
|
||||
|
||||
# Optional TUI for parallel scanning and real‑time alerts
|
||||
$ elegant-bouncer --tui --scan /path/to/samples
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## DFIR tips and edge cases
|
||||
|
||||
- Embedded objects: PDFs may embed images (JBIG2) and fonts (TrueType); extract and recursively scan
|
||||
- Decompression safety: use libraries that hard‑limit tables/buffers before allocation
|
||||
- False positives: keep rules conservative, favor contradictions that are impossible under the spec
|
||||
- Version drift: re‑baseline bounds (e.g., VP8L table sizes) when upstream parsers change limits
|
||||
|
||||
---
|
||||
|
||||
## Related tools
|
||||
|
||||
- ElegantBouncer – structural scanner for the detections above
|
||||
- pdfid/pdf-parser/peepdf – PDF object extraction and static analysis
|
||||
- pdfcpu – PDF linter/sanitizer
|
||||
- fontTools/ttx – dump TrueType tables and bytecode
|
||||
- exiftool – read TIFF/DNG/EXIF metadata
|
||||
- dwebp/webpmux – parse WebP metadata and chunks
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
- [ELEGANTBOUNCER: When You Can't Get the Samples but Still Need to Catch the Threat](https://www.msuiche.com/posts/elegantbouncer-when-you-cant-get-the-samples-but-still-need-to-catch-the-threat/)
|
||||
- [ElegantBouncer project (GitHub)](https://github.com/msuiche/elegant-bouncer)
|
||||
- [Researching FORCEDENTRY: Detecting the exploit with no samples](https://www.msuiche.com/posts/researching-forcedentry-detecting-the-exploit-with-no-samples/)
|
||||
- [Researching BLASTPASS – Detecting the exploit inside a WebP file (Part 1)](https://www.msuiche.com/posts/researching-blastpass-detecting-the-exploit-inside-a-webp-file-part-1/)
|
||||
- [Researching BLASTPASS – Analysing the Apple & Google WebP PoC file (Part 2)](https://www.msuiche.com/posts/researching-blastpass-analysing-the-apple-google-webp-poc-file-part-2/)
|
||||
- [Researching TRIANGULATION – Detecting CVE‑2023‑41990 with single‑byte signatures](https://www.msuiche.com/posts/researching-triangulation-detecting-cve-2023-41990-with-single-byte-signatures/)
|
||||
- [CVE‑2025‑43300: Critical vulnerability found in Apple’s DNG image processing](https://www.msuiche.com/posts/cve-2025-43300-critical-vulnerability-found-in-apples-dng-image-processing/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
Loading…
x
Reference in New Issue
Block a user