SIG_LFH = b“\x50\x4b\x03\x04“ # Local File Header SIG_CDH = b“\x50\x4b\x01\x02“ # Central Directory Header

def patch_flags(buf: bytes, sig: bytes, flag_off: int): out = bytearray(buf) i = 0 patched = 0 while True: i = out.find(sig, i) if i == -1: break flags, = struct.unpack_from(‘<H’, out, i + flag_off) if flags & 1: # encryption bit set struct.pack_into(‘<H’, out, i + flag_off, flags & 0xFFFE) patched += 1 i += 4 # move past signature to continue search return bytes(out), patched

if name == ‘main’: inp, outp = sys.argv[1], sys.argv[2] data = open(inp, ‘rb’).read() data, p_lfh = patch_flags(data, SIG_LFH, 6) # LFH flag at +6 data, p_cdh = patch_flags(data, SIG_CDH, 8) # CDH flag at +8 open(outp, ‘wb’).write(data) print(f’Patched: LFH={p_lfh}, CDH={p_cdh}’)

</details>

Utilisation:
```bash
python3 gpbf_clear.py obfuscated.apk normalized.apk
zipdetails -v normalized.apk | grep -A2 "General Purpose Flag"

Vous devriez maintenant voir General Purpose Flag 0000 sur les entrées principales et les outils analyseront l’APK à nouveau.

2) Champs Extra volumineux/personnalisés pour casser les parseurs

Les attaquants insèrent des champs Extra surdimensionnés et des IDs étranges dans les en-têtes pour faire trébucher les décompilateurs. En conditions réelles, vous pouvez voir des marqueurs personnalisés (p.ex., des chaînes comme JADXBLOCK) intégrés là.

Inspection:

zipdetails -v sample.apk | sed -n '/Extra ID/,+4p' | head -n 50

Exemples observés : des IDs inconnus comme 0xCAFE (“Java Executable”) ou 0x414A (“JA:”) contenant de gros payloads.

Heuristiques DFIR :

• Alerter lorsque les Extra fields sont anormalement volumineux sur les entrées core (classes*.dex, AndroidManifest.xml, resources.arsc).
• Considérer comme suspect tout Extra ID inconnu sur ces entrées.

Atténuation pratique : la reconstruction de l’archive (p. ex., zipper à nouveau les fichiers extraits) supprime les Extra fields malveillants. Si les outils refusent d’extraire en raison d’un chiffrement factice, effacez d’abord GPBF bit 0 comme indiqué ci-dessus, puis recréez l’archive :

mkdir /tmp/apk
unzip -qq normalized.apk -d /tmp/apk
(cd /tmp/apk && zip -qr ../clean.apk .)

3) Collisions de noms de fichier/répertoire (cacher les vrais artefacts)

Un ZIP peut contenir à la fois un fichier X et un répertoire X/. Certains extractors et decompilers se confondent et peuvent recouvrir ou masquer le vrai fichier par une entrée de répertoire. Cela a été observé avec des entrées entrant en collision avec des noms de base d’APK comme classes.dex.

Triage et extraction sécurisée:

# List potential collisions (names that differ only by trailing slash)
zipinfo -1 sample.apk | awk '{n=$0; sub(/\/$/,"",n); print n}' | sort | uniq -d

# Extract while preserving the real files by renaming on conflict
unzip normalized.apk -d outdir
# When prompted:
# replace outdir/classes.dex? [y]es/[n]o/[A]ll/[N]one/[r]ename: r
# new name: unk_classes.dex

Détection programmatique post-fix:

from zipfile import ZipFile
from collections import defaultdict

with ZipFile('normalized.apk') as z:
names = z.namelist()

collisions = defaultdict(list)
for n in names:
base = n[:-1] if n.endswith('/') else n
collisions[base].append(n)

for base, variants in collisions.items():
if len(variants) > 1:
print('COLLISION', base, '->', variants)

Blue-team detection ideas:

• Signaler les APK dont les en-têtes locaux marquent un chiffrement (GPBF bit 0 = 1) mais qui s’installent/s’exécutent.
• Signaler les champs Extra volumineux/inconnus sur les entrées core (chercher des marqueurs comme JADXBLOCK).
• Signaler les collisions de chemins (X et X/) spécifiquement pour AndroidManifest.xml, resources.arsc, classes*.dex.

Autres astuces ZIP malveillantes (2024–2025)

Répertoires centraux concaténés (contournement multi-EOCD)

Des campagnes de phishing récentes livrent un seul blob qui est en réalité deux fichiers ZIP concaténés. Chacun a son propre End of Central Directory (EOCD) + central directory. Différents extracteurs parsent différents répertoires (7zip lit le premier, WinRAR le dernier), ce qui permet aux attaquants de cacher des payloads que seuls certains outils montrent. Cela contourne aussi les AV de passerelle mail basiques qui n’inspectent que le premier répertoire.

Commandes de triage

# Count EOCD signatures
binwalk -R "PK\x05\x06" suspect.zip
# Dump central-directory offsets
zipdetails -v suspect.zip | grep -n "End Central"

S’il apparaît plus d’un EOCD ou s’il y a des avertissements “data after payload”, divisez le blob et inspectez chaque partie :

# recover the second archive (heuristic: start at second EOCD offset)
# adjust OFF based on binwalk output
OFF=123456
dd if=suspect.zip bs=1 skip=$OFF of=tail.zip
7z l tail.zip   # list hidden content

Quoted-overlap / overlapping-entry bombs (non-recursive)

La ‘better zip bomb’ moderne construit un petit kernel (bloc DEFLATE fortement compressé) et le réutilise via des local headers qui se chevauchent. Chaque entrée du central directory pointe vers les mêmes données compressées, atteignant des ratios >28M:1 sans imbriquer d’archives. Les bibliothèques qui font confiance aux tailles du central directory (Python zipfile, Java java.util.zip, Info-ZIP avant les versions durcies) peuvent être forcées d’allouer des pétaoctets.

Détection rapide (offsets LFH dupliqués)

# detect overlapping entries by identical relative offsets
import struct, sys
buf=open(sys.argv[1],'rb').read()
off=0; seen=set()
while True:
i = buf.find(b'PK\x01\x02', off)
if i<0: break
rel = struct.unpack_from('<I', buf, i+42)[0]
if rel in seen:
print('OVERLAP at offset', rel)
break
seen.add(rel); off = i+4

Gestion

• Effectuer un dry-run walk: zipdetails -v file.zip | grep -n "Rel Off" et s’assurer que les offsets sont strictement croissants et uniques.
• Limiter la taille totale décompressée acceptée et le nombre d’entrées avant extraction (zipdetails -t ou parseur personnalisé).
• Lorsqu’il faut extraire, le faire dans un cgroup/VM avec des limites CPU+disk (éviter les plantages dus à une expansion non bornée).

Références

• https://michael-myers.github.io/blog/categories/ctf/
• GodFather – Part 1 – A multistage dropper (APK ZIP anti-reversing)
• zipdetails (Archive::Zip script)
• ZIP File Format Specification (PKWARE APPNOTE.TXT)
• Hackers bury malware in new ZIP file attack — concatenated ZIP central directories
• Understanding Zip Bombs: overlapping/quoted-overlap kernel construction

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.