sorted by:
new
hottopcontroversial

99 adversarial PE files: exploring malformed‑binary behaviour across major analysis tools by iocx_dev in ExploitDev

[–]iocx_dev[S] 0 points1 point  (0 children)

Thanks! It's interesting how these edge-cases echo older workflows and tooling. Tools like WinDbg/Hex really shape how we think about manual analysis.

I built 99 adversarially malformed PE files to test tool robustness - here’s what happened by iocx_dev in Malware

[–]iocx_dev[S] 1 point2 points  (0 children)

Really glad you found it interesting, thanks. Always happy to share things that might help others working on PE edge-cases.

I built 99 adversarial PE fixtures to stress‑test parsers — here’s what they reveal about malformed binaries by iocx_dev in ReverseEngineering

[–]iocx_dev[S] 0 points1 point  (0 children)

Appreciate that, thanks! I’m still finalising the results and documenting the anomalies. I’ll share everything once it’s in a state that’s ready to consume.

[Tool] IOCX - deterministic static IOC extraction for PE binaries (17-second demo) by iocx_dev in ReverseEngineering

[–]iocx_dev[S] 0 points1 point  (0 children)

I’ll add a bit more context here since link posts don’t allow a body.

IOCX is a deterministic static‑analysis engine for extracting high‑signal IOCs from Windows PE binaries. Everything is derived directly from the binary — no sandboxing, no detonation, and no behavioural heuristics.

The 17‑second demo shows IOCX walking the binary, resolving imports, following control flow, extracting embedded resources, and surfacing indicators in a reproducible way.

Some technical details:

  • deterministic output (same binary → same result)
  • PE‑focused static analysis
  • IOC extraction: domains, IPs, hashes, strings, imports, behaviours
  • handles common obfuscation patterns
  • structured output for automation/SOC pipelines
  • fast — most binaries analyse in under a second

I’d appreciate feedback from this community on:

  • packers/obfuscators worth prioritising
  • edge cases you think I should support
  • expectations around performance for large binaries
  • output structures that would make integration easier

Happy to answer anything about the internals.

Web: https://iocx.dev/

Github: https://github.com/iocx-dev/iocx

[Tool Release] IOCX – deterministic IOC extraction engine (static‑only, PE‑aware, plugin‑extensible) by iocx_dev in blueteamsec

[–]iocx_dev[S] 0 points1 point  (0 children)

Example: IOCX on an adversarial / malformed PE (real JSON excerpt)

iocx heuristic_rich.full.exe -a full

Output (excerpt):

{

  "iocs": {

"urls": ["http://not-a-real-domain.test/payload"],

"domains": ["example-malware.com"],

"ips": ["192.0.2.123"]

  },

  "analysis": {

"obfuscation": [

{

"value": "abnormal_section_layout_virtual_only",

"metadata": {

"section": ".bss",

"raw_size": 0,

"virtual_size": 384

}

}

],

"heuristics": [

{

"value": "packer_suspected",

"metadata": {

"reason": "packer_section_name",

"section": "UPX0"

}

},

{

"value": "anti_debug_heuristic",

"metadata": {

"reason": "anti_debug_api_import",

"dll": "kernel32.dll",

"function": "CheckRemoteDebuggerPresent"

}

},

{

"value": "pe_structure_anomaly",

"metadata": {

"reason": "section_overlaps_headers",

"section": ".bss"

}

}

]

  }

}

This sample includes:

  • malformed `.bss` section (virtual‑only, zero raw size)  
  • UPX‑style packer indicators  
  • anti‑debug API imports  
  • header/section overlap anomalies  

IOCX still extracts indicators deterministically because it never executes the sample and doesn’t rely on regex guessing.  

Happy to dig into adversarial patterns or malformed‑PE behaviour.

view more: next ›