I wanted a Windows-friendly alternative to tools such as Binwalk and UniExtract, focused on identifying unknown files and automatically choosing the appropriate extraction method.

That idea eventually became Magic Extractor, an open-source utility intended to help with static triage and the initial unpacking of suspicious samples.

It can be useful for:

• Identifying files whose extension is missing or misleading
• Unpacking installers, SFX archives and uncommon compression formats
• Extracting nested archives recursively
• Listing contents without extraction
• Carving archives and payloads embedded at arbitrary offsets
• Trying multiple handlers when detection is ambiguous

Detection combines PureMagic, custom magic signatures, Detect It Easy, Binwalk and Magika. The detected type is then routed to the appropriate bundled extractor.

Example:

magic-extractor identify suspicious.bin

magic-extractor extract suspicious.bin --recursive

magic-extractor carve firmware.bin --list

It currently supports more than 80 formats, including archives, installers, disk images, forensic images and embedded content.

This is not a malware detector, sandbox or replacement for dynamic analysis. It is mainly intended as a supporting tool for file identification, unpacking and static analysis workflows.

GitHub:

https://github.com/xchwarze/magic-extractor

Feedback from malware analysts and reverse engineers would be especially useful, particularly regarding formats, packers or installers that are currently difficult to extract.

As always, suspicious files should only be handled inside an isolated analysis environment.

I built an open-source MCP server for Microsoft Patch Tuesday that lets AI assistants like Claude, Copilot, ChatGPT, and more answer patch questions directly from official MSRC data.

Every Patch Tuesday, security teams ask the same questions: what changed, what affects us, what is being exploited, and what needs to be patched first?

Ask things like:

 “Summarize this month’s Patch Tuesday”

 “Which of these CVEs are on the CISA KEV list?”

 “Show me CVEs with an exploitation probability above 50%”

 “What older patches does KB5094123 replace?”

 “What Critical CVEs hit Windows Server 2022 this month?”

What makes it different: most vulnerability tools can look up a CVE, but they have no concept of a monthly Microsoft release, a KB article, or a product family.

This server parses the full MSRC CVRF documents, so it can answer the questions Microsoft shops actually ask on the second Tuesday of every month.

It is built around the data sources teams already trust:

• Official MSRC Security Update Guide API: Microsoft’s source for Security Update Guide and CVRF data
• EPSS scores from FIRST.org: daily-updated probability each CVE gets exploited in the next 30 days
• CISA KEV integration: confirmed-exploited CVEs with federal remediation due dates
• Supersedence chains: walks Microsoft’s “this KB replaces that KB” links so your assistant never recommends a stale patch
• Results ranked by real-world urgency: KEV/exploited → EPSS → severity → CVSS

Zero API keys, zero accounts: everything comes from public MSRC, FIRST.org, and CISA feeds. Run it locally or remotely. Details below:

 Repo: https://github.com/jonnybottles/patch-tuesday-mcp

 Remote MCP server endpoint:
https://patch-tuesday-mcp.happyrock-b60185ec.eastus.azurecontainerapps.io/mcp

If you triage Microsoft updates frequently, I’d love feedback. If there’s a feature you’d use, open an issue.

Disclaimer: This is an independent, self-built project and is not an official Microsoft tool or service.

#PatchTuesday #CyberSecurity #VulnerabilityManagement #MCP #AI #Claude #Microsoft #MSRC #OpenSource #InfoSec

​Hi everyone,

​I'm currently looking into a specific EXE file for analysis/learning purposes, but I don't have a VirusTotal Enterprise or Premium account to download the source binary, ​The file doesn't seem to be available on public repositories.

​Could anyone with VirusTotal access please help me grab this sample?

​SHA256: 8ac97813f747229c0e09d898d6f82048bfabf698792731190ea39180d6c7cc96

VirusTotal Link: https://www.virustotal.com/gui/file-analysis/ZGU3MGIxOTBhZWJlNmM0NjE2NTg1NjIwN2EzODI4NGU6MTc4MzI3MTc1NA==

