Notepad Bypass: fa817dc1 Full Reversal & Detection

The sample is a 64-bit Windows PE executable, 4.90 MB on disk, distributed under the filename notepad.exe to blend in with the legitimate Windows text editor. Despite the benign name, the binary has no relationship to Microsoft Notepad — it is a packed bypass loader with the entire payload encrypted inside a single custom section.

• Architecture: PE32+ (x86-64), subsystem 3 (Console) — despite the notepad.exe name, no GUI window is created by the stub; the real payload may spawn one
• Compile timestamp: 0x6514b842 → 2023-09-27 23:18:26 UTC — plausible; not zeroed or far-future, suggesting the developer did not manipulate it
• Checksum: 0x00000000 (zeroed — standard for packed/modified PE files)
• SizeOfImage: 0x0089F000 (9,109,504 bytes / ~8.7 MB) — the virtual footprint after all sections are mapped, significantly larger than the 4.9 MB on-disk file due to the six virtual sections that contain no file data but occupy address space; this value appears in Windows AppCompatCache and PcaSVC records alongside the file path and is a useful secondary indicator
• DllCharacteristics: 0x8160 — DYNAMIC_BASE (ASLR), HIGH_ENTROPY_VA, NX_COMPAT (DEP), TERMINAL_SERVER_AWARE all set
• Manifest: requireAdministrator — UAC elevation is demanded on launch
• Debug directory: absent — no PDB path, no CodeView record. The developer stripped the debug directory before distribution, unlike the ApateonDecoy/Wizard sample which leaked a full PDB path
• Rich header: not present — the DOS stub area contains no Rich marker, either stripped or never generated (uncommon for MSVC builds; may indicate use of a third-party linker or post-link PE manipulation)

Nine sections are declared in the section table. Six of them — .gala, .xys23, .prom, .ax512, _gbit_, and .2024 — have a raw size of zero and contain no file data. Their virtual sizes and section headers exist solely to inflate the apparent complexity of the PE for superficial scanners. All executable code, decryption routines, and the encrypted real payload are consolidated into the single .tiko section.

The .tiko section records a Shannon entropy of 7.88 out of a theoretical maximum of 8.0. This is near-perfect randomness, consistent with AES, ChaCha20, or a custom symmetric cipher applied to the entire payload before packing. Static string scanning of this region produces no readable plaintext or API names, ruling out simple XOR obfuscation applied to a plaintext binary.

The binary's entry point (RVA 0x3C4A87, VA 0x1403C4A87) lands inside .tiko at offset 0xEA87 (59 KB into the section, 1.2% of its size). The first executed instruction is PUSH 0x19BAB67 — a seed constant passed to the root bootstrap function at 0x140853D23. This is structurally different from the Wizard variant, which embeds its bootstrap at 47.3% into its .zyw section via a CALL-slalom chain. Section names .tiko, .limco, .dino, .gala, .xys23, .prom, .ax512, _gbit_, and .2024 are all non-standard and constitute reliable static indicators — no legitimate software ships with this combination of section names.

Structurally this binary belongs to the same packer family as ApateonDecoy / Wizard bypass — both use a single high-entropy payload section, six or more hollowed virtual sections, identical dynamic API resolution logic via PE export table walking, and the same ROL-XOR decryption constant. The section names differ between samples, indicating the packer re-randomises names per build.

Ghidra headless analysis identifies 16 functions in the visible (non-encrypted) portion of the binary. The remaining code is unreachable until the runtime decryptor unpacks the payload into memory.

The entry point at 0x1403C4A87 executes exactly three instructions before jumping to the main decryption bootstrap:

The far jump (JMPF) after the call is deliberately placed but unreachable in practice —FUN_140853d23 does not return in the normal case. This is a common obfuscation tactic to confuse linear-sweep disassemblers into following the wrong execution path.

FUN_140853d23 (108 bytes) is the root of the bootstrap chain. It sets up the decryption key, calls into FUN_1407522af (the 1,279-byte main resolver), and orchestrates mapping the decrypted payload before transferring control. The argument 0x19bab67 pushed before the call is used internally as an initial state value for the cipher or as a hash seed — it appears nowhere else in the stub and is not a valid Windows API ordinal.

The core API-string and payload decryption cipher is implemented in FUN_1407522af (1,279 bytes) and reused verbatim in FUN_140752798 (373 bytes). Both functions contain the identical decryption loop at different offsets.

The cipher is a position-dependent ROL-XOR scheme:

The key 0x32063cae appears at two independent call sites — once in FUN_1407522af at 0x140752502 and again in FUN_140752798 at 0x1407527d9. Its presence at both sites confirms it is the primary decryption constant and not a coincidental immediate value.

This cipher decrypts API name strings on demand: rather than storing plaintext DLL and function names in readable memory, the stub stores them encrypted and decrypts each one immediately before calling LoadLibraryA or GetProcAddress. After the call resolves, the decrypted string may be re-encrypted or discarded. This prevents memory-scanning tools from locating hidden API names at rest.

The loop iterates up to 0x104 (260) bytes per string — the maximum Windows API name length — and terminates at a null decrypted byte. The decrypted output lands in a stack buffer at rsp+0x50 before being passed to GetModuleHandleA or LoadLibraryA.

In addition to decrypting API names before passing them to GetProcAddress, the binary implements a manual PE export table walker in FUN_1407522af. This allows it to resolve exports from already-loaded modules without ever calling GetProcAddress — bypassing API-level hooks placed by EDR products.

The walker sequence, confirmed by disassembly:

The walker performs a binary search over the export name pointer array, comparing each candidate name against the decrypted target string one character at a time. When a match is found, it resolves the corresponding ordinal and function address. This technique completely avoids the hooked GetProcAddress entry point while still finding the correct function.

When a module is not already loaded, the stub falls back to LoadLibraryA via the decrypted name path (call site at 0x1406131A7), loads it, then re-enters the walk loop against the newly loaded DLL. The resolver recurses into itself (CALL 0x1407522af at 0x1407528D7) to handle nested dependencies.

The visible import table (located inside .tiko) contains 19 imports across five DLLs. This is the minimum surface needed to bootstrap the runtime — every other API used by the real payload is resolved dynamically and leaves no trace in the static import table.

The PE export directory declares exactly one export (ordinal 1, base 1). The function address RVA is 0x00000000 — a null pointer that would crash if actually called. The export exists purely to anchor the export name entry.

The “name” of this export, instead of a readable ASCII identifier, is a 3,100-byte binary blob with Shannon entropy of 7.94/8.0 — statistically indistinguishable from random data. This is encrypted content embedded where export name strings normally live. Tools that parse the export table looking for DLL name or function name strings will either crash, truncate at the first unexpected byte, or display garbage.

The 3,100-byte blob is almost certainly a configuration block, decryption table, or secondary payload fragment stored in the export name slot because it is a convenient location that many parsers overlook or mishandle. The loader accesses it by navigating the export directory directly via the PE walk routine — not via any normal name-resolution API.

The stub layer implements multiple independent anti-analysis and anti-debug measures before the real payload is mapped. Each technique targets a different analysis environment.

The COFF header timestamp is 0x6514b842, which decodes to 2023-09-27 23:18:26 UTC. Unlike the ApateonDecoy/Wizard sample (timestamped 2026-01-01 — manipulated to a future date), this timestamp falls within a plausible range for a real build date. It is not zeroed, not in the distant future, and corresponds to a Wednesday evening in late September 2023.

• The timestamp alone does not prove the binary was compiled on that date — MSVC timestamps can be set arbitrarily — but its plausibility suggests less attention to anti-forensics in this dimension
• Assuming the timestamp is authentic, the binary predates the ApateonDecoy/Wizard sample by roughly 27 months, suggesting a shared packer codebase that has been reused and distributed over an extended period
• SizeOfImage 0x89F000 appears in Windows AppCompatCache/PcaSVC shimcache records paired with the executable path — this value combined with the SHA-256 hash provides a reliable historical detection artifact even after the file is deleted

Ghidra headless analysis identifies 16 functions in the non-encrypted stub layer. The bulk of functionality lives in the encrypted .tiko payload and is only visible after runtime decryption. Functions are listed by address, size, and role.

The patterned obfuscation stubs (FUN_1407938f7, FUN_140860bb7, FUN_14086ce7c, etc.) exist to break up the control flow graph and prevent disassemblers from cleanly following execution. They interleave meaningless arithmetic operations (CMC, STC, CLC, BSWAP on partially-used registers) with the real logic. This is a known obfuscation technique called junk instruction insertion — the junk instructions have no net effect on program state but dramatically increase the number of nodes in the control flow graph.

This binary and the ApateonDecoy/Wizard bypass sample share a common packer architecture. The following structural features match exactly:

