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>

Використання:
```bash
python3 gpbf_clear.py obfuscated.apk normalized.apk
zipdetails -v normalized.apk | grep -A2 "General Purpose Flag"

Тепер ви повинні бачити General Purpose Flag 0000 на core записах і інструменти знову проаналізують APK.

2) Large/custom Extra fields to break parsers

Зловмисники вставляють надмірно великі поля Extra та нестандартні ID у заголовки, щоб збити з пантелику decompilers. У природі ви можете побачити кастомні маркери (наприклад, рядки на кшталт JADXBLOCK) вбудовані там.

Перевірка:

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

Спостережувані приклади: невідомі ID, такі як 0xCAFE (“Java Executable”) або 0x414A (“JA:”), які містять великі payloads.

DFIR евристики:

• Попереджати, коли поля Extra неприродно великі в ключових записах (classes*.dex, AndroidManifest.xml, resources.arsc).
• Вважати невідомі Extra ID в цих записах підозрілими.

Практичне пом’якшення: перебудова архіву (наприклад, повторне zip-упакування вилучених файлів) видаляє шкідливі поля Extra. Якщо інструменти відмовляються витягувати через фальшиве шифрування, спочатку очистіть GPBF bit 0, як описано вище, потім повторно запакуйте:

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

3) Колізії імен файлів/каталогів (приховування реальних артефактів)

ZIP може містити як файл X, так і каталог X/. Деякі екстрактори та декомпілятори плутаються й можуть накладати або приховувати реальний файл за записом каталогу. Це спостерігалося при колізіях записів з основними іменами APK, такими як classes.dex.

Тріаж і безпечне витягання:

# 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

Постфікс для програмного виявлення:

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:

• Позначати APKs, чиї локальні заголовки вказують на шифрування (GPBF bit 0 = 1), але вони все одно інсталюються/запускаються.
• Позначати великі/невідомі Extra fields у основних записах (шукати маркери на кшталт JADXBLOCK).
• Позначати path-collisions (X and X/) особливо для AndroidManifest.xml, resources.arsc, classes*.dex.

Інші шкідливі ZIP трюки (2024–2025)

Конкатеновані центральні каталоги (multi-EOCD evasion)

Останні phishing кампанії доставляють один blob, який насправді є два конкатеновані ZIP файли. Кожен має свій власний End of Central Directory (EOCD) + central directory. Різні екстрактори розбирають різні каталоги (7zip читає перший, WinRAR — останній), що дозволяє атакам приховувати payloadи, які показують лише деякі інструменти. Це також обходить базовий mail gateway AV, який інспектує лише перший каталог.

Команди для триажу

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

Якщо з’являється більше одного EOCD або виникають попередження “data after payload”, розділіть blob і перевірте кожну частину:

# 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)

Сучасна “better zip bomb” створює крихітне kernel (дуже стиснутий DEFLATE блок) і повторно використовує його через перекриваючіся локальні заголовки. Кожен запис центрального каталогу вказує на ті ж стиснені дані, досягаючи співвідношень >28M:1 без вкладених архівів. Бібліотеки, які покладаються на розміри записів у центральному каталозі (Python zipfile, Java java.util.zip, Info-ZIP до жорсткіших збірок), можна змусити виділяти петабайти.

Швидке виявлення (повторні зсуви LFH)

# 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

Обробка

• Виконайте dry-run walk: zipdetails -v file.zip | grep -n "Rel Off" і переконайтеся, що зсуви (offsets) строго зростають і є унікальними.
• Обмежте прийнятний загальний розмір у розпакованому вигляді та кількість записів перед вилученням (zipdetails -t або власний парсер).
• Якщо потрібно розпаковувати, робіть це всередині cgroup/VM з лімітами CPU та диска (щоб уникнути аварій через необмежене роздування даних).

Посилання

• 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

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

• Перевірте плани підписки!
• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.