Binary Atlas — Static Analysis for Windows PE Files

The Real Problem Malware analysis is not hard because tools do not exist. It is hard because most tools surface isolated signals, and you are left doing the correlation yourself. One tool says a section has high entropy. Another flags suspicious imports. A third matches a YARA rule. Each signal matters, but none of them, by themselves, prove a binary is malicious. I originally thought malware detection was mostly about finding the right signature. After seeing too many false positives on legitimate binaries, I realized the real problem was correlation. So I built Binary Atlas to test a simple idea: what if a PE analysis tool did not just flag individual indicators, but correlated them into a unified threat picture?

TL;DR Binary Atlas is a PE static analysis tool that runs multiple specialized detectors, correlates their findings, and produces confidence-based reports instead of a simple yes/no verdict. It is designed to explain why a binary looks suspicious, not just to scream that it does. The sample DLL report I analyzed is a good example: the tool does not claim certainty, but it does surface a meaningful combination of signals - elevated entropy, suspicious imports, shellcode-like patterns, anti-analysis behavior, DLL hijacking indicators, and suspicious resources - and rolls them into an overall medium threat assessment with 32% confidence.

Why I Built It The hardest part of malware analysis is not finding something unusual. The hardest part is deciding whether the unusual thing is actually meaningful. A lot of legitimate software looks suspicious when you only inspect one piece of it: packers and protectors can raise entropy debuggers and monitoring tools can use injection-related APIs installers and launchers can load DLLs dynamically compressed assets can look like encrypted payloads anti-debug checks can also appear in software protection systems

That is why isolated indicators are weak. Real analysis comes from combining them. Binary Atlas was built around that idea.

The Architecture Here is the pipeline at a high level: PE parsing - extract headers, sections, imports, strings, hashes, and metadata Signature check - check whether the binary is signed or unsigned Run specialized detectors - each detector looks for a specific threat pattern Correlate findings - merge overlapping evidence into a unified assessment Score confidence - report risk as a spectrum, not a binary Generate reports - produce readable output with context and indicators

The detectors cover things like packing, anti-analysis, persistence, DLL hijacking, shellcode patterns, import anomalies, resource anomalies, string entropy, YARA matches, compiler metadata, mutexes, overlays, and threat classification. Why this order matters: static analysis is about reducing noise before interpreting the evidence. The sample DLL report shows why that matters. Several indicators are suspicious, but none of them should be treated as proof in isolation.

What the Sample DLL Report Shows The DLL report makes the design much more concrete. The file is: 32-bit PE Windows GUI subsystem unsigned or invalidly signed statically analyzed only

That means there is no valid signature signal to lower the risk score, so the tool has to rely on structure, imports, strings, sections, and heuristic behavior. Section-level signals The report shows multiple sections with elevated entropy: .text entropy: 6.59 .RLD0 entropy: 6.76 .RLD1 entropy: 7.91

That does not prove packing on its own, but it is a real clue. High entropy in code-like sections can indicate obfuscation, encryption, or packing. Import and behavior signals The tool found imports such as: GetProcAddress VirtualAlloc VirtualProtect LoadLibraryA

Those imports are not malicious by themselves, but together they are consistent with dynamic API loading and memory manipulation patterns often seen in shellcode and loaders. It also detected: anti-debug APIs like IsDebuggerPresent timing checks like GetTickCount and QueryPerformanceCounter OutputDebugStringW SetUnhandledExceptionFilter

That is a meaningful anti-analysis cluster. Any one of those APIs could be benign in isolation. Together, they raise the confidence of evasion behavior. DLL hijacking and resource indicators The report also flags: suspicious DLL import behavior relative-path DLL loading patterns unusual resource entries several high-entropy resources

None of those alone is proof. But in combination, they support the idea that the binary is doing more than ordinary application work. Unified assessment The final summary is the most important part: Overall Threat Level: MEDIUM Detection Confidence: 32% Total Threats: 9 findings Malware Complexity: INTERMEDIATE Anti-analysis/evasion: YES C2/communication: NO Persistence: NO

That is the kind of result I wanted the tool to produce: not a fake sense of certainty, but a structured, evidence-based assessment.

What Makes Binary Atlas Different

It does not treat every suspicious import as a verdict A lot of tools see VirtualAlloc or GetProcAddress and immediately act like they have found malware. That is not analysis. That is pattern matching without context. Binary Atlas treats these as evidence, then asks what other signals support them.
It prefers combinations over single indicators High entropy alone is weak. Suspicious imports alone are weak. A single YARA match alone is weak. But high entropy + dynamic API loading + anti-debugging + suspicious resources + DLL hijacking indicators? That is much more interesting.
It reports confidence, not certainty A static analyzer should be honest about its limits. Binary Atlas does not prove malicious intent. It reports how strong the evidence is and why the binary deserves a closer look. That is much better than pretending every suspicious file is definitely malware.

