ipIII nie zastępuje warsztatu reverse-engineeringu. ipIII spina jego wyniki w łańcuch dowodowy: custody próbki, import findingów, rejestr IOC/YARA, mapowanie MITRE ATT&CK, log kroków deobfuskacji, evidence-package i legal triggers. Analityk pracuje w Ghidrze, IDA, radare2; ipIII pilnuje, żeby każdy wynik miał hash, źródło, klasyfikację i ślad audytowy.
Disassembler pokaże funkcje. YARA dopasuje regułę. CAPA opisze zdolności. Ale to, czy z tego powstanie dowodliwy artefakt — z hashem próbki, chain-of-custody, klasyfikacją TTP i pakietem dla organu — jest zadaniem warstwy evidence-first. ipIII przyjmuje findingi z narzędzi, nadaje im status ≤ dowód i produkuje evidence-package.
Każdy krok produkuje artefakt z hashem i wpisem w chain-of-custody. ipIII nie wykonuje kroków RE za analityka — rejestruje ich wynik jako dowód.
| # | Krok | Kto wykonuje | Co ipIII rejestruje jako dowód |
|---|---|---|---|
| 1 | Próbka | analityk / IR | sha256 + md5, rozmiar, źródło, chain-of-custody (kto/kiedy/skąd), status TLP |
| 2 | Triage | PEiD / DIE / file | typ pliku, wykryty packer/compiler, entropia — jako finding type:obfuscation |
| 3 | Analiza statyczna | Ghidra / IDA / radare2 / YARA / CAPA / FLOSS | import findingów (strings, imports, dopasowania YARA, zdolności CAPA) → incydent + evidence (hash) |
| 4 | Deobfuskacja | analityk + narzędzia RE | log kroków: technika (packing/XOR/base64/control-flow flattening) → artefakt rozpakowany + hash + custody |
| 5 | Analiza dynamiczna | sandbox / debugger (poza ipIII) | zaobserwowane zachowanie i IOC (C2, mutex, pliki, klucze rejestru) → rejestr IOC |
| 6 | Mapowanie ATT&CK | analityk (biblioteka ipIII) | TTP incydentu /incidents/:id/ttp |
| 7 | Evidence-package | ipIII | PDF/JSON: manifest + wszystkie hashe + chain-of-custody + package_sha256 |
| 8 | Legal triggers | ipIII (decision-support) | mapowanie na NIS2 (24h/72h) / DORA art.19 z zegarami — jeśli zdarzenie kwalifikuje się jako incydent |
Zgodnie z regułą §16: bez kodu + testu + endpointu = nie LIVE. Warstwa dowodowa jest wspólna z orchestratorem (import/custody/MITRE/evidence-package działają na żywej bazie). Automatyzacja samego RE (unpacker, sandbox, integracje headless) = ROADMAP.
| Zdolność | Status | Dowód / uwaga |
|---|---|---|
Import findingów RE POST /imports/re | LIVE v1 | współdzielona warstwa importu v1 (JWT+RBAC+audit, PostgreSQL); RE-findings normalizowane do modelu incydent+evidence. Import = MEDIA_SIGNAL, nie dowód naprawy. |
| Custody próbki (sha256/md5 + chain-of-custody) | LIVE v1 | evidence z hashem i śladem custody w DB (wspólne z evidence-layer). |
Mapowanie MITRE ATT&CK /incidents/:id/ttp | LIVE v1 | biblioteka TTP (Fala 1) — mapowanie incydentu na techniki. |
| Rejestr IOC / dopasowań YARA | LIVE v1 | IOC i YARA-match jako findingi powiązane z incydentem. |
| Log kroków deobfuskacji (technika → artefakt + hash) | LIVE v1 | kroki jako evidence z custody; artefakt rozpakowany = kolejny hash w łańcuchu. |
| Evidence-package (PDF/JSON + hash) | LIVE v1 | GET /reports/evidence-package/:id — manifest + package_sha256 (bezzależnościowy generator PDF). |
| Legal triggers (NIS2/DORA dla incydentu malware) | LIVE v1 | /incidents/:id/legal-triggers — decision-support, terminy orientacyjne, nie porada prawna. |
| Automatyczny unpacker / deobfuscator | ROADMAP | ipIII nie rozpakowuje automatycznie — to pozostaje pracą analityka + dedykowanych narzędzi. |
| Sandbox / detonation | ROADMAP | brak własnej detonacji; integracja z zewnętrznym sandboxem = specyfikacja. |
| Ghidra / IDA headless integration | ROADMAP | headless import auto-analizy (Ghidra script / IDA) = specyfikacja. |
| Symbolic execution | ROADMAP | angr/Triton — brak. |
| Binary diffing | ROADMAP | BinDiff/Diaphora import = specyfikacja. |
| Konektor CAPA / FLOSS | ROADMAP | dziś: import przez generic RE findings JSON; dedykowany parser CAPA/FLOSS = ROADMAP. |
Endpoint: POST /api/ip3/v1/imports/re (auth v1, JWT+RBAC). Trzy przyjmowane formaty. Każdy import tworzy incydent + evidence z hashem; import jest sygnałem (MEDIA_SIGNAL), nie dowodem naprawy.
Wynik skanu YARA: reguły dopasowane do próbki, meta reguły, offsety. Mapowane na findingi type:yara-match.
Wyjście -j z r2/rizin: sekcje, imports, strings, funkcje. Mapowane na findingi statyczne + IOC.
Uniwersalny format dla dowolnego narzędzia RE (CAPA, FLOSS, ręczna analiza).
Schemat generic RE finding (pola):
{
"title": "string — krótki opis findingu",
"severity": "P0 | P1 | P2 | P3",
"type": "malware | obfuscation | ioc | yara-match",
"sha256": "hash próbki lub artefaktu (chain-of-custody)",
"technique": "np. UPX-packing | XOR-0x5a | base64 | control-flow-flattening | T1055 (ATT&CK)",
"description": "string — szczegóły, kontekst, źródło"
}
Import → normalizacja severity (P0–P3) → incydent + evidence (sha256 + chain-of-custody) w PostgreSQL. Warstwa i egzekucja reguł wspólne z Connectors.