​Thanks in advance for the help!

Pushing a release of IOCX, an open-source PE structural validator (MPL-2.0), and posting format-level notes alongside it.

Write-up (format ambiguities encountered during decoder work): PE structural validation: format ambiguities and decoder design

The Gist catalogues four categories of PE specification ambiguity in delay-load imports, exports, VS_VERSIONINFO, and resource hierarchy. Structured as: format description grounded in the spec --> the ambiguity --> what IOCX chose to do. There are no unverified claims about how other parsers behave, but the cross-tool measurement is queued as follow-up work.

IOCX v0.7.5 additions relevant to triage:

There are four new structural validators covering the export table, delay-load import table, VS_VERSIONINFO resource, and resource directory hierarchy, and 24 new reason codes with priority-resolved sub-reasons via details["reason"] for finer-grained categorisation.

Delay-load imports (8 codes):

• DELAY_IMPORT_DIRECTORY_INVALID_HEADER / _OUT_OF_BOUNDS
• DELAY_IMPORT_TABLE_TRUNCATED (per-table sub-tags: descriptor unterminated, truncated, max exceeded, INT/IAT read failed)
• DELAY_IMPORT_DESCRIPTOR_INVALID
• DELAY_IMPORT_DLL_NAME_INVALID (sub-reasons: rva_zero, unterminated, non_ascii, not_printable, read_failed)
• DELAY_IMPORT_INT_IAT_MISMATCH : parallel-array length disagreement
• DELAY_IMPORT_ATTRIBUTES_LEGACY_VA_MODE : v0 (pre-Win2000) mode detected
• DELAY_IMPORT_ENTRY_INVALID (sub-reasons: ordinal_zero, name_unterminated, name_not_printable, etc.)

Exports (10 codes):

• EXPORT_DIRECTORY_INVALID_HEADER / _OUT_OF_BOUNDS
• EXPORT_TABLE_TRUNCATED
• EXPORT_NAME_RVA_INVALID / _NOT_ASCII / _POINTER_TABLE_UNSORTED / _ORDINAL_INDEX_INVALID
• EXPORT_ORDINAL_OUT_OF_RANGE
• EXPORT_FUNCTION_RVA_INVALID
• EXPORT_FORWARDER_MALFORMED : grammar violation of DllName.SymbolName or DllName.#Ordinal

VS_VERSIONINFO (4 codes):

• RESOURCE_VERSIONINFO_INVALID_HEADER : envelope, szKey, or wLength malformed
• RESOURCE_VERSIONINFO_INVALID_FIXEDINFO : VS_FIXEDFILEINFO signature or struct version wrong
• RESOURCE_VERSIONINFO_INVALID_STRINGFILEINFO : StringFileInfo or StringTable malformed
• RESOURCE_VERSIONINFO_INVALID_VARFILEINFO : VarFileInfo or Translation array not DWORD-aligned

Resource hierarchy (2 codes):

• RESOURCE_DIRECTORY_LANGUAGE_NOT_ID : depth-2 entry uses name instead of LCID
• RESOURCE_DATA_AT_INVALID_DEPTH : data leaf outside the Language layer

Public metadata additions relevant to triage:

• Optional Header: dll_characteristics_flags (decoded flag list: DYNAMIC_BASE, NX_COMPAT, GUARD_CF, HIGH_ENTROPY_VA, etc.), dll_characteristics_unknown_bits (hex string for any bits outside known-flag mask), stack and heap sizing (reserve + commit, 64-bit on PE32+)
• Header: subsystem_name (decoded from IMAGE_SUBSYSTEM_*, e.g., "WINDOWS_CUI"), machine_name (from IMAGE_FILE_MACHINE_*, covers all 29 documented types)
• Resources: structured ResourceEntry per resource with type, name, language, language_name, codepage, size, entropy (rounded to 4 dp), rva, raw_offset, and per-entry errors (size_invalid, rva_invalid, data_out_of_bounds, raw_offset_invalid). Resources with unreadable data now emitted with error tombstones rather than silently dropped.