• Single high-entropy payload section (7.82 in Wizard's .zyw vs 7.88 in this sample's .tiko) containing all executable code
• Six or more hollowed virtual sections with no raw file data
• Identical ROL-XOR decryption cipher with key 0x32063cae present in both samples at corresponding function positions
• Manual PE export table walker for API resolution, bypassing hooked GetProcAddress
• Import stub limited to {LoadLibraryA, GetProcAddress, GetModuleHandleA} plus capability imports
• requireAdministrator UAC manifest in both samples
• Entry point inside the encrypted payload section
• Zeroed PE checksum

Section names differ between samples (.zyw / .3L9 / .64X vs .tiko / .limco / .dino / .gala, etc.), indicating the packer re-randomises or regenerates section names per build. The underlying packer code and decryption key, however, are consistent — suggesting either the same individual built both, or a shared packer-as-a-service tool is in use.

• Behavioural: demands UAC elevation, enumerates CPU cores via affinity mask, queries window station name, calls WTSSendMessageW cross-session, reads registry keys dynamically
• Memory: at runtime the decrypted payload will be mapped into a newly allocated RWX region; look for unsigned executable pages not backed by a file on disk
• Network: not determinable from static analysis — the real payload is encrypted

The following rule targets both this specific sample and future builds from the same packer family. Two variants are provided — a tight single-sample rule and a broader family rule.

rule NotepadBypass_fa817dc1_Exact {
    meta:
        description = "Exact match: notepad.exe bypass (fa817dc1)"
        hash_sha256 = "b61907b9081bb5d7125264c5e60de013c02b7b866148248de603fb55f8d39a18"
        date = "2026-06-06"

    strings:
        // ROL-XOR decryption key constant (little-endian DWORD)
        $key = { AE 3C 06 32 }
        // Bootstrap seed pushed at entry point
        $seed = { 68 67 AB B9 01 }
        // Section name strings
        $sec_tiko  = ".tiko"  ascii wide
        $sec_limco = ".limco" ascii wide
        $sec_gala  = ".gala"  ascii wide

    condition:
        uint16(0) == 0x5A4D and filesize < 8MB and
        $key and $seed and ($sec_tiko or $sec_limco or $sec_gala)
}

rule NotepadBypass_PseudoPacker_Family {
    meta:
        description = "PseudoPacker family — covers fa817dc1 and ApateonDecoy/Wizard variants"
        author = "Clubhouse AC Research"
        date = "2026-06-06"
        reference = "https://clubhouseac.shop/research/notepad-bypass-detection"

    strings:
        // Shared ROL-XOR key constant
        $rolxor_key = { AE 3C 06 32 }
        // Export table abuse: null function RVA in export directory
        // Manual PE walk: MZ signature check pattern
        $mz_check = { B8 4D 5A 00 00 66 3B 01 }
        // PE sig check immediate
        $pe_check = { 81 3C 08 50 45 00 00 }
        // ApateonDecoy section names
        $sec_zyw   = ".zyw"   ascii
        $sec_3l9   = ".3L9"   ascii
        // This sample section names
        $sec_tiko  = ".tiko"  ascii
        $sec_limco = ".limco" ascii

    condition:
        uint16(0) == 0x5A4D and filesize < 25MB and
        $rolxor_key and
        ($mz_check or $pe_check) and
        ($sec_zyw or $sec_3l9 or $sec_tiko or $sec_limco)
}

Because this binary and ApateonDecoy/Wizard share the decryption key 0x32063cae, a single YARA rule targeting the key constant catches both samples and likely all other builds from the same packer family. Adding the PE export table walk pattern (MZ signature check immediate + PE\0\0 check) narrows false positives without missing variants that change section names.

• AppCompatCache / ShimCache: the SizeOfImage value 0x89F000 and the file path are cached by Windows PCA service even after the file is deleted. Querying SRUM, Prefetch (NOTEPAD.EXE-XXXXXXXX.pf), and AppCompatCache with path and size allows post-incident detection on endpoints where the file has been cleaned up
• Memory forensics: the decrypted payload, once mapped at runtime, will appear as an unsigned PE image in memory. Tools like Volatility3 windows.malfind or windows.dlllist will identify the unsigned module
• Behaviour: a call to WTSSendMessageW from an unsigned process claiming to be Notepad is an extremely high-fidelity detection signal — no legitimate Notepad variant makes this call
• Affinity manipulation: calls to SetProcessAffinityMask immediately after startup (before any user interaction) from an alleged text editor should be flagged