_

have you tried analyzing an .exe but realized that PE analyzers expect you to know what 0x00400000 means...? ;-; let's make it beginner friendly & pretty (˶ˆᗜˆ˵)

normal tools are ugly(sorry) and hard to read for beginners. they just throw hex numbers at you and expect you, a beginner, to figure it out. it helps growth, but beginners can't grow from something they don't understand.

this is for the cuties who just wanna know if a file is sus without reading a 400 page manual c:

no!! PE-pal is NOT a virus scanner. it will not tell you if a file is safe or not. it will only show you the internal structure of the file and highlight suspicious elements.

  • a PE analyzer is designed to dissect and examine the internal structure of executable files.
  • a virus scanner is designed to detect and remove malicious software.

if you want to check if a file is safe, try uploading it to virustotal.

seeing an indicator in a PE analyzer does not automatically mean a file is malicious! software developers often use those exact same things for legitimate reasons. finding a sus trait in an analyzer means you should take a closer look, not that it is dangerous.

the simple version: you give PE-pal a Windows executable file. it reads the file and extracts information about its structure and what functions it uses. then it displays that info in a cute format so you don't have to stare at random hex numbers :D

"what's inside a PE file?"

  • the DOS header: the file saying "haiii, i'm an executable!" (it always starts with 4D 5A = "MZ" in text)
  • sections: containers that hold code (.text), data (.data), or other stuff. each section is encrypted or not depending on how sophisticated the malware is.
  • the import table (IAT): a list of functions the .exe is calling from Windows. like if it's calling CreateRemoteThread, that's sus because it lets you inject code into other processes.
  • strings: readable text hidden in the binary like URLs, file paths, IPs, or registry keys. malware sometimes leaves these as clues c;
  • the rich header: metadata that shows which compiler version built the file (usually hidden by malware to cover its tracks)

"what does PE-pal do with this?"

  • entropy analysis: measures how "random" each section is. normal code has patterns, encrypted/packed malware doesn't. it's a jumbled mess. (entropy > 7.0 = sus)
  • function classification: groups imported functions by behavior (networking, file system, process injection, etc.) so you can see what the malware is trying to do, in simple terms.
  • string flagging: highlights URLs, IPs, and file paths as suspicious since badly-written malware sometimes hardcodes these
  • compiler tracking: shows the compiler timeline so you can see if the file is a frankenstein of different builds

"how does the code work?"

  • you drag a file and the browser loads it into memory as bytes
  • web worker processes it and a separate JavaScript thread (worker.js) parses the PE structure without freezing the UI. it reads binary data using DataView API to extract all the things mentioned above.
  • calculations happen. entropy is calculated for each section using information theory (frequency analysis). then, functions are categorized. strings are extracted by scanning for readable ASCII text in the hex.
  • data flows back. the worker sends results to the main thread, which renders cutie charts so you can actually understand what's going on :3
  • no files leave your computer! everything happens in your browser's memory. the moment you close the tab, it'll all be gone.