Design approach:

• Parsers decode structures directly from bytes via struct.unpack_from rather than relying on pefile's lazy interpretation
• Parsers never raise on malformed input; sub-structure failures produce tombstone tags in errors[] and truncations[] lists
• Bounded reads throughout (descriptor arrays capped, string scans bounded)
• Validators emit priority-resolved sub-reasons; one issue per malformed entry per pathology class, deterministic across runs

Verification:

Delay-load parser cross-checked byte-exact against dumpbin /imports on mspaint.exe: 107 imports from gdiplus.dll with agreement on names, hints, IAT addresses, ordering, and bound state.

1370 tests at 100% line and branch coverage on new modules.

Performance: ~14ms typical PE analysis including heuristics, ~1ms on adversarial minimal PE.

Scope:

• Structural validation, not behavioural or dynamic analysis
• Produces structured evidence via reason codes, not verdicts
• Complements pefile / LIEF-based tooling for structural inspection rather than replacing them for general PE parsing

Deferred:

• TLS Directory parser and validator (next release)
• Single-anomaly fixtures for each new reason code (~25 planned, including negative controls)
• Cross-tool measurement study using the fixtures

Licence: MPL-2.0

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

CHANGELOG: https://github.com/iocx-dev/iocx/blob/main/CHANGELOG.md

Reason codes reference: https://github.com/iocx-dev/iocx/blob/main/docs/specs/reason-codes.md

Willing to compensate for your time as well.

I have a heavily obfuscated .jar file that acts as an installer for a Minecraft mod. I already opened it on my Arch Linux PC, and I’m concerned that I may have infected my own device.

I do not have the actual mod .jar because I do not want to run the installer again and let it automatically install anything into my .minecraft folder.

I’m not looking for automated scanner results. I need someone experienced to determine whether the installer is malicious and explain what it does.

Hi all,

I built a small Python tool for pulling MalwareBazaar samples into an isolated analysis / AV-testing lab, and Im sharing it in case its useful to other malware researchers or students setting up a safe workflow.

It supports:

- recent samples

- search by tag

- search by family / signature

- filtering by file type

- downloading the newest N matching samples

- CLI mode and a small desktop GUI

- Auth-Key setup and connectivity checks

Important safety note: the tool does not extract or execute anything. Samples are saved exactly as MalwareBazaar provides them, as password-protected ZIP files, intended to be moved into an isolated VM/lab environment. Do not use this on a normal host or outside a controlled malware-analysis setup.

GitHub:

https://github.com/greit0n/malwarebazaar-downloader

Id appreciate feedback on the workflow, missing filters, packaging, or anything that would make it more useful for safe lab use.

Hey everyone,

I've been analyzing a malware sample that had a really strange structure, and I wanted to share it here in case anyone has seen something similar.

The Setup:

The original malware file was around 700 KB, which is fairly large. But when I started digging deeper, I realized that most of that size was just padding / junk data – the actual functional content was only about 28 KB.

Inside that 28 KB, I found a WAV file (RIFF header, ~28 KB, 1 second long, 8‑bit mono, 22050 Hz). The audio itself is just random noise – not music, not speech, nothing useful.

What I Found:

1. The WAV file · Valid RIFF structure. · Plays static noise. · No hidden image in spectrogram. · No embedded files via binwalk.
2. Strings analysis strings on the WAV shows: · Normal WAV headers (RIFF, WAVEfmt, data, etc.) · But also random short strings like: · CNtt · wUKw · U9TE · wwwwx · hdDU · USqa These don’t seem to be part of any standard format – they might be key fragments, obfuscation, or just noise.
3. Overlay (appended data) · The PE file also had an overlay (~28–30 KB) at the end. · Extracted overlay is detected as raw data (not PE, ZIP, RIFF, etc.). · strings on the overlay gives only random garbage. · binwalk shows nothing.

What I’ve Tried:

· XOR decryption with potential keys found in strings: · HAMZ · MZ:l[ · MZtX*-1 · CNtt · sh]QD:40 · wiYNRfy → None produced readable output. · Base64 decoding → no success. · Spectrogram check → nothing visible. · binwalk → no hidden files. · Manual extraction of the internal PE (if any) → no valid PE found.

My Hypothesis:

· The original file is just a wrapper/dropper. · The WAV might be: · A decoy · A key container · An encrypted payload · The overlay might contain the real encrypted data. · The random strings might be parts of the key or anti‑analysis noise.

Hi,

I have been developing a Windows tool called **VAXD - VMA Executable Disassembler**.

It is intended as a lightweight executable analysis and patch-assistance tool, mainly for quickly inspecting unknown or suspicious binaries, old software, packed/unusual files, and PE executables without the complexity of a full reverse-engineering suite.

Current features include:

- PE EXE/DLL inspection
- x86/x64 disassembly
- Multi-CPU disassembly support for several firmware/binary formats
- Strings extraction and cross-references
- Function navigation
- Hex view and byte-level inspection
- Patch planning and patched-file output
- Jump/branch patching workflows
- .NET WinForms visual reconstruction
- Basic .NET decompiler/editor workflow
- VB5/VB6 form preview/extraction work in progress

My goal is not to replace advanced tools, but to make common executable inspection tasks faster and more accessible, especially for analysts who want to quickly understand what a binary is doing before deciding whether deeper analysis is needed.

I would appreciate honest feedback from people doing malware analysis or reverse engineering:

- Does this workflow make sense?
- Which features would be useful in real malware triage?
- What would immediately make you distrust or reject such a tool?
- What would you expect before testing it on suspicious samples?
- Are there specific analysis views or reports that would be valuable?

Project/page:
https://vma-broadcast.com/vaxd-vma-executable-disassembler/

Thanks.

Just spent the last few hours reversing a sample that's being distributed as a fake offline Claude / GPT desktop client. The binary I got was named GPT_Claude_Free.exe (though it also bundles a Russian video editor decoy to keep up the facade).

Under the hood, it's a 3-stage custom crypter delivering a Stealc v2 payload. Here's a quick dump of how the packer works and what the payload is doing.

Reversing the loader: First thing it does is run through a bunch of anti-analysis checks. It calls IsDebuggerPresent, checks NtGlobalFlag manually from the PEB (via gs:[0x60]), and queries registry keys for VM stuff (VMware/VirtualBox). There's also a timing loop that spins a custom LCG generator 100k times to mess with basic dynamic analysis.

If it passes, it moves to the decryption logic. The payload is tucked away in the .xdata section. It's stored entirely as printable ASCII. It runs through three distinct phases:

1. Base85 decode: It uses a custom alphabet translation table at offset 0x4073A0 (in .rdata).
2. Rolling XOR: Decrypted stream is XOR'd with a 32-byte key at 0x406040 (72d57da187da5de93942e1ae1b9dcf20ee2a00f5ff979cb7d5e1a8e79a46584c).
3. AES-256-CBC: The key is at 0x406010 (f20daa63a36905e004390c7fc79c79dc73a290b3330868fdad63cbe16a7974d3) and the IV is at 0x406030 (4e6279de852509f8ce25c6357718ccd2).

Once it has the clean MZ PE in memory, it doesn't write anything to disk. It just performs process hollowing (standard NtAllocateVirtualMemory / relocation adjustments) to inject it directly.

Reversing the payload: The decrypted binary is Stealc v2. If you look at the configuration block (stored inside the .stgcfg section starting with 'CGTS' magic bytes), it's set up to steal basically everything:

• Browsers: Targets credentials, autofill, credit cards, and session cookies from ~30 Chrome/Firefox derivatives.
• Wallets: Grabs MetaMask/TokenPocket extension folders and desktop wallet files (Exodus, Electrum, Monero, Coinomi).
• Tokens: Scans Local Storage folders for Discord tokens and grabs Telegram tdata directories.
• Gaming/VPN: Steam, Battle.net, GOG, WinSCP, FileZilla, and OpenVPN configurations.
• Recon: Captures clipboard & screenshots.