The Technical Breakdown Entropy-Based Obfuscation Detection Malware is often packed or encrypted, but entropy alone is not enough. In the sample DLL, several sections are elevated enough to deserve attention, especially .RLD1 at 7.91. That is a strong signal that something is compressed, encrypted, or otherwise non-standard. But legitimate software can also have high-entropy sections. So the tool pairs entropy with other indicators: section type import behavior suspicious APIs resource anomalies anti-analysis behavior

That keeps the detector from overreacting. Import Anomaly Analysis Imports are useful, but they are not truth. VirtualAlloc, VirtualProtect, GetProcAddress, and LoadLibraryA all matter, but they become more meaningful when viewed together. For example: GetProcAddress + LoadLibraryA can suggest dynamic API resolution VirtualAlloc + VirtualProtect can suggest staged payload execution those same imports can also appear in legitimate software, which is why the tool does not treat them as proof

That is the entire point: imports are clues, not convictions. Anti-Analysis Detection The sample DLL contains multiple anti-analysis indicators: debugger checks timing checks exception handling tricks emulator-related keywords

This is the kind of cluster that deserves attention because it suggests the binary may behave differently under analysis. Resource Section Analysis The report also shows unusual resources and high-entropy embedded data. That can mean: compressed payloads encrypted blobs embedded configuration staged data used later at runtime

Static analysis cannot tell which one with certainty, but it can identify the anomaly. DLL Hijacking Indicators The report flags suspicious DLL loading patterns, which is useful because DLL side-loading and hijacking often rely on import behavior and path resolution mistakes. Again, the tool is not saying “this is definitely a hijack.” It is saying the import and path patterns deserve scrutiny.

VirusTotal and Why Labels Are Not Ground Truth I also checked the same DLL against VirusTotal. 46 out of 72 vendors flagged it as malicious or potentially unwanted, with labels like hacktool, crack, gamehack, PUA, and trojan. That matters, but it does not make VirusTotal absolute truth. In this case, the sample is a Steam-related crack DLL, so the result sits in a messy middle ground. It is not a clean business application, but it is also not automatically “classic malware” in the narrowest sense. That is exactly why both false positives and false negatives happen in real-world analysis. The lesson is not “VirusTotal was wrong” or “my tool was right.” The lesson is that labels are opinions, signals are evidence, and context decides how much weight each signal deserves. A good static analyzer should behave the same way: it should not blindly copy a vendor label, and it should not ignore one either. It should use that label as one more input in a broader confidence model.

Where the Tool Is Still Limited Static analysis is not execution A binary can import suspicious APIs and never call them. It can contain encrypted data that is never used. It can include anti-debug logic that exists for legitimate protection. Static analysis produces evidence, not proof. Signatures are useful, but not magic A valid signature is a strong trust signal. An invalid or missing signature is not proof of malware. In the sample report, the binary appears unsigned or invalidly signed, which means heuristics matter more here. But even then, the correct output is still a confidence score, not a declaration of guilt. False positives are still the hardest problem The real challenge is not finding suspicious binaries. The real challenge is avoiding the ones that only look suspicious. That is why the tool has to be conservative, explain itself, and combine signals instead of latching onto one indicator.

What I Learned Malware analysis is not binary I started out thinking in terms of “malware” and “not malware.” Reality is messier. A binary can be packed, obfuscated, protected, legitimate, malicious, or some combination of all of those. The job of a good analyzer is to map that uncertainty clearly. One signal means very little A YARA match can be useful. So can entropy. So can suspicious imports. But each one is only a clue. The real value comes from correlation. Static analysis is hypothesis generation Binary Atlas does not prove intent. It generates hypotheses: this binary may be packed this binary may use anti-analysis tricks this binary may be loading code dynamically this binary may contain suspicious embedded data

That is enough to prioritize deeper analysis. The best tools explain themselves The most useful tools do not just warn you. They tell you what they found, how they weighed it, and where they are uncertain. That is what I was trying to build.

What Comes Next Binary Atlas is a static analysis tool, which means it is only one part of the pipeline. The next step would be to add: Dynamic sandboxing - observe actual runtime behavior Threat intelligence enrichment - compare indicators against known IOCs Better graph-based correlation - connect related findings across detectors More rigorous scoring - tune confidence with real sample sets

Static analysis is useful, but it is not the whole story.

The Main Lesson The goal is not to build a tool that shouts “malware” at everything suspicious. The goal is to build a tool that tells the truth about what it sees. That means: using multiple signals being honest about confidence avoiding false certainty explaining why something looks suspicious knowing when static analysis is not enough

Binary Atlas taught me that malware analysis is less about finding one perfect signature and more about building a trustworthy picture from imperfect evidence. Build tools that explain. Do not build tools that overclaim.

Want to Play With It? The tool is open source on GitHub and focused on PE static analysis. It is educational, not a replacement for full sandboxing or production-grade malware triage. But if you are learning PE structure, import analysis, entropy, or heuristic correlation, it is a solid reference. https://github.com/bilal0x0002-sketch/Binary-Atlas

You can find the full source on GitHub: bilal0x0002-sketch/Binary-Atlas

Bilal