Anomaly Company — Reversing a Ren'Py-Wrapped Multi-Stage Malware

Discovery

It started with a simple download link dropped in a Discord server : Anomaly Company Build 03/02/2026 — try our new game ! what followed was anything but a game. The sample was shared by a colleague who stumbled upon it at its original distribution website, still up at the time of writing this article.

Initial Recon — The Archive Structure

My first step was to unzip the archive and get a feel about what we're dealing with. Here is what greeted me :

.
├── data
│   ├── 7ByXk3POijf8.Vd
│   ├── cache
│   │   ├── bytecode-39.rpyb
│   │   ├── py3analysis.rpyb
│   │   ├── screens.rpyb
│   │   └── shaders.txt
│   ├── gui
... (some images, skipped)
│   ├── libwin32.rpa
│   ├── python-packages
│   │   ├── libpython.rpmc
│   │   └── sys_config
│   │       ├── access_internet.py
│   │       ├── __init__.py
│   │       ├── sys_check.py
│   │       ├── sys_file.py
│   │       └── sys_spec.py
│   └── script_version.txt
├── lib
│   ├── py3-windows-x86_64
│   │   ├── d3dcompiler_47.dll
│   │   ├── libEGL.dll
│   │   ├── libGLESv2.dll
│   │   ├── libpython3.9.dll
│   │   ├── librenpython.dll
│   │   ├── libwinpthread-1.dll
│   │   ├── nvdrs.dll
│   │   ├── python.exe
│   │   └── pythonw.exe
│   ├── python3.9
│   │   ├── abc.pyc
... (full of Python bytecode for the imports)
├── renpy
│   ├── add_from.py
... (all Ren'Py project files)
│   └── webloader.py
├── Setup
└── setup.py

The Ren'Py project is available here : https://github.com/renpy/renpy, after checking the files in the renpy folder, none of them had been modified. This leaves us with three points of interest : the data/ and lib/ folders and the PE binary Setup.

Stage 0 — The PE Launcher

Let's start with the binary. Opening it in IDA reveals a function which is launching another function from a DLL. Here is the decompiled code :

As we can see, the Setup binary loads librenpython.dll and calls its exported function launcher_main_wide, standard behaviour for any Ren'Py game. This function initializes the embedded Python interpreter and executes setup.py.

The first interesting function in setup.py is path_to_gamedir() :

Ren'Py scans for a game directory by trying a hardcoded list of names in order : game/, then data/, then launcher/game/. Since there is no game/ folder here, Ren'Py automatically falls back to data/, which is exactly where the attacker placed all the malicious files. A deliberate choice : data/ looks far less suspicious than game/ to a casual observer.

Ren'Py's Import Hook Hijacking

Once the game directory is resolved, setup.py's main() hands control to the Ren'Py engine :

Inside bootstrap.py, the engine initializes its import system :

And this is the key call. init_importer() inserts a custom Python importer into sys.meta_path, Python's global import hook list :

From this point on, any import statement in the game scripts will first be resolved against data/python-packages/, which is where the attacker placed sys_config/, his anti-sandbox module. No explicit call, no obvious hook : the malicious import is made possible by Ren'Py's own legitimate loading mechanism.

The Anti-Sandbox Module: sys_config

Files in sys_config are pretty much obfuscated, but we can easily understand what they are used for.

access_internet.py — Connectivity Stubs

As the class name states, it simply checks that we got access to internet probably used before exfiltrating victim's data.

__init__.py — Module Entry Point

Which I simplified as :

In python the __init__.py file will simply tell to the renpy program once sys_config imported to execute the is_sandboxed function from sys_check.py file.

sys_check.py — The Scoring Engine (Sysbox)

Here is the content of this file :

I simplified the code for better understanding :

It is the Sysbox class we saw before, it is used to log the probability to be in a vm for the malware, sysbox class is regrouping all the scores of the different checks and use a ponderation scoring algorithm function : _normalize, to say with a probability X if the malware is in a VM or not, of course it prints the results and details for debug in a custom terminal. Certainly this scoring algorithm will tell if the malware has to execute or not, if the total score exceeds 3, the malware will execute, otherwise it will not. Additionally if any of the tests described below returns a score of 0, the malware will not run at all.

sys_file.py — Filesystem & Registry Detection

I noticed the creator used more junk code on this file, so I simplified it a bit :

The FileSystem class is responsible for detecting virtual machine artifacts at the filesystem level. It operates exclusively on Windows (os.name == 'nt') and returns a score from 0 to 5 for each check.

The first function check_vm_registry_keys() searches HKEY_LOCAL_MACHINE for registry keys known to be created by VirtualBox and VMware (guest additions, drivers, services). Finding any of them drops the score to 2.

The second function check_vm_files() checks for the physical presence of VM-related driver and executable files on disk, VirtualBox (.sys, .dll, .exe) and VMware drivers. Each file found reduces the score, but never below 2.

The third one check_vm_processes() lists running processes via PowerShell, WMIC, or tasklist (three fallbacks) and looks for known VM guest agent processes such as vboxservice.exe, vmtoolsd.exe, or qemu-ga.exe.

The last one check_prev_logins() inspects C:\Users\ to count user profiles and measure their age in days. More importantly, it checks the current username against a hardcoded list of known sandbox accounts : wdagutilityaccount, vagrant, and sandbox, a match immediately returns score 0.

Others functions are disabled by the creator...

sys_spec.py — Hardware Fingerprinting

Which once simplified gave me :

Function check_hard_drive() is basically retrieving total disk size of drive, and gives a score of 0 if the disk size is under 20 GB, and 5 if it's bigger than 120GB. Then we got function check_ram_space() it queries total physical memory if this physical memory is under 2GB checks will return 0 else for 8GB or more it will return 5. Function check_cpu_cores() is used to count number of cpus of the machine, less than 2 cpus put the score at 0 but 6 cpus and more let the score at 5. Of course all those functions are not that binary they can give other scores that will be passed to the _normalize function, which finally says if the malware executes or not. However the rest of the functions : check_serial_number(), check_model(), check_manufacturer() are indeed binary, bcs they check at hardcoded values if it matches it's a 0 else it's always a 5. Finally here is what's resume the check for the sandbox, i guess the author didn't use all his functions cause it was too restrictive :

The Execution Gate — What Actually Runs

Finally, as shown in the diagram above, _check_file_system() is never called by is_sandboxed(), the entire FileSystem class is dead code. Whether this was an oversight or a deliberate choice to keep the detection lightweight, only check_model() and check_manufacturer() actually influence the final score.

Hunting for the Dropper

At this point we know the sandbox check passes, but where is the actual dropper code ? There is no game/script.rpy in the archive, this file is normally run by Ren'Py. Indeed the author compiled it, generated the bytecode cache, then deleted the source before distributing the malware. The cache files (py3analysis.rpyb, screens.rpyb) are standard Ren'Py auxiliary files, nothing suspicious. The malicious code is isolated to a single entry inside data/cache/bytecode-39.rpyb, mixed among 3075 legitimate compiled scripts to make it harder to spot.

Unpacking the Bytecode Cache

The bytecode is compressed using zlib and packed with pickle. I used this tiny Python script to unpack it :

This code gave me tons of results so I added a filter to see only malicious code which might call the sandbox we reversed earlier : if b"is_sandboxed" in code_bytes: print(code_bytes)

As we can see on the screen below, we recovered the right bytecode :

Disassembling the Dropper

In order to disassemble the bytecode I downloaded Python 3.9 :

Then I used this code :

We get the bytecode perfectly decompiled :

  2           0 LOAD_CONST               0 (0)
              2 LOAD_CONST               1 (None)
              4 IMPORT_NAME              0 (json)
              6 STORE_NAME               0 (json)

  3           8 LOAD_CONST               0 (0)
             10 LOAD_CONST               1 (None)
             12 IMPORT_NAME              1 (subprocess)
             14 STORE_NAME               1 (subprocess)
...
 10          60 LOAD_CONST               3 (<code object xor_decrypt_file ...>)
             62 LOAD_CONST               4 ('xor_decrypt_file')
             64 MAKE_FUNCTION            0
             66 STORE_NAME               8 (xor_decrypt_file)

 27          68 LOAD_CONST               5 (<code object extract_and_run ...>)
             70 LOAD_CONST               6 ('extract_and_run')
             72 MAKE_FUNCTION            0
             74 STORE_NAME               9 (extract_and_run)

I asked Claude AI to reconstruct the code :

This is the code of the first-stage dropper. Let's break it down :

• It reads the configuration from a hidden .key file with base64-encoded JSON data.
• It launches the sandbox checks, if the weighted score is above 0.5 it exits.
• It decrypts an encrypted archive (7ByXk3POijf8.Vd) with the password from .key.
• Finally it extracts the archive and executes the malware.

Stage 2 — Inside the RPA Archive

Now the question is : how do we get this secret .key file to keep exploring this multi-stage malware ?

There is a file called libwin32.rpa and it is an archive for Ren'Py apps. Here you can see the header of the file :

Those archives work with a position index and an XOR key. The data present at the position indicated in the header is zlib-compressed and serialized with pickle. Also the key is used to calculate the next position index.

I used an online tool to extract the sources from that RPA file : https://grviewer.com/

Here is the code we get :

I noticed that .key file doesn't appear anymore, however we can see in the code it is looking for any file with the format .*. And we got one file with this format, the .UkJ file, which contains base64 data :

QxNWWlhUa1cORgxEA3oaYFMBYXxdWlQIGjBdEBsURgRLRhIJFkMCbC89RgtuGk8aXUpSbFJcEAoW
N25+W0BsN3BQHlZMVBYVQRdYAmtaGxoCVFBfR1UeEkQEZkEVDBQkZ3AIAwNuVUoOO15QVws8CgAQ
HRFcUUFYFlwbUQEOVwFbCAkDAQBSCVJWUAMNXVoBWlRVCwMBCglRV18KUQRTBwwDB1FRVA0PVVdS
AFVdBgAAUAMBB1FWAFVRXVECUgMACQNTBwJSB1pQBwFUA1tTCw4KAgNSAlFRVVVbVg4AAFAKAAcB
VlcBClYGDl5WDlcKCQJVEUk=

Decoding the Configuration

At the beginning when I opened and tried to decode this file, I couldn't, however the code gives us the XOR key : 81034149cd6f48c8821340204f92766e. That key isn't sent by the C2, which is a significant operational security mistake.

Once decoded I got :

IP Tracking via Clicky Analytics

Now let's simplify the elnk function :

call_lnk simply makes a GET request. Replacing all the parameters we get :

https://in.getclicky.com/in.php?site_id=101506811&sitekey_admin=8aaa19ea0911cc2198cce177c1da058d&type=download&title=file&ip_address=165.16.146.12&href=A_A807_asm_h6c3_28&custom[hash]=c68adc99...

I tried going to this URL but got no interesting response, it is probably just an IP logger to track victims.

Decrypting the Payload Archive

Let's now dig into the archive which contains the actual malware. First, notice the cryptographic mistake of the creator.

Even if we have the password in the decoded config file, if we check the first bytes of the 7ByXk3POijf8.Vd archive :

00000000: 227d 5648 4d70 6d5a 7236 f035 982c 3a7c "}VHMpmZr6.5.,:|

You probably notice already that part of the password is leaked. It is possible to use a known plaintext attack through zip magic bytes and recover the key, indeed XOR is invertible because plaintext ^ key = ciphertext and so plaintext ^ ciphertext = key. Applying it with the zip magic bytes 50 4B 03 04 00 00 00 00 :

That is very close to the key, we could just brute-force the one incorrect byte M to find the right value Y.

Once I deciphered the archive with a simple XOR and unzipped it, here are the files we got :

cmmbiz.dll        d3dcompiler_47.dll   DuiLib.dll
libssl-3-zm.dll   msvcp140.dll         QWLlvZRHa.exe
system-proc.xml   ucrtbase.dll         util.dll
vcruntime140.dll  zNetUtils.dll        Cmmlib.dll
displaydef.dll    libcrypto-3-zm.dll   msaalib.dll
msvcp_win.dll     reslib.dll           UIBase.dll
vcruntime140_1.dll zCrashReport64.dll  zWinRes.dll

Analyzing the DLL Bundle

The system-proc.xml file contains garbage ASCII data. The most suspicious DLL from the list above is displaydef.dll :

We got a lot of garbage text at the beginning of the file, just like system-proc.xml, but different, and at the end we got some binary data. Looks like this garbage text is there to waste analysis time.

It is not a DLL, and I noticed by reversing all the other DLLs that the only one using those files was actually util.dll. Indeed we can find the filename system-proc.xml in util.dll :

The offset off_1805D285 is a pointer to the string of this filename, and everything interesting happens in the class mem_log_file.

DLL Patching via displaydef.dll

IDA failed to decompile this class properly, however we can get some idea reading the code :

This function is encrypting stuff from memory and placing filename system-proc.xml in a big struct. I tried debugging the malware but somehow couldn't get into this function and see what was in the struct. Again that's because IDA didn't decompile all this stuff properly.

So I took the assembly close to this function. Here is some assembly code that seemed interesting, first we got this :

This code is an API hash resolver checking if : $\sum h = h \times 2 + char = target$, with the hash seed located at rax+0x1c and the targets being constant values like d24d, d2a9, d26d, d275, d259 pointing to values in program memory.

I tried breaking in to get the seed but the DLL crashed.

However with the constant values in IDA we can reconstruct and interpret the meaning. After the definition of this API resolver, some functions that we can guess are called :

const	value	meaning
d24d	0x80000000	GENERIC_READ
d2a9	0x1	FILE_SHARE_READ
d26d	0x40	PAGE_EXECUTE_READWRITE
d275	0x38be	offset header in displaydef.dll
d259 / d285	—	"displaydef.dll" / "system-proc.xml"

The call sequence is then something like this :

180016df1: call rax  ; CreateFileW("displaydef.dll", GENERIC_READ, FILE_SHARE_READ, …, OPEN_EXISTING, …)
180016e0a: call rax  ; GetFileSize(hFile, NULL)   -> esi = size
180016e41: call rax  ; ReadFile(hFile, rbx, size, &read, NULL)

Shellcode Injection into tapisrv.dll

Deciphering occurs at offset 0x38BE :

With all this we understand that something is happening at offset 0x38BE of displaydef.dll and indeed if we check, we end up right at the end of the garbage text :

000038a0: 6968 6561 656f 7563 6963 7461 7473 6e74  iheaeoucictatsnt
000038b0: 7469 6f65 696e 6c65 636f 6e65 7163 8420  tioeinleconeqc.
000038c0: 0000 7e40 e858 8f33 7917 eb32 8a1d b023  ..~@.X.3y..2...#
; 0x38be starts at 8420...

The layout after the garbage text is :

[size_of_chunk=0x2084][delta=0x58E8407E][thechunkdata]

Adding delta to every DWORD in thechunkdata gives us "tapisrv.dll" as the first string. Right after, the assembly :

As you can see, the malware is using DLL patching : taking decrypted bytes from displaydef.dll and placing them in the .text section of tapisrv.dll. I extracted this shellcode using the following script :

The IDAT Loader (HijackLoader)

Now that the shellcode is extracted, let's take a look at its functionalities. We got about 40 functions :

Function sub_1470 is the main one. It handles a struct a4 which has been passed to the shellcode by the replacement function we saw before, and it does things with system-proc.xml. As the code is quite complex I asked AI for help, and here a more comprehensive code :

The high-level behaviour :

• PEB walking to enumerate loaded modules without using Windows API.
• Anti-debugging : calls NtQuerySystemInformation and sleeps 5 seconds × 9 if a debugger is detected.
• Loads system-proc.xml via LoadConfigFile.
• Parses chunks with the pattern ????IDAT from the XML file.

The ParseChunks function :

This function concatenates all chunks matching the ????IDAT pattern in system-proc.xml.

The first one appears right after the gibberish text :

Those chunks are then XOR-decrypted and LZNT1-decompressed. I used this script to extract the next binary stage :

At this step I was a bit stuck so I asked some help to my friend : ScottKushy We looked up about this technique online, it is called IDAT Loader / HijackLoader, first seen in the wild in 2023. A lot of malware families are now abusing it.

Reference : https://malpedia.caad.fkie.fraunhofer.de/details/win.hijackloader

While researching we came across this post : G DATA — PiviGames spreads HijackLoader, which was very close to my case. The author left a GitHub script to properly extract the HijackLoader configuration : https://github.com/struppigel/hedgehog-tools/tree/main/HijackLoader

HijackLoader Configuration

Running the extraction script, we managed to get all the embedded components :

AVDATA:              OpenPGP Secret Key Version 2
COPYLIST:            data
CUSTOMINJECT:        PE32 executable (GUI) Intel 80386, for MS Windows, 6 sections
CUSTOMINJECTPATH:    ASCII text, with no line terminators
ESAL / ESAL64:       data
ESLDR / ESLDR64:     data / zlib compressed
ESWR / ESWR64:       data
FIXED:               PE32 executable (console) Intel 80386, for MS Windows
LauncherLdr64:       PE32+ executable (console) x86-64, for MS Windows
modCreateProcess:    data
modTask64:           zlib compressed data
modUAC64:            zlib compressed data
modWD64:             zlib compressed data
modWriteFile64:      zlib compressed data
MUTEX:               data
PAYLOAD:             PE32 executable (GUI) Intel 80386, for MS Windows, 7 sections
tinystub / tinystub64: PE32/PE32+ executables
tinyutilitymodule.dll / tinyutilitymodule64.dll: PE DLLs

Reading CUSTOMINJECTPATH confirms that the malware drops its persistence at %TEMP%\1778015778\MicrosoftEdgeUpdate.exe, disguised as a legitimate Microsoft binary.

The Final Payload: Lumma Stealer

The PAYLOAD file is the binary launched by the other components loaded by system-proc.xml. Here is the full infection chain :

In my case the malware dropped was not an ACRStealer but a Lumma Stealer. Reversing it statically was too hard, so Scott ran the final payload and debugged it with x32dbg, which allowed us to retrieve the C2 information :

This confirms what VirusTotal shows in the relations tab after uploading the malware : VirusTotal report

Here is the full attack graph :

Conclusion

Looking up the C2 domain online confirms it's quite recent :

Unfortunately, as it is behind Cloudflare I couldn't find a way to get more information about the owners of this domain.

To summarize the full chain :

1. Ren'Py wrapper → abuses the engine's import hook to silently load sys_config
2. Sandbox evasion → hardware model/manufacturer check via WMI (filesystem checks are dead code)
3. Bytecode dropper → hidden in bytecode-39.rpyb, XOR-decrypts and extracts a password-protected archive
4. Stage 2 loader → full dropper in libwin32.rpa, decodes an XOR-encrypted config, phones home via Clicky analytics
5. DLL patching → util.dll injects shellcode from displaydef.dll into tapisrv.dll's .text section
6. IDAT Loader / HijackLoader → shellcode parses PNG-like IDAT chunks from system-proc.xml, decompresses and executes stage 3
7. Lumma Stealer → final payload, exfiltrates credentials via a Cloudflare-protected C2