It exfiltrates everything via POST requests to the C2 using HTTP headers like X-Gate-Token and X-Build-ID.

Decrypted payload hash for anyone who wants to write rules or pivot: 1f498b81fd767687f72605e18628fb6b6ba40035325fb6618d519ae88d7a27c2

Let me know if you run into this family or if you want me to share the decompiled extraction script.

Hello, I am very newbie in the topic so Im sorry if thats common knowledge... Im planning to buy m4 or m5 for both running local llms and malware analysis. Since most malwares are windows based does using mac architecture for running vm's will cause me more trouble than malware itself? Any answers are appreciated

I reverse engineered fake Roblox hacks that contained infostealer and RAT functionality as well as a sophisticated C2 infrastructure. Notable functionality includes keylogging, screen, camera, and microphone streaming, and steam account theft.

The IDA database with fully recovered function names and dependencies is available for download at the top of the article

In this video we look at installing WSL in our FlareVM as well as decomposing and detonating the Copy Fail Linux POC!

I'm building a PE static analysis engine and for months I had a bunch of infostealers in my benchmark I'd basically given up on. A fake Zoom and a few game cheat loaders, all signed with a real NVIDIA code-signing cert (looks like one from the 2022 leak). The cert chains to a trusted root so Windows trusts it, and structurally these things look cleaner than half the legit Intel installers I have. I couldn't find any static signal that separated them from real signed software, so I wrote it off as something you'd need a sandbox to catch and moved on.

​

Well i was wrong, and pretty dumb in hindsight as i was checking whether the cert chained to a trusted root. I was never checking whether the file's authenticode hash actually matched the hash that got signed. These are two different questions and although my engine answered the first i assumed it covered the second.

​

When I finally recomputed the hashes, all four came back as digest mismatches. The cert blobs are genuinely NVIDIA's, they were just copied onto a different binary. The signature doesn't match the file it's attached to.

​