tl;dr: PE-pal is a binary file translator. it reads the instructions inside your PE file and tells you what it's trying to do in a language that doesn't require a compsci degree to understand! (´ ▽` )b

paranoid? good! welcome to infosec o_o

this runs 100% in your browser. the file never leaves your pc. you won't be uploading anything to my servers. all this happens locally through javascript (ᵔ▭ᵔ)

how to use (guide 4 dummies)

01.

find a sus file

got any sus PE from trying to download free games? no? then click [ generate fake malware ] above to see a demo instantly.

02.

drag and drop!

throw it into the box on the next page!(ᵔ▭ᵔ)

03.

inspect the stuff

hover over the (???) icons to see explanations or warnings about suspicious elements. the web is your best friend here! search the function names online to learn more.

PE-pal :3
[ FILE ]

drop it here (ᵔ▭ᵔ)

.exe  .dll  .sys  .ocx

initializing... (◕‿◕)
parsing file... [............] 0%

filename.exe

ARCH SIZE TS

hashes  (???) hashes are tiny digital fingerprints calculated directly from the import list and rich header structure inside a PE file, and analysts search these unique ID strings to quickly match unknown samples because if several suspicious files share the exact same fingerprint, they prob came from the same malware author or toolset! :3

anomalies & red flags  (???) header anomalies happen when the blueprint at the very front of the .exe lists impossible or conflicting instructions, like asking for huge RAM even though the file on disk is tiny or pointing the entry start to a weird non-code area, and since developers usually don't do that by accident, these odd values often come from packing or process hollowing style tricks :3

file anatomy map  (???) this is a table-of-contents style map of the executable where each bar is one section stored in the file body, and compilers create these chunks during build so windows knows where code and data live, but if a chunk looks oddly random or gets risky permissions like writable plus executable, it can hint that hidden code is being unpacked there (ᵔ▭ᵔ)

section breakdown  (???) entropy measures how random or jumbled the bytes inside each section look on a scale from 0 to 8, and while normal executable code usually has visible patterns and lower scores, encrypted or compressed content looks scrambled and often goes above 7.0, which can mean the file is trying to hide its real instructions until runtime c:

name
entropy
size
red flags
characteristics

hidden extra data (overlay)  (???) an overlay is extra hidden data stuck onto the very tail end of a file past its official boundary, and anyone can append those bytes after compile without breaking how windows runs the program, so malware authors often hide encrypted payloads or huge dummy blobs there and later read that tail data from inside the running app to slip past simple scanners (ᵔ▭ᵔ)

import table / IAT  (???) the import table is the list of external functions the .exe is calling. if it's calling things like CreateRemoteThread or URLDownloadToFile, it may be a red flag! pink function names are usually sus, but not always. some apps genuinely need it! the web is your best friend here.

malware intent analysis  (???) this pie chart groups the imported windows helpers by behavior type so you can see the file's overall "personality". it's built from the same import list above. heavy slices in stealth categories like injection or keylogging can mean the program is designed to do sus things like hiding or spying or tampering...

capabilities detected  (???) this card matches API combinations like recipe ingredients against local behavior rules, so when known combos appear (for example VirtualAllocEx + WriteProcessMemory + CreateRemoteThread) we tag likely capabilities to help triage faster, and while these patterns are common in malware, they are still hints, not final proof!!

strings  (???) this view shows readable text pulled from raw bytes across the whole file, including URLs, file paths, and commands that may be hardcoded or recovered by decoding, and while suspicious strings can reveal command servers or payload paths, clean-looking text by itself never proves a file is safe or unsafe~

compilation timeline (rich header)  (???) the rich header timeline is like a hidden factory label written near the front of the file between the dos stub and pe signature, and since normal compiler/linker steps add this build metadata automatically, wiped or weird entries can be a clue that someone tried to hide where the binary came from.

raw hex viewer  (???) this is the actual .exe content on disk shown byte-by-byte in hexadecimal, and you can click sections above to jump to exact offsets here so high-level warnings connect to real raw data in a way beginners can actually see and trust.

every file on ur computer is just bytes. bytes are numbers from 0 to 255. this viewer shows the raw bytes of the file you dropped in hexadecimal (base 16). one byte is exactly two hexadecimal digits, from 00 to FF.

each row has three columns: offset (where in the file this row starts, starting from zero)  →  hex bytes (the actual byte values)  →  ascii (what those bytes look like as text. a dot (".") means the byte isn't a printable character).

why hex? 1 byte is exactly 2 hexadecimal digits, and it's more compact than decimal. the very first two bytes of any .exe file are always 4D 5A. that's the MZ signature! it tells windows "haiii, i'm an executable!" (it was named after Mark Zbikowski, a DOS developer at Microsoft in 1981 !!)

click any section in the map or list above and this viewer jumps to those bytes and highlights them in cyan. you are looking at raw machine code/data that your CPU loads into memory.