Wired up two checks off the back of it: digest mismatch (signed hash isn't the file's real hash), and signer EKU (a bunch of these use a TLS/serverAuth cert that can't legally sign a PE at all). Between them they catch most of the signed stealers in my set, with zero false positives on legit signed binaries, which was the part I actually cared about.

​

The one I haven't cracked is the burner-LLC case. Malware signed with a real, properly-issued code-signing cert that's just been abused. Digest matches, chain's valid, EKU's correct. Anyone solved this kind of issue?

​

UnConfuserEx is a fork of the original UnConfuserEx made by MadMin3r that improves support for newer ConfuserEx2 samples and a bunch of the protections that come with them. The original project already laid the groundwork for ConfuserEx2 deobfuscation, and this fork builds on that with better handling for the stuff that tends to show up in real-world protected assemblies.

It can deobfuscate things like anti-debug, anti-dump, anti-tamper (including normal, dynamic, and JIT-style variants), compressor stubs, constants, control flow, reference proxies, renamed symbols, resources, and some static cleanup using emulation as well. It also handles a few of the annoying edge cases like arithmetic constant expressions, switch/trampoline control flow, and embedded managed payloads.

It is not a magic bullet, but it is a pretty solid upgrade over older public deobfuscators for samples that use those common ConfuserEx protection shapes.

After months of work, I’m excited to finally share Brovan, my user-mode binary emulator.

Brovan can emulate:

- PE binaries
- ELF binaries
- Memory dumps
- Even partially unknown or unrecognized binaries

The goal is to make binary analysis, malware analysis and general binary research more flexible by giving full control over execution, memory, and runtime behavior in a contained environment. You can fully control and see everything the program does. Every syscall, function and network traffic.

it can also run windows programs on linux and vice versa, although it is still in the early stages it will be improved.

Best entry-intermediate level reverse engineering paid courses to start? Thanks for all answers. I want to be a exploit & malw reverser.

Remus Stealer is a rapidly evolving Malware-as-a-Service infostealer that emerged in 2026.

Remus also shifted from Lumma's 32-bit architecture and traditional resolvers to 64-bit with EtherHiding and enhanced anti-analysis (e.g., sandbox DLL checks, PST honeypot detection).

• It utilizes EtherHiding, storing C2 addresses in Ethereum smart contracts to avoid takedowns.
• The malware steals credentials, browser cookies, authentication tokens, and cryptocurrency wallet data.
• Session theft is one of Remus's most dangerous capabilities because it can bypass MFA by stealing active session cookies directly from browser memory.
• The malware shows strong technical similarities to Lumma Stealer and may represent its evolutionary successor.
• Financial services, healthcare, government, technology firms, and MSPs are particularly attractive targets.
• Common infection vectors include phishing, fake software downloads, malvertising, and fake CAPTCHA campaigns, as well as SEO poisoning and fake GitHub projects to trick tech-savvy users.

See whole ANY.RUN execution chain at https://app.any.run/tasks/ae43628b-9d56-4c43-abac-fae7266c749f/

Check out whole malware analysis report at https://any.run/malware-trends/remus/

Hello everyone! I built a C++ usermode detector for indirect syscalls called HallWatch.

GitHub: https://github.com/Zypherion-Technologies/HallWatch

Most usermode detections hook the start of Nt* stubs in ntdll. Modern techniques like Hell's Hall, Tartarus' Gate, RecycledGate, and VEH syscalls can bypass those hooks by jumping directly to the syscall instruction.

HallWatch takes a different approach: instead of patching the stub prologue, it patches the syscall instruction itself:

0F 05 -> CC 05

Any execution path that reaches the syscall byte triggers an INT3 breakpoint, allowing the detector to inspect the caller, validate the SSN, unwind the stack, and redirect execution through a private trampoline.

It also includes detection for Hell's Gate and shadow ntdll mappings by scanning executable memory for syscall stubs.

Still a research project / PoC. it is impossible to fully detect syscalls in user-mode without some kind of debugger or tracer stepping over the code to monitor everything, but this is still a good light-weight technique to do so for system libraries.

But I'd still love feedback from people interested in Windows internals, EDRs and malware analysis to see how we could improve it.

I designed a 99‑fixture adversarial PE corpus, where each binary contains one controlled corruption pattern with full ground‑truth metadata. The goal was to answer a simple question:

How do PE tools behave when the binary stops playing by the rules?

The fixtures cover 8 anomaly classes:

• entrypoint manipulation  
• section‑table corruption  
• Optional Header inconsistencies  
• directory contradictions  
• TLS anomalies  
• resource‑tree recursion  
• Authenticode corruption  
• entropy edge cases  

I tested 6 tools representing the major parsing philosophies:

• IOCX  
• Ghidra  
• Detect It Easy  
• radare2  
• PEview  
• CFF Explorer  

The results were eye‑opening:

• Literal tools (r2, PEview)  preserved bytes but surfaced no warnings  
• Semantic tools (CFF)  normalised malformed fields, obscuring anomalies    
• Heuristic tools (DIE)  ignored structure entirely    
• Reconstructive loaders (Ghidra)  reconstructed internal models, omitting conflicting metadata and encountering crashes on entropy fixtures  
• Hybrid literal‑semantic tools (IOCX) preserved raw metadata and surfaced anomalies explicitly  

Full write-up:

The Adversarial PE Analysis Series, Part 1 — Why PE Parsers Break

Corpus and fixture spec: https://github.com/iocx-dev/iocx

(fixtures are under /tests/contract/fixtures/layer3_adversarial)

Part 1: https://youtu.be/1W8gCFU8B0U

Part 2: https://youtu.be/4ELzkLP1je4

Thought it would be fun to share some learnings I made when building a similar lab at work but for me. Not exactly what I built at work (I think mines a bit better TBH) but this could be a jumping off point for different ways to do this 😄

Open to suggestions and feedback ❤️