I previously reversed LG’s Monitor App Installer and the driver that installed it. Today, Windows Update offered a new version of that SoftwareComponent. Given the recent criticism, I wanted to know what LG had changed.

Inside the update

I exported version 2.0.2026.810 from the Driver Store. It contains three files:

LGMonitorAppSoftwareComponent.cat       11.2 KB
lgmonitorappsoftwarecomponent.inf        1.2 KB
LGMonitorInstallManager.exe              2.2 MB

Before the update, the old INF used a Store-app link:

[LG_Monitor_Control_Install]
SoftwareType=2
SoftwareID=pfn://LGElectronics.LGMonitorApp_cfnzzhwkr8z5w

SoftwareType=2 tells Windows to install that Store package. This is how the old app arrived without a prompt.

The new INF removes that section and replaces it with this:

[LGMonitor_Install.Software]
AddSoftware=LGMonitorInstallManager,,LG_Monitor_InstallManager_Install

[LG_Monitor_InstallManager_Install]
SoftwareType      = 1
SoftwareBinary    = %13%\LGMonitorInstallManager.exe
SoftwareArguments = /driverflow,/campaign:1,/delay:60,<<DeviceInstanceID>>
SoftwareVersion   = 1.1.0.0

SoftwareType=1 instead tells Windows to run a bundled Win32 executable. %13% is the Driver Store. Device Setup Manager event 165 recorded the exact launch:

"C:\Windows\System32\DriverStore\FileRepository\
lgmonitorappsoftwarecomponent.inf_amd64_46db1b4b0dcddd74\
LGMonitorInstallManager.exe"
 /driverflow
 /campaign:1
 /delay:60
 SWD\DRIVERENUM\{3846ad8c-dd27-433d-ab89-453654cd542a}#LGMonitorApp&6&4c65595&0

The old driver automatically installed a Store app. The new driver automatically runs an EXE.

What the new program does

LGMonitorInstallManager.exe is a .NET Framework WinForms application, version 2.0.2026.805. It is obfuscated with Eazfuscator.NET: names are scrambled, strings encrypted, and anti-disassembly and anti-tamper protections enabled. That is an odd amount of protection for a consent dialog whose purpose is supposedly transparency.

I used EazFixer to recover its strings, removed SuppressIldasmAttribute from an analysis copy, and disassembled the IL.

Windows launches /driverflow elevated during device installation. It exits if:

1. an older LG SoftwareComponent package with the previous pfn:// auto-install directive is still present;
2. the user has already given a final answer for the current campaign.

Otherwise it:

1. copies itself from the Driver Store to C:\Program Files\LG Electronics\LGMonitorInstallManager;
2. creates a machine-wide Run entry so the question survives future logins;
3. creates an Add/Remove Programs entry named LG Monitor Software Notice;
4. creates state.ini under C:\ProgramData\LG Electronics\LGMonitorInstallManager;
5. starts a second copy in the active user’s session with /install /campaign:1 /delay:60;
6. creates a cleanup task that eventually removes the copied EXE, Run entry, uninstall entry, state, and task.

The user-session process waits 60 seconds, checks again, and displays this:

When the prompt appears and what Install does

The prompt is suppressed if the old LG driver is still present, the Store app is already installed, the user has already answered the current campaign, or another copy is running. This is why it initially did not appear on my PC: the old, outranked driver package was still in the Driver Store.

Clicking Install removes the temporary Run entry and starts this hidden child process:

%LOCALAPPDATA%\Microsoft\WindowsApps\winget.exe install \
  --id 9PM9N6F47JB8 \
  --source msstore \
  --accept-package-agreements \
  --accept-source-agreements \
  --silent

Store product 9PM9N6F47JB8 resolves to:

Package: LGElectronics.LGMonitorApp
PFN:     LGElectronics.LGMonitorApp_cfnzzhwkr8z5w
Version: 1.2606.1601.0
Arch:    x86

That is the same app the previous driver installed directly. LG has simply inserted a consent dialog before it.

Code and consent

LG seems to misunderstand the consent problem. Its earlier defense emphasized that McAfee was optional. Strictly speaking, that was true: the Monitor App installed itself silently, then asked about the next thing.

The new design moves that question one step earlier:

Old:
driver -> automatically install LG Monitor App -> ask about more software

New:
driver -> automatically execute LG consent app -> ask to install LG Monitor App

This is an improvement: the full Store app is no longer installed before consent. But connecting a monitor still lets LG run an elevated program that copies itself into Program Files, creates persistence, and asks a marketing question. The question is more polite; the code that asks it still ran without asking.

A monitor should not need to run a two-megabyte obfuscated .NET program to ask whether I want another program. LG can simply link to its software and let me choose to get it.

• I used a hierarchy of low-cost source-reading agents, stronger review agents, and manual verification to trace how 3,006 open-source projects handle software updates.
• I found 624 with an updater that could download and then install, load, or execute code: 134 used a pinned signing key, 109 enforced a publisher identity, 332 relied only on HTTPS, and 49 used broken transport security. The other 2,382 had no updater or were notification-only.
• In those 49 projects, a man-in-the-middle attacker could replace update payloads and achieve remote code execution on users’ machines.

Browse the dataset or inspect and correct it in the public repository.

Why update security matters

An updater downloads code and places it inside a trusted application. It may launch an installer, replace an executable, load a plugin, or flash firmware. That makes it a natural supply-chain target.

SolarWinds distributed malicious code through trusted Orion updates. In 2023, attackers compromised the 3CX build environment after first compromising another software package. In 2025, attackers compromised infrastructure used by Notepad++ and selectively redirected update requests toward malicious payloads.

These incidents had different root causes, but they point to the same trust boundary: an application should not execute a downloaded file merely because it came from its usual server. Properly validated HTTPS blocks ordinary network interception, but it does not help when the server, CDN account, storage bucket, or deployment credentials are compromised. Independent payload signatures can protect against that narrower—but important—class of attack.

This problem is not new. A 2006 HotSec study examined ten deployed update systems and found several vulnerable to weak man-in-the-middle attacks. Two decades later, UpdSight tested 85 desktop applications and found 22 exploitable update vulnerabilities. Those studies performed deeper hands-on testing of smaller samples. My goal was different: use agent-assisted source review to scale the initial survey to 3,006 open-source projects, then manually review the 49 Tier-D findings.

What I scanned

For each project, I asked:

1. Does it update itself or install executable content?
2. If so, what authenticates the content before it runs?

The agents followed the entire path:

check version
  -> obtain manifest
  -> choose payload URL
  -> download payload
  -> verify or skip verification
  -> install / execute / load / flash

A verifySignature() function is not evidence by itself. It must check the relevant payload, use a trustworthy key, and stop installation on failure. Likewise, a SHA-256 value downloaded beside the payload from the same server is not independent authentication.

The four tiers

I used tiers because update security depends on the threat model. Tier C validates HTTPS and is not immediately vulnerable to an ordinary network attacker. But a high-security user may reject it because a compromised server or CDN can replace both the package and its hash.

I also recorded the underlying facts—transport settings, signatures, trusted keys or publishers, and source locations—rather than only a verdict. Each tier summarizes the trust model of one update path, not the security of an entire project.

A — application-pinned signing key

package, signature = download_update()
trusted_key = key_embedded_in_application

if verify(trusted_key, package, signature):
    install(package)
else:
    reject()

Compromising the website, CDN, DNS path, or repository is insufficient without an accepted signing key. Sparkle’s EdDSA support is one example: the public key is embedded in the application while the private key should remain separate from the update server.

B — expected operating-system publisher

package = download_update()
signature = os_code_signature(package)

if signature.valid and signature.publisher == EXPECTED_PUBLISHER:
    install(package)
else:
    reject()

The updater enforces the expected Authenticode or platform-signing identity. Merely checking that someone signed the file is not enough.

C — validated HTTPS only

manifest = https_get(server, verify_certificate=True)
package = https_get(manifest.url, verify_certificate=True)

if sha256(package) == manifest.sha256:
    install(package)

This blocks ordinary man-in-the-middle attacks. It does not survive compromise of the authorized distribution path because the attacker can replace both the package and its server-supplied hash.

D — broken transport, no independent signature

client.verify_peer = False
client.verify_hostname = False

manifest = client.get("https://updates.example/manifest.json")
package = client.get(manifest.url)
install(package)

The older version is even simpler: download an executable over HTTP and run it. Either design may allow an on-path attacker to substitute code.

Some projects used HTTPS but disabled certificate validation. Static analysis cannot tell us why. CA-bundle deployment problems, old certificate stores, and forgotten debugging workarounds are plausible explanations—not established causes.

I used N when no in-app updater was found or the application only opened a download page. N does not mean every external package manager or manual installation route is secure.

Results

The dataset contained 624 entries (20.8%) with such an updater and 2,382 (79.2%) with no updater or only update notifications. Among the 624 updater entries, Tier C was the largest group.

These are dataset entries, not 3,006 verified unique applications. The corpus contains duplicate projects, platform-specific implementations, and separate application, plugin, firmware, and content channels. It was collected for breadth rather than statistical sampling. The percentages describe this dataset—not all open-source software.

The agent architecture

I performed the core research from August 3–23, 2026. Claude Opus 4.8 was the strongest model I used in that Claude Code workflow, but using it to read every repository would quickly exhaust the five-hour and weekly limits. I worked with an Opus 4.8 coordinator, while many Claude Sonnet 5 agents handled the broad source review. Opus 4.8 review agents consolidated the reports and rechecked suspected Tier-D findings.

The bulk agents cloned source with shallow history, searched for updater code, and recorded the revision, platform, behavior, transport, verification, trust root, and file:line evidence. They were read-only: no builds, dependency installation, or execution of repository code.

The final expansion from 2,008 to 3,006 entries took about 15 hours and approximately 8.5 million subagent tokens. Small, lower-cost contexts handled the repetitive reading; higher-cost reasoning was reserved for consolidation, disagreement, and findings with security impact.

The initial pass produced 73 Tier-D candidates. Suspected vulnerabilities entered a feedback loop: stronger agents re-read the source and tried to disprove them. That pass retained 51 as D, moved six to C, moved fourteen to N, and refuted two. Later corrections produced the published historical count of 49.

This is why the hierarchy matters. Sonnet provided coverage; the adversarial Opus pass raised the bar before I called something broken. I then read all 49 final Tier-D findings myself before disclosure.

Responsible disclosure

I tried to contact maintainers before publishing actionable Tier-D findings. The disclosure ledger records:

• 9 GitHub Private Vulnerability Reports
• 16 coordinated-disclosure emails
• 25 projects contacted in total

I could not find a usable private contact channel for the remaining 24 Tier-D projects. Of the 25 projects I contacted, two responded positively: FOG Project and SuiteCRM. Both fixed the reported issues.

Writing 25 fully bespoke reports is difficult to scale. My compromise was to write the important opening myself—what I found, why I was contacting the project, and what I wanted the maintainer to do—then attach AI-assisted technical detail with the relevant code path and suggested remediation. That is not ideal, and some maintainers understandably disliked receiving AI-generated material. But silently publishing the findings, or sending no notification at all, would have been worse. The better lesson is that automation must reduce clerical work without replacing evidence review, respectful communication, or accountability for the report.

Some maintainers also challenged the threat model. Two recurring objections were that an attacker would need a fraudulent certificate for GitHub, or that an on-path attacker was unrealistic. Those objections do not apply when the updater itself disables certificate or hostname validation: the attacker can present an arbitrary certificate and does not need to break public-key cryptography or compromise a certificate authority.

An active on-path position is a real prerequisite for many Tier-D findings, and it should be stated rather than exaggerated. Possible positions include a hostile network, compromised router, malicious proxy, or redirected traffic. Server or CDN compromise is a stronger and different position—the main concern for Tier C—but repeated supply-chain incidents show that distribution infrastructure cannot be assumed infallible.

Where I want the ecosystem to move

Tier D is the immediate problem: plaintext HTTP, disabled certificate checks, or ignored TLS errors should be fixed.

Tier C is the larger supply-chain concern. TLS may work perfectly while a compromised server returns a malicious manifest and matching payload. The Notepad++ incident shows why distribution infrastructure should not be the only trust root.

The practical direction is straightforward:

• Tier D → C: require HTTPS, certificate validation, and hostname validation
• Tier C → A/B: authenticate the payload independently of the download server
• Fail closed on missing, invalid, or unexpected signatures
• Keep signing keys separate from public distribution infrastructure
• Test corrupted, unsigned, wrongly signed, and rolled-back updates

Projects do not need to invent this themselves. The Update Framework provides role separation, threshold signatures, rotation, and defenses against rollback and freeze attacks. Sparkle supports EdDSA-signed macOS updates with a public key embedded in the application and can also require signed feeds.

The data remains public and correctable:

• Search all 3,006 analyses
• Review the evidence
• Propose a correction

Chinese Chess Master III: Jiangzu (象棋大師 III／將族) was a popular DOS Xiangqi game. Its developer’s historical company profile claims 200,000 copies sold. I played a number of games against it when I was yong and won most of them. I’m an international Xiangqi grandmaster, so that wasn’t particularly surprising, but I still found it a worthwhile opponent.

My father is also a Xiangqi fan and used to play this game when he was younger. I found his disk and played it a little myself. It came out in 1992, the same year I was born.

I liked the interface, especially the opponent-selection screen. It includes characters from the Chinese novel Journey to the West (西遊記), each with a portrait and a short description.

Eventually I wanted to do more than run it in DOS. Could I preserve the engine and play against it in a modern GUI?

TL;DR: With Codex’s help, I rewrote the engine in C, added UCI/UCCI support, and checked it against the original on 408,708 test cases. The code is on GitHub.

A little background

The game was developed by Yu Hsi-Shun (虞希舜) and T-Time Technology (光譜資訊). It grew out of Yu’s earlier Xiangqi programming work and became a commercial DOS game with graphics, named opponents, and a challenge-based progression. This historical account describes how the 1992 release built on the earlier program.

Its 36 opponents look like different personalities, but underneath they share the same engine. Seven use a fixed two-ply search—roughly a move and a reply, with extra tactical searching. The others get different game clocks, which determine how much thinking time the engine can spend. Bogey gets one minute, Hand eight, and Skeleton 47: whole-game allowances, not time per move.

So the characters mostly change the search budget, not the engine’s understanding of Xiangqi. Some even share identical settings.

Rebuilding the engine

I used Codex to investigate the game and write a portable C version. We used Binary Ninja and disassembly to inspect the DOS code, then DOSBox-X to run the game and capture its initialized memory.

The engine lives in CMS1.EXE, a module loaded by the main game, CCH.EXE. It is a classical engine: it searches moves and replies using alpha-beta search, then evaluates positions with hand-written rules and tables.

Getting a working rewrite was only part of the job. It soon agreed with the original on many positions, but there were still plenty of disagreements. I wanted more than an engine that played reasonably well. I wanted this particular engine’s decisions.

That meant recovering the small details too: exact evaluation constants, move order, repetition handling, and special cases in the search.

The rewrite comes to about 3,400 lines of C code.

Building a feedback loop

Rather than keep asking Codex to “make it more accurate,” I pushed for a repeatable test loop.

We built a harness using Unicorn to run the original 16-bit engine code without clicking through the DOS interface. Then we could:

1. Generate a large batch of positions from legal move histories.
2. Run the original and the rewrite at the same search depth, with opening books disabled.
3. Compare their chosen moves and scores.
4. Investigate disagreements, fix the rewrite, and repeat with fresh positions.

This is how I think about harness engineering here: give the coding agent a way to run its work, measure the result, and get concrete feedback. The original program was our reference, so we did not have to trust that a plausible-looking translation was correct.

Some differences were tiny. In one case, both engines chose the same move, but one scored it 157 and the other 156. We traced that to the order in which they searched escape moves during a cannon check. Fixing the ordering resolved the discrepancy.

As the tests got faster, I kept asking for larger batches. When one batch matched, we generated another.

The chart shows the growing test corpus, not an accuracy percentage. The final rewrite matched the original’s move and score on 408,708 cases, mostly at depths 2–4, with a smaller set of deeper searches. The last three fresh shallow batches had 20,000 cases each and found no differences.

That does not mean the algorithm is a perfect rewrite. Since program equivalence is undecidable in general, the testing convergence gives me enough confidence to call the rewrite successful.

How strong is it?

I also wanted a rough strength estimate. Full-strength Pikafish would be far too strong, so we used a version with calibrated strength controls: UCI_LimitStrength enables reduced-strength play, and UCI_Elo sets the target rating.

Against Pikafish set to 1400, CCH won 13 games and lost 11. That gives a rough estimate of 1,429 on Pikafish’s engine-rating scale. It is a small sample with wide uncertainty, not an official human Elo. These matches also preceded the final fidelity fixes.

We tested ElephantEye, another open-source Xiangqi engine. It is much weaker than full-strength Pikafish, but still comfortably stronger than CCH: it beat our experimental larger-cache CCH variant 8–0. The validation notes explain the limitations of these comparisons.

None of that takes away from what I like about the game. I wanted to bring back an opponent my father and I had played, not turn it into a modern champion.

The port now runs natively, speaks UCI and UCCI, and works in my Xiangqi GUI, Pikaboard. The repository includes the engine and smoke tests, but not the original game binaries, opening book, or artwork. Recovered numeric tables are included; NOTICE explains their provenance and the license scope.

An engine born in the same year as me gets to keep playing.

I started by asking Claude to rewrite it from screenshots. That got us a working game quite quickly, but some of the pieces were different from the original. To figure out which pieces should actually appear, I eventually had to download the old app, buy an iPhone, jailbreak it, and reverse engineer the executable. Then I got distracted by another idea: how well could an AI play this game?

The first attempt: rebuild what I could see

In March 2026, I gave Claude screenshots of the original game and asked it to recreate it. The rules are simple: drag a piece onto the board, and when a line is full, the blocks on that line disappear. On the hexagonal board, lines can run in three directions.

I asked Claude to reproduce the shapes and colors in the images. I used Flutter so I could run it on both the iPad and my Mac, and I called the remake Hexris. After a few rounds of fixing dragging and adjusting the piece sizes, it was playable.

However, after playing it for a while, we noticed that some pieces did not seem to belong. The remake generated shapes that we did not remember seeing in the original, and some were quite difficult to place.

I tried removing the shapes that seemed wrong. This improved the game, but I was still relying on memory. I did not know whether I had removed the right pieces, or whether the remaining ones appeared with the right frequencies.

At that point I wanted to find the original app and look at its code. There had to be a piece generator somewhere in it.

Recovering a delisted IPA

Getting a copy was harder than I expected. The app was no longer listed in either the Chinese or US App Store. I also thought I might have saved a copy on my Mac, but could not find one.

Fortunately, my wife’s Apple ID had acquired it in 2016. Although the listing was gone, Apple still had a copy available to that account. An archived store page helped us identify the App Store ID, 1052414239, and bundle ID, com.balabafire.1010hex.

I used ipatool-py to download it from Apple. The downloader needed some fixes because Apple’s authentication endpoints had changed, but eventually it worked. I got version 1.7, an IPA of about 11 MB.

Of course, an IPA downloaded from the App Store is still encrypted with FairPlay. Both the ARMv7 and ARM64 slices had cryptid 1. I could inspect the resources and some unencrypted data, but the code I needed was in the encrypted region.

Why a virtual iPhone was not enough

I did not have a jailbroken device, so I first looked into using Corellium. I hoped I could sign into the account on a virtual iPhone, launch the app, and dump the decrypted code there.

That did not work out. Corellium requires an already-decrypted IPA for this use; its virtual devices cannot run the encrypted App Store copy through the normal Apple services. I had the wrong half of the solution.

I bought an iPhone 8 Plus and jailbroke it with palera1n. Getting the phone into DFU mode took many attempts. I watched videos, retried the button sequence, and kept seeing the Apple logo. After replacing the USB cable, I finally got it working. I had spent quite a bit of time blaming my button timing.

I then signed into the account that had acquired the app and installed the encrypted copy using appinst, with AppSync Unified on the phone. It launched! This worked because the authorization to use the purchased app was tied to the Apple ID, rather than limited to the device on which it was originally downloaded. I could use that account on the newly bought iPhone to run the encrypted copy, even though the app was no longer listed in the store.

For the dump, I used ipadecrypt, which handled the device-side helper and produced a decrypted IPA for analysis. It used OpenSSH to communicate with the phone, with the USB connection forwarded through iproxy from libusbmuxd.

This was a nice discovery on its own. An app disappearing from the store does not necessarily mean its binary is lost. In this case, a previous purchase let me download it, and a compatible physical device let me run it. It still depends on Apple serving the app and on the old app working on the available iOS version. A purchase record alone cannot guarantee either of those things.

Reverse engineering the game

The game uses Cocos2d-x and native C++. Before decryption, we had already checked the resources for shape definitions. There were UI scenes and sprite atlases, but no gameplay scripts or per-piece images. The game draws pieces by repeating a single hexagonal sprite. The actual shapes were defined in the executable.

With the decrypted ARM64 code open in Binary Ninja, we could finally follow the catalog construction and random selection routines. The answer to my original question was quite specific: hex mode has 22 possible pieces, consisting of a one-cell dot and 21 four-cell shapes. Each entry is selected uniformly, with a probability of 1/22, or about 4.545%.

There were also two masks elsewhere in the configuration that looked like pieces, but they were not added to the active catalog. Simply collecting every shape-like constant would have given us the wrong answer. We needed to follow how the generator used them.

We also checked the surrounding rules. The board has 61 cells, with nine across the middle. Full lines clear along three axes. A used tray slot is replaced immediately, and the game ends when none of the three available pieces can fit. The level calculation does not change the active hex piece distribution in version 1.7; all 22 entries are already available at level one.

Scoring was another difference from the first remake. Ordinary placement gives no points. When a move clears lines, it awards:

distinct cells removed + lineCount × (10 + 5 × (lineCount - 1))

Intersections count only once among removed cells. The line bonuses are therefore 10, 30, 60, and 100 points for one, two, three, and four simultaneous lines.

The square mode turned out to use a different generator. It selects one of nine shape families using integer weights totaling 20, then selects an orientation uniformly within that family. For example, the dot and 3×3 square each occur 5% of the time, while the 2×2 square occurs 15%. Hex mode is simpler: all 22 active catalog entries are equally likely.

I asked AI to add the recovered rules to Hexris as an optional Classic mode, keeping Undo for convenience. The previous version remains the default, so we can play either one.

Then I wondered: can an AI play it?

After getting the rules working, I suddenly wanted to see how well an AI could play. I asked the coding agent to try a few approaches using a simulator of the recovered hex rules.

We compared random moves, a greedy player that evaluates one move at a time, a trained version of that evaluator, and two search methods that look ahead at possible future pieces. Each played the same 20 seeded games, with a limit of 1,000 moves per game:

Looking ahead helped much more than tuning the evaluator. Expectimax had the highest average score, with its best game reaching 10,346. Rollout had a slightly better median, but took more than twice as long.

I also tried a small neural network. Combined with search, it averaged 2,532 points in a separate test, versus 5,074 for the handwritten evaluator on the same seeds. So the neural version did not improve things this time.

Here is one complete expectimax game. It is a representative run rather than the longest one: 2,309 points over 235 moves. The three available pieces are shown below the board, and the gold outline marks the piece that was just played.

My wife’s best was around 6,000 points. This was not a controlled comparison, but it was fun to see some of the agents’ games exceed that score.

I originally expected to spend a little time getting Claude to draw a board and some pieces. I certainly did not expect to buy an old iPhone to find out which pieces belonged in it. But now I think it is totally worth the time and effort!

• Windows’ new age API is supposed to give an app only your age range
• The current implementation first obtains your date of birth, then calculates the range inside the requesting app’s process
• The requesting process can intercept the token or DOB

The API returns a range—but that is not the whole story

Windows Latest recently reported that Windows 11 will allow apps to request an age range without receiving the user’s birthday. Microsoft’s documentation describes GetUserAgeRangeAsync, which returns ranges such as 13–15, 16–17, or 18+.

On Windows 11 25H2 build 26200.9168, the API is present but currently returns E_NOTIMPL because a DigitalSafetyAPI feature flag is disabled. The implementation is already inside UserMgrProxy.dll, however, so I looked at what will happen after that gate is enabled.

The flow is:

requesting application
  -> UserMgrProxy.dll requests an ID token through WAM
  -> the token contains the birthdate claim
  -> UserMgrProxy.dll extracts the DOB
  -> it calculates the exact age
  -> it converts that age to a range
  -> the public API returns only the range

The relevant decompiled code is unambiguous:

if (DecodeJwtAndExtractClaim(
        token, tokenLength, "birthdate", &birthdate, ...))
{
    int32_t age = CalculateAgeFromDoB(&birthdate);
    memset(&birthdate, 0, sizeof(birthdate));
    if (arge >= 0)
      int64_t range = MapAgeToRange(age);
    // omitted...
}

In other words, Windows receives the DOB and derives the range locally.

The conversion happens inside the requesting process

This distinction matters because UserMgrProxy.dll is loaded into the process that calls the API. I confirmed this by invoking the API from PowerShell and observing C:\Windows\System32\UserMgrProxy.dll loaded in that same PowerShell process. The OAuth response, JWT, and decoded birthdate therefore enter the requesting application’s address space before being reduced to an age range.

This means the process can hook the JWT decoder or inspect its memory to obtain the user’s date of birth. There are plenty of ways to do this because the process has full control over itself, including the DLLs loaded into it.

Windows does perform capability, account, and caller checks. Those checks can prevent an unauthorized app from using the API, but they cannot hide data from an authorized app after Windows has placed that data inside the app’s own process.

I also downloaded and analyzed UserMgrProxy.dll version 10.0.29648.1000 from the latest available Windows preview build. Microsoft changed some internal plumbing, but the core mechanism for obtaining the age range remains the same. While Microsoft can change what it eventually enables or ships, there is currently no sign that it has replaced this design with a broker that returns only an age range.

The application should call a trusted Windows broker or Microsoft service that returns the age range directly. The DOB-to-range conversion should happen before any result crosses into the application’s process. It is surprising to see Microsoft make such a basic privacy-design mistake, even if temporarily.

Bring Your Own Vulnerable Driver (BYOVD) is a familiar Windows attack technique: an attacker loads a legitimate, signed driver and abuses a flaw in it to gain kernel-level capabilities. Microsoft maintains a vulnerable-driver blocklist to make this harder, while the community-maintained LOLDrivers project catalogs known vulnerable and malicious Windows drivers.

But sometimes the dangerous capability is intentional. A security or system-inspection driver may legitimately need to terminate processes, open privileged handles, or resist interference. Removing that functionality would break the product, so the driver must instead decide who is allowed to request it. Vendors therefore add caller authentication:

untrusted process ──X──> privileged driver operation

trusted client  ───────> privileged driver operation

This creates a second security boundary. The question is no longer only whether an untrusted executable can send a privileged IOCTL, but whether an attacker can take control of the trusted caller:

• Can code be injected into the trusted process?
• Can an attacker launch the trusted image while retaining a powerful creator handle?
• Can trust be inherited across processes, or remain valid after the process has been modified?

I call this pattern Bring Your Own Trusted Caller (BYOTC): instead of attacking the kernel interface directly, obtain code execution inside—or otherwise abuse—the user-mode program the driver already trusts, then make it invoke the privileged interface. The authorization check succeeds, but its security meaning has been lost. BYOTC is therefore a confused-deputy problem at the user/kernel boundary.

This post develops the idea through two case studies from my research: Malwarebytes’ mbamchameleon.sys and System Informer’s SystemInformer.sys. Their trust models differ substantially, but both illustrate the same lesson:

Establishing—and continuously preserving—the integrity of a process at runtime is hard.

Case study 1: Malwarebytes Chameleon

In June 2025, I reported a BYOTC issue in Malwarebytes’ mbamchameleon.sys (SHA-256: d86b9b20788b6bff70a1a4c4111b2ea33b9ec705cc6b8fe869362fc3899820a3). The driver exposed an IOCTL, 0x222024, that ultimately invoked ZwTerminateProcess. This was not a stray memory-safety bug: process termination was a feature of the driver.

The driver did not allow every process to use that operation. A caller first had to register as trusted through IOCTL 0x222008. My reverse engineering showed that this path checked whether the calling process’s image was signed by Malwarebytes.

The problem was that a valid signature describes the file that started the process; it does not prove that the process is still executing only Malwarebytes-controlled code.

For the proof of concept, I launched the legitimate, signed MBAM.exe, injected a DLL into it, registered that process as trusted, and then asked the driver to terminate Microsoft Defender’s MsMpEng.exe:

attacker (administrator)
        │
        ├── inject DLL ──> signed MBAM.exe
        │                        │
        │                        ├── IOCTL 0x222008: register trusted client
        │                        └── IOCTL 0x222024: terminate MsMpEng.exe
        │
        └────────────────> mbamchameleon.sys ──> ZwTerminateProcess

The proof of concept loads mbamchameleon.sys, injects into the signed Malwarebytes client, and uses the trusted process to terminate Microsoft Defender.

This case is the simplest form of BYOTC:

1. Bring the signed driver.
2. Bring its signed user-mode client.
3. Gain execution inside the client.
4. Let the client pass the driver’s signer check.
5. Invoke the driver’s intended privileged feature for an unintended purpose.

Malwarebytes disclosure timeline

• June 15, 2025: I submit my Chameleon report to Malwarebytes.
• July 2, 2025: Malwarebytes says my report duplicates an earlier report made by a different researcher.
• September 5, 2025: My report is closed as a duplicate.
• October 31, 2025: Malwarebytes says a fix is in progress and that I will be invited to retest after release.
• March 4, 2026: 180 days have elapsed since the report was closed.
• September 3, 2026: I publicly disclose my findings in this blog post. As of publication, no fix is available.

I do not blame Malwarebytes for not shipping a fix after a year. As we will see in the next case study, even systematic validation of the client process can still leave a gap.

Case study 2: System Informer and the evil parent

System Informer was the more interesting target because KSystemInformer already performed unusually thorough client validation. It assigned each client one of five cumulative process-integrity levels. The state definitions and KphGetProcessState show exactly what each level added:

System Informer uses its own message system for user-kernel communication, and each message declares the minimum integrity level required to execute it. On every request, KphpCommsMessageNotifyCallback recomputes the caller’s state and rejects the message if the process does not meet that requirement. For example, KphMsgTerminateProcess requires MAXIMUM, so only a client at that level can ask the driver to terminate a process.

This reduced my research question to two parts: How does SystemInformer.exe obtain MAXIMUM, and can an attacker get code execution inside that instance? The answer to the first part lies in how System Informer starts.

How The Truest Client reached MAXIMUM

Before following the startup sequence, it helps to see the complete set of checks required for a MAXIMUM process:

System Informer used three separate processes rather than gradually raising the trust level of one process. The sequence began when the user launched SystemInformer.exe with administrator rights. This first instance brought up the driver: KphConnect first tried to connect to an existing driver and, if none was available, created the kernel-driver service before starting it and connecting again.

1. The user launches SystemInformer.exe as administrator.
   This first instance loads SystemInformer.sys and connects to it.
   Because the driver started after this process was created, it can
   verify the image but cannot establish the full creation-time chain. → LOW

2. Because it is below HIGH, it starts SystemInformer.exe -kh.
   The driver observes this child from creation, verifies it,
   protects it against dangerous outside handles, and confirms
   that it is not being debugged and has loaded no untrusted images. → HIGH

3. Because the child is HIGH but not MAXIMUM, it starts
   SystemInformer.exe -kh -kx. Under the old rule, creation by a
   HIGH parent set SecurelyCreated; the child repeats all checks.      → MAXIMUM

4. The MAXIMUM instance can invoke the most privileged driver APIs.

The user-mode restart decisions are in KsiConnectDriver, while the old HIGH parent → SecurelyCreated child rule is in KphpPerformProcessTracking.

How the evil-parent attack broke the chain

The gap was a narrow exception in an otherwise strong design. Windows process creation requires the creator to retain powerful handles while initializing its child. System Informer’s object callbacks normally stripped dangerous rights from handles to protected clients, but KphpShouldPermitCreatorProcess permitted the actual creator extra rights, including PROCESS_VM_OPERATION and PROCESS_VM_WRITE. Duplication was blocked, but the creator could use its own handle directly.

An elevated malicious.exe could therefore create the legitimate -kh instance and modify it through the creator handle after it became HIGH. That compromised process could create the -kx instance, which the old rule promoted to MAXIMUM, and modify that child through the next creator handle. All image and runtime checks could pass even though control flowed from the evil parent into the trusted chain.

malicious.exe
    └─ creates and modifies ─> verified HIGH instance
                                  └─ creates and modifies ─> verified MAXIMUM instance
                                                                  └─> privileged driver APIs

Simply removing the creator exception was not practical: process initialization legitimately needed those rights and failed without them. The weakness was the combination of necessary Windows creation semantics with a trust rule that allowed a child to become more trusted than the process that still controlled its initialization.

How System Informer fixed it

The System Informer developers responded quickly, confirmed the gap, and designed a fix. The fix has two complementary parts.

First, the driver no longer treats a HIGH System Informer process as securely created merely because another HIGH process created it. The new process can advance into the maximum-trust chain only if its creator is already MAXIMUM, or if the creator is a protected process signed at Windows TCB/System level. This change is visible in KphpPerformProcessTracking, where the driver checks PsGetProcessProtection and accepts only PsProtectedSignerWinTcb or PsProtectedSignerWinSystem as the root of a new secure-creation chain.

Second, System Informer changed how it restarts itself. Rather than letting the weaker GUI process directly create the stronger instance, it creates a temporary service and asks the service path to perform the creation. The Service Control Manager runs services.exe as a WinTcb-protected process, providing an operating-system-backed root of trust. The user-mode side of this design is shown in the kph restart self through tcb commit.

The resulting chain is:

System Informer (< MAXIMUM)
        │ create and start temporary service
        ▼
services.exe (WinTcb PPL)
        │ create
        ▼
System Informer (HIGH)
        │ create
        ▼
System Informer (MAXIMUM)

Because the untrusted initiator does not receive the privileged creator handle to the trusted child, and handle duplication across the verified-process boundary is already prohibited, the evil-parent path is broken. A malicious ordinary administrator cannot manufacture the WinTcb-protected root that the driver now requires.

Two nearby hardening changes also made relevant state checks “sticky”: once a violation such as debugging or an untrusted image load is observed, temporarily removing that condition cannot restore the process’s earlier trust. That addresses the broader TOCTOU concern: trust should generally be monotonic in the direction of revocation.

System Informer disclosure timeline

• April 20, 2025: I privately report the evil-parent design gap.
• April 20–21, 2025: System Informer’s maintainers author the TCB-rooted secure-creation and service-restart changes during our technical discussion.
• February 1, 2026: The rebased equivalents of those changes enter the current public repository history.
• August 29, 2026: The maintainer confirms that the updated signed driver has shipped to the Release Channel and closes the disclosure loop.

A lesson from game anti-cheat

Game anti-cheat provides a useful comparison. Kernel anti-cheat drivers also try to determine whether a user-mode process remains trustworthy while an adversary actively attempts to modify or deceive it. Riot Games’ Vanguard architecture overview describes its driver as validating memory and system state and checking that the client has not been tampered with.

Anti-cheat and general-purpose utilities have different compatibility constraints, but the structural problem is the same. The never-ending contest between anti-cheat developers and cheat authors shows that runtime integrity is not a single check that can be perfected. A live process can be influenced through its memory, threads, loaded modules, handles, creation history, and even its view of the operating system. BYOTC brings this lesson to driver review: a recognized process is not a static identity, but a security-sensitive object whose integrity must be established and maintained over time.

How should BYOTC be fixed?

The strongest pattern I have found so far is to anchor trust in Protected Process Light (PPL). Ideally, the trusted client itself runs as PPL. A less direct design, like System Informer’s fix, roots the client’s creation chain in a PPL process and combines that origin with extensive runtime protections. In both designs, Windows—not the vendor’s driver alone—protects the root of trust from an ordinary administrator.

That is much harder to deploy than it sounds. Windows has a supported route for protected antimalware services, but it is not a general-purpose “make this process PPL” switch. It requires an ELAM driver and strict certification and code-signing arrangements. A protected antimalware service can also launch a protected child, but this remains a specialized service model. It is a poor fit for an on-demand system utility such as System Informer, which instead used the already-protected services.exe as the root of its launch sequence.

That solution is impressive, but it is also complicated and product-specific. I would not expect every affected software to reproduce it correctly, especially products that currently rely on a simple caller check. For software that cannot run its client as PPL, a broadly reusable answer is still missing. In that sense, I increasingly see BYOTC as a platform problem for Microsoft: Windows needs a supported way for a driver to grant sensitive capabilities to a user-mode principal whose runtime integrity the operating system can preserve.

Microsoft is already working on an adjacent problem. The Windows Endpoint Security Platform is intended to move more antivirus enforcement from third-party kernel drivers into user mode. Reducing kernel code is valuable: a bug in user mode is less likely to crash or corrupt the operating system. But moving an operation out of a vendor driver does not, by itself, answer the BYOTC question. If a privileged service still authenticates a client process that an attacker can modify, the attacker may inject into that trusted client and make the same privileged request from there.

macOS offers a useful contrast. Its security model binds entitlements to a process’s code signature, while the Hardened Runtime enables library validation by default. Apple documents that library validation rejects external code unless it is signed by Apple or by the same team as the main executable. This is not identical to PPL, and it does not make injection impossible, but it makes loading unsigned code into a trusted client substantially harder. Windows does not currently give ordinary third-party applications an equally simple equivalent for this use case.

For antivirus and EDR developers, BYOTC should be treated as an emerging attack surface. Defensively blocking known-abusable drivers can remove obvious building blocks. If your own driver exposes legitimate but dangerous operations, test more than whether the caller’s executable is signed: determine whether an attacker can take control of the trusted client or exploit a trust transition. If you are working on this problem, developing an affected product, or believe you have a more general solution, please feel free to Contact me – I would be happy to chat.

BYOTC also deserves a large-scale study across the Windows driver ecosystem. Related research on vulnerable and abused drivers includes:

• Screwed Drivers—Signed, Sealed, Delivered
• Breaking Boundaries: Investigating Vulnerable Drivers and Mitigating Risks
• Exploring vulnerable Windows drivers
• POPKORN: Popping Windows Kernel Drivers At Scale
• Finding vulnerable drivers with hooking and reading result verification
• Unveiling BYOVD Threats: Malware’s Use and Abuse of Kernel Drivers
• The Windows IOCTL Census: A Corpus-Scale, Multi-Architecture Database of the Driver Control-Code Surface
• IOCTLance: Enhanced Vulnerability Hunting in WDM Drivers with Symbolic Execution and Taint Analysis
• Building a Scalable Windows Driver Vulnerability Analyzer
• 100+ Kernel Bugs in 30 Days

A similar corpus-scale study of trusted user-mode clients would help determine how widespread BYOTC is across the Windows driver ecosystem: how many drivers authorize privileged operations this way, and how many of those trust boundaries can be bypassed.

Conclusion

BYOTC targets the trusted user-mode client of a privileged driver. Malwarebytes showed the direct version—injecting into a signed client—while System Informer showed how a process-creation trust chain could be hijacked. Both cases demonstrate how hard it is to preserve a process’s integrity at runtime.

I have also found a third BYOTC case study, which remains under embargo. If coordination proceeds as expected, I will publish its technical analysis and disclosure story later in September 2026.

• Zoom can notice that Google Meet, Teams, Slack, and other applications may be in a meeting and offer to start My Notes
• On macOS, Zoom monitors Control Center’s sensor-indicators log stream
• The messages contain records such as [mic] Google Chrome (com.google.Chrome)
• Zoom extracts an application identity and detects when microphone use starts or stops
• On Windows, it obtains equivalent application-usage information from the per-user Capability Access Manager microphone records in the registry
• Reading this metadata requires neither administrator/root privileges nor Zoom microphone permission

Why does Zoom know that Chrome is using the microphone?

Zoom’s My Notes feature can take notes during meetings hosted in applications such as Google Meet, Microsoft Teams, and Slack. Before the user starts it, Zoom can display a Take Note prompt when it thinks a third-party meeting is in progress.

That raised an interesting question: how does Zoom recognize the other application before it has started taking notes?

The answer differs by platform. On macOS, Zoom parses human-readable Unified Logging output. On Windows, it enumerates microphone-usage records in the registry.

The macOS detector

I statically analyzed the arm64 build of Zoom Workplace 7.1.5 (84650).

The implementation is in a class named PrivacyEventMonitor inside viper.framework. Its relevant methods are:

-[PrivacyEventMonitor startMonitoring]
-[PrivacyEventMonitor handleLogOutput:]
-[PrivacyEventMonitor parseSystemLogLine:]
-[PrivacyEventMonitor parseAttributionsStringForMicrophone:]
-[PrivacyEventMonitor notifyMacAppStateChange:previousStates:]

startMonitoring launches /usr/bin/log:

/usr/bin/log stream \
  --type log \
  --level default \
  --predicate 'subsystem == "com.apple.controlcenter" AND category == "sensor-indicators"' \
  --style compact

macOS Control Center maintains the orange and green privacy indicators for microphone and camera use. The same subsystem writes the currently responsible applications to Unified Logging. A microphone record for Chrome looks like:

Sorted active attributions from SystemStatus update: [mic] Google Chrome (com.google.Chrome)

macOS has already supplied the display name and bundle ID. Zoom keeps entries marked [mic], parses those two fields, and compares each new attribution list with the previous one. An application appearing or disappearing becomes a microphone-start or microphone-stop event; no audio analysis is involved.

From Chrome to Google Meet

The UI layer contains a product category named chrome, labels it Google Meet, and applies notification and per-application blacklist settings. The overall flow is:

Chrome opens the microphone
  -> macOS updates Control Center's sensor attribution
  -> Control Center emits a sensor-indicators log record
  -> Zoom extracts “Google Chrome” and “com.google.Chrome”
  -> Zoom detects an application-state transition
  -> product mapping and notification policy
  -> optional “Take Note” prompt

This is more accurately called microphone-use detection than meeting detection. Chrome could be accessing the microphone for a reason unrelated to Google Meet. Zoom’s higher layers decide whether the signal should produce a prompt.

The Windows detector

I also statically analyzed Zoom Workplace for Windows x64 7.1.8.46825. Its detector is in viper_async_device.dll and reads this per-user registry key:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\
CapabilityAccessManager\ConsentStore\microphone

Zoom opens the key with KEY_READ, enumerates packaged application entries and the NonPackaged subtree used by classic desktop applications, and queries each entry’s 64-bit LastUsedTimeStop value. A zero value represents an access interval that has not ended, so Zoom treats that application as currently using the microphone.

The Windows flow is therefore:

Chrome opens the microphone
  -> Windows updates ConsentStore\microphone\NonPackaged
  -> LastUsedTimeStop remains zero while access is active
  -> Zoom enumerates the registry records
  -> Zoom identifies Chrome's executable
  -> product mapping and notification policy
  -> optional “Take Note” prompt

This part uses ordinary registry APIs. I found no ETW consumer, audio-session observer, or PCM processing in the application-attribution routine. Static analysis does not establish its polling interval, the feature flags controlling it, or whether detection metadata is included in telemetry.

Does this require permission?

I tested Zoom’s exact /usr/bin/log stream predicate as an ordinary user, without sudo, and macOS accepted it. Reading the records did not require Microphone, Screen Recording, System Audio Recording, or Accessibility permission.

On Windows, the key is under HKEY_CURRENT_USER and Zoom requests only KEY_READ, so it likewise requires neither elevation nor microphone access.

Neither mechanism should be treated as a stable application API. Zoom depends on undocumented macOS log formatting and Windows registry implementation details that either operating-system vendor could change.

It is a clever use of privacy bookkeeping that both operating systems already expose—and a reminder that privacy indicators can themselves become a source of cross-application activity information.

• Teams has a feature that can detect third-party recording and AI note-taking applications during a meeting
• On Windows and macOS, it enumerates running processes every 30 seconds and compares their names with a classification table
• The local user sees the detected application name
• Eligible meeting participants are told which participant may be recording, but not which application was found
• Separate Microsoft telemetry contains the matched app name, type, and risk level
• Microsoft can update the table remotely through its Experimentation and Configuration Service (ECS)
• It only runs in meetings where the host organization’s policy enables it; the default is off
• This detector is separate from Teams’ “Prevent screen capture” feature

Does Teams know I opened OBS?

Microsoft introduced Prevent Screen Capture in September 2025. That part was fairly conventional. Teams uses Windows window-content protection, including SetWindowDisplayAffinity, and propagates the protection to meeting pop-out windows. It is a useful speed bump, but it is easy for a sufficiently uncooperative client to bypass.

While looking through the client, however, I found something more interesting: RecordingDetectorModule.

The current Teams client contains a process classification table with entries for OBS, ShareX, Snipping Tool, Camtasia, Bandicam, Loom, Snagit, XSplit, AI note-takers, audio tools, browsers, and a surprisingly broad supporting cast.

For example, the built-in Windows rules include:

{
  "name": "obs64",
  "displayName": "OBS Studio",
  "appType": "ScreenRecorder",
  "risk": "High",
  "expected": false
}

The complete built-in Windows list contains 167 process names:

Full built-in Windows list (167 entries)

High (33): Airgram, Avoma, Chorus, Fathom, Fireflies, Gong, Grain, Read AI, Tactiq, CamtasiaStudio, handy, Krisp, LogiCapture, ManyCam, natspeak, obs32, obs64, Otter, ShareX, voiceai, willow voice, Camtasia, Loom, obs, streamlabs, XSplit, XSplit.Core, Zoom, Zoom.exe, murmure, OpenWhispr, Typeless, Wispr Flow.

Medium (24): Action, Audacity, bdcam, CamRecorder, copilot, copilot.exe.old, Debut, FlashBack, GoldWave, M365Copilot, mscopilot, NVIDIA Share, Resolve, ScreenPal, ScreenToGif, Snagit32, SnagitEditor, SnippingTool, SoundRecorder, WavePad, Ableton Live 12 Suite, Adobe Premiere Pro, Aximmetry.Composer, MOTIV Mix.

Low (76): ffmpeg, ffplay, ffprobe, nvcontainer, VoiceMeeter, VoiceMeeter8, chrome, Code, firefox, GoXLR App, msedgewebview2, msrdc, mstsc, NVIDIA Broadcast, proximity, python, qemu-system-x86_64, rundll32, SoTGame, SteelSeriesSonar, Unity, voicemeeter_x64, brave, msedge, iCUE, Elgato.WaveLink, FxSound, LogiTune, SilencePlayer, SoundKeeper64, comet, opera, PrismaAccessBrowser, thorium, vivaldi, waterfox, Figma, thunderbird, Signal, Telegram, Viber, WeChat, Weixin, WhatsApp.Root, XboxPcApp, Zoiper5, AzureKinectServer, github, scrcpy, conhost, powershell, WindowsTerminal, RuneLite, UnrealEditor, UnrealGame-Win64-Shipping, GoTV, Photos, cloudmusic, QQMusic, Spotify, vlc, Microsoft.Media.Player, wmplayer, dcvagent, rdcx, RDCMan, vmware-vmx, Windows365, VoiceAssistant, jfw, fsSynth32, nvda, wfica32, vmconnect, horizon-protocol, LiftComponent.

None / expected (34): POWERPNT, TextInputHost, audiodg, CiscoCollabHost, Cortana, Discord, g2mcomm, GoToMeeting, HdxRtcEngine, Microsoft Teams, ms-teams, ms-teams_modulehost, MsMmrHost, MsTeamsVdi, RuntimeBroker, SearchHost, ShellExperienceHost, Skype, SkypeApp, Slack, svchost, System, SystemSettings, Teams, webexmta, EXCEL, OUTLOOK, Todo, WINWORD, LiveCaptions, Narrator, osk, VoiceAccess, RtkAudUService64.

What happens after a match?

When the native detector reports a match, the meeting JavaScript applies the configured app-type and risk-level filters, then stores the remaining app names, types, and risk levels locally.

The defaults in the JavaScript are:

const displayRiskLevels = externalRecordingDisplayRiskLevels ?? ["Medium", "High", "Critical"];
const publishRiskLevels = externalRecordingMetaDataPublishRiskLevels ?? ["High", "Critical"];

OBS is classified as High, so it qualifies for both.

The user running the matched application gets a dismissible warning. It is quite direct:

You are capturing meeting with OBS Studio
An app on your device has been detected to be listening or recording this meeting. Others in the meeting have been notified about this.

Teams then invokes this GraphQL mutation when metadata publication is enabled:

mutation ($teamsCallId: ID!, $isRecording: Boolean!, $recordingCount: Int!) {
  publishLocalExternalRecordingState(
    teamsCallId: $teamsCallId
    isRecording: $isRecording
    recordingCount: $recordingCount
  )
}

The mutation includes neither the process name, application type, nor risk level. Other clients receive participant state containing externalRecording.isRecording and use it to render an indicator:

This meeting is being captured
An external app on Alice’s device may be recording or listening to this meeting.

Who can see it is separately feature-gated. Depending on externalRecordingVisibility, it can be available to everyone or limited to organizers and co-organizers.

Telemetry and remote configuration

There is a second outbound path. The client emits an external_recording_detected_apps telemetry event containing detector matches shaped as:

[
  {
    "appName": "OBS Studio",
    "appType": "ScreenRecorder",
    "riskLevel": "High"
  }
]

Microsoft’s telemetry therefore receives richer information about the matched application.

Microsoft can also change the process list without shipping a Teams update. The hard-coded JSON is the built-in default, but Teams fetches configuration from Microsoft’s Experimentation and Configuration Service (ECS), including:

recordingDetectorClassificationsWin
recordingDetectorClassificationsMac
recordingDetectorPollIntervalMs
recordingDetectorStopTimeoutMs
recordingDetectorUnknownRiskLevel
recordingDetectorUnclassifiedRiskLevel

The response is cached locally in ecs_settings.dat64. If Microsoft supplies a valid classification list, the client uses it; if parsing fails, native logging says it uses the built-in table.

How detection runs

An organization administrator can enable the feature with the EnableExternalRecordingDetection meeting policy, which defaults to false. Microsoft says it detects third-party screen recorders, audio recorders, and AI note-takers and notifies participants, but does not document the implementation details discussed here. It only runs during an eligible active meeting and stops when the call ends. This policy is independent of Prevent Screen Capture.

On Windows, Teams takes an initial process snapshot with CreateToolhelp32Snapshot, walks it with Process32FirstW and Process32NextW, and uses ProcessIdToSessionId and QueryFullProcessImageNameW to identify processes in the applicable session. It repeats this every 30 seconds by default and compares the names with its configured list. This establishes that a listed process is running, not that it has started recording.

macOS does the same thing

I also checked out how it works on the macOS version. The detector lives in the main MSTeams Mach-O, which helpfully contains its original source path:

native_modules/mods/recordingdetector/mac/mac_detection_module.cpp

It imports process-enumeration facilities including sysctl, getuid, proc_pidinfo, and proc_pidpath, performs periodic process snapshots, and applies recordingDetectorClassificationsMac. It does not need macOS Screen Recording permission because it is reading process information, not the screen.

The built-in Mac list includes:

System processes such as coreaudiod, WindowServer, and ReplayKit’s replayd are expected and assigned None risk.

Thinking about secretly recording a Teams meeting? Think twice—the other participants might find out.

• I collected 38 UCPD.sys binaries representing 24 versions
• UCPD first shipped in August 2023, seven months before its public discovery
• It grew from a 29 KB browser-association filter into a 196 KB registry and process policy engine
• Later versions added ACL, rename, injection, UI Automation, backtrace, and dynamic-rule defenses
• Versions 4.4–4.7 added cross-device resume, gaming, FeatureV3, and an expanded deny list

Going backward

My recent article examined how the Dynamic Rules (DR) work in the UCPD driver, and earlier research by Christoph Kolbicz, Gunnar Haslinger, and me captured individual stages of its development. The remaining piece was to track how the driver evolved over time.

So I used Winbindex to locate and retrieve 38 reconstructable x64 UCPD.sys files from Microsoft’s public symbol server. Microsoft had removed the corresponding PDBs for most versions, so the comparison relied on the binaries rather than symbol information. The files cover 24 versions, and I compared adjacent versions.

Most of this work was performed by Codex using Binary Ninja’s MCP integration. I was quite surprised by its ability to diff binaries without specialized tools such as BinDiff and BinExport.

UCPD was already in Windows in August 2023

The oldest indexed binary is UCPD.sys version 1.0.1.383513. Winbindex associates it with Windows 11 22H2 preview update KB5029351, released on August 22, 2023.

That is about seven months before the reports that led to UCPD’s public discovery.

The distinction is important. Early 2024 appears to be when Microsoft activated or broadly rolled out the protection, not when it wrote the driver. Microsoft had already been developing and servicing UCPD in public Windows packages for months.

The first version was not an empty shell, either. It was a 29,184-byte driver with 58 unwind-described functions. Its strings and code identify the essential design:

Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice
Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice

RemoveUserChoice
RenameUserChoice
OriginalFilename

*\dllhost.exe
*\reg.exe
*\rundll32.exe
*\svchost.exe

In other words, version 1.0 already knew which registry keys represented the default browser, distinguished operations against them, and had a list of Microsoft utilities that should not be trusted merely because Microsoft signed them.

The architecture that would define UCPD was present from the beginning:

registry operation
      |
      v
is this a protected key?
      |
      v
is the requesting executable trusted?
      |
      +-- not Microsoft-signed -> deny
      |
      `-- Microsoft-signed
              |
              `-- utility deny list -> deny

Everything that followed made the protected surface wider and made the definition of “trusted” much harder to fool.

The complete growth curve

The driver grew almost sevenfold over three years:

Function counts come from the x64 exception directory. They are not a perfect source-level function count, but they are consistent enough to show the scale of each transition.

Windows servicing branches do not form a perfectly linear history. The same logical version can appear as multiple binaries for 22H2, 24H2, 25H2, or 26H1, and release dates can cross. I therefore treated file version and policy contents as the primary ordering and used KB dates as supporting provenance.

Version 2: no longer just the default browser

Version 2.0 added the first major expansion:

Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\UserChoice
SOFTWARE\Microsoft\Windows\CurrentVersion\Control Panel\DeviceRegion
FeatureV2

It also introduced UserChoiceLatest and UserChoicePrevious forms for HTTP, HTTPS, and PDF. UserChoiceLatest would not become operationally important until much later, when Windows enabled its new association-hash rotation design. Christoph eventually documented that migration in UserChoiceLatest – Microsoft’s new protection for file type associations.

The code had been waiting in UCPD since 2023.

The deny list also changed. Version 2 removed svchost.exe and added powershell.exe and regedit.exe. Version 2.1 added wscript.exe and cscript.exe; version 2.2 added cmd.exe.

Version 2.1 was also where UCPD visibly escaped its name. It added registry rules for Windows UI features:

SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds
SOFTWARE\Microsoft\Windows\CurrentVersion\NandI
Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced

ShellFeedsTaskbarViewMode
IsFeedsAvailable
TaskbarDa

At that point, “User Choice Protection Driver” was already becoming a misleading description. It was protecting choices, but they were no longer limited to file associations.

Version 3: defending trusted processes from other processes

The jump from 2.2 to 3.0 is the first enormous one: 41 KB became 86 KB and 74 functions became 143.

This is where the problem changed from “who made this registry call?” to “can I trust what is running inside the process that made it?”

Version 3 added process and publisher vocabulary for Kingsoft, Qihoo/360, Edge, Explorer, and Opera. It classified selected processes and used object callbacks to prevent particular vendors from injecting into trusted Microsoft processes or driving the Settings UI through desktop journal playback.

The driver also expanded its registry surface to Search and Taskband, while the deny list gained InfDefaultInstall.exe and pwsh.exe.

Version 3.1 is an interesting reminder that this history is not monotonic. One 3.1 build contains the Copilot BrandedKeyChoiceType rule; another removes its path and value strings. Version 4.0 restores them. That looks like branch divergence or A/B feature experimentation rather than a feature being implemented once and permanently enabled.

The manager confirms the feature-driven design. I recovered the original UCPDMgr input from my old Binary Ninja database, then downloaded its matching PDB from Microsoft’s symbol server. Its feature traits include:

UCPD
UCPDV2
UCPD_PRONG1
UCPD_PRONG2
UCPD_TASKBAR
UCPD_WSB
UCPD_ANTIUIA
UCPD_ANTIINJECTION
UCPD_NEWDENYLIST
UCPD_RENAME_ATTACK

UCPDMgr did not invent the policies. It translated Windows Feature Staging decisions into the FeatureV2 mask consumed by the driver.

Version 4.1: a general registry integrity engine

Version 4.0 broadened the publisher and regional policies, but 4.1 is the more important conceptual transition. It added:

• unknown-file/OpenWith handler repair
• .htm and .html associations
• Word, Excel, and PowerPoint associations
• UserChoiceLatest\ProgId rules
• registry security and ACL operations
• explicit delete and rename handling for the new families

The Unknown handler is especially illustrative. Windows expects these keys to launch the real OpenWith.exe:

SOFTWARE\Classes\Unknown\shell
SOFTWARE\Classes\Unknown\shell\open\command
SOFTWARE\Classes\Unknown\shell\openas\command

UCPD contains the expected command, DelegateExecute CLSID, and dedicated UnknownModify, UnknownDelKey, and UnknownRenKey paths. This is not about choosing a browser. It is registry integrity protection against replacing a trusted shell action with an attacker-controlled command.

Version 4.1 also removed the remaining UserChoicePrevious strings. Windows kept UserChoiceLatest; the earlier fallback design apparently did not survive.

Version 4.2: a signed policy channel appears

Version 4.2 grew from 119 KB to 135 KB and added the machinery that led to my dynamic-rules article:

\REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Services\UCPD\DR

Base64Decode
ParsePEFormat
CalculatePEHashInMem
CertificateVerify
DecryptData
DispatcherConfig

AntiInjection
AllowListV1
DenyListV1

The registry value is a Base64-encoded, data-only PE. UCPD parses it, verifies its Microsoft signature, decrypts the .rdata, and dispatches nested TLV records into independent policy structures.

This solved an operational problem for Microsoft. Before this mechanism, changing UCPD policy required a new driver and usually a reboot. A signed registry policy can change deny/allow, injection, UI Automation, or stack-trace rules independently.

The same version also contains explicit paths for protecting the UCPD service and DR key themselves. A remotely updatable kernel policy is only useful if another administrator-level process cannot replace its input.

Version 4.3: trust the original file and the entire stack

Version 4.3 added two names that summarize the next defenses:

ParseOriginalFileName
StackTrace

The original UCPD trust rule had a wonderfully simple weakness: copy a Microsoft binary under another name. Its signature remained valid, but it no longer matched the utility deny list. VMware even used this approach for its default-association tooling.

The OriginalFilename check closes that gap by reading the PE version resource and comparing the program’s real name rather than trusting its current path.

The stack check addresses the other obvious route. Even if the registry write originates in SystemSettings.exe, UCPD can walk the stack, identify the loaded modules behind the call, and reject the operation when a blocked publisher appears in the chain.

At this point, the trust decision looked more like this:

registry operation
      |
      +-- protected path/value/operation?
      |
      +-- Microsoft-signed caller?
      |
      +-- denied utility by path or OriginalFilename?
      |
      +-- blocked process/publisher classification?
      |
      +-- suspicious module publisher in stack?
      |
      `-- allow or deny, then emit telemetry

Version 4.4: CrossDeviceResume

Version 4.4 introduced a previously undocumented rule family named CrossDeviceResume. It protects five path/value pairs:

In the later driver, this family is controlled by FeatureV2 bit 0x08000000 and has a dedicated CrossDeviceResume ETW label.

The names strongly suggest protection against spoofing a cross-device resume notification: which app it claims to represent, its icon, whether it is installed, and its notification state. I have not found public documentation for this internal registry schema, so that interpretation is an inference rather than a confirmed product contract.

Version 4.4 also adds regini.exe to the hardcoded deny list and makes the dynamic loader’s CertificateVerify stage explicit in its event vocabulary.

Version 4.5: GamingConfiguration

Version 4.5 added another complete policy family:

Software\Microsoft\Windows\CurrentVersion\GamingConfiguration
    DefaultGamingApp
    DefaultToGamingExperience

This is controlled by FeatureV2 bit 0x40000000. Unlike a coincidental registry string, it has dedicated paths for every important operation:

SetGameConfig
DelGameConfig
RenameGameConfig
DeleteGameConfigValue
GameConfig

Microsoft’s current Gaming Configuration documentation describes an OEM-configurable full-screen gaming experience, including the gaming-home app launched at startup. The public setting names differ, but DefaultGamingApp and DefaultToGamingExperience line up closely with that design.

The security motivation is sensible: a third-party program should not silently install itself as a shell-like gaming launcher or force the device to start in that experience.

Version 4.6: FeatureV3 and the broken cipher

Version 4.6 adds three particularly revealing strings:

FeatureV3
SHA512
Unknown publisher

FeatureV2 is a 32-bit REG_DWORD, and by this point Microsoft had assigned nearly every bit. FeatureV3 is a separate 64-bit REG_QWORD. The 4.7 manager’s public PDB identifies its writer exactly:

SetFeatureV3Status(__int64 mask)

It currently maps seven Windows feature IDs into bits 0 through 6. The feature traits have only numeric names, so the PDB tells us their IDs but not their product descriptions. The driver consumes those bits in its rule database and in several distinct enforcement paths.

This also dates the dynamic-rule crypto bug more precisely.

The captured DR policy was encrypted using the old MD5-derived CS64 algorithm. Version 4.6’s consumer uses SHA-512 to derive its state. The policy consequently decrypts to garbage. The loader existed in 4.2, while the incompatible SHA-512 change appears in 4.6.

That does not prove the entire mechanism can never work. It proves that the captured producer and this consumer disagree. Microsoft could correct the policy producer without changing UCPD again.

Version 4.7: the dynamic deny list becomes the baseline

The DR sample contained 14 denied Microsoft utilities:

dllhost.exe          reg.exe             rundll32.exe
powershell.exe       regedit.exe         wscript.exe
cscript.exe          cmd.exe             InfDefaultInstall.exe
pwsh.exe             wmiprvse.exe        regini.exe
bssafe.exe           mshta.exe

In 4.6, the last two existed only in the captured dynamic policy. Version 4.7 adds bssafe.exe and mshta.exe to the driver’s hardcoded strings, so the static and dynamic lists finally become identical.

Version 4.7 also adds generic matching vocabulary:

*\UserChoice
*\ProgId
*\UserChoiceLatest
\ProgId

The explicit paths are still present, but these patterns suggest Microsoft was consolidating parts of the association matching logic rather than continuing to special-case every suffix.

What changed, conceptually?

Looking across all versions, UCPD evolved through four different jobs:

1. Association filter — protect HTTP and HTTPS UserChoice from simple registry writes.
2. Shell-setting filter — protect PDF, DeviceRegion, Feeds, taskbar, Search, Copilot, and Office associations.
3. Process integrity system — track processes, publishers, loaded modules, injection rights, UI Automation, original filenames, and call stacks.
4. Updatable policy engine — accept Microsoft-signed rule blobs and protect its own configuration.

The name stayed the same while the product changed underneath it.

The pattern of additions also looks much less arbitrary when placed on a timeline. Many changes are direct answers to a bypass:

It is an arms race preserved in version history.

How I built the corpus

I queried Winbindex for every indexed x64 UCPD.sys, then downloaded the available PE reconstruction from Microsoft’s symbol server. For each entry I recorded:

• indexed original SHA-256
• downloaded-file SHA-256
• file version and size
• Windows branch, KB, build, and release metadata
• PE sections and imports
• exception-directory function count
• ASCII and UTF-16 strings
• CodeView/PDB identity
• additions and removals relative to the adjacent version

Microsoft no longer serves the corresponding UCPD PDBs for most of this corpus, so this comparison did not depend on symbols. I grouped equivalent branch builds, ordered the remaining versions, and compared their strings, imports, and PE metadata. For important additions, I followed the string references into the machine code to confirm that they created real rules rather than being unused text.

There is an important provenance detail here. The Microsoft symbol server sometimes reconstructs the executable without its original Authenticode certificate overlay. Consequently, the downloaded file can differ from the original indexed SHA-256 and may report NotSigned even though it came from Microsoft’s symbol infrastructure.

I kept the two hashes separate and did not treat every reconstruction as independently signature-valid. Several original binaries recovered from my older .bndb files still retain their exact signatures, as does the current locally installed pair.

I also gave Codex access to the Binary Ninja databases from my earlier UCPD research, covering snapshots from March 2024 through June 2026. Symbols for UCPD.sys were missing for most versions, but Microsoft still served matching PDBs for the corresponding UCPDMgr.exe files. Those manager symbols exposed feature traits and helper names that offered another view into the changes, while the driver comparison itself remained symbol-free.

Conclusion

Following one binary over time tells a different story from analyzing one version deeply.

UCPD began as a small, narrowly focused registry filter at least as early as August 2023. Each generation responded to another way software could influence a supposedly trusted registry operation. By 2026 it had become a region- and feature-dependent kernel policy engine that watches registry operations, process creation, loaded images, object handles, UI Automation, publishers, original filenames, and stacks—and can consume signed policy from the registry.

The most interesting additions are not even about the default browser anymore. Cross-device resume prompts and the default gaming experience are now part of the same protection framework.

I suspect FeatureV3 is a good indication of what happens next. FeatureV2 ran out of room, but Microsoft is clearly not finished adding rules.

References

• The Binary Hiding in Your Registry: Cracking Windows UCPD’s Dynamic Rules
• Inside Windows’ Default Browser Protection
• UCPD.sys – UserChoice Protection Driver Part 2
• UserChoice Protection Driver – UCPD.sys
• UserChoiceLatest – Microsoft’s new protection for file type associations
• KB5121767 Enables Additional UCPD.sys Features on Windows 11 Enterprise
• Windows UserChoice Protection Driver UCPD
• UCPD analysis databases and tooling
• Winbindex

• Microsoft Paint supports both local and cloud image generation
• Paint and Photos also ship local AI models
• The two apps send the prompt to a remote server for moderation
• The server returns a GUID along with the moderated prompt
• The GUID is embedded into the locally generated image as an invisible watermark
• A separate visible-watermark setting does not control this invisible watermark
• On Copilot+ PCs, image generation is local but prompt moderation remains remote
• Microsoft discloses that Paint adds C2PA metadata to AI-generated images
• AI-generated image saves limited to C2PA-preserving formats: PNG, JPEG, GIF, and .paint

A curious look at Microsoft Paint

This research started with my curiosity about Paint. I recently had some success looking into less-explored Windows features like UCPD, WHESCVC, and I have long known that Microsoft added a bunch of AI features into the Paint app. I do not know if anyone actually uses Paint + AI to generate images, but I wanted to see how exactly the image generation works.

Before I started, I expected that it simply called a remote API to do the image generation. However, after I set up Binary Ninja MCP with Codex and started the analysis, I soon realized that Microsoft actually shipped local models in Windows as part of Copilot.

The Paint App is sitting in the following path (yes, they are all Windows Apps now):

C:\Program Files\WindowsApps\Microsoft.Paint_11.2605.71.0_x64__8wekyb3d8bbwe\PaintApp\

And there are four apparent model files with the .onnxe extension:

seg.onnxe          23.1 MB
inseg_enc.onnxe    28.0 MB
inseg_dec.onnxe    16.5 MB
mager.onnxe       302.4 MB

The format of seg.onnxe was previously known, i.e., when it is XORed with the string Microsoft_2023, it becomes a normal ONNX file. However, the format of the other three .onnxe files initially looked different.

It turned out that Microsoft had not changed the algorithm, only the key. segapi.dll contains a small key registry:

ps_enc_key.1.0.80-main -> "Microsoft_2023"
ps_enc_key.1.0.81-main -> a 4,096-byte alphanumeric string

After decryption, onnx.checker.check_model() works on all of them:

A visible watermark

While walking through these files, I found a Watermarker.dll:

This is not super surprising to me, because while I interacted with the Paint app, I already discovered that it has a setting to embed a visible watermark to the image that it produces:

The visible watermark is just a small Copilot logo at the bottom right of the image, which is totally normal.

Then, out of nowhere, I decided to ask AI to analyze the DLL and see if it could also be embedding an invisible watermark. This is part of my intuition as a reverse engineer, because the file is 1.67 MB in size, which is unusually large for such trivial functionality (arguably, the visible watermark does not even require a separate DLL). Apparently, the recent Claude Code text-watermark announcement also played a role in prompting me to think about this possibility.

An invisible watermark

To begin with, the visible watermark is added by AddPerceptibleWatermark:

CPBDoc::Save(...)
  |
  `-- perceptible-watermark save helper(bitmap, WatermarkSetting)
        |
        +-- WatermarkSetting::Never
        |     `-- return the original bitmap
        |
        +-- WatermarkSetting::AskEveryTime
        |     `-- show the Yes / No confirmation popup
        |           +-- No: return the original bitmap
        |           `-- Yes: continue
        |
        `-- Always or confirmed Yes
              +-- Paint::AI::GetPerceptibleWatermarkSvg()
              `-- Paint::AI::AddPerceptibleWatermark(bitmap, SVG stream)
                    `-- composite the visible Copilot logo

Then there is also a different WmkWriteWatermark function:

Watermarker.dll!WmkWriteWatermark(
    output_pixels,
    payload,
    payload_length,
    width,
    height,
    stride,
    input_pixels,
    pixel_format);

Tracing the call tree, we can see WmkWriteWatermark is called after a local Stable Diffusion image generation. And if WmkWriteWatermark fails, Paint converts the entire generation into an error rather than returning the image without it:

CocreatorViewModel::GenerateImageAsync(...)
  |
  `-- Paint::AI::StableDiffusionHelpers::GenerateAsync(..., watermarkId, ...)
        |
        `-- Microsoft.ImageCreation.ImageGenerator
              |
              `-- NPU-generated image result
                    |
                    +-- output safety/moderation checks
                    |
                    +-- Paint::AI::AddWatermark(bitmap, watermarkId)
                    |     |
                    |     `-- Watermarker.dll!WmkWriteWatermark(...)
                    |           |
                    |           +-- success: return the watermarked bitmap
                    |           `-- failure: turn generation into an error
                    |
                    `-- construct successful StableDiffusionResult

Then it is natural to ask what the incoming payload actually is. It quickly becomes apparent that it must be 16 bytes:

if (payload_length < 16)
    return -6;

if (payload_length > 16)
    return -5;

It is funny to me that the code is using two different error codes when the payload is too short or too long. The function then ignores the length parameter and uses a hard-coded loop bound when it copies the payload:

for (size_t i = 0; i < 16; i++)
    message.push_back(payload[i]);

We do not yet know what the 16-byte payload is, but as we will see later, it is a GUID! WmkWriteWatermark does not embed the GUID directly. Its wrapper constructs the following 18-byte (144-bit) message:

0x4c || GUID[0..15] || (sum of the 16 GUID bytes modulo 256)

The core encoder rounds the usable image dimensions down to multiples of eight and keeps 144 counters, one for each bit. It requires every bit to be placed at least three times.

The encoder itself can be summarized as:

WmkWriteWatermark(output, guid, 16, width, height, stride, input, format)
  |
  +-- validate pointers, format, stride, and payload length
  +-- require width >= 192 and height >= 192
  +-- construct payload
  |     `-- 0x4c || GUID || byte-sum checksum
  +-- expand 18 bytes into 144 individual bits
  +-- round usable dimensions down to 8-pixel boundaries
  +-- scan/select suitable image blocks
  +-- quantize selected block/matrix values according to each bit
  +-- require at least three successful placements per bit
  |     |
  |     `-- insufficient capacity -> return -8
  `-- reconstruct RGB pixels into the output buffer

The embedding loop performs small quantized changes over selected image blocks. It contains 3-by-5 matrix operations and a matrix-decomposition routine, and it uses constants including 24.0, 0.25, 0.5, and 0.2. This looks like a content-adaptive block-domain, SVD-style watermark.

I am not an expert in image watermarking, but one thing should be clear – this is an invisible watermark! AI even wrote some code to call this function directly and tested it with a synthetic 512-by-512 BGRA image – 193,376 of the 262,144 pixels changed after adding the watermark.

That led to the next question. Where does the input of the watermark come from?

a GUID from remote prompt moderation

At the WmkWriteWatermark boundary, the payload is only a pointer and a length. Knowing that it must be 16 bytes was a clue, but many things can be 16 bytes. I therefore started walking backward through its callers. The immediate wrapper in PaintAIManager.dll has this symbolized signature:

Paint::AI::AddWatermark(
    Gdiplus::Bitmap& image,
    winrt::guid const& watermarkId);

winrt::guid, yikes! Now we know that the 16-byte watermark payload is indeed a GUID.

Further tracking the source, we find that the GUID actually comes from a network request. Before Paint runs the local image model, AIServices.dll sends the prompt and style to:

https://apsaiservices-a0fqcjc6bzbhgdcd.b02.azurefd.net/
v1/paint-cocreator/moderate-prompt

The request is JSON and contains at least these fields:

{
  "prompt": "...",
  "style": "...",
  "lastPromptGenerationId": "..."
}

The response parser expects:

{
  "revisedPrompt": "...",
  "promptGenerationId": "...",
  "watermarkId": "...",
  "containsHumanReference": false
}

Static analysis is nice, but at this point I wanted to see a real response from the server. I reused Paint’s own authenticated session and sent the following prompt through the moderation endpoint:

a cobalt blue circle above a tiny orange square

The server returned HTTP 200:

{
  "revisedPrompt": "a cobalt blue circle above a tiny orange square",
  "promptGenerationId": "74d9e06b-adea-43ce-85fe-186a26e2e34a",
  "watermarkId": "83424621-03cb-40e3-9808-a9fae837156d",
  "containsHumanReference": false
}

I also tried the prompt a portrait of a smiling person wearing a blue hat. This time the response contained a different pair of GUIDs and containsHumanReference was true. The field is therefore a server-side classification of whether the prompt refers to a human. Paint parses and stores it alongside the IDs, although I found no evidence that it controls the watermarking step itself.

ParseModerateResponse parses both ID strings as GUIDs and rejects zero values with InvalidPromptGenerationId or InvalidWatermarkId. The server’s watermarkId is what becomes part of the generated image:

PaintUI.dll
  `-- IPromptModerationService
        `-- PaintAIManager.dll
              `-- AIServices.dll!ModerateAsync(...)
                    |
                    +-- build JSON
                    |     +-- prompt
                    |     +-- style
                    |     `-- lastPromptGenerationId
                    |
                    +-- HTTPS POST /v1/paint-cocreator/moderate-prompt
                    |
                    `-- AIServices.dll!ParseModerateResponse(response)
                          +-- revisedPrompt
                          +-- promptGenerationId -> parse as GUID
                          +-- watermarkId        -> parse as GUID
                          `-- containsHumanReference
                                |
                                `-- PaintUI stores WatermarkId
                                      `-- StableDiffusionHelpers::GenerateAsync(..., watermarkId, ...)
                                            `-- local Stable Diffusion result
                                                  `-- Paint::AI::AddWatermark(bitmap, winrt::guid const&)
                                                        `-- WmkWriteWatermark(..., guid, 16, ...)
                                                              `-- modified RGB pixels

In other words, “generated locally” does not mean that the complete operation is local. Microsoft receives and moderates the prompt, then issues the unique GUID that Paint embeds into the locally generated image. Paint also sends the previous promptGenerationId as lastPromptGenerationId with its next moderation request, allowing successive requests to be linked explicitly.

The same watermark GUID in C2PA metadata

There is another piece to this story. Paint does more than alter the pixels. It also attaches C2PA Content Credentials to the saved file. The code responsible for this lives in ProvenanceHelper.dll, backed by provenancesdk.dll.

For the local Stable Diffusion path, the flow looks like this:

local Stable Diffusion result
  |
  +-- Paint::AI::AddWatermark(bitmap, watermarkId)
  |     `-- Watermarker.dll!WmkWriteWatermark(..., watermarkId, 16, ...)
  |
  `-- AIServices.dll!SignIngredientOnlineAsync(..., promptGenerationId, image, ...)
        |
        +-- POST /v1/paint-cocreator/image-sign
        |     +-- imageMetadata
        |     |     +-- PromptGenerationId
        |     |     +-- GenerationSeed
        |     |     +-- CreativityLevel
        |     |     +-- AIFVersion
        |     |     `-- moderation scores
        |     `-- imageToSign.jpg
        |
        `-- ParseProvenanceResponse(...)
              `-- server-supplied C2PA manifest
                    `-- ProvenanceHelper::InsertManifestIngredient(...)
                          `-- AuthoringFinalizeOutputToBufferAsync(...)
                                `-- final image with C2PA metadata

Notice that the signing request sends PromptGenerationId, while the image already contains the separately returned watermarkId. The server assigned both values during moderation, so it can associate the signing request with the watermark already present in the submitted pixels.

I then saved a real image directly from Paint’s Image Creator and inspected its PNG chunks. Immediately after IHDR was an 18,979-byte caBX chunk containing a signed C2PA manifest. The interesting part was this:

{
  "c2pa.soft-binding": {
    "alg": "com.microsoft.invismark.1",
    "blocks": [
      {
        "scope": "the entire image",
        "value": "83424621-03cb-40e3-9808-a9fae837156d"
      }
    ]
  },
  "c2pa.actions.v2": {
    "actions": [
      {
        "action": "c2pa.watermarked",
        "description": "Content watermarked by Microsoft Responsible AI"
      }
    ]
  }
}

Decoded into something more readable, the manifest says:

• Generator: Microsoft Responsible AI Provenance
• AI system: Azure OpenAI ImageGen
• Action: c2pa.watermarked
• Algorithm: com.microsoft.invismark.1
• Watermark value: 83424621-03cb-40e3-9808-a9fae837156d
• Description: Content watermarked by Microsoft Responsible AI

The server’s watermarkId, the identifier embedded into the pixels, and the C2PA c2pa.soft-binding.value are the same per-generation value.

That relationship is important. C2PA calls this a soft binding: a value derived from, or embedded into, the content so that the content can still be matched with its provenance record after the file-level manifest has been removed. For a watermark soft binding, the value is the watermark’s content identifier. Microsoft cryptographically signed this assertion.

Why does Paint watermark locally?

At this point, the existence of Watermarker.dll started to make more sense. Paint actually has two rather different generation paths.

The Image Creator feature I tested above uses Azure OpenAI ImageGen. Generation, watermarking, and provenance packaging can all happen in Microsoft’s cloud, and Paint can simply receive a finished image that already contains both the invisible watermark and C2PA manifest:

Image Creator
  `-- Microsoft cloud
        +-- content filtering
        +-- Azure OpenAI ImageGen
        +-- invisible watermark
        +-- C2PA manifest
        `-- completed image returned to Paint

Cocreator is different. On a supported Copilot+ PC, Microsoft says that the NPU generates the image locally, while Azure online services still perform the safety checks. The feature therefore requires both a Microsoft account and an internet connection even though the actual Stable Diffusion inference runs on the device:

Cocreator on a Copilot+ PC
  |
  +-- prompt -> Microsoft moderation service
  |                 +-- revisedPrompt
  |                 +-- promptGenerationId
  |                 `-- watermarkId
  |
  +-- revisedPrompt + sketch -> local NPU generation
  |
  +-- Watermarker.dll -> embed watermarkId locally
  |
  `-- online provenance signing -> final C2PA manifest

This is probably the reason Paint needs a local watermark implementation at all. A cloud generator can watermark its output before returning it. A local generator cannot rely on that, so Paint has to alter the locally generated pixels itself. It also explains why Paint treats a failure from WmkWriteWatermark as a failure of the entire generation instead of quietly returning an unmarked image.

There is another surprisingly visible sign that Microsoft designed the save path around provenance. When I save a generated result directly from the Image Creator pane, Paint offers exactly one format: PNG.

After an AI result is applied to the Paint canvas, the available formats are still restricted to PNG, JPEG, GIF, and Paint’s own .paint format. BMP—the classic Paint format—is conspicuously absent.

This lines up with the formats supported by C2PA. PNG stores its manifest in a caBX chunk, JPEG uses one or more APP11 marker segments, and GIF has its own C2PA application-extension representation. The .paint format is controlled by Microsoft and can preserve whatever provenance state Paint requires. By contrast, the C2PA specification explicitly calls out BMP as a classic format that cannot embed arbitrary manifest data without using an external manifest. If Paint allowed the image to be exported directly as BMP, the file-level C2PA manifest would therefore disappear.

The split also raises an interesting security question about the cloud path. If the underlying remote image-generation endpoint can be made to return the generated image before watermarking and provenance packaging—or has an internal option that suppresses those stages—it might be possible to obtain a cloud-generated image with neither signal attached.

How to classify such a path would depend entirely on Microsoft’s design goal. It could be intended behavior if the underlying service is allowed to return raw generations and Paint is merely responsible for applying the provenance layers. It could be a product bug if Microsoft overlooked the possibility of someone calling the API directly and bypassing Paint’s watermarking step. Or it could be a security vulnerability if Microsoft treats watermarking as a mandatory abuse-prevention or provenance control and the endpoint can be made to bypass it. Without knowing the intended trust boundary, all three possibilities remain open.

Photos app does the same thing

While I was trying to locate the Watermarker.dll on disk, I happened to notice that Microsoft Photos contains a DLL with the same name:

C:\Program Files\WindowsApps\
  Microsoft.Windows.Photos_2026.11060.2004.0_x64__8wekyb3d8bbwe\Watermarker.dll

There are also local Stable Diffusion operations behind Photos’ Image Creator and Restyle Image features. Both lead to the same watermark wrapper:

Photos Image Creator
  `-- PerformSDTextToImageAndWatermarkAsync(..., promptGenerationId, ...)
        +-- run the local text-to-image model
        `-- ApplyWatermark(image, promptGenerationId)
              +-- parse promptGenerationId as a GUID
              +-- ConvertGUIDtoContiguousByteArray()
              +-- convert RGBA to ARGB
              +-- Watermarker.dll!WmkWriteWatermark(..., guid, 16, ...)
              `-- convert ARGB back to RGBA

Restyle Image takes the parallel path:

Photos Restyle Image
  `-- PerformSDSketchToImageAndWatermarkAsync(..., promptGenerationId, ...)
        `-- ApplyWatermark(image, promptGenerationId)
              `-- Watermarker.dll!WmkWriteWatermark(..., guid, 16, ...)

A subtle difference between Photos and Paint is failure behavior. If the watermark encoder returns an error, its code logs:

ApplyWatermark encountered error: ... - watermark will not be applied.

It then appears to continue returning the generated image. Paint instead treats a watermarking failure as a generation failure and the image is not returned to the user.

What Microsoft discloses

After doing this analysis, I found that Microsoft does disclose some adjacent parts of the system on its Image Creator support page. On content filtering, it says:

“we apply content filtering to prevent the generation of images”

The same page says that generated images:

“will contain C2PA manifest helping users identify that it is an AI generated image.”

It also explains that Image Creator uses Azure online services and says Microsoft collects user and device identifiers together with prompts for abuse prevention and monitoring. That is a meaningful disclosure of remote filtering and C2PA metadata.

What the page does not explain is that the C2PA manifest contains a GUID identifying the invisible pixel watermark, or that Paint’s local generation path receives its watermark GUID from remote prompt moderation. Calling the feature “Content Credentials” is accurate, but it does not make this prompt-associated identifier obvious to a Windows user.

Conclusion

To the best of my knowledge, this is the first research to document and analyze the invisible-watermarking behavior of Paint and Photos. Visible watermarks on AI-generated images are not new—Microsoft documents them for Microsoft 365 and Bing Image Creator—nor are invisible pixel watermarks such as Google’s SynthID and Bing’s hidden watermark.

Microsoft does disclose that Paint uses remote content filtering and adds C2PA Content Credentials. The new evidence shows that this metadata is not merely an unrelated file-level AI label: its signed c2pa.soft-binding assertion names Microsoft InvisMark and records the identifier carried by the invisible pixel watermark. The file-level manifest and pixel-level watermark are two layers of the same provenance system.

The local and cloud paths also explain the unusual division of labor. Cloud Image Creator can return an already watermarked and signed image, while Cocreator must embed the server-issued identifier after local NPU inference. In both cases, “local” does not mean offline: the prompt still goes to Microsoft for moderation, and the completed local result goes through online provenance signing.

This might be related to Article 50 of the EU AI Act, whose transparency rules took effect on August 2, 2026 and require AI-generated content to carry a detectable, machine-readable mark—but not a prompt-specific GUID. Microsoft discloses the existence of C2PA metadata, but I could not find a disclosure explaining the server-issued watermark GUID, its association with prompt moderation, or its presence in the pixels. Those details carry obvious privacy and right-to-know implications.

It also appears possible to modify Paint or Photos to bypass both prompt moderation and watermarking. But that does not provide a new capability: anyone can already run Stable Diffusion directly without either mechanism.

MICROSOFT ADDED A NEW BACKGROUND SERVICE TO YOUR PC IN WINDOWS 11. It is called Windows Health and Optimized Experiences. It starts automatically every time you boot. It monitors your CPU, thermals, and battery then sends data to Microsoft every 15 minutes.

Enough people believed it that Microsoft’s Scott Hanselman replied personally:

This was added in 2025 and is for Performance-diagnostic capture: When Windows detects slow or sluggish behavior, it can record targeted performance traces locally under %SystemRoot%\Temp\DiagOutputDir\Whesvc that can be filed with Feedback Hub. It’s not laptop specific. SAYING THINGS IN ALL CAPS FOR DRAMA DOESN’T MAKE THEM DRAMATIC

He is right, and so are the fact-checks that followed on Neowin, PCWorld, and Windows Latest. The service is not new, it is not recording your screen, and the traces stay on your disk unless you file them yourself.

But it appears to me that nobody has really looked at the binary, and that is quite unsatisfying for a reverse engineer.

So I opened it (well, mostly with Binary Ninja MCP). It is a perfectly legitimate diagnostics service, and everything it ships does exactly what the name suggests. What surprised me is how it is built: whesvc runs a Lua interpreter as SYSTEM, with 84 compiled Lua scripts riding along, and the machinery underneath is considerably more powerful than the job seems to need.

Everything below is on Windows 11 Pro 26200, with service binaries 10.0.26100.8972. The tools I wrote are in the companion repo if you wish to follow along on your own machine.

Where Do I Start?

The service short name is whesvc, and at first glance it is entirely unremarkable:

Name        : whesvc
DisplayName : Windows Health and Optimized Experiences
Description : Monitors the device for a better user experience
PathName    : C:\WINDOWS\system32\svchost.exe -k whesvc -p
StartName   : LocalSystem
StartMode   : Auto (delayed)

It is a svchost service, so the interesting part is the ServiceDll, which points at C:\Windows\System32\whesvc.dll. That is only 229 KB, and public symbols are available for it, which makes the job much easier.

The entry point is HealthAndOptimizerService::StartWHEService, and it is short enough to read in one screen:

HealthAndOptimizerService::StartWHEService()
  ├─ RegGetValue(...\whesvc, "WaitForDebugger")
  ├─ SetProcessMitigationPolicy(ProcessRedirectionTrustPolicy, 1)
  ├─ InitializeAssetLoader()   → LoadLibraryW(%systemroot%\system32\whesvc_assets.dll)
  ├─ WinDiag::Initialize()     → GetSystemDirectoryW + \windiag.dll
  ├─ OrchestratorSingleton::Initialize()
  ├─ OrchestratorSingleton::RegisterOneSettingsConfigChangeWNF()
  └─ StartWindiagModuleWithUri("builtin://scenario/init")

Three things caught my eye here. It loads two other DLLs I had never heard of, whesvc_assets.dll and windiag.dll. It registers for OneSettings configuration changes, so Microsoft can adjust its behavior remotely. And the last thing it does is start a module named by a URI, builtin://scenario/init.

That last one is unusual. Services do not normally have modules, and they certainly do not address them by URI. Something else is running the show here, and I will come back to what that module turns out to be.

In fact, whesvc.dll barely does any work at all. WinDiag::Initialize loads windiag.dll and resolves exactly three exports from it – WinDiagnosticsRequest, WinDiagnosticsResume, and WinDiagnosticsFree. That is the entire interface. So whatever this service really is, it lives in windiag.dll.

A Lua Interpreter in system32?

windiag.dll is 946 KB, and its strings answer the question immediately:

$LuaVersion: Lua 5.4.7  Copyright (C) 1994-2024 Lua.org, PUC-Rio $

I had not seen this before – Windows ships a Lua interpreter in system32, and a service runs it as SYSTEM.

To be fair, Lua is a sensible choice for this kind of job. It is tiny, it is fast, and embedding it is easy. That is exactly why games and embedded devices use it. It is still a little surprising to see Windows take on a new language dependency inside a system service.

Now, what about the other new DLL? whesvc_assets.dll turns out to be even stranger, because it contains no code at all. Its section table is just .rdata and .rsrc, there is no .text, and consequently there is no PDB for it either – there was nothing to compile. Everything is in the resources:

== TYPE LUALIBM ==   61 resources   (libraries)
== TYPE LUAMOD ==    23 resources   (scenarios)
== TYPE PROFILE ==    5 resources   (WPRP trace profile XML)

LUAMOD and LUALIBM are the Lua. So there are 84 scripts in here, and their names read like a table of contents: SCENARIO/HANG_TRACE, SCENARIO/SLOW_APP_LAUNCH, SCENARIO/NOISY_FAN, CORE/REG, CORE/SECURITY, MISC/ARTIFACT_MANAGER.

What Could the Scripts Do?

When you find a scripting engine inside a program, the bridge between the script and the native world is the half worth looking at first. It sets the ceiling: a script can never do more than the bridge allows.

Here the bridge is a global table called wdg, and every CORE/* library is a thin wrapper that re-exports part of it. So I wrote a small pass over the bytecode that tracks which registers hold that table and collects every field read from it. That gives 79 native functions.

Sixty of them are grouped into twelve libraries:

The remaining nineteen do not belong to any library. core/global.lua injects them directly into the environment of every script, so they are available without importing anything: getpid, getcmd, getcwd, process_info, system_info, system_times, sessionid, thread_name, create_guid, sleep, event_write, and a handful of timing primitives.

Registry write, arbitrary file I/O, process creation, WMI method invocation, and a general-purpose FFI. That is roughly the capability set of a systems administration language. It is quite a lot for a program whose job is to notice that your laptop is running hot.

The file access surprised me the most, because it has no restriction whatsoever. This is the whole of write_data, at line 9 of core/file.lua:

function write_data(path, data)
    assert(io.open(path, "wb")):write(data)
end

No prefix check, no allowlist, no canonicalization. And before you assume io here is some hardened Microsoft replacement, it is not – windiag.pdb exports luaopen_io, luaopen_os, and luaopen_package unmodified, so this is the stock PUC-Rio liolib calling fopen.

This is the part the viral post got backwards, so let me be clear. None of the shipped scripts do anything questionable with this. They read sensors and write JSON into their own directories, which is exactly what a diagnostics service should do. The engine underneath would simply let them do much more, and what keeps them in their lane is that Microsoft wrote them that way.

It is worth seeing what the sharper capabilities are actually used for, because the answer is mundane in every case.

File I/O. scenario/system_summary writes its result to a temporary file, and misc/artifact_manager later publishes it into %ProgramData%\Whesvc\ and enforces the retention limits:

local path = env.expand("%TEMP%\\") .. name .. "_summary.json"
file.write_data(path, json.stringify(summary))

Registry. scenario/perftrack_monitor keeps its counters under whesvc’s own key so they survive a restart. On my machine one of those entries looks like this:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\whesvc\scenarios\29783662:1
    id                a92c2390-587f-4ee7-af5b-d1e05402e98a
    number            29783662
    on_ac             1
    total_count       5
    bucket_ms         2
    last_update_time  134309573839635035

The only write that leaves whesvc’s own keys is misc/driver_info, which can set VerifyDrivers, VerifyDriverLevel, VerifyMode, and VerifierOptions under Session Manager\Memory Management. That is Driver Verifier configuration, used by memory_monitor for pool tracking, and it is gated behind WINDIAG_DRIVER_TELEMETRY_ENABLED. It is easily the most invasive thing any of these scripts can do to a machine.

Process creation. Exactly one script spawns a process through security.create_process, and it runs an in-box Windows tool:

local opts = {
    cmd_line   = sysdir .. "/powercfg.exe /sleepstudy /output \"" .. outfile .. "\"",
    redirected = true,
    console    = false,
}
local proc = security.create_process(opts)

That is misc/sleep_study asking powercfg for a sleep study report and then reading its output. Interestingly, there is a second process-spawning path that does not use this binding at all: core/etw shells out to wpr.exe -merge through io_popen. Two mechanisms for the same job, in the same codebase.

Getting the Scripts Out

Now I can go read them. Except the resources are not plain Lua, and this is probably why nobody had looked inside: running strings on whesvc_assets.dll shows nothing resembling a script.

Each resource starts with a small header:

0x00  u32  magic 0xC0E5510A
0x04  u16  header size (0x18)
0x06  u16  tag
0x08  u64  uncompressed size
0x10  u64  uncompressed size (again)
0x18  u32  compressed size
0x1C  ...  'CK' + raw DEFLATE

That CK is the giveaway: MSZIP, which is deflate with a two-byte signature in front, so the unpacker is four lines of Python. No encryption, and no hash or MAC anywhere in the header either, which will matter later.

Underneath the compression is Lua 5.4 bytecode. And here is the part I did not expect:

Nothing was stripped. The header sentinels are the stock values (LUAC_INT = 0x5678, LUAC_NUM = 370.5), and the opcode table is unmodified upstream ordering. I wrote a disassembler against the plain Lua 5.4 opcode list and it decoded every module correctly on the first attempt.

Why keep the debug info? I suspect it is deliberate. The engine formats its errors as file(line)!address, and the WIL telemetry logs failures with call context. If you strip the symbols, you blind yourself to your own field failures. There are even lua_debugger_enabled and vscode_debugger_enabled hooks sitting in the sandbox script.

So What Is Keeping This In Check?

Two things are supposed to, and both are worth a look.

The first is a sandbox. It lives in a LUASB resource plus core/global.lua, and before any scenario script runs it deletes a list of globals from the environment: debug, require, os, package, loadfile, dofile, load, getmetatable, setmetatable, and collectgarbage.

That accomplishes one thing, and it is the important one. With load, loadfile, dofile, and require all gone, a scenario script cannot load code that did not ship in the signed DLL. There is a path that loads Lua from the filesystem through a WINDIAG_LUALIB_PATH environment variable, but it is gated on the host process being windiag.exe, a separate developer tool, so that door is closed too.

Beyond that it does not do much. io was never on the block list, and io.popen is deliberately re-exported as io_popen – core/etw.lua uses it to shell out to wpr.exe -merge – so removing os does not remove the ability to run commands. The core libraries also grab what they need before the strip happens, and core/global keeps an upvalue named, with admirable honesty, sandbox_stripped_refs. It is namespace hygiene rather than confinement.

The second thing is the signature on whesvc_assets.dll, since that is the DLL holding the code that actually runs. Except there is no check. Neither DLL imports WinVerifyTrust, the process never sets MicrosoftSignedOnly, and there is no hash or MAC in the container header either. The file is validly signed, and nothing looks at that signature when it is loaded.

But that does not really matter, because of who is allowed to write the file:

C:\Windows\System32\whesvc_assets.dll
    NT SERVICE\TrustedInstaller:(F)
    BUILTIN\Administrators:(RX)
    NT AUTHORITY\SYSTEM:(RX)
    BUILTIN\Users:(RX)

TrustedInstaller has full control, and everybody else – including SYSTEM and Administrators – gets read and execute only. Anyone who can replace this file is already an administrator, and administrator to SYSTEM is not a boundary Windows defends anyway. So this is fine.

So what actually keeps this engine in bounds is not the sandbox and not the signature. It is a file permission, plus the set of scripts Microsoft chose to ship. That is enough in practice, but it is worth knowing that is what the safety rests on.

So What Do the Scripts Actually Do?

Now I can finally answer the question I left hanging earlier: what is builtin://scenario/init?

The builtin:// scheme is handled inside windiag.dll, and it simply names a resource. scenario/init becomes the LUAMOD resource called SCENARIO/INIT, which is 536 bytes on disk and unpacks to 777 bytes of bytecode. The debug info calls it @luamod\scenario\init.lua, and it is 48 instructions in total, so I can show the whole thing:

disable_global_variables()

local opts = module_options{
    disabled_modules = "",
}

local workflow  = reflib("misc/module_workflow")
local telemetry = reflib("misc/utc_telemetry")

telemetry.event_write("FeatureStates", feature_states())

workflow.start_feature_modules({
    { module_uri = "builtin://scenario/housekeeper" },
    { module_uri = "builtin://scenario/rtsmon" },
    { module_uri = "builtin://scenario/devicehot" },
    { feature_name    = "ECP",
      module_uri      = "builtin://scenario/ecp",
      on_battery_only = true },
    { feature_name = "MemoryLeakDetection",
      module_uri   = "builtin://scenario/memory_handle_leak" },
    { module_uri = "builtin://scenario/noisy_fan" },
}, "init", opts.disabled_modules)

That is the entire entry point. It locks down the environment, pulls in two helper libraries, emits one telemetry event recording which feature flags are on, and hands six modules to the workflow starter. No logic of its own beyond that.

From there the structure is easy to follow. Of the 23 scenario modules, 21 start by default. Those six above are the first wave, and one of them, rtsmon, opens a realtime ETW session and starts fourteen more. Thirteen run unconditionally, six sit behind Windows feature flags that Microsoft controls server-side, and one needs a battery to be present.

Roughly, they fall into four groups.

Responsiveness. hang_trace waits on WerHangTraceSignal and captures a trace when an application stops responding. input_delays and output_delays watch input latency and display glitches. slow_app_launch fires when an app takes too long to start. svc_start_stop flags services stuck in a pending state. And hotkey_trace is the interesting one, because it captures a full trace when you press a hotkey. That is the manual reproduction path, for when you can trigger the problem yourself.

Power and thermals. ecp decides between LowerPower, NoChange, and HigherPower, and then applies the result. excessive_power_drain looks for sustained drain and badly behaved background apps. fast_battery_drain_improvement is a small state machine that engages QoS separation and CPU frequency throttling when drain stays high. sleep_offenders works out what kept the machine awake, and shells out to powercfg /sleepstudy to do it.

Memory. memory_monitor takes heap snapshots. memory_handle_leak does real leak detection: it tracks per-process memory and handle counts across intervals, and uses consecutive-increase counts together with a linear regression slope to tell a leak apart from normal growth. That is more statistics than I expected to find in a shipped diagnostic script.

Aggregation. system_summary is where the famous 15 minutes comes from. It reads WINDIAG_SYSTEM_SUMMARY_FLUSH_SEC, which defaults to 900. The artifacts on my own machine agree:

{"start_time":"2026-08-11 21:02:16.727114",
 "end_time":"2026-08-11 21:17:56.930144",
 "elapsed_time":"00:15:40.203030", ...}

So the 15 minutes is a real number. The question is what happens when the timer fires, and the answer is that it writes a JSON file into C:\ProgramData\Whesvc\ and emits one small ETW telemetry event. Here is an entire crash record, from my machine:

{"app_name":"binaryninja.exe","mod_name":"TTDReplay.dll",
 "exception_code":"0xC0000005","exception_offset":"0x994EA",
 "app_version":"5.4.10219.0","count":1}

That is the payload everybody was worried about. It is a crash summary, and in this case it is my own debugger crashing on me during development.

The network side is similarly undramatic. Across all 84 scripts the only URL is symweb.azurefd.net, which is Microsoft’s public symbol server, and it is gated behind a WINDIAG_SYM_CLOUD_TOKEN environment variable that is not set on a retail machine. No scenario module makes an HTTP request at all. windiag.dll imports three WinINet functions and zero socket functions. The running service holds no TCP or UDP endpoints.

Two controls deserve more credit than the discussion gave Microsoft. Heavy trace capture checks AllowTelemetry and requires it to be 3, meaning full or optional diagnostic data, and returns false when the value cannot be read at all – so it fails closed. And auto-escalation, the one mechanism that can hand data to the telemetry pipeline without you filing feedback, is off by default in all ten automatic scenarios. It is on in exactly one: hotkey_trace, the one you trigger yourself.

How Does It Know the Fan Is Loud?

SCENARIO/NOISY_FAN was actually the first module I opened, because I could not immediately think of a non-alarming way to detect a noisy fan. I have taken a fan apart on this blog before, so I felt some obligation to check this one.

Happily, it is not listening to anything. I went through the full import tables of both binaries, and there are no audio APIs anywhere.

What it does instead is read RPM. The platform’s thermal stack exposes a fan descriptor that sorts RPM into four zones, each with a maximum RPM and an accumulated time spent in that zone:

FanNoiseZoneLow  FanNoiseZoneMedium  FanNoiseZoneMediumHigh  FanNoiseZoneHigh

The module polls on an interval, and then does exactly one comparison:

if time_per_impact[FanNoiseZoneHigh].seconds_in_zone > high_impact_sec_threshold then
    device_health.signal_problem{ problem_area = Power, source = "NoisyFan" }
end

So “noisy” means the fan has spent more than N accumulated seconds above an RPM threshold that the OEM declared. It is a proxy for noise rather than a measurement of it, which is a sensible way to do this without a microphone. And if your machine has no fan telemetry at all, the module exits immediately with Fan sensors not supported on device, which is what happens on most desktops.

There Was Already a CVE

While writing this up, I found that this service has already produced a real vulnerability: CVE-2025-59241, a local elevation of privilege with CVSS 7.8, fixed in builds 26100.6899 and 26200.6899 back in October 2025. Microsoft classified it as improper link resolution before file access. (Tenable has a more readable summary than the MSRC page.)

Which rather punctures my earlier line about nobody having opened this binary. Somebody clearly had, and they walked away with a CVE while I walked away with a blog post. I will console myself with the belief that I am at least the first to write the thing up in this much detail.

Microsoft published one sentence about it, and I could not find a pre-patch binary on my machine to diff against, so what follows is the shape of the problem rather than a confirmed account of the exact reported case.

The ingredients are still visible. The service creates C:\ProgramData\Whesvc\<artifact_type>\ if it does not exist and writes a file inside it, as SYSTEM, with no path validation. The type names are hardcoded and predictable, and system_summary guarantees a write every fifteen minutes. Meanwhile, look at who can write into that tree:

icacls C:\ProgramData\Whesvc
    BUILTIN\Users:(I)(CI)(WD,AD,WEA,WA)      <- create files and directories
    CREATOR OWNER:(I)(OI)(CI)(IO)(F)

Every entry is marked (I), meaning inherited – the service never sets its own DACL, it just accepts whatever C:\ProgramData hands down. Once an unprivileged user can create a directory a SYSTEM process will later write into, the classic move is to make it a junction pointing somewhere else. The retention logic, which deletes old artifacts, offers the same trick in reverse.

The fix is visible in the current binaries, and I like it. Remember that SetProcessMitigationPolicy(ProcessRedirectionTrustPolicy, 1) at the very top of StartWHEService? That tells the kernel to refuse to follow junctions and symlinks created by less-trusted principals. It kills the entire class of bug rather than patching one path, and it is set declaratively in the svchost group configuration as well. There is a second and narrower guard in core/file.lua, where the recursive directory walker refuses to descend into reparse points:

if file.is_directory(entry) and not file.is_reparse_point(entry) then
    table.insert(q, entry.path)
end

This is the only call to is_reparse_point in all 84 modules, which tells you plainly what it was added for.

The artifact directory still inherits its permissive DACL rather than setting its own, so the defense rests on that one kernel mitigation. It is a good mitigation and it does the job, but an explicit DACL would have made it two layers instead of one.

Final Thoughts

The viral claim was wrong on essentially every count. The service is not new, it does not upload your traces, and it is not recording anything. The 15 minutes is a real number attached to a thoroughly boring event, and Hanselman’s description matches the code right down to the directory path he quoted.

What is worth talking about is the machinery rather than the behavior. The scripts read sensors and write JSON files, while the engine underneath would let them write any file, set any registry key, spawn processes, and call arbitrary native functions through an FFI, all as SYSTEM. None of that is being misused – I went looking for something dodgy and did not find it. It is simply more capability than the task calls for, and CVE-2025-59241 is a fair illustration of what that can cost. Windows Health and Optimized Experiences is not spyware; it is a legitimate diagnostics service built on a general-purpose scripting runtime, and that is a different thing to threat model than a program which reads a fan sensor.

The tooling I wrote for this – the PE resource extractor, the MSZIP container unpacker, and the Lua 5.4 disassembler – is on GitHub, together with instructions for unpacking the scripts from your own copy of Windows.

Affiliate codes, briefly

If you have looked closely at a Baidu search URL you have seen something like this:

https://www.baidu.com/s?wd=something&tn=47018152_13_dg&ie=utf-8

That tn= is a Baidu Union account identifier — it tells Baidu which partner the traffic came through. This is old and well known; Firefox historically shipped tn=suvion_dg, Maxthon used tn=myie2dg. Software that ships a Baidu search box generally has its own code.

Sogou has an equivalent. Sogou search URLs carry a p= parameter shaped like sogou-site-0e57098d0318a954 — a four-letter channel type and sixteen hex digits.

Replacing the codes

When a Sogou Browser user navigates to a Baidu search carrying an affiliate code, this is what the browser actually requests:

in   https://www.baidu.com/s?wd=test&tn=47018152_13_dg&ie=utf-8
out  https://www.baidu.com/s?wd=test&tn=98010089_dg&ie=utf-8&ch=19

And the same on Sogou, with that engine’s own p= scheme:

in   https://www.sogou.com/web?query=x&p=sogou-site-0e57098d0318a954&ie=utf8
out  https://www.sogou.com/web?query=x&p=sogou-addr-cc9657884708170e&ie=utf8

The code is swapped and the rest of the URL is left alone. On the Baidu side a ch=19 parameter is set as well, overwriting any existing ch value rather than duplicating it.

Two conditions have to hold for it to fire at all. The URL must begin with www.baidu.com or sogou.com — a Sogou code carried by some other site, or a Baidu URL nested in a redirect wrapper, is ignored. And the code has to appear on a list built into the browser; anything else is left untouched.

The list of codes

The lists live in a plugin called QBSafe.dll, loaded at browser startup, which receives every navigation URL.

For Sogou URLs there are three tables of strings in .data, holding 128, 219 and 246 entries — 593 in total, every one of the form sogou-<four letters>-<sixteen hex>, and every one distinct. Each table has a single replacement, and the tables are tried in order with the first match winning:

For Baidu URLs there are eleven codes built directly on the stack, all mapping to one replacement:

tn=93912046_hao_pg   tn=68082196_oem_dg   tn=18029102_oem_dg
tn=39042058_2_oem_dg tn=02049043_35_pg    tn=47018152_13_dg
tn=02049043_32_pg    tn=47018152_8_dg     tn=02049043_50_pg
tn=93139410_hao_pg   tn=02049043_30_pg
                  ↓
            tn=98010089_dg     (plus ch=19)

MITM verification

To confirm my finding, I set up mitmproxy in front of the browser and observed the behavior:

You might be curious why Sogou is doing this. There are many possible reasons, and I will leave that to interested readers.

This post is the whole story of chasing it down: first getting the game to run on its own outside of Excel, and then — years later — freeing it completely, into a standalone program that carries nothing of Excel with it at all.

What Dev Hunter is

To trigger the Easter egg in Excel 2000, you navigate to the cell WC2000 and press the little Office logo. Up pops a 2D driving game: you steer a car down a highway and shoot the cars ahead of you. It is called Dev Hunter because the road is painted with the names of the Excel developers — you are, the game informs you, hunting them down. Between the names it scrolls taunts at you like “Pivot! Pivot! Pivot!” and “You will respect the rectangles.”

Getting it out of Excel

The first step, back in 2019, was just to get it running at all. Excel 2000 does not install on a modern machine, so I started inside a Windows XP virtual machine, and after enough fiddling, Dev Hunter popped up. I played it for a few minutes and found it… not that interesting anymore. Maybe it was only ever interesting because I had nothing else to do. But by then I had become a reverse engineer, and a more interesting question had already taken hold: how is this thing actually implemented?

To get to the game, I exported the spreadsheet to a web page, and that page references the CLSID 0002E510-0000-0000-C000-000000000046, which points at MSOWC.DLL — the Office Web Components control. I loaded that DLL into Binary Ninja, searched for the string “Dev Hunter,” and landed straight in the function that holds the game logic. Its parent runs the familiar PeekMessage / TranslateMessage / DispatchMessage loop; its grandparent is the part that decides whether to trigger the egg at all, by checking that you are sitting on row 0x7cf (1999) and column 0x2bd (WC):

I could have stopped there, but I wanted to run the game on its own, without the entire bulk of Excel behind it. The message-loop function turned out to be conveniently self-contained. It is thiscall, with ecx pointing at a large buffer that is really a C++ object — and the game does not depend on anything being in that buffer beforehand. So I could simply allocate 0x100000 bytes, zero them, and hand that over as ecx, along with three stack arguments: a handle to the DLL, a zero, and a magic 0x7fa87860 that turns out to control the car colors. The whole loader is only a few dozen lines of assembly:

; PAGE_READWRITE
push 0x4
; MEM_COMMIT
push 0x1000
; size
push 0x100000
push 0
call [VA(VirtualAlloc)]
mov  edx, eax

; zero the allocated page
mov  edi, eax
xor  eax, eax
mov  ecx, 0x40000
stosd

mov  ecx, edx          ; hand the buffer over as `this`
push VA(Dll)
call [VA(LoadLibraryA)]

push 0x7fa87860        ; magic constant — the player car's color
push 0
push eax
add  eax, 0x10c946     ; func2 = DLL base + 0x10c946
call eax

Compiled to a tiny loader.exe — and, with a couple of patches plus the wonderful DDrawCompat shim to make its ancient DirectDraw calls behave on modern Windows, the game ran outside of Excel. Here it is running standalone, straight from the loader:

I wrote that adventure up as an article in Paged Out! #6, published in March 2025. One detail I only chased down while writing it: the developer names are stored XOR-encrypted with the byte 0x52, and, of all things, in CBC mode — you can read the decrypted roll of names that scrolls down the road. The loader itself lives at github.com/jeffli678/excel2000-devhunter-loader.

Freeing it completely

The loader was a good trick, but it still needs MSOWC.DLL. And that DLL, with its ancient DirectDraw, only gets harder to run with every passing year. What I really wanted was to rewrite the game completely: to reimplement it as a small standalone program with no external dependencies.

This time I did not write it myself. I had an AI agent do the entire job: reverse engineer MSOWC.DLL and translate the game into a standalone C++ program, while I steered.

Working from Binary Ninja’s decompilation, the AI rebuilt the game piece by piece — the recovered 256-color palette, the decrypted developer text, the floating-point RNG, the perspective projection, and, crucially, the DLL’s real render and rasterizer routines, all translated into C. It built, and it ran. And it looked badly wrong:

The names spill off the tarmac, the road is at the wrong scale, and the cars are reduced to blocks. The integer and pointer code had come across faithfully, but the geometry runs entirely on the x87 FPU stack, and it is not decompiled perfectly. Each little error was invisible in the listing, and no amount of re-reading it was going to fix them.

At this point I stepped in — I told it to run the original under Binary Ninja’s debugger and compare against ground truth.

The AI scripted the headless debugger to launch the real game, break right before the DirectDraw Unlock — the moment the finished frame exists in memory but is not yet on screen — and read out the live 8-bit framebuffer, using the pixel pointer at *(this+0x34) and the row pitch at *(this+0x20), together with the entire ~0x9a96c-byte game object. Then it diffed its own rendering against those real pixels, frame by frame, and checked the physics by comparing the game object before and after a single tick.

That changed everything. Every vague “it looks off” became a specific, usually one-line fix: a projection edge the decompiler had turned into a running total (which sheared the road); a floating-point value dropped off the FPU stack, so the off-road crash check was reading the odometer instead of the car’s speed; a texture-row mask that is really and al, 0xe0 — a low-byte-only mask that keeps 32 rows — rather than the full-width & 0xe0 the decompiler implied, which had crushed the letters. One by one, the render converged on the original:

Getting to a clean comparison took two more tricks. The game’s one-time setup (terrain, textures, and a 3D letter atlas built with GDI) is deterministic, seeded from zero, so rather than re-derive that gnarly initialization the port simply loads a snapshot of its exact output and relocates the pointers inside it. And because the game derives its frame timing from the wall clock, headless runs were not even reproducible until I had it wire in a fixed virtual clock — only then could a SHA-256 of the frame dumps prove that the two are truly the same.

The source, build instructions, and a playable Windows release are on GitHub: github.com/xusheng6/excel2000-devhunter-standalone.

What I take away from it

The lesson I take away is about the limits of static reverse engineering. Even with a capable AI agent driving it, reading the disassembly got the port perhaps 90% of the way, and then stalled — the remaining errors simply were not visible in the code it was reading. Debugging is the right way to close the gap.

And at the end of it, Dev Hunter is out. A little game that spent twenty-five years locked inside an office suite that barely runs anymore is now a few hundred kilobytes you can clone, compile, and play in a window. I doubt the developers who hid their names in that road ever expected someone to come along, decades later, and rewrite the whole thing.

It showed up on its own — I never went to LG’s website and downloaded anything. It just appeared one day, offering to install “Dual Controller” and a few other LG utilities. I did not think about it too much at the time; I clicked the little x and moved on with my life.

Then, more recently, I came across a few X posts reporting the exact same thing, for example this one, and even a Gamers Nexus video digging into how LG ships this software through Windows Update. The consensus was some flavor of “LG is installing bloatware/adware on your PC without asking.” That matches my experience, and it is a fair complaint.

But none of the coverage I saw actually reverse engineered the binary to see what it does. That is the part I care about, so I pulled the files apart. This post is about that: which packer it uses, how to unpack it, how to recover the strings, and what the program actually does once you can read it.

The files

The program lives in a folder called LGMonitorAppManager. The interesting pieces are:

LGMonitorAppManager.exe            (.NET, WPF)        <- the brain
Executables/EDIDMgr.dll            (native)           <- reads monitor EDID
Executables/DPIHandler.dll         (native)
Executables/LGErrorHandler.dll     (native)
Executables/TracerLib.dll          (native, MFC)      <- logging
Executables/LGMonitorAppSilentInstaller.exe  (native) <- the elevated installer
Executables/LGMonitorAutoStartupApp.exe      (native) <- persistence
Ionic.Zip.dll  Newtonsoft.Json.dll                    <- third party

The first thing I checked was the Authenticode signatures. Everything native is validly signed by LG Electronics Inc., so this is genuinely LG’s software and not some third party impersonating them. The one exception is interesting: the main LGMonitorAppManager.exe — the .NET assembly that actually orchestrates everything — is not signed. Keep that in mind for later.

The native DLLs turn out to be the boring part. Their imports contain no networking APIs at all — no WinHTTP, no WinINet, no sockets. EDIDMgr.dll reads the connected monitor’s EDID (so LG can tell which of its monitors you have plugged in), DPIHandler does DPI stuff, LGMonitorAutoStartupApp.exe drops a shortcut into the Startup folder, and LGMonitorAppSilentInstaller.exe runs InstallShield setups silently. All the actual logic — the network calls, the decision making, the installs — lives in the unsigned .NET brain. So that is where I spent my time.

Unpacking the .NET assembly

Decompiling LGMonitorAppManager.exe immediately shows it is obfuscated. Every class is named with unprintable Unicode characters, and every string is gone, replaced by calls like:

Registry.LocalMachine.OpenSubKey(Class8.smethod_0(252488964));

Class8.smethod_0(int) is a string decryptor — you hand it an integer id and it returns the real string. This pattern (confusable Unicode identifiers + an int-keyed string decryptor) is the signature of Eazfuscator.NET, a commercial .NET obfuscator.

Step one is de4dot, which cleans up the control flow and renames the garbage symbols into something readable (Class8, smethod_0, etc.). But de4dot could not decrypt the strings — it reports the obfuscator as “Unknown,” because this is a 2025 build of Eazfuscator and de4dot’s engine is from 2015.

I tried pointing de4dot at the decryptor manually:

de4dot input.exe --strtyp delegate --strtok 0x06000106

This did run — every smethod_0(...) call got replaced — but every single string came out as the literal placeholder X0X. That was the clue for what is going on. Reading the decompiled decryptor explains it:

static Class8()
{
    // ...
    StackTrace stackTrace = new StackTrace(2, fNeedFileInfo: false);
    StackFrame frame = stackTrace.GetFrame(0);
    MethodBase methodBase = frame?.GetMethod();
    Type type = methodBase?.DeclaringType;
    if (type == typeof(RuntimeMethodHandle)) { /* seed A */ }
    else if (type == null)                   { /* seed B */ }
    else                                     { /* seed C */ }
    // the seed becomes the key used to decrypt every string
}

The static constructor walks the call stack and derives the decryption key from who called it. When the caller is a normal method inside the assembly, it takes one branch; when the caller is RuntimeMethodHandle — i.e. you invoked it through reflection, exactly what de4dot does — it takes a different branch and derives the wrong key. It is an anti-tamper trick: try to call the decryptor out of context and you get garbage.

The clean way around this is EazFixer, which is built specifically for modern Eazfuscator. It uses Harmony to patch that stack-based check at runtime, then lets the assembly decrypt its own strings in the correct context:

EazFixer.exe --file LGMonitorAppManager.exe --out fixed.exe
...
StringFixer: Success

Decompiling fixed.exe finally gives fully readable code, strings and all. Now we can actually see what the thing does.

What it does

The core is a class called UIManager. On startup it:

1. Reads the connected monitors’ EDID (via the native EDIDMgr.dll) to get each monitor’s vendor/product id, and keeps only the LG ones.
2. Checks that the machine is online.
3. Fetches a JSON catalog from LG’s server:

https://lmu.lge.com/ExternalService/LGMonitorAppInstaller/MonitorAppInfo.json
https://lmu.lge.com/ExternalService/LGMonitorAppInstaller/McAfee_MonitorAppInfo.json

The MonitorAppInfo.json is the app catalog. It is an array of monitor groups; each group lists the product ids it applies to and the apps offered for those monitors. Here is one entry (trimmed):

{
  "pid_list": ["23603", "23604", "23640", "23641"],
  "vid_list": ["7789"],
  "supported_app_list": [
    {
      "app_type": "Recommended",
      "app_name": "OnScreen Control",
      "setup_url": "https://lmu.lge.com/ExternalService/LGMonitorAppInstaller/Win/OnScreen Control/Setup/Win_OSC_9.16.zip",
      "iss_url":   "https://lmu.lge.com/ExternalService/LGMonitorAppInstaller/Win/OnScreen Control/Setup/OnScreen Control.iss",
      "app_info_list": [
        { "lang_name": "English", "app_description": "OnScreen Control is an application to ...", "eula_url": "..." }
      ]
    }
  ]
}

Each app entry points at a setup_url (a zip) and an iss_url (an InstallShield silent-install response file). When you accept an app, UIManager downloads the zip, unzips it with Ionic.Zip, and hands the extracted setup.exe plus the .iss file off to the elevated LGMonitorAppSilentInstaller.exe, which runs the installer silently.

The catalog it serves me right now offers these LG applications, all hosted on lmu.lge.com:

“LG Channels” is a nice tell about the nature of this thing. It is not a program at all — installing it just drops a desktop shortcut that opens www.lgchannels.com/?Y2FsbGVyPU1vbml0b3ImdGFyZ2V0PWhvbWU= in your browser. That base64 decodes to caller=Monitor&target=home, i.e. an attribution tag so LG can count how many of these ad clicks came from the monitor installer. The shortcut’s target is your default browser, resolved by reading HKCU\...\UrlAssociations\http\UserChoice.

The McAfee part

There is a second catalog, McAfee_MonitorAppInfo.json, and a bunch of McAfee-specific machinery in the client. It enumerates your installed antivirus via WMI:

\\.\root\SecurityCenter2  ->  SELECT displayName FROM AntivirusProduct

and if it decides McAfee should be pushed, it downloads and installs it like any other app, then fires a “conversion ping” to a tracking URL from the server config. That ping is the giveaway: this is an affiliate arrangement, where LG is set to earn a commission on every McAfee installation that comes through the monitor installer. It is the same referral economics that gets a McAfee trial bundled with so many other products — the AV enumeration decides whether you are a viable “conversion,” and the ping reports back when one lands.

The one funny detail: the McAfee bundle is a password-protected zip, and the password is hardcoded in the (unsigned) client:

McAfeeLGdasusodkug!@#

McAfee + LG + dasusodkug + !@#. I wondered whether dasusodkug was Korean typed on an English keyboard (LG being a Korean company), but mapping it through the 2-beolsik layout gives ㅇㅁㄴㅕㄴㅐㅇㅏㅕㅎ, which starts with three consonants and no vowel — not real Korean. It is just filler to make the password look strong. In any case, a hardcoded password in a shipped binary is not a security control.

I wanted to grab the McAfee installer to look at it, but I was unable to obtain it. The live McAfee_MonitorAppInfo.json currently contains zero McAfee entries, and the actual installer is nowhere I could reach: the catalog URL is static with no parameters, so there is no query that surfaces the payload, and guessing the path just returns a tiny text/html soft-404. There are a couple of plausible reasons. It could be gated server-side — by region, or by which antivirus you already have — so a generic request never gets it. But it is also entirely possible that LG simply pulled the McAfee installer after the widespread backlash over exactly this bundling, and the code path is now dormant. Either way, the McAfee capability is plainly still present in the client, even though I could not pull the actual payload.

No signature check

Here is the part I want to point out, gently. I looked for any integrity verification in the download-and-install path — Authenticode/WinVerifyTrust, a hash or checksum compared against the catalog, certificate pinning, anything. There is none. The download is simply:

webClient.DownloadFile(new Uri(setup_url), destination);

where setup_url comes straight from the server’s JSON. The zip is unzipped and the setup.exe inside is executed with elevation. Nothing between “bytes off the network” and “run as admin” checks that the bytes are what LG intended.

To be fair, I downloaded all eight LG installers and checked them, and every one is validly Authenticode-signed by LG Electronics Inc. (the newer builds even use an EV certificate). So under normal conditions you are running authentic LG code. But that is a property of what LG’s server happens to be serving today, not something the client enforces — if the server returned an unsigned or swapped setup.exe, the client would run it just the same. There is also no scheme check, so the client would follow an http:// URL if the catalog contained one; today it does not, and TLS validation is at least not disabled.

The net of it: the whole trust model rests on HTTPS and on LG keeping lmu.lge.com pristine. Whoever controls that endpoint — an origin/CDN compromise on LG’s side, or an attacker who can MITM with a certificate the system trusts — gets silent, elevated, zero-interaction code execution on every machine running this, because the software auto-starts and will happily install whatever the catalog points at. Under the right conditions that is a textbook supply chain attack. It is not something anyone can trivially exploit from the outside, but for software that shipped itself to your PC uninvited and runs at boot, “we only pinky-promise the server is fine” is a thin guarantee.

How does this even get on your machine?

The part that bothered most people, including me, is that nobody installed this. You buy a monitor, plug it in, and some time later it is just there. The common explanation online is “Windows Update,” and that turns out to be exactly right — but the mechanism is more specific and more interesting than “Windows Update installs random programs,” so I dug the trail out of my own machine.

It rides in on a driver, using Microsoft’s Hardware Support App (HSA) feature. Here is the chain, all verifiable locally with pnputil and the registry:

1. You connect the monitor. Windows sees its PnP hardware id — on my machine DISPLAY\GSM77E8, “Generic Monitor (LG ULTRAWIDE)”.
2. Windows Update matches that id and automatically pulls down two LG driver packages, both WHQL-signed by “Microsoft Windows Hardware Compatibility Publisher” (i.e. they went through Microsoft’s hardware certification and are distributed through Windows Update itself):
   • a monitor extension INF (monitor.inf), which among other things advertises a child device literally named “LG Monitor Support Application”;
   • a SoftwareComponent INF (lgmonitorappsoftwarecomponent.inf), which matches that child and runs an AddSoftware directive.
3. That directive is the whole trick:

[LG_Monitor_Control_Install]
SoftwareType=2
SoftwareID=pfn://LGElectronics.LGMonitorApp_cfnzzhwkr8z5w

SoftwareType=2 with a pfn:// id means “go install this Microsoft Store app by its package family name.” So Windows fetches LGElectronics.LGMonitorApp from the Store and installs it. On my machine it landed at C:\Program Files\WindowsApps\LGElectronics.LGMonitorApp_1.2606.1601.0_x86__cfnzzhwkr8z5w, SignatureKind = Store, version 1.2606.1601.0 — the exact binary I had been reverse engineering. The INF does not even hide what it is; one of its strings is Hsa.ComponentDesc = "LG Monitor Support Application", and HSA is Microsoft’s own acronym for Hardware Support App.

So, does Windows Update install third-party programs? Not arbitrary .exe files, no — but through this sanctioned path, effectively yes. A WHQL-signed driver is allowed to pair itself with a companion app via AddSoftware. There are two flavors: SoftwareType=1 is a Win32 executable bundled inside the driver package and run once, and SoftwareType=2 is a Microsoft Store (MSIX) app referenced by package family name. LG uses type 2, so what you get is a packaged, Store-signed app that a Windows-Update-delivered driver quietly requested on your behalf.

Here is the nuance that ties this back to the rest of the post. The Microsoft-blessed, signed, sandboxed part of this whole story ends at “a Store app is installed.” Everything that app then does — phoning lmu.lge.com, and downloading and silently installing classic Win32 installers with no signature check — happens entirely outside the Windows Update and Store trust model. Windows Update delivered a signed driver, the driver requested a signed Store app, and that Store app is the thing that goes off and side-loads everything else. The trust chain quietly falls off a cliff at the last step.

Conclusion

So what is LG Monitor App Manager? Honestly, it is fairly ordinary adware. It detects your LG monitor, phones home for a list of LG apps and promotions, nudges you to install them, quietly bundles a McAfee referral, and plants a tracked shortcut to an ad-supported streaming service. Nothing here is malware, nothing exfiltrates your files, and it is all signed by LG. As adware goes, it is tame.

What still surprises me is the delivery. I did not install this. I did not visit lg.com. I plugged in a monitor, and Windows Update — by way of a signed driver and the Hardware Support App mechanism above — installed a Store app that then set itself to run at every boot and started offering to install more software. The HSA part is a legitimate Windows feature and works as designed; what unsettles me is what LG chose to put at the end of it. Shipping an auto-updating, self-starting software distribution channel to people simply because they bought your monitor — and wiring up its final stage with no signature checks on the payloads — is a lot of trust to ask for a brightness-control utility. If you have an LG monitor and would rather not have this, uninstalling the “LG Monitor” software, deleting the shortcut from your Startup folder, and disabling the corresponding StartupTask will get rid of it, at least until the next time you reconnect the monitor.

Preliminary

The main() function is actually quite simple:

Just one function call and a branch, which decides if the player succeeds. The core function looks like what a VM should be:

It has a dispatcher at the top-center of the graph, and various VM instruction handlers beneath it. We see most of the instructions are not complex (supposedly), except for the longer four ones at the left-hand side. Looking at the first basic block in the function quickly reveals some important information about the VM:

The code first sets up a huge buffer on the stack and then copies 0x3b1a bytes of data from address 0x3008 into it. Upon further inspection, I decided this is the actual VM code. Then it clears 32-byte spaces at the top of the stack. I did not know what it is at the moment, since it could be RAM or registers for the VM. Anyways, let us proceed to the first VM instruction and its handlers.

Analyzing the First VM Instruction

The start of the common handler reads one byte from the current VMIP (VM IP) and goes to different handlers based on its value. It serves as an opcode (operation code) for the instruction. The opcode of the first VM instruction is 0xf6, and we can find its handler according to the value:

Looking at the handler, it reads another byte right after the opcode byte and checks whether the lowest two bits of it is 0x0. If so, it goes into the left branch in the image. We call this byte sub-opcode byte because it determines which variant of the opcode to execute. Then it has two shr instructions followed by two and and mov. It is not immediately clear to me what it is doing at first sight.

Upon closer inspection, I find if we treat the data at the top of the stack (address rsp) as an array of dwords, then the two mov essentially moves a dword from index rcx into index rax. And tracing back, we find the two values come from the sub-opcode byte. The source index comes from s 7-8 of it, and the destination index comes from bits 5-6. Remember the lowest two bits of the sub-opcode byte are used to decide the opcode variant.

Now it is pretty clear that this is moving values between VM registers. (Well, it could also be VM memory, but this does not make a big difference.) This instruction can be disassembled something like mov r1, r3, for example. Of course, the actual indices of the registers need to be parsed from the sub-opcode byte.

Alright, what about the other sub-opcode? I.e., when the lowest two bits of the byte is 0x2. It reads a dword after the sub-opcode, and moves that into a register decided by the bits 5-6 of the sub-opcode. Here, since both instructions are encoding registers using two bits, I deduced that this VM has four registers. However, this conclusion is later challenged when I reverse the last VM Opcode.

Nice, we analyzed one VM instruction. Now we simply need to repeat the process for every VM instruction and will eventually complete it. However, the VM code is quite lengthy (0x3b1a bytes long), manually analyzing it is hopeless. We need some way to automate the process.

Writing an Architecture Plugin in BinaryNinja

This time I decided to write an architecture plugin in BinaryNinja to disassemble the VM. I have been using BinaryNinja for several years, but I have not written any architecture plugins before. Previously, I wrote my recursive descent disassembler for VMs. It requires the user to write a disassembler function for the custom architecture, and it will drive the disassembler, i.e., fetch the binary code, ask for disassembly, and then print it.

However, writing an architecture plugin in BinaryNinja is a more powerful solution. Firstly, it benefits from a great GUI that I am already familiar with. I get a decent graph view, register highlighting, cross-references, etc, for free. Secondly, if we lift it to BinaryNinja IL, we can almost forget that we are dealing with an alien architecture – just read the BLIL and analyze it from there.

Andrew has done a tutorial on writing new architecture plugins, which I followed as I set up the initial code.

Basics of Architecture Plugin

Writing a new architecture plugin turns out to be quite simple: one simply sub-classes Architecture, and then register() it. After that, in the GUI, we can create a function in the new architecture. Since Andrew’s blogpost can already serve as a walk-through, so I will not cover every detail here. Instead, I will just describe some of my feelings and thoughts about the process.

Most of the work needs to be done are implementing two functions of the new architecture: get_instruction_info() and get_instruction_text(). get_instruction_info() returns the length of the instruction, branches (if any) after the instruction, etc. It will help BinaryNinja disassemble the function and draw the graph of basic blocks. get_instruction_text() returns to tokens of the instruction, which will be displayed as the disassembly. There is another function get_instruction_low_level_il(), which allows the instruction in the architecture to be lifted to LLIL. Then BinaryNinja will then lift it to MLIL and HLIL, do lots more analysis, and produce a decompiler output eventually. In this VM example, since the disassembly is already quite straightforward to read, I did not lift it to LLIL.

Let us go back to the first VM instruction and see how we handle it in the architecture plugin.

def get_instruction_info(self, data, addr):
    result = InstructionInfo()
    opcode = data[0]
    byte1 = data[1]
    if opcode == 0xf6:
        if byte1 & 3 == 0:
            result.length = 5
        elif byte1 & 3 == 2:
            result.length = 6

Right, since this one does not affect the control-flow, we simply need to return the instruction length of it. This VM happens to use the rdx register to store the VMIP, so tracking its value change can tell us the instruction length. One interesting part of this VM is NOT all bytes in an instruction is necessarily used for encoding. Sometimes, it wastes several bytes for nothing. I guess the purpose of this is to confuse the reverser. For disassembly, it is slightly more complex:

def get_instruction_text(self, data, addr):
    instrLen = 0
    tokens = []
    opcode = data[0]
    byte1 = data[1]
    if opcode == 0xf6:
        if byte1 & 3 == 0:
            instrLen = 5
            tokens.append(InstructionTextToken(InstructionTextTokenType.InstructionToken, 'mov'))
            tokens.append(InstructionTextToken(InstructionTextTokenType.TextToken, ' '))
            reg0 = (byte1 >> 4) & 3
            reg1 = (byte1 >> 6) & 3
            tokens.append(InstructionTextToken(InstructionTextTokenType.RegisterToken, 'r%d' % reg0))
            tokens.append(InstructionTextToken(InstructionTextTokenType.OperandSeparatorToken, ','))
            tokens.append(InstructionTextToken(InstructionTextTokenType.TextToken, ' '))
            tokens.append(InstructionTextToken(InstructionTextTokenType.RegisterToken, 'r%d' % reg1))
        elif byte1 & 3 == 2:
            instrLen = 6
            tokens.append(InstructionTextToken(InstructionTextTokenType.InstructionToken, 'mov'))
            tokens.append(InstructionTextToken(InstructionTextTokenType.TextToken, ' '))
            reg0 = (byte1 >> 4) & 3
            tokens.append(InstructionTextToken(InstructionTextTokenType.RegisterToken, 'r%d' % reg0))
            tokens.append(InstructionTextToken(InstructionTextTokenType.OperandSeparatorToken, ','))
            tokens.append(InstructionTextToken(InstructionTextTokenType.TextToken, ' '))
            int0 = int.from_bytes(data[2:6], byteorder='little')
            tokens.append(InstructionTextToken(InstructionTextTokenType.IntegerToken, '0x%x' % int0, int0))

    return tokens, instrLen

The disassembly is made up of several tokens. The reason to use different types of tokens is to inform the UI of its purpose, which can then provide better support. For example, when we use RegisterToken in the disassembly, and we select one of them, all register tokens with the same text will be all highlighted. This allows us to track the data flow faster.

Also, even one does not wish to spend time on creating these tokens, he can simply use a TextToken to hold all the token texts. That means my disassembler should retire because it is completely superseded by using the BinaryNinja architecture plugin.

From here we repeat the process and disassemble all instructions one by one. In BinaryNinja, we can easily see what is the bytecode of the next unhandled instruction, which is quite convenient to speed up the development loop.

Analyzing the Algorithm

I did not wait until I finish every instruction to start analyzing the algorithm. The first three VM instruction already gives me something meaningful:

We see that r0 is 0x20 after the subtraction, and then it writes it to the terminal. The ASCII 0x20 corresponds to the space char. So these three instructions print space to the terminal. This process is repeated lots of times:

What is it doing? Well, it just prints the text we see when we execute the binary:

$ ./KataVM_L1 
    .-------------------------.
    | Towel's KataVM: Level 1 |
    '-------------------------'

>> 

Well, yeah, it prints a banner and then asks for the input. So we do not bother analyzing these instructions, because we know their effect. Let us see what happens after the prints:

It first sets r2 to 4, and reads 4 bytes of input into both r0 and r1. Note in this VM, the bytes to read are decided by the third parameter of the read() call, in this case being 4. Next, it copies the input in r1 into r2 and r3, and does some shift, add, and xor on it. This looks like the TEA algorithm, isn’t it?

A COMPLEX VM Instruction

The next VM code I encounter is the hardest one in this VM. It has four sub-opcode, and all of them look similar.

Even if I probably only need to analyze one of them, it is still quite complex. I first read its disassembly, but I quickly get lost. However, I do see some patterns within it. Let us look at the left-most sub-opcode, and the red block in the middle is always executed. And the code on top of it and beneath it also looks similar to each other. So it means maybe I only need to understand one of the two, drastically lowering the workload.

Also, at the bottom of the handler, we see this interesting block:

It is using the SSE instruction pshufd to reorganize the four dwords at address rsp and rsp+0x10. At first sight, this is more confusing than revealing. I thought this VM has four registers, which means four dwords. They are 16 bytes in total and span from rsp to rsp+0x10. Then what the heck is this code doing when it transforms the four dwords starting at rsp+0x10, is it just trying to confuse me?

Well, let’s first figure out what it does to the four registers sorted at rsp. We know pshufd transforms the second operand according to the third operand (which is an 8-bit immediate), and stores the result in the first operand. And what does the third parameter, 0x1b corresponds to? It is actually 0b00011011 in binary, or 00 01 10 11 when put into groups. Wow, so the pshufd will swap the first dword with the last one, and the second one with the third one. Nice, this makes sense!

Now we still need to read the bulky part of the handler.

At the beginning of it, it first reads a dword after the sub-opcode byte. Then it does some length-based comparison based on that value. I did not make sense out of it initially, but when I zoom out, I discovered a new pattern:

There are two loops in it. And the smaller one looks like this:

It is just copying dwords from one pointer to another pointer until the two-pointer converges. Well, it seems to be reversing all of the dwords between two pointers. Looking at the larger one, it appears to be doing the same thing, just using SSE instructions to handle more data at the same time, to run it faster:

Suddenly, the length comparison, as well as the two loops that does the same thing start to make sense to me! It is trying to reverse the dwords, but it will first use the SSE version when the buffer is large, then use regular instructions to wrap up. It is similar to the handling in SSE version of string functions, e,g., strcpy.

Nice progress! The next thing I discover is that no arithmetic computation is performed on the data, they are just moved from one place to another. Given all this information, I fired up gdb to see what it is doing.

The VM instruction I followed reads out a parameter from the dword after sub-opcode. The parameter has a value 0x5. The instruction breaks up the 8 dwords start at rsp into two groups, with the first group being the first 6 dwords, while the other being the rest 2 dwords. It then reverses the position of the dwords WITHIN the two groups, respectively. If you use an integer to represent the location of the dwords, it works like this:

Start 
0 1 2 3 4 5 6 7

Group 1
0 1 2 3 4 5 ==> 5 4 3 2 1 0

Group 2
6 7 ==> 7 6

End 
5 4 3 2 1 0 7 6

So far, no magic, right? Then it reverses the orders of the first four dwords, and the last four dwords, respectively:

Start 
5 4 3 2 1 0 7 6

Group 1
5 4 3 2 ==> 2 3 4 5

Group 2
1 0 7 6 ==> 6 7 0 1

End 
2 3 4 5 6 7 0 1

If we put the start and end together, we can see it clearly:

Start 
0 1 2 3 4 5 6 7

End 
2 3 4 5 6 7 0 1

Equivalently, the dwords are rotate shifted right 6 times! Wow, how smart a way to do it! I did not work out the mathematics behind this transformation, though I would expect it to be simpler than reversing this function.

Now that the VM turns out to have eight registers, though only the first four can be accessed using r0-r3. To access the other four ones, they have to be first shifted into the position of the first four, and then operated upon. Interesting, this is the first time I have seen something like this!

For the rest handlers similar to the one we have dechiphered, one does shift left in the same way. And the other two reads the number of cells to shift from a register. Great, we now fully reverse-engineered and understood the VM!

Is it TEA?

Looking at the code and comparing it with a reference implementation (shown below, excerpted from Wikipedia), I believe it must be TEA. The registers are being rotated but if we track it precisely, we see those are just obfuscations. Everything matches except the delta is 0xe09ffbb1, not 0x9E3779B9. But that does not make a big difference to the algorithm. Also, the VM code is 32 rounds of unrolled loops. The entire program reads 16 bytes of input, and every 8 bytes are processed in the same way.

void encrypt (uint32_t v[2], const uint32_t k[4]) {
    uint32_t v0=v[0], v1=v[1], sum=0, i;           /* set up */
    uint32_t delta=0x9E3779B9;                     /* a key schedule constant */
    uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3];   /* cache key */
    for (i=0; i<32; i++) {                         /* basic cycle start */
        sum += delta;
        v0 += ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);
        v1 += ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3);
    }                                              /* end cycle */
    v[0]=v0; v[1]=v1;
}

And the key appears to be:

uint32_t key[4] = {0x80b86e21, 0xa268295d, 0xf171f22d, 0x28a13c94};

After 32 rounds of encryption, the encrypted input is checked against two constants:

The fail = 0x1 means if the cmp returns not equal, the check fails.

Then I copied the reference decrypting code (from Wikipedia), changed the delta (and sum as well):

void decrypt (uint32_t v[2], const uint32_t k[4]) {
    uint32_t v0=v[0], v1=v[1], sum=0x9E3779B9 * 32, i;  /* set up; sum is 32*delta */
    uint32_t delta=0x9E3779B9;                     /* a key schedule constant */
    uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3];   /* cache key */
    for (i=0; i<32; i++) {                         /* basic cycle start */
        v1 -= ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3);
        v0 -= ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);
        sum -= delta;
    }                                              /* end cycle */
    v[0]=v0; v[1]=v1;
}

Then I happily ran it, and believe I solved it. However, the decrypted one seems to contain unprintable char. And when I feed them in as input, the check also fails. Emmm, where did I make any mistake?

Checking Each Round One-By-One

I used the text 12345678 as input and compared the encryption result from TEA and the VM. The first several rounds all match, and I am tired of comparing them manually. One difficulty here is there is no way to set a breakpoint on the VMIP, we can only set up breakpoints on the VM handlers. So if we wish to compare the result after n rounds, it is not easy to set a breakpoint.

However, I made an observation that always ends up a swap registers VM instruction, and each round contains exactly four swap registers instructions. That makes the handler of that instruction a great place to set up a breakpoint. Set up a breakpoint at the end of the handler, when it hits, first use c to continue four times, and then dump the 8 dwords starting at rsp using d/8dx $rsp. I wrote a script to automate this process and dump the result, then compare it with the output from TEA.

I discovered the result from the 22nd round of encryption is different in two outputs. I browsed the code to do the 22nd round of encryption, and almost immediately saw the issue:

The number of shifts are different! They are 2 and 3 instead of 4 and 5. I adjusted my decryption code a little bit:

void decrypt (uint32_t v[2], const uint32_t k[4]) {
    uint32_t v0=v[0], v1=v[1], sum=0xe09ffbb1 * 32, i;  /* set up; sum is 32*delta */
    uint32_t delta=0xe09ffbb1;                     /* a key schedule constant */
    uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3];   /* cache key */
    for (i=0; i<32; i++) {                         /* basic cycle start */
        if (i == 9)
            v1 -= ((v0<<2) + k2) ^ (v0 + sum) ^ ((v0>>3) + k3);
        else
            v1 -= ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3);

        v0 -= ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);
        sum -= delta;
    }                                              /* end cycle */
    v[0]=v0; v[1]=v1;
}

Note, the decryption works in reverse, so the 22nd round in forwarding means the 9th round in reverse. Now it works! I get the output xNVa2_N07_t3aAlg, and it is correct:

$ ./KataVM_L1 
    .-------------------------.
    | Towel's KataVM: Level 1 |
    '-------------------------'

>> xNVa2_N07_t3aAlg

[+] Correct!

I earned this title since I am the Champnion of the 8th North American Cup. Game records can be viewed online.

The certificate is shown here:

However, I have not taken very few photos in recent years. One excuse is I become busy and get obsessed with reverse engineering. But a more convincing reason is I am less interested in this world. The situation might change in the future, though.

I will write about reversing, coding, Xiangqi, and other stuff.

I did not tally the statistics, but there is a fairly good amount of new submissions (of both crackmes and solutions) every week. And most of them are nice! For me, crackmes.one is a place for reversers to exchange knowledge and joyfulness. So I am very glad that we see a steady flow of input. Now that we have three reviewers, and I hope an increase in the reviewing speed will shorten the feedback loop for contributors, which, in turn, will lead to more contributions from the community.

Nevertheless, some of the submissions did not meet our standards and got rejected. The reasons vary, but many of them are using existing obfuscator/protector. Among them, many have a dull verification algorithm and the sole challenge is to get past the obfuscator. We welcome the use of protectors/obfuscators, but we do not like the use of existing ones, especially commercial ones, e.g., VMP, WinLicense. These protectors are definitely breakable (trust me), but it is too hard for a crackme and it will take very long to solve. For folks who can do it, they would probably invest the time in some more important/interesting things, rather than spending a long time on it to break the protector, and only to find the actual algorithm is just on XOR.

Meanwhile, using existing tools deviates from the spirit of crackmes.one. As I wrote above, I believe this is a place for us reversers to "exchange knowledge and joyfulness". We not only practice and improve our reversing skills but also share and obtain knowledge. However, using an existing tool does not help the author learn anything, beyond how to execute the tool, which is relatively simple. Conversely, if the author digs deep into an existing (open-source) tool, understands how it works, makes certain changes to defeat existing tools, s/he would learn more.

Below, I will list some of the things that we should better avoid when writing a crackme. Note, these rules are not absolute and I will write a longer version of explanation following it.

Don’ts

1. Do not upload crackmes that are not written by you.
2. Do not upload malware or unwanted software of any kind, e.g., trojan, ransomware, adware, etc.
3. Do not use a commercial packer, protector, or obfuscator.
4. Do not upload a crackme that you cannot solve.
5. The crackme should not fail to execute. Please, no missing library dependencies or internal errors!
6. The crackme should not make network connections to any host other than localhost (127.0.0.1).
7. The crackme me should make it clear how it accepts/expects input (if any). And it should also clearly tell the player whether the input is correct.
8. The crackme must be solvable without guessing or a non-trivial amount of brute-forcing.
9. The crackme must be solvable in a reasonable time – when solved optimally.
10. The crackme should not rely on any hardware unique identifier as part of the algorithm.
11. The crackme should not stack unrelated levels of protection together.

Justifications

A reader might notice some of the items above are too restrictive. So I will now explain the reason to set them and some of the exceptions for it. Also, if you are in doubt about a specific crackme or crackme idea, please contact one of the reviewers on Discord.

1. The crackme should be the uploader’s original work. Do not upload crackmes that have potential copyright issues. Do not upload crackmes you see on the Internet or in CTFs, unless you get permission to do so.
2. An exception is that one might make a pseudo-ransomware/malware that is a reverse engineering challenge. If that is the case, be sure to limit the damage to a very small and specific range (e.g., a flag.txt in the current dir), and state it clearly before the actual payload runs.
3. Using commercial packers, protectors, or obfuscators does not help challenge authors to learn and improve. And it could also take too long to solve. Also, avoid using any of these tools that already exist. Making your own or improving existing tools are very welcome!
4. Related to #3 and #8, do not make a crackme that even the author cannot solve.
5. This is a disappointing situation. Try to be compatible with more systems you target. Though we know that compatibility with all systems is impossible. At least test it on another computer and see if it works!
6. We discourage the use of network connections. Network traffic makes it harder to determine whether the program has any malicious behavior. If you need to have a network connection, only do that with the localhost. If you do not wish the player to temper with the “remote” server, still bundle the server and run it on the localhost, but tell the player not to reverse it.
7. If the crackme accepts inputs, e.g., user name and passwords, do not obscure the way it reads it. Also, be honest and tell the player if s/he solves it. Do not accept fake flags. Do not hide the flag somewhere that cannot be triggered by code execution. Note, this rule does not state that a crackme has to do password validation. We do have crackmes that ask the player to defeat the anti-debugging or decrypt a file that gets encrypted. These are good and not affected by this rule. In other words, if you have a novel challenge style, explain it to the player so they do not get lost.
8. Do not put the flag/secret in a function that is never gonna be executed. Do not make crackmes that the player has to guess something important to proceed.
9. Most crackmes can be solved instantly, or in a few seconds. I think a max 1-minute time limit is a reasonable recommended maximum.
10. Do not blindly add layers of protection, unless they form a cohesive unity. If protections are duplicated in large numbers, there should be a way to automatically tackle it.

This is not the first time Towel came up with OCaml crackmes. Qt Scanner, rated as level 5, is a hard challenge. I attempted that, but have not succeeded yet. So, when I first saw these two new OCaml challenges, I am not very eager to try them, despite they are rated as level 1 and 3. Nevertheless, we cannot hide from challenges forever, so I decided to try it last week. And the outcome is good, I managed to solve them without digging deep into the OCaml runtime.

Baby OCaml

OCaml is an interpretive language, but it can be compiled to native code. This is in contrast to Python/PyInstaller, where the script is just packaged into the generated binary and we can restore the original source of it. The OCaml compiler generates native code based on the source code, and the source is not present within the generated binary. Worse still, when we deal with new programming languages, e.g., OCaml, Go, Rust, we are likely to encounter some novel things we do not expect. For example, Rust has a very different way of passing parameters and return values of a function. We need to first get familiar with it, then start reversing the actual code logic.

The Baby binary is 2.0 MB in size, which is HUGE for a crackme. The OCaml runtime will occupy lots of space in it, so we need to find the code that we are interested in. Opening the binary in BinaryNinja reveals that it is a statically linked binary:

OK, so even libc functions are not easy to find. But the entry point looks so familiar to me that I can still recognize the call 0x470980 at 0x401c48 is libc_start_main, and sub_401770 at 0x401c41 is the main function. However, the main function is mostly initializing the OCaml runtime, and I cannot find the actual entry point to the code.

Then I decided to run the binary and see if I can get any clue from it:

$ ./baby 
-= Montrehack =-
   Baby OCaml

[!] Nope, try again.

Ok, it does not ask for input, so the input should probably be supplied as a command line argument. I tried to find the strings it prints but failed. Well, the strings must be encrypted or otherwise obfuscated. Now I cannot quickly find the logic that checks the input, so again this is a dead end.

I tried to reverse the binary for a half-day but cannot make a breakthrough. The call stack is deep and lots of function pointers are used. I was lost and put the binary aside for a while until one day Towel poked me to try his challenges. I told him that I cannot even solve the baby one, thanks to the string obfuscation. We chatted about the challenges a little bit, and I decided to give it a try again.

This time, I have to admit, that I am super lucky. I browsed the string list and spotted something unusual in the first few:

Looks readable, right? I navigated to the location and the code seems to be comparing strings:

I am pretty sure the code is checking whether the ASCII string at rax is Getting_Warmed_Up. Note, the last char, 'p', with an ASCII value 0x70, is checked against 0x600000000000070. Well, due to little-endian, this will be effectively checking the lowest byte in the qword, but I have no idea what the 0x60 means. So OCaml runtime does have some weird things that are quite unusual.

Anyways, I solved the challenge:

$ ./baby Getting_Warmed_Up
-= Montrehack =-
   Baby OCaml

[+] Success!

FLAG-c34bc2bd73fdb06799061a8e76f62664

Tennager OCaml

Although I did not solve the last challenge decently, I cannot wait to start working on the Teenager one. This binary is 1.9 MB in size. So, yeah, the size is mostly static libraries + OCaml runtime, and the size of the actual logic is almost negligible within it.

This time it does not use string obfuscation so I can easily locate the place where the binary asks for input:

The control flow seems quite obvious, in the first node it asks for input, there there are two checks, and we must get to the lower left node to pass the check. I was pretty relieved when I saw this since there aren’t many functions in this graph. However, it turns out I am naive and too optimistic about it.

The first thing that I cannot understand is…. the first check.

At 0x403168, rbx must be 0x2b, from which we can deduce that rbx must be 0x15 at 0x403163. And tracing back, it becomes weird. From debugging I noticed at 0x40314b, rax actually holds the ASCII string of the input. What could be located at rax-0x8? Well, I am not sure, but it is highly likely to be something related to the string’s length. However, reading the code I cannot make any sense of it. I tried inputs with different lengths and the value does not change according to the input length.

Furthermore, at 0x40315b there is a movzx rdi, byte [rax+rbx]. We know rax is the string, if this is one of the input char, then this check is very strange. The length will be checked against one particular char, and the result must be 0x15.

Luckily, I debugged the code more and find after code at 0x403160, rbx always holds the length of the input. So this one is checking whether the string length is 0x15. The OCaml is yet unsolved, but I managed to get some information out of it.

Now, there are only three functions ahead, but I cannot trace the execution easily. The code uses lots of function pointers and I quickly get lost. A patient reverser would study the OCaml compiler to figure out how the code is generated, but I still have one thing to try: hardware breakpoint on the input string.

The plan is simple, we now know the string is held in rax at 0x40314b, then we can set a hardware breakpoint on it and see who accesses it. If everything goes well, we can find the code that reads the input, which is very likely to be also the checking logic code.

I set a breakpoint at 0x40317f, and supplied the input string “111111111111111111111” (which is just ‘1’ * 0x15). It hits! Not bad, at least we are correct on the length check. The pwndbg shows rax does point to the input string:

RAX  0x7ffff7ff9b90 ◂— '111111111111111111111'

Then I set a hardware read breakpoint:

pwndbg> rwatch *0x7ffff7ff9b95
Hardware read watchpoint 3: *0x7ffff7ff9b95

Note, the string starts at 0x7ffff7ff9b95, but I set a breakpoint at 0x7ffff7ff9b95, which is the 6th char of the input. This is a personal habit since there could potentially be more places that access the first char than we are interested in. On the other hand, the code that reads a char in the middle is more likely to be interesting and worth checking out.

The hardware breakpoint is hit at 0x402c07, and the instruction above it is reading the 6th char of the input:

This function (sub_4024f0) looks like:

So it is very likely that the function is checking very char one by one. This function has no xref to it at all, so I probably will not be able to find it easily, if I do not use hardware breakpoint. Inspecting the stack gives me the actual caller, 0x402410, and I have to say it is not easy to find the actual callee without debugging. The good news is if I were to reverse OCaml in the future, I know where to look at and with the help of debugging, I can hopefully find the callee and sort out the execution flow.

I notice if the check passes, the return value is set to 0xa7. Remember the check at 0x4031e6? 0xd9f is quite a strange value, but it could be related to the 0xa7 here.

>>> hex(0xd9f/0x15)
'0xa6'

So, there is some code, which I have not discovered, that minus 1 from the return value and then sum everything up. Now we know the check for each char, and it should not be hard to dump the constraints and solve it with z3.

I am lazy and do not wish to manually transcript the constraints and z3 syntax. However, angr does not easily work with it, thanks to the OCaml runtime, which angr does not understand. So I need to combine the power of BinaryNinja API to simplify the binary and enable angr to work with it.

Solving with BinaryNinja and Angr

If we look at the basic block at 0x402d4c, there are two inputs to it: 1) the ASCII string in rax, 2) the value of rbx set at 0x402d24. We also need to extract the char index from the instruction at 0x402d4c (0x3 for in this screenshot). To get the initial value of rbx, we do not need to search for the instruction at 0x402d24. Instead, we can use the possible value set of rbx to get it. To enable angr, we also need to get the target address of the true/false branch of the conditional at 0x402d64.

Getting True/False Branch Address

To get the good/bad branch, we first get the outgoing_edges of a basic block and check the edge.type:

bbl = bv.get_basic_blocks_at(addr)[0]
edges = bbl.outgoing_edges
for edge in edges:
    if edge.type == BranchType.TrueBranch:
        good_addr = edge.target.start
    elif edge.type == BranchType.FalseBranch:
        bad_addr = edge.target.start

Parsing LLIL and Getting Char Index

For each constraint, we need to know the index of the char being checked. For example, for instruction movzx rax, byte [rax+0x3], we need to get 0x3 from it. This requires us to walk the LLIL instruction and find its value.

def find_llil_basic_block(llil_basic_blocks, addr):
    for llil_bbl in llil_basic_blocks:
        if llil_bbl[0].address == addr:
            return llil_bbl

func = bv.get_functions_containing(addr)[0]
llil_basic_blocks = list(func.llil_basic_blocks)
llil_bbl = find_llil_basic_block(llil_basic_blocks, addr)
src = llil_bbl[0].operands[1].operands[0].operands[0]

char_idx = 0
if src.operation == LowLevelILOperation.LLIL_ADD:
    char_idx = src.operands[1].value.value

Note, the above code might not be very reader-friendly, e.g., src = llil_bbl[0].operands[1].operands[0].operands[0]. This is because LLIL is essentially a tree, and we are travelling down it.

Getting the Possible Value of rbx

To get the possible value of rbx when the execution enters the basic block, we need to use the get_possible_reg_values API.

rbx_value = 0
value_set = llil_bbl[0].get_possible_reg_values('rbx')
if value_set.type == RegisterValueType.ConstantValue:
    rbx_value = value_set.value
    rbx_value &= 0xffffffffffffffff

Note, not all of the check uses rbx. For them, the value_set.type will be UnderterminedValue, and rbx_value will remain 0x0. This has no side effect on solving.

Angr Time

The last step is to solve it with angr:

def angr_solve(addr, good_addr, bad_addr, char_idx, rbx_value):
    proj = angr.Project('./teenager')
    state = proj.factory.entry_state(addr = addr)
    # suppose the input string (ASCII) is stored at 0xaa000000
    input_addr = 0xaa000000
    state.regs.rax = input_addr
    state.regs.rbx = rbx_value
    flag = state.solver.BVS('flag', 8)
    state.memory.store(input_addr + char_idx, flag)
    simgr = proj.factory.simgr(state)
    simgr.explore(find = good_addr, avoid = [bad_addr])
    if simgr.found:
        solution_state = simgr.found[0]
        char_solution = solution_state.solver.eval(flag, cast_to = bytes)
        return True, char_solution
    else:
        False, None

Note, the above script is not super robust, since we really expect the solving to succeed.

We still need to manually collect the 0x15 address of the basic blocks. Although it is possible to automatically collect them, I feel the time to make it work will be longer than just select and copy 0x15 addresses.

The script returns 0CamL_Ints_Ar3_W4rped, and feeding it to the challenge gives me:

$ ./teenager 
-= Montrehack =-
   Teenager

Enter Password: 0CamL_Ints_Ar3_W4rped

[+] Success!
FLAG-221fddd2bbf810be10d156b060b0eda5

This reminds me of the description of the challenge:

A slightly harder OCaml challenge to get practice with OCaml integer representations.

So, it seems that I solved without knowing anything about OCaml integer representation.

This time I am writing about the challenge ReverseMe3 from jochen_. The challenge can be found on crackmes.one. The password to unzip is “crackmes.one”.

The description given on the challenge page says the program will show a message box when it not running under a debugger. And the goal is to make it also show the message box when it is running under a debugger. Basically, to circumvent the anti-debugging techniques.

Interestingly, the author mentions the program only runs properly on 3 latest builds of Windows 10. 1909 2004 and 20H2. And if we were to conquer it inside a VM, we have to bypass one more check. So maybe the program uses some new feature that is introduced in the latest versions? Or it might be relying on low-level/un-documented features that only work on these versions. I do not have a VM that has the proper Windows build version, so I decide to solve it statically.

As always, I will not only explain how to solve it correctly – I will try to mention many of my thought processes as well as some detours that I have took. I believe this is more interesting to read than a flawless straight-sail.

First Impression

The challenge binary ReverseMe3.EXE is only 2.6 KB, relatively small. Loading it into BinaryNinja quickly reveals something unusual:

It first sets eax to 0x40, bswap it, and then calls cpuid. the bswap will make eax 0x40000000, and according to my memory that does not return anything useful for cpuid. However, at 0x40101d, the return value in ecx is moved into eax, which is then used to decrypt the code starting from 0x401030. The code to be decrypted is 0x258 bytes long. Code at 00401030 immediately follows the decryption loop, and of course, it cannot be properly disassembled since it is still encrypted.

From what I see now the challenge is probably hand-written. I like hand-written challenges since it can be denser in terms of tricks and traps, which is the fun of reverse engineering.

Note the decryption only uses one byte from the return value of cpuid, so it is possible to try all 256 possibilities, disassemble the decrypted code and see which one can be disassembled properly. The same technique is used in one of the crackmes in the book “Reversing: Secrets of Reverse Engineering”.

CPUID

But we do not have to do the hard work, at least for now. We can see what cpuid is returning and decrypt the code with the correct return value. However, as stated in the challenge description, this challenge does not run properly in a VM. And we know that cpuid sometimes returns different values inside/outside the VM. So if we actually run the program, we probably get a wrong return value.

Anyways, let us have a look at of the documentation about cpuid. In fact, eax register determines the type of information that will be returned by the cpuid. For example, if eax is zero upon the execution, cpuid will return the maximum valid input value for basic CPUID information. Besides, a value that is larger than 0x80000000 will request extended CPUID information. However, these do not help us since the input is 0x40000000.

In the doc, anything between 0x40000000 - 0x4FFFFFFF is descibed as:

Invalid. No existing or future CPU will return processor identification or feature information if the initial EAX value is in the range 40000000H to 4FFFFFFFH.

I was tempted to think the return value will be undefined, or even a certain kind of fault will be triggered. However, we see clearly from the code that not only the cpuid should execute properly, its return value should be stable.

Upon closer inspection of the documentation, I find that:

If a value is entered for CPUID.EAX is higher than the maximum input value for basic or extended function for that processor then the data for the highest basic information leaf is returned.

I am not sure 0x40000000 is greater than 0x80000000 – maybe they do a signed comparison. Anyways, we know what is going to happen: the data for the highest basic information leaf is returned.

Now that we still need to find the concrete return value. I do have a Windows VM, but that gives me 0x56 in cl, which after the decryption, gives me garbage rather than valid code. I am not planning to install an actual Windows machine to solve this challenge, so what should I do now?

I soon realize, for things like cpuid, it does not matter what OS I run. I am currently on Linux, but the value returned should be the same. I launched rappel, an assembly REPL tool.

> mov eax, 0x40000000
> cpuid
rax=00000000000008fc rbx=00000000000012c0 rcx=0000000000000064
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000400003 rsp=0000000000000033 rbp=0000000000000000
 r8=0000000000000000  r9=0000000000000000 r10=0000000000000000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
[cf=0, zf=0, of=0, sf=0, pf=0, af=0, df=0]
cs=002b  ss=0000  ds=0000  es=0000  fs=0000  gs=0000            efl=00000202

The return value of ecx is 0x64. Is this reliable? Will it always return the same value on different machines? I tried to find the maximum index of the basic information by calling cpuid when eax is set to 0:

> mov eax, 0
> cpuid
rax=0000000000000016 rbx=00000000756e6547 rcx=000000006c65746e
rdx=0000000049656e69 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000400003 rsp=0000000000000033 rbp=0000000000000000
 r8=0000000000000000  r9=0000000000000000 r10=0000000000000000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
[cf=0, zf=0, of=0, sf=0, pf=0, af=0, df=0]
cs=002b  ss=0000  ds=0000  es=0000  fs=0000  gs=0000            efl=00000202

We can see the return value of eax 9s 0x16, which means the maximum basic information is 0x16. Then I set eax to 0x16 and call cpuid again:

> mov eax, 0x16
> cpuid
rax=00000000000008fc rbx=00000000000012c0 rcx=0000000000000064
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000400003 rsp=0000000000000033 rbp=0000000000000000
 r8=0000000000000000  r9=0000000000000000 r10=0000000000000000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
[cf=0, zf=0, of=0, sf=0, pf=0, af=0, df=0]
cs=002b  ss=0000  ds=0000  es=0000  fs=0000  gs=0000            efl=00000202

Not bad, the same output is returned. So I am pretty confident calling cpuid with eax set to 0x40000000 has the same effect as calling it with 0x16. Looking for the value 0x16 in the table in Intel docs tells me that it returns Processor Frequency Information Leaf. For register ecx, it says “Bits 15 - 00: Bus (Reference) Frequency (in MHz).”

I am not sure whether this information is all the same on different machines since such bus frequency could vary in different cases. Please feel free to get in touch with me if you have any ideas about this! Anyways, if I do install a Windows machine and execute the program, I should get the same output. I proceeded with the value and used it to decrypt the 0x258 bytes of encrypted code, starting at 0x401030. BinaryNinja makes it super easy to transform the code, and the output looks valid:

Before we proceed to analyze the decrypted code, I would like to see what is returned on a VM. I used a similar assembly REPL tool, WinREPL, to checkout the result on Windows:

>>> mov eax, 0x40000000
>>> cpuid
assembled (2 bytes): 0f a2
rax: 0000000040000006 rbx: 00000000786f4256 rcx: 00000000786f4256 rdx: 00000000786f4256
r8 : 0000000000000000 r9 : 0000000000000000 r10: 0000000000000000 r11: 0000000000000000
r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
rsi: 0000000000000000 rdi: 0000000000000000
rip: 0000023ca56f000e rsp: 000000478b2fef00 rbp: 0000000000000000
flags: 00000200  CF: 0  PF: 0  AF: 0  ZF: 0  SF: 0  DF: 0  OF: 0

When we run cpuid with eax set to 0x40000000, the return value in ecx is actually the string “VBox”. I am not entirely sure which basic information it is trying to return, so I set eax to 0 to find out:

>>> mov eax, 0
>>> cpuid
assembled (2 bytes): 0f a2
rax: 0000000000000016 rbx: 00000000756e6547 rcx: 000000006c65746e rdx: 0000000049656e69
r8 : 0000000000000000 r9 : 0000000000000000 r10: 0000000000000000 r11: 0000000000000000
r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
rsi: 0000000000000000 rdi: 0000000000000000
rip: 0000023ca56f0007 rsp: 000000478b2fef00 rbp: 0000000000000000
flags: 00000200  CF: 0  PF: 0  AF: 0  ZF: 0  SF: 0  DF: 0  OF: 0

Not bad, it returns the same value when running on a real machine, 0x16. However, when I run cpuid with eax set to 0x16, I get the surprising output:

>>> mov eax, 0x16
>>> cpuid
assembled (2 bytes): 0f a2
rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 rdx: 0000000000000000
r8 : 0000000000000000 r9 : 0000000000000000 r10: 0000000000000000 r11: 0000000000000000
r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
rsi: 0000000000000000 rdi: 0000000000000000
rip: 0000023ca56f0015 rsp: 000000478b2fef00 rbp: 0000000000000000
flags: 00000200  CF: 0  PF: 0  AF: 0  ZF: 0  SF: 0  DF: 0  OF: 0

Then return values are all zero, and they are different from those returned when we set eax to 0x40000000. To sum up, the output is wrong in two senses: 1). when we set eax to 0x16, it does not return a valid CPUID information; 2). when we set eax to 0x40000000, it does not give the same output as if we were running cpuid with eax set to the maximum index of basic information, in this case, 0x16. So these two are subtle differences between a real machine and a VM, which can be used as VM detection as well.

Native Syscall on Windows

Now it is time to analyze the decrypted code. Looking at the image above, we notice it first calls NTCreateThread to create a thread, whose entry is at 0x4010ce. And it then makes two system calls using the syscall instruction. Note the thread entry 0x4010ce is right below the code that makes syscalls, and the two syscalls do not seem to transfer the control to any other places, so it is very likely they are not doing something special.

But we still need to figure out what the two syscalls are doing. I did not see any challenges using syscall on Windows, mostly because the system call index is opaque on Windows, and they can be different across different system versions. Oh, this could be the reason why the author says it only works on specific versions of Windows – it relies on the specific index of certain system calls.

There are many ways to dump the system call on a Windows system. However, since my Windows VM is having a wrong build version, the system call index I can get is also probably NOT the same as the author expects. So I searched online for a bit and found something already organized the information into a nice searchable table at https://j00ru.vexillium.org/syscalls/nt/64/.

So the first syscall is made with eax = 4, and I found it is NtWaitForSingleObject. And the object it waits for happens to be the newly created thread. The next system call is 0x2c, which is NtTerminateProcess. So the remaining code just waits for the thread to finish, and terminate the process.

We also see that the index for these two system calls is different on different major Windows versions, e.g., Win7 v.s. Win10, but they remain the same within different Win10 versions. So they do not account for the special requirement for the three Win10 builds.

So now we shift the focus of the analysis to the thread routine, as shown below:

It starts by making a syscall 0xd, which translates to NtSetInformationThread, with r9 set to 0x11, which means ThreadHideFromDebugger. This is a common anti-debug technique that tried to hide the thread from the debugger. The thread will continue to execute, but the debugger will no longer be notified by any debug events related to the thread.

Next, it retrieves PEB at gs:0x60, at checks whether the field at 0x118 is equal to 0xa. Inspecting the structure with windbg shows (some output omitted):

lkd> dt _PEB
nt!_PEB
...
   +0x118 OSMajorVersion   : Uint4B
   +0x11c OSMinorVersion   : Uint4B
   +0x120 OSBuildNumber    : Uint2B
...

So it is checking whether the OSMajorVersion is 10. Yeah, so it is checking whether this is a Win10.

Moving downward, we see that it is checking OSBuildNumber for a specific value, 0x47bb. I have no idea what it is when I first see it (though there are ways to figure it out). If the version matches, we see it is setting the dword at 0x401149 to be 0xa1. At first, I do not understand it, so I skipped it and moved to analyze the code at 0x401125.

The next system call it makes is 0xa5. Searching it on the previous webpage gives me an interesting result (the image is cropped to show only the important part):

We can see on the latest two versions of Win10, i.e., version 2004 and 20H2, system call 0xa5 means NtCreateDebugObject. However, on version 1909, 0xa5 means a different system call and NtCreateDebugObject is 0xa1. Hmmm, 0xa1, does it look familiar? We have just seen it at address 0x40111e, right? And it is writing to data_401149, in the middle of an instruction. I suddenly understand what it is doing: it is patching the instruction at 0x401148 to "mov eax, 0xa1", when the current system has OSBuildNumber 0x47bb.

Now I am pretty sure 0x47bb means Win10 version 1909. And the code uses a small patching trick to make sure that always calls NtCreateDebugObject, even if the system call number varies. Besides, this also explains why the program only works on a very limited number of Win10 builds: the system call number of other Win10 builds are different as well, and there is no code to take care of that.

A careful reader should have noticed that the code should also work on Win10 version 1903, which happens to have the system call number 0xa1 for NtCreateDebugObject. The only change needed is to also change the instruction to "mov eax, 0xa1" when a Win10 1903 is encountered.

Now, let us get back to the code itself. It is calling NtCreateDebugObject, which is likely to be a common anti-debugging technique. Although I know this technique, I cannot remember the details of it. So let me research the code as if it is something new to me.

The first thing to find out is the definition of the system call, which helps us understand the meaning of its parameters. MS does not document it, but we can still find some clue by searching withing the ReactOS source code:

NTSTATUS
NtCreateDebugObject(
    _Out_ PHANDLE DebugHandle,
    _In_ ACCESS_MASK DesiredAccess,
    _In_ POBJECT_ATTRIBUTES ObjectAttributes,
    _In_ ULONG Flags
);

Alternatively, we can always search it with Duckduckgo and this time we will be lucky since Process Hacker also uses it: https://processhacker.sourceforge.io/doc/ntdbg_8h.html#aaf201d37b7597c3997ba3380de6253dd.

Among the four parameters, the interesting one is the first one, DebugHandle. Note the Windows x64 calling convention passes the first four parameters in the order of rcx, rdx, r8, r9. So we know data_4015ac is the returned DebugHandle. Then the code checks the return value and the system call NtCreateDebugObject must have succeeded.

Anti-debugging Techniques

The next basic block is longer, which starts with two system calls and also includes a function call. Note the last two instructions, i.e.,

push 0x401288
ret

will transfer the control flow to 0x401288. The bytes at 0x401288 do not look like valid code yet, so there might be a second round of decryption. Scanning upwards I see at address 0x4011dc, 0x401288 is moved into rcx, along with a strange string "1c4TLKe6Px8M2fN7iAlC". sub_401226 is very likely a decryption function! Let us have a look at it first:

It is a rather small and simple function: it uses a string as the key to xor decrypt the given data. The actual xor happens at 0x401256. Its four parameters are:

rcx: data to decrypt
rdx: data length
r8:  xor key
r9:  key length

Comparing these with the call-site at 0x4011f8, we can know that the data (code) at 0x401288 is 0x143 bytes long, and the xor key is "1c4TLKe6Px8M2fN7iAlC", which is 0x14 bytes long.

However, if we proceed to decrypt the code, we will get the wrong result. The author sets up another trap here. The xor key string is written to before the decryption. This can be seen in a more obvious way if we define it as a string:

xor_key[4] and xor_key[0x13] are both changed before the decryption. And the new value is derived from data_4014b8 and data_4015bc, which we need to figure out now.

data_4015bc is easier to figure out, since we get cross reference to it, right in the code above:

It is calling NtQueryInformationThread with the second parameter being ThreadHideFromDebugger to query whether ThreadHideFromDebugger is set. Remember the code at 0x4010ef, which uses NtSetInformationThread to set ThreadHideFromDebugger to true (0x1)? Here, the code is checking its value. It is trying to verify we do not change the value. Since a common way to circumvent the ThreadHideFromDebugger is to skip the NtQueryInformationThread call, in which case the thread will not hide from the debugger, but the query result will return false (0x0). Further, the program does not check whether the return value is true or false, rather it uses it as part of the decryption key. Had the program been running outside of a debugger, data_4015bc should have value 0x1 at 0x4011b6. If the value is altered, the program will appear to be running fine, but the decrypted code will contain errors.

This is an aha moment in reversing, and it is one of the reasons I love reversing. Although I do not know the author of the challenge when I reached this point, I enjoy the obstacle he set up here. It even feels that we had a short but pleasant virtual conversation about this challenge.

Also, this reminds me of checking out the implementation of ScyllaHide, the popular anti-anti-debug plugin for x64db, to see if it handles this correctly. Which I will cover at the end of the write-up.

What about data_4014b8? There is no xref to it. But it is pretty close to another data variable data_4014a8,

data_4014a8 is referenced in the remaining system all that we have not analyzed yet:

If data_4014a8 is a non-trivial structure, then data_4014b8 is very likely a field inside of it. And its value will be determined by the NtQueryObject call.

NtQueryObject happens to be documented:

__kernel_entry NTSYSCALLAPI NTSTATUS NtQueryObject(
  HANDLE                   Handle,
  OBJECT_INFORMATION_CLASS ObjectInformationClass,
  PVOID                    ObjectInformation,
  ULONG                    ObjectInformationLength,
  PULONG                   ReturnLength
);

rdx is ObjectInformationClass and its value is 0x2, r8 holds ata_401478 and it is the ObjectInformation that we are interested in.

Searching the MSVC headers or ReactOS source gives the following definition for OBJECT_INFORMATION_CLASS:

typedef enum _OBJECT_INFORMATION_CLASS {
    ObjectBasicInformation,
    ObjectNameInformation,
    ObjectTypeInformation,
    ObjectAllTypesInformation,
    ObjectHandleInformation
} OBJECT_INFO_CLASS;

And 0x2 for ObjectInformationClass means ObjectTypeInformation.

The reverse-engineered definition of OBJECT_TYPE_INFORMATION can be found at geoffchappell’s site:

(The screenshot is cut short to save space)

We can do the calculation and find data_4014a8 is at offset 0x10 into the structure at data_4014a8, and the field is ULONG TotalNumberOfObjects. What is the correct value of TotalNumberOfObjects, if the program is not being debugged? Details can be found here and it should be 0x1. Now the code looks like this:

And we know both object_type.TotalNumberOfObjects and thread_hide_from_debugger is 0x1, so we can deduce xor_key[4] will be changed to 0x42 (‘B’), and xor_key[0x13] will be changed to 0x51 (‘Q’). And the xor_key becomes "1c4TBKe6Px8M2fN7iAlQ". Decrypting 0x143 bytes starting from 0x401288 gives me the following code:

Resolving DLL Imports with Function Name Hash

The call at 0x40129c and 0x4012b7 looks way too familiar to me. It is finding the address of a particular function inside a DLL. The difference between the ordinary GetProcAddr is that it uses a hash of the function name, rather than the function name itself for the lookup. There is a uint32_t hash(char* function_name) that returns a dword as the hash for the function name. And the code walks the export table of the given DLL, calculate the hash of every export function, and see if there is a match. In this example, the two hashes are 0xa216a185 and 0x9a9c4525.

How do we know which function it tries to find? Well, for this simple example, we can guess from the code that the first one is a LoadLibraryA, and the second one is a MessageBoxA (from the challenge description). However, if we need to deobfuscate a lot of functions, guessing is not a good idea.

There are mostly two ways to deal with it. The first one is to run the code, ask itself to find the function, and we just write it down. This is helpful when the number of functions is small, and the code can run properly. If we are analyzing a large binary or a memory dump, then it is not feasible.

The second way is to reverse engineer the hash function, enumerate the export table of the DLL, and try to find a match by ourselves.

The function needs to process the PE format so it is not trivial. But there is a shortcut to deal with it. We can see the loop at 0x401372 is operating on a string in rsi, and the result is put into rdi. At 0x401381, the calculated hash is compared with the expected_hash, which is an argument of the function. If they match, the code proceeds to find the address of the function; if they do not match, the code proceeds to the next loop.

So we only need to reverse engineer the loop at 0x401372. A Python equivalent is:

def rol(val, n):
    bin_str = bin(val)[2:]
    bin_str = '0' * (32 - len(bin_str)) + bin_str
    bin_str = bin_str[n : ] + bin_str[ : n]
    return int(bin_str, 2)

def calc_hash(name):
    val = 0
    for c in name:
        val += ord(c)
        val &= 0xffffffff
        val = rol(val, ord(c) & 31)
    return val

# prints 0xa216a185
print(calc_hash('LoadLibraryA'))
# prints 0x9a9c4525
print(calc_hash('MessageBoxA'))

There is one thing worth noting about at 0x401377, the code is "rol edi, cl" where the cl is the next input char. cl can be (and likely is) larger than 31 since it is an ASCII char. However, the edi is only 32 bits wide, what would happen? Well, I studied the behavior of this case earlier in another writeup, and the conclusion is:

The count is masked to 5 bits (or 6 bits if in 64-bit mode and REX.W is used). The count range is limited to 0 to 31 (or 63 if 64-bit mode and REX.W is used).

In other words, only the lowest 5 bits of the input char will be involved in the rol operation. And that is also the reason that I wrote val = rol(val, ord(c) & 31) in the Python code.

Another interesting thing is the way the author passes the DLL handle. The second handle, i.e. the handle of user32.dll, is returned by LoadLibraryA so there is nothing special about it. But for the first handle, we can find LoadLibraryA from it, which indicates the module must be kernel32.dll. How does the author get it? We can see it is passed in by r15 at 0x401288. Tracing back to the previous function we see mov r15, qword [rel 0x4015c4], and cross-reference of data_4015c4 brings me back to the very beginning of _start:

I noticed this piece of code when I started the journey, but I do not immediately understand it then. But now it is another aha moment! Note this is a hand-written program, so its entry point is where the execution starts. This is different from a compiled program where the main() function is called by the C runtime.

Who calls the entry point? Well, it is somebody inside of the kernel32.dll. Then the author clears the ax, and subtract 0x10000 from rax to get the base of kernel32.dll. This is related to memory alignment, the behavior of ASLR, as well as the offset of the callee into the base of the DLL. I am not sure it always works, but it looks fine to me. In the end, the base of kernel32.dll is saved into data_4015c4.

Alright, we have deciphered all the secrets of this challenge!

This is a small binary so we can reverse all of the bytes in it. I notice there are some bytes under the GetProcAddr function, which looks like this:

The 4883 in the beginning tells me it is probably code, and defining a function there gives me:

Ha, another call to MessageBoxA. And this one is calling the one in the IAT table, whereas the real one is dynamically resolved.

NtCreateThreadEx and THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER

The original challenge asked us to make the program run properly and also pop up a MessageBox even when it runs under a debugger. Since we have analyzed all its tricks, I think it would not be hard at all to do it. To do this, I downloaded the Win10 20H2 ISO and installed a VM.

The first patch needed is to hardcode the return value (0x64) of cpuid. I patched the following four instructions:

mov eax, 0x40
bswap eax
cpuid
mov eax, ecx

to

mov eax, 0x64

and copies the patched binary to VM. Now if I double-click it, it does run and the MessageBox pops up:

Not bad, it works!

The next step is to remove the anti-debugging checks. The simplest way is to remove the calls to NtSetInformationThread, NtQueryInformationThread, NtCreateDebugObject and NtQueryObject. And hardcode the expected value, or directly change the xor_key. However, before I make those patches, I found the breakpoint at 0x4010ce is never triggered. The debuggee simple exits.

The first mistake I made is using software breakpoint on self-modifying code. We know that software breakpoint works by patching the byte to 0xcc. The debugger internally keeps a list of addresses of software breakpoints and the original byte value so it will still display the old byte value if we display it. However, things get tricky when the code self-modifies. The 0xcc byte will be overwritten by the new byte value, and it is no longer a breakpoint. Now if the execution reaches the address where we put a breakpoint, it will not fire since the actual byte value is NOT 0xcc. If in a good case, another breakpoint hit (or any other debug event happens) and the debugger gets a chance to inspect the list of breakpoints and see one of them is changed from 0xcc to a new different value, then it can reason:

Ok, this byte was 0x12, and I changed it to 0xcc. Now it is 0xab.
What happened? It must be the program modifies the byte.
I simply need to restore it to 0xcc, and update the "original value" of this byte to 0xab.

If this is the case, the debugger can handle self-modifying code properly. Unfortunately, the case I encounter is the bad case where the modified breakpoint is the one that is expected to fire. So there is no way it works. And the only way is to use a hardware breakpoint (or trace it with single-step).

Nevertheless, even if I used hardware breakpoint on the thread entry it still does not hit. Later, I found the secret is with NtCreateThreadEx. I do not know any anti-debugging tricks with it, so I naively think I can set a breakpoint on the thread entry point and wait there. However, this blog post explains an anti-debugging with NtCreateThreadEx: setting the CreateFlags to THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER (0x4) will also hide the debuggee from the debugger, which has the same effect as calling NtSetInformationThread with ThreadHideFromDebugger. So no wonder the breakpoint on the thread routine will not hit at all! The thread is hidden from the debugger.

This is easy to fix once I understand the trick. Since the code is decrypted before it runs, if we were to patch it we need to make sure we patch the encrypted bytes so the decrypted code is what we want. This is possible, especially when the decryption is just xor. However, I am a little bit lazy and I decide to bypass it in a debugger, i.e., change rbx back to 0, right after the code set it to 0x4 at 0x401034. Now the breakpoint on the thread entry point hits.

Then I directly set the rip to 0x4011b6:

And manually set the value of object_type.TotalNumberOfObjects and thread_hide_from_debugger to 1. Then press F9 to run the program, and the MessageBox pops up:

Nice, I have COMPLETELY analyzed the program and explained lots of details in it. I hope you like this write-up! And feel free to get in touch with me if you have any questions or suggestions.

The challenge can be downloaded at https://crackmes.one/crackme/5e727daa33c5d4439bb2decd. It is created by user BinaryNewbie, who is NOT a newbie for binary reversing.

We will discuss an important topic in this writeup: how to mutate binary executable to obstruct reverse engineering tools. Specifically, these techniques aim to fool the binary parsers so that they fail to parse the binary or the parsing result is missing important information. In the worst case, the binary crashes the analysis tool. For convenience, we will call these techniques Executable Format Manipulation (EFP).

These scenarios are especially discouraging for reversers since they cannot even get started easily. That said, these techniques are not resilient to determined reversers since they can study the file format and figure out what has caused the issue, and fix the binary to allow a better analysis, or improve the binary parser if it is open-source.

EFP often leverages the ambiguity in the executable format specification as well as the gap between the code that enforces the format and the specification. Executable formats are complex to implement, and for several reasons, the executable parser/loader in the operating system can differ from the docs slightly. It is also hard for an analysis tool to precisely replicate the behavior of the OS parser, so this enables the EFP to create binaries that can be executed properly but is hard to analyze properly.

Stage One

This crackme comes with a relatively simple first stage. It is carried out inside the main() function at 0xa80. Since it is not related to what I want to discuss, I will skip the reversing part and only give the algorithm. It first retrieves the currently logged-in user name, and then calculate a key as follows:

name = 'jeff'
val = 0
for i, c in enumerate(name):
    val += ord(c)
    val ^= i
    val ^= 0xf

My user name is “jeff” so the corresponding value is 385. Now I can get past the first stage and proceed to the real challenge.

Stage Two

After we pass the first check, we can see that it loads another program from 0x202020. It starts with "\x7fELF", which is the sign of another ELF. By analyzing the loader code we also know its size is 0x2008. We save this file to the disk and it can be executed properly. We will now work on this file from now. The file is included in the repo and its sha1 sum is 1d31fac493665f8baa23baac8e1aa5385dd1ace2.

BinaryNinja and Ghidra fail to parse it as a valid ELF and can only load it as raw binary. Cutter can load the binary and identify some code (probably thanks to linear sweep), but it cannot find the entry point and cannot find any important functions.

This immediately tells me that there is something unusual with this file, we need to examine it, especially the header, closely.

There are two tools that I often use to inspect a file format. The first one is Kaitai Struct, which is a declarative binary format parsing language. It is specifically designed to ease the development of binary parsers and it can show the parsed binary in a tree view. For many popular formats, including ELF, the community already contributed parsers. It has an online IDE so we do not have to install it. There is a BinaryNinja plugin for it, as well.

Unfortunately, this file also triggers an error in the Kaitai parser so we cannot easily view it in the tree view. This is a big drawback since we lose a strong tool. But we still have other options.

010Editor is another option for binary format inspection. It is primarily a hex editor, but it comes with template that describes various file formats and can show the parse result in a table view. Templates can be downloaded from here or installed from within the program.

010Editor also fails to parse it without issue. However, it can show partial parse results so we can at least see what is normal and what could be wrong. Besides, if no tool can parse it at all, we can still manually inspect it and find and defeat any tricks in it. The 010Editor parsing result looks like this:

The ELF magic looks fine. Immediately after that, we find something unusual, the ELF class byte (offset 0x4) is set to none, whereas it should set to 1 for 32-bit programs and 2 for 64-bit programs. Cutter already showed us some code snippets in it and it is x64 code. So we set it to 0x2. At byte 0x5, the endianness is also not set, which is probably little-endian since it runs properly on my little-endian Linux system. Next, the EI_VERSION at byte 0x6 is set to 0x1 in most ordinary binaries.

After we fix these three fields, BinaryNinja is now able to load it as ELF and find the entry point:

Not bad, but we are missing symbols. I have reversed lots of binaries on Linux so data_201fe0 is actually __libc_start_main and data_a50 is the main() function. After I define the function, it looks like this:

The complexity of the CFG is OK. But since we are missing all imported functions, we have no clue of what this program is doing. If i double click sub_980, it is essentially a jmp to a PLT function.

Which means it is an imported function. Had this binary not been tampered with, we should already know what it is.

Since we have fixed the binary, 010Editor can parse it without any errors. We see that all of the section headers are removed, and the number of segments is also less than usual.

The readers might have heard of that section headers are not important for ELF file executions. Linux only uses information in segments to load the binary and kick off the execution. However, since sections typically exist (generated by compilers) and contain more information than the segments, many reverse engineering tools use information from sections to parse the binary. Now that the section headers are wiped out, they cannot function properly.

There is a e_shoff field in the ELF header that points to the start of the section headers. Section headers, when they exist, are organized into an array and placed at the end of the binary. Of course, they do not have to be there – as long as the e_shoff actually points to the start of it. In several obfuscated ELF binaries that I reversed, the e_shoff is wiped out but the section headers are left intact at the end of the file. For that case, it is easy to repair since we simply need to count how many sections do we have and find out the start of the array accordingly.

However, for this particular binary, the e_shoff and the actual section headers are both wiped out. It is very hard to recover all the section headers since there are lots of information on it.

Note, however, I am not saying the sections are wiped out. No, impossible. Only the section headers are gone. Sections still contain data that is crucial for the execution. And it is highly likely that they are not touched. Though we do not know the boundaries of each of them, so we cannot recover them.

But here is a problem: if we cannot resolve the imports, how could the loader resolve them? The programs execute properly. So there must be a way!

We still have segments and the loader relies on segments to resolve imports. Do segments store the information at another place so it still works? Well, sections and segments overlap. We do not know where sections are since we do not have the section headers, but the segments contain offsets to useful information and can help the loader. Nevertheless, the information in segments is organized in a different format so existing tools do not parse them well. We can either reconstruct a part of the section headers so the analysis tool can parse the imports correctly, or we replace the loader by ourselves – parse the imports directly. This is especially doable for Linux since everything is open-source.

It is noteworthy that there is a third approach – debug the program and see where those stub function jumps into, so that we can resolve the imports semi-manually. I have used this previously for a PE challenge where the imported APIs are obfuscated. This is a small crackme and we do not have lots of them, so the workload is fine. However, when I try to run it in gdb, gdb fails to parse the binary too. It cannot find __libc_start_main so we cannot properly debug it. I would say gdb could do a better job but enhancing gdb right now is not an option for me.

So I turned to another approach – resolve the imports via a script.

Non-lazy symbols

We will start with non-lazy symbols first. Non-lazy symbols are resolved by the loader at loading time. The first thing we need is the DYNAMIC segment. The segments are described in an array of Elf64_ProgramHeader in the ELF header. For this particular binary, it is the No.4 one inside the array.

00000120      [0x4] = 
00000120      {
00000120          enum p_type type = PT_DYNAMIC
00000124          enum p_flags flags = PF_R
00000128          uint64_t offset = 0x0
00000130          uint64_t virtual_address = 0x201d58
00000138          uint64_t physical_address = 0x0
00000140          uint64_t file_size = 0x0
00000148          uint64_t memory_size = 0x0
00000150          uint64_t align = 0x0
00000158      }

We see that the DYNAMIC segment starts at offset 0x201d58. It contains an array of structure Elf64_Dyn, whose definition is:

typedef struct
{
  Elf64_Sxword  d_tag;          /* Dynamic entry type */
  union
    {
      Elf64_Xword d_val;        /* Integer value */
      Elf64_Addr d_ptr;         /* Address value */
    } d_un;
} Elf64_Dyn;

Among the two fields, d_tag specifies the type of it. And depending on the value of d_tag, d_un could be either an address or an integer value. Some legal values for d_tag are:

/* Legal values for d_tag (dynamic entry type).  */

#define DT_NULL     0       /* Marks end of dynamic section */
#define DT_NEEDED   1       /* Name of needed library */
#define DT_PLTRELSZ 2       /* Size in bytes of PLT relocs */
#define DT_PLTGOT   3       /* Processor defined value */
#define DT_HASH     4       /* Address of symbol hash table */
#define DT_STRTAB   5       /* Address of string table */
#define DT_SYMTAB   6       /* Address of symbol table */
#define DT_RELA     7       /* Address of Rela relocs */
#define DT_RELASZ   8       /* Total size of Rela relocs */
#define DT_RELAENT  9       /* Size of one Rela reloc */
#define DT_STRSZ    10      /* Size of string table */
#define DT_SYMENT   11      /* Size of one symbol table entry */
#define DT_INIT     12      /* Address of init function */
#define DT_FINI     13      /* Address of termination function */
#define DT_SONAME   14      /* Name of shared object */
#define DT_RPATH    15      /* Library search path (deprecated) */
#define DT_SYMBOLIC 16      /* Start symbol search here */
#define DT_REL      17      /* Address of Rel relocs */
#define DT_RELSZ    18      /* Total size of Rel relocs */
#define DT_RELENT   19      /* Size of one Rel reloc */
#define DT_PLTREL   20      /* Type of reloc in PLT */
#define DT_DEBUG    21      /* For debugging; unspecified */
#define DT_TEXTREL  22      /* Reloc might modify .text */
#define DT_JMPREL   23      /* Address of PLT relocs */
#define DT_BIND_NOW 24      /* Process relocations of object */
#define DT_INIT_ARRAY   25      /* Array with addresses of init fct */
#define DT_FINI_ARRAY   26      /* Array with addresses of fini fct */
#define DT_INIT_ARRAYSZ 27      /* Size in bytes of DT_INIT_ARRAY */
#define DT_FINI_ARRAYSZ 28      /* Size in bytes of DT_FINI_ARRAY */
#define DT_RUNPATH  29      /* Library search path */
#define DT_FLAGS    30      /* Flags for the object being loaded */
#define DT_ENCODING 32      /* Start of encoded range */
#define DT_PREINIT_ARRAY 32     /* Array with addresses of preinit fct*/
#define DT_PREINIT_ARRAYSZ 33       /* size in bytes of DT_PREINIT_ARRAY */
#define DT_SYMTAB_SHNDX 34      /* Address of SYMTAB_SHNDX section */
#define DT_NUM      35      /* Number used */
#define DT_LOOS     0x6000000d  /* Start of OS-specific */
#define DT_HIOS     0x6ffff000  /* End of OS-specific */
#define DT_LOPROC   0x70000000  /* Start of processor-specific */
#define DT_HIPROC   0x7fffffff  /* End of processor-specific */
#define DT_PROCNUM  DT_MIPS_NUM /* Most used by any processor */

There are many important information in this array. For example, there are six fields related to INIT and FINI, i.e., DT_INIT, DT_FINI, DT_INIT_ARRAY, DT_INIT_ARRAYSZ, DT_FINI_ARRAY, DT_FINI_ARRAYSZ. However, those relevant to the resolving of import functions are listed below:

00201d58  struct Elf32_Dyn _.dynamic[26] =  
00201d58  {
00201dd8      [0x8] = 
00201dd8      {
00201dd8          enum Elf64_Sxword d_tag = DT_STRTAB
00201de0          uint64_t d_ptr = 0x4e8
00201de8      }
00201de8      [0x9] = 
00201de8      {
00201de8          enum Elf64_Sxword d_tag = DT_SYMTAB
00201df0          uint64_t d_ptr = 0x2c0
00201df8      }
00201df8      [0xa] = 
00201df8      {
00201df8          enum Elf64_Sxword d_tag = DT_STRSZ
00201e00          uint64_t d_ptr = 0x113
00201e08      }
00201e08      [0xb] = 
00201e08      {
00201e08          enum Elf64_Sxword d_tag = DT_SYMENT
00201e10          uint64_t d_ptr = 0x18
00201e18      }
00201e28      [0xd] = 
00201e28      {
00201e28          enum Elf64_Sxword d_tag = DT_PLTGOT
00201e30          uint64_t d_ptr = 0x201f48
00201e38      }
00201e38      [0xe] = 
00201e38      {
00201e38          enum Elf64_Sxword d_tag = DT_PLTRELSZ
00201e40          uint64_t d_ptr = 0x168
00201e48      }
00201e58      [0x10] = 
00201e58      {
00201e58          enum Elf64_Sxword d_tag = DT_JMPREL
00201e60          uint64_t d_ptr = 0x788
00201e68      }
00201e68      [0x11] = 
00201e68      {
00201e68          enum Elf64_Sxword d_tag = DT_RELA
00201e70          uint64_t d_ptr = 0x680
00201e78      }
00201e78      [0x12] = 
00201e78      {
00201e78          enum Elf64_Sxword d_tag = DT_RELASZ
00201e80          uint64_t d_ptr = 0x108
00201e88      }
00201ef8  }

We can see that DT_STRTAB has value 0x4e8, which means the string table starts at offset 0x468. Also, the DT_STRSZ is 0x113, so the size of the string table is 0x113. This can be verified in the following image:

We can see many familiar names in it, e.g., srand, time, and malloc. These are the names of imported functions. Now what we need to figure out is how these are linked with symbols so that we can know which symbol corresponds to which name.

The next thing we should look at is the symbol table. DT_SYMTAB is 0x2c0, which means the symbol table starts at 0x2c0. DT_SYMENT is 0x18, which suggests there are 0x18 = 24 symbol entries. Interestingly, there are 23 entries, which I do not fully understand. If anyone has any idea on this, feel free to help me out.

Each symbol entry is an Elf64_Sym:

typedef struct
{
  Elf64_Word    st_name;        /* Symbol name (string tbl index) */
  unsigned char st_info;        /* Symbol type and binding */
  unsigned char st_other;       /* Symbol visibility */
  Elf64_Section st_shndx;       /* Section index */
  Elf64_Addr    st_value;       /* Symbol value */
  Elf64_Xword   st_size;        /* Symbol size */
} Elf64_Sym;

Due to space limitation, I will only show the first three symbol entries here:

000002c0  struct Elf64_Sym data_2c0[23] = 
000002c0  {
000002c0      [0x0] = 
000002c0      {
000002c0          uint32_t st_name = 0x0
000002c4          uint8_t st_info = 0x0
000002c5          uint8_t st_other = 0x0
000002c6          uint16_t st_shndx = 0x0
000002c8          uint64_t st_value = 0x0
000002d0          uint64_t st_size = 0x0
000002d8      }
000002d8      [0x1] = 
000002d8      {
000002d8          uint32_t st_name = 0x9d
000002dc          uint8_t st_info = 0x12
000002dd          uint8_t st_other = 0x0
000002de          uint16_t st_shndx = 0x0
000002e0          uint64_t st_value = 0x0
000002e8          uint64_t st_size = 0x0
000002f0      }
000002f0      [0x2] = 
000002f0      {
000002f0          uint32_t st_name = 0xce
000002f4          uint8_t st_info = 0x20
000002f5          uint8_t st_other = 0x0
000002f6          uint16_t st_shndx = 0x0
000002f8          uint64_t st_value = 0x0
00000300          uint64_t st_size = 0x0
00000308      }
00000308      [0x3] = 
00000308      {
00000308          uint32_t st_name = 0x54
0000030c          uint8_t st_info = 0x12
0000030d          uint8_t st_other = 0x0
0000030e          uint16_t st_shndx = 0x0
00000310          uint64_t st_value = 0x0
00000318          uint64_t st_size = 0x0
00000320      }

The first entry is always all 0. So the first entry has index 0x1. Field st_name does not store the string itself. Instead, it stores the offset into the string table that we discussed earlier. Each name is null-terminated. Given the value 0x9d, we can find out that is free. st_info contains the symbol type that we will not cover in detail here. Now that we connect symbols with its name, we still have no idea which PLT entry corresponds to which symbol. And that is the last part of the mystery.

There are two relocation tables. The first one is DT_RELA and it starts at 0x680 and has a size 0x108. The second one is DT_JMPREL. It starts at 0x788 and it has a size 0x168. Both of them are arrays of Elf64_Rela which is defined as follows:

typedef struct
{
  Elf64_Addr    r_offset;       /* Address */
  Elf64_Xword   r_info;         /* Relocation type and symbol index */
  Elf64_Sxword  r_addend;       /* Addend */
} Elf64_Rela;

The first 4 entries are listed here:

00000788  struct Elf64_Rela _.rela.plt[15] = 
00000788  {
00000788      [0x0] = 
00000788      {
00000788          uint64_t r_offset = 0x201f60
00000790          uint64_t r_info = 0x100000007
00000798          int64_t r_addend = 0x0
000007a0      }
000007a0      [0x1] = 
000007a0      {
000007a0          uint64_t r_offset = 0x201f68
000007a8          uint64_t r_info = 0x300000007
000007b0          int64_t r_addend = 0x0
000007b8      }
000007b8      [0x2] = 
000007b8      {
000007b8          uint64_t r_offset = 0x201f70
000007c0          uint64_t r_info = 0x400000007
000007c8          int64_t r_addend = 0x0
000007d0      }
000007d0      [0x3] = 
000007d0      {
000007d0          uint64_t r_offset = 0x201f78
000007d8          uint64_t r_info = 0x500000007
000007e0          int64_t r_addend = 0x0
000007e8      }
000007e8      [0x4] = 
000007e8      {
000007e8          uint64_t r_offset = 0x201f80
000007f0          uint64_t r_info = 0x700000007
000007f8          int64_t r_addend = 0x0
00000800      }

Taking the first entry as an example, the r_offset is 0x201f60. Where is this address? Going back to the DYNAMIC segment, we see that DT_PLTGOT is 0x201f48. This means the PLT starts at 0x201f48.

We know the first three entries of PLT have special uses so the first item the compiler tends to use is the fourth one. Now the last problem is which function does the first entry corresponds to.

The secret is in the r_info, which has a value of 0x100000007. There are three macros related to it:

#define ELF64_R_SYM(i)          ((i) >> 32)
#define ELF64_R_TYPE(i)         ((i) & 0xffffffff)
#define ELF64_R_INFO(sym,type)      ((((Elf64_Xword) (sym)) << 32) + (type))

The low dword is 7, which specifies the type of relocation entry. and the high dword is 1, which means that the current relocation entry corresponds to the no.1 entry in the symbol table. Remember the No.0 entry is always 0 and we already mentioned that the no.1 entry is free(), so we can rename it to free right now.

This binary is small so I manually resolved all the names like this. But if the binary is large and has many import functions, it is also not hard to write a Python script to resolve them automatically. It looks like this after I finish them.

And we now know what is happening in main().

Solve it, finally!

Not that we have passed the most difficult part of the challenge. We still have to reverse the algorithm and solve the challenge itself. The first thing I notice is there is a ptrace based anti-debug:

Since there is no integrity check on the binary, I simply patched to Never Branch so it never gets to the failure path.

The next challenge is gdb cannot properly debug it. It cannot even find and set a breakpoint at __libc_start_main. Even if we use the actual address of _start, which is the entry point of the binary, it still malfunctions. I do not have even time to debug why gdb fails, but I managed to find a workaround. I patched an instruction (near the _start) to 0xcc (int3), so it will break and gdb manages to catch it (thx!), we can start debugging from there.

The underlying algorithm is not complex so we will skip it here.

Lazy Symbols

Now that we have explained how non-lazy symbols are resolved. Many materials explain how lazy symbols are resolved. Note the way that the two types of symbols are resolved differently. Lazy symbols are not resolved in a slightly different way. We will recap how they differ and discuss what are some consequences.

So the call to time() in the main() function actually first calls into a stub function. The qword at time_GOT is 0x986, and the code at 0x986 is:

Now we see the push 0x6 and the jmp which is covered in lots of writeups about PLT/GOT. 0x6 is also the index into the relocation table that helps the loader resolve the import. We all know that lazy-symbols are not resolved at load-time. When the program calls it for the first time, the index (0x6) is pushed onto the stack before the code gets to _dl_runtime_resolve(). Note this push n is ONLY used for lazy symbols. For non-lazy ones, the loader uses the information in Elf64_Rela->r_info to resolve the imports. By the time the import function is called for the first time, the value at time_GOT is already the actual address of time() in libc.so and NOT 0x986. So the code in the above screenshot is never executed. You can patch it to int 3 to test it. However, for lazy symbols, where the push n plays a role, if we do the same patch, the program will crash during loading.

To sum up, non-lazy symbols directly use the index in Elf64_Rela->r_info and lazy-symbols use index in the push n to the first index into the relocation table, and then use Elf64_Rela->r_info to continue the resolution.

Thus, to obfuscate the binary, we can change the value of push n and make it point to a different symbol. Since it seems current tools all use Elf64_Rela->r_info to retrieve the index value into the symbol table. So there is an opportunity to create a binary that executes as expected, but cannot be properly analyzed by reverse engineering tools. I will update this writeup when I have a concrete example.

For reverse engineering tools, the best way to defeat this obfuscation is to distinguish lazy/non-lazy symbols and parse the push n for lazy symbols and obtain the index accordingly. But this creates several issues since they typically do not only support x86/x64, they have to also support other architectures like ARM. There are going to be some nuances that inflate the code logic so it is not simple to do.

References

There are many references that I used during writing. Unfortunately, I did not mark it when I referenced them. Instead, I assembled a list and put it here:

• elf.h in Linux source code
• Book "Learning Linux Binary Analysis"
• Understanding _dl_runtime_resolve
• ELF: dynamic struggles

The Plan

I have always been hoping to make some reversing challenges based-on the encoding of the x86 instruction set. It does not have to be super hard, maybe just explore some interesting aspects of the x86, which goes lower than the disassembly. Recently, thanks to my intern task that lifts x86 instructions, as well as reading this blog post, I decided to do it rather than set it for the future (indefinitely).

There are several ways to do it, and I think it is not a bad idea to mutate the executable code according to the user input. It is interesting because, for most reversing challenges, the solver is not expected to change (patch) the code. However, we can take the user input and explicitly use it, in certain ways, to modify the code.

So how do we do it? Executing the user input directly is probably not a good idea. Since code is typically non-printable, so the solution is going to be ugly. More importantly, when we grant the player with arbitrary code execution, it is hard to enforce that they solve it in our intended way.

So it is best to modify existing code according to the user input. The first thing that came to my mind is we can do some arithmetics with it. We can have an equation like:

start_value ± a1 ± a2 ± .. ± an == result

Where the user has to figure out the correct plus or minus sign to make this equation correct. The start_value, result, as well as the ai (1 <= i <= n), are all randomly generated. I made them 32-bit integers.

Implementing and Automating

There are a couple of things to make the idea concrete.

Firstly, how do we accept the user inputs? We can directly take plus or minus signs as string literals but I wish to make it slightly twisted here: the program will take a 32-bit integer and use each of its bits as the indicator of plus/minus.

The next thing is about the x86 instruction encoding. I decided to use the register eax to hold the accumulated value and eventually compare it with the target value. We know that x86 instruction encodes the opcode in a straight-forward way, so it is quite easy to switch between an add instruction and sub instruction.

If you look at the highlighted line, you will notice that ADD EAX, imm32 is encoded as 05 id, where the 05 stands for the opcode, and the id means a 32-bit immediate follows it. So if we have bytes 0512345678, it will decode to ADD EAX, 0x78563412 (note the endianess). Similarly, SUB EAX, imm32 is encoded as 2D id. So the real difference between an ADD EAX, imm32 and a SUB EAX, imm32 is the opcode, i.e., the first byte of the instruction.

So the code modifying is easy: we just need to check every bit of the user input and overwrite the opcode byte of the correct one (05 or 2D). Each instruction is 5 bytes and the latter four bytes encode the immediate value in the equation.

This challenge can be made manually, but I prefer to be able to generate it automatically. That brings several benefits, e.g., the ease of debugging during development. The source code of the challenge is provided in the source folder, and you can have a look at it.

The code that does not change is written in C, whereas a Python script will generate random constant values for the changes and write it to a .h header file. the header file is included in the C source file so it can compile end-to-end. I also make a Makefile so I can easily build debug and release version of it. The Python generator looks like this:

import random
import os

rounds = 32
MAXINT = 0xffffffff

output = open('code.h', 'w')

val = random.randint(0, MAXINT)
# mov eax, val
output.write('{0xb8, 0x%x},\n' % val)
ans = 0

for i in range(rounds):
    op = random.randint(0, 1)
    round_val = random.randint(0, MAXINT)
    ans |= (op << i)
    if op == 0:
        val -= round_val
    else:
        val += round_val

    val &= MAXINT
    
    junk_opcode = random.randint(0, 0xff)
    output.write('{0x%x, 0x%x},\n' % (junk_opcode, round_val))

# cmp eax, val
output.write('{0x3d, 0x%x},' % val)
output.close()

print('the answer is: %d' % ans)
os.system('make')

The C source file defines a struct to describe the two particular instructions we are using:

#pragma pack(1) 
typedef struct
{
    unsigned char opCode;
    uint32_t operand;
}instr;

The main.c is the core part of the challenge:

#define N 32

instr code[]  __attribute__ ((section (".x86"))) = {
    #include "code.h"
    {0x0f, 0x9090d094},         
    // 00201043  0f94d0             sete    al  {0x1}
    // 00201046  90                 nop     
    // 00201047  90                 nop     
    {0xc3, 0}
    // 00201048  c3                 retn     {__return_addr}
};

int main()
{
    // read the input
    int input = 0;
    int unused = scanf("%d", &input);
    // modify the code according to the user input
    for(int i = 0; i < N; i ++)
    {
        bool bit = input & 1;
        input >>= 1;
        if (bit)
        {
            // add eax, imm32
            code[i + 1].opCode = 0x05;
        }
        else
        {
            // sub eax, imm32
            code[i + 1].opCode = 0x2d;
        }
    }
    // set page to executable
    void *page =
     (void *) ((unsigned long) (&code) &
        ~(getpagesize() - 1));
    mprotect(page, getpagesize(), PROT_READ | PROT_WRITE | PROT_EXEC);

    // call the code and check result
    bool (*func_ptr)() = (void*)&code;
    if (func_ptr())
    {
        printf("Well done!\n");
    }
    else
    {
        printf("Try again!\n");
    }
}

Solving it with Z3

Now it is time to solve it. A dull brute-force solves it, though it could take a while to complete. The most straightforward idea is to use Z3. We create 32 booleans and transcribe the calculations into Z3 syntax. Of course, we need to extract those constant values, but it should be relatively easy. Then I get:

from z3 import *

# extracted from the challenge binary
init_val = 0x3df2f794
target_val = 0x7a612770
constants = [
    0x52ae22f2,
    0xbf409bcc,
    0x46417dc1,
    0x25f7d9a1,
    0xef83a7ce,
    0x2dd63e8e,
    0x584a1ec5,
    0x8e58e1df,
    0xf2705f70,
    0x2e94ef1e,
    0x3ca9e080,
    0xa617b5df,
    0x29ae9c3d,
    0x7461ed52,
    0x7125faac,
    0x65dfffd6,
    0x97f1f41c,
    0x6f4e0648,
    0xd803e5d0,
    0xf358f0eb,
    0xbc3b30c7,
    0x585685f8,
    0x2a9cc47c,
    0x7f03d175,
    0xc1d942ae,
    0x174c7d4f,
    0xb7d004f0,
    0xbec8b077,
    0x8ce8eaa2,
    0x2510e330,
    0x4aed0eee,
    0x4043cd91
]

# solver script
n = 32
inputs = [Bool('bit_%d' % i) for i in range(n)]

val = BitVecVal(init_val, 32)
for i in range(n):
    val = If(inputs[i], val + constants[i], val - constants[i])

s = Solver()
s.add(val == BitVecVal(target_val, 32))

if s.check() == sat:
    print('solved')
    m = s.model()
    solution = 0
    for i in range(n):
        bit = m.evaluate(inputs[i])
        if bit:
            solution |= (1 << i)
    print(solution)
else:
    print('failed')

It works but it is a little bit slow. It took 5 minutes to solve it, IIRC. The solution I get is:

$ python z3_solve.py 
solved
2371132652

And it works:

$ ./x86
2371132652
Well done!

Interestingly, the solution found by Z3 is different from the seed I used to generate the challenge, which is 1804139300. But this is not surprising since there could exist other solutions than the original one. And I did not do anything to enforce the uniqueness of the challenge.

Solving it with Divide-and-Conquer

Z3 is good enough. However, there is another way to solve it. We can use divide-and-conquer to accelerate the brute-force. We can try the first 16 bits, which make up (2 ^ 16 = 65536) possibilities. We take note of the values we get. After that, we do the same thing for the latter 16 bits and do the same. Now we compare the two sets and compare if there are any matches. This allows us to find solutions in a faster way. Also, this can help us find ALL the solutions to this challenge.

I am too lazy to do it by myself. I will leave it for interested readers!

First Impression

The forum probably does not allow users to post binary files, so challenges are all posted as base64 encoded. There are too many ways to restore the binary, but Binary Ninja saves you from remembering the command: Just copy the encoded text, create a new empty binary, and then click “Paste From” -> “Base64”. Then you are done!

We get a 14.5 kB ELF file. There is some mild obfuscation in the start of the main, which does not pose a serious challenge. In the middle of the main we see the program is reading input and checking length:

The first thing I notice is that the input must be exactly 0x50 chars, which is quite unusual. Not it reads at most 0x50 chars and checks if the chars read are at least 0x50 chars, which means it must be 0x50 chars.

Besides, after the length check, we see it calls mmap. For reversing challenges, once we see a mmap in it, probably there is a self-modifying code.

Moving downward we see that the program copies a 0xae4-byte buffer into the newly allocated buffer, and then calls it. A strange thing here is the user input is moved into register r12. Typically, no compilers will use register r12 to pass function argument, so this code might be hand-crafted.

After the call rdx, the program tells if the flag is correct based on the return value. Now the next step is obvious, we need to define a function on that code buffer and see what it has.

Decryption routine

The function looks like this. The loop decrypts another buffer at data_20ab, whose size is 0xa59. The decryption is just xor with 0x9f. Note the code_size variable sits right after this function, and right before the next data buffer to be decrypted. Meanwhile, the loop calculates a checksum of the next data buffer, and compare it with the dword at register r12. What is it? It is the user input! So the user input must match the checksum value.

If the checksum matches, the program continues to execute the second newly decrypted buffer. Here, we can use Binary Ninja’s transformation to transform the data in place, after which we define a function at the start of it.

The newly defined function looks like this:

It looks almost the same as the previous one, except for some small mutations. The xor key is different and it is 0xb6 this time. The buffer size is 0x9ce this time, which is smaller than the previous one. And that indicates we are probably recursively decrypting this buffer and each time we only decrypt the first part of it, which forms a function.

I tried to repeat the process a few times and it just repeats. RECURSION. That is probably a good reason for the name.

The first way to solve this is to solve it statically. We only need to get the xor key and the buffer size, to decrypt the buffer and calculate the checksum. However, due to the mutation, it is not that easy to get it correct. It is, though, definitely possible, but not optimal. So I come up with a dynamic approach.

Using Hardware Breakpoints and Automating GDB

I did not rewrite the checksum algorithm by myself, despite it is super simple. Even if it is super complex and I cannot reverse/rewrite it, I can still solve this challenge. Why?

Because we can wait at the line where the dword from the user input is compared with the correct checksum. Particularly, it is the cmp esi, edi line. the register esi holds our input, which, during debugging, is trash. Register edi holds the correct checksum. If we set a breakpoint here and examine the value of edi, we directly get the correct checksum.

However, this approach cannot easily scale to the entire challenge. The problem here is we do not know where to set the next breakpoint before we decrypt the code. However, manually decrypting the code is arduous and error-prone, so we would better automate the solution.

Note the address of the user input buffer is moved into r12 and never changed. If one checksum matches, the program executes add r12, 0x4 to move to the next dword. So we can use a hardware breakpoint to catch the program when it reads the buffer r12, and read the value of edi. Then we remove the current hardware breakpoint, set a new one on the next address, and wait for the program to break again.

Automating GDB is easier said than done. I have known it is possible for a long time, though I have never done it before. After duckduckgo-ing a little bit, I found there are two ways to do it. The first one is to implement a GDB command in Python; the second way is to use pygdbmi to interact with GDB’s machine interface.

Both methods allow us to execute gdb commands as if we directly use GDB, and get the output from GDB afterward. However, I found the pygdbmi approach is much harder to use for the current purpose. First of all, it runs GDB headlessly. So if there is an error in the script, it is hard to find it. Conversely, if we take the first approach, since we register ourselves as a new command (solve in particular) after we run the stuff we are still in GDB. We can see the commands we executed and see the outputs from GDB, which allows painless debugging. Also, despite the name machine interface, it does not automatically parse the string output from GDB. For example, if we examine the value of rdi by executing

p/x $rdi

The GDB returns something like:

$1 = 0x555555557e90

I would expect the pygdbmi to parse the value for me. However, it does nothing for this and directly returns the string output. We get the very same thing in the first approach. So obviously it is the better way to do it.

Note that I am not saying gdbmi is not good. It is used by various projects, e.g., gdbgui, which is a browser-based GDB frontend. If you have not tried it, I strongly recommend you to experiment with it. It is just using gdbmi will require more development work and it is not suitable for reversing challenge, where we care more about getting things rolling faster.

Ok, so much for the comparison. It is time to get to the code. The code is not fancy – it just requires some effort to write it correctly.

import gdb
import struct

def get_reg_value(response):
    response = response.split()[2]
    value = int(response, 16)
    return value
    
class Solve(gdb.Command):
    def __init__(self):
        # This registers our class as "solve"
        super(Solve, self).__init__("solve", gdb.COMMAND_DATA)

    def invoke(self, arg, from_tty):
        # When we call "solve" from gdb, this is the method
        # that will be called.

        dummy_input = open('input.txt', 'wb')
        dummy_input.write(b'1' * 0x50)
        dummy_input.close()

        solution = bytes()

        inferiors = gdb.inferiors()
        inferior = inferiors[0]
        gdb.execute('del')
        gdb.execute('file crackme.elf')
        gdb.execute('set breakpoint pending on')
        gdb.execute('b __libc_start_main')
        gdb.execute('r < input.txt')
        response = gdb.execute('p/x $rdi', to_string = True)
        main_addr = get_reg_value(response)
        main_addr_raw = 0x1229
        print(main_addr)
        base = main_addr - main_addr_raw

        gdb.execute('b *%d' % (base + 0x1399))
        gdb.execute('c')

        response = gdb.execute('p/x $rax', to_string = True)
        input_addr = get_reg_value(response)
        print('input_addr', hex(input_addr))
        
        i = 0
        while True:
            try:
                gdb.execute('del')
                gdb.execute('rwatch *%d' % (input_addr + i * 4))
                gdb.execute('c')

                response = gdb.execute('p/x $edi', to_string = True)
                checksum = get_reg_value(response)
                print('checksum', hex(checksum))
                solution += struct.pack('<I', checksum)
                
                gdb.execute('set $rsi = %d' % checksum)
                i += 1
            except:
                break

        print('=' * 50)
        print('the flag is:')
        print(solution)
        print('len:', len(solution))

        output = open('solution.txt', 'wb')
        output.write(solution)
        output.close()


# This registers our class to the gdb runtime at "source" time.
Solve()

To use it,

1. run gdb
2. inside gdb, run source gdb_solve.py
3. inside gdb, run solve
4. after it runs, it should print the solution and also write it to solution.txt
5. verify it by cat solution.txt | ./crackme.elf

Which is quite simple, isn’t it? Maybe the command rwatch is new, which sets hardware read/write breakpoints.

The correct flag contains non-printable chars, which is not surprising, as it is unlikely the checksum of the code happens to be a printable string. Unless the maker put some effort to make it that way.

In the above script, there is one thing to point out. We run

set breakpoint pending on

before

b __libc_start_main.

This is because, if we do not do it, the attempt to set a breakpoint on __libc_start_main will produce an error. And it only happens before we run the binary. So in other words, if we first run the binary in GDB for at least once, and then directly set a breakpoint on __libc_start_main, it will succeed. That is because GDB has seen that function once, and it knows to wait for it. However, since we are automating GDB, every time it bootstraps cleanly and it does not know there exists a __libc_start_main, hence the error. I am not familiar enough with the GDB source code so I cannot speculate why it happens, but probably there are some reasons behind it. Anyway, set breakpoint pending on is the correct way to deal with it.

The author also released his/her own writeup, which needs to be decrypted by the correct flag. I suggest you to have a look at it, espcially the mutation part.

First Impression

The target (keygenme4.exe) is a PE. The entry point looks like this:

There are several things which we can notice easily:

1. The basic block is quite long.
2. It has excessive amounts of continuous arithmetic operations.

1. is quite common for obfuscated code. Several obfuscation techniques inflate the code and make it hard to read. 2. is unique to this obfuscator. If we look at the following instructions closely, we notice it is first loading a constant into eax, does a series of arithmetic operations on it, and saving it to a variable.

0041af0a  mov     eax, dword [data_41c1b4]
0041af10  shr     eax, 0x0
0041af13  shr     eax, 0x1
0041af16  xor     eax, 0xa8f3a9ca
0041af1c  shl     eax, 0x7
0041af1f  sub     eax, 0x5a041880
0041af25  mov     dword [ebp-0x14 {var_18}], eax

After we check the dword value at data_41c1b4, we can emulate the above code snippet and find out the final value of eax. It turns out to be 0. So the code is equivalent to:

0041af25  mov     dword [ebp-0x14 {var_18}], 0x0

data_41c1b4 is a global variable. When we click on it, we can see all its cross-references. After browsing the list we find that the value is read a lot of time, but it is never written to.

This means the value never changes. And sequence of instructions like the above one can be simplified to just one constant load.

We will call this convoluted constant load later on. Not bad, we break one of the obfuscation! Well, not yet. We just understand how it works and solves it manually. But we need to solve them automatically. Automation is an important topic in deobfuscation. Often the obfuscation is not hard to understand, but solving them can be much harder. We will discuss how to tackle it later.

Hunting for Other Obfuscation Techniques

As we explore the binary, we can find the following obfuscation techniques.

Obfuscated Calls

0x41c0fa is the string to be printed by printf, which is nothing special. The next four instructions do the interesting stuff:

00416db8  call    $+5 {var_c}  {data_416dbd}
00416dbd  pop     eax {var_c}
00416dbe  add     eax, 0xa  {sub_416dc7}
00416dc1  push    eax {var_c}  {sub_416dc7}

After the call $+5, the eip becomes 0x416dbd. Meanwhile, the return address is pushed onto the top of the stack. Note the return address is also 0x416dbd. The following pop, add, push sequence would change the return address to sub_416dc7 (which is also calculated by BinaryNinja).

Now it executes jmp printf. Note this is a jmp so it does not push a return address onto the stack. sub_416dc7 is still on the top of the stack. The string to be printed is right below it. In other words, this creates a fake call stack and it manipulates the return address so the code will continue execution from a different place (rather than the code below the printf).

printf has no magic and it just prints the string. When the execution returns from the printf, the return address sub_416dc7 is popped from the stack and executed. In other words, the above code is equivalent to:

This is not hard to deal with since the pattern is quite obvious. We will cover how to solve it later.

Opaque Predicate

Another abnormal thing we notice is the code has an excessive amount of branches. If we look at the code closely, we can see something like this:

00401248  sub     edx, edx  {0x883d6589}  {0x883d6589}
0040124a  jne     0x40120a  {0x0}

Thanks to the sub edx, edx, the zero flag is always set thus the jne never jumps. This is more obvious if we switch to the Low-Level IL (LLIL):

In other words, the branch is fake and the execution always gets to 0x40124c. We call this an opaque predicate.

Opaque predicate is a well-known obfuscation technique that slows down reversers. When we reverse a piece of code, we often first get a grasp of the behavior of the code by looking at its layout (branches, loops, etc). Even beginners know to look for the critical branch that decides whether the code will print a “congratulation” or “sorry”.

Opaque predicate can be removed statically – since they are opaque and one branch is always taken. However, in real-world, we can use some mathematical fact that is hard to be solved by a program. For example, for any integer x, this is always true:

x * (x + 1) * (x + 2) == 0 (mod 6)

If we know the set of opaque predicates the obfuscator use, then we can do a pattern matching. Otherwise, we might need to use z3 to prove it. The good news is, in this particular binary, the opaque predicates are quite easy to deal with.

Junk Code Insertion

Inserting junk code is another popular obfuscation technique. Check out the following code:

It is pretty messy – which is a sign of useless code. And we see the register edx is overwritten before it is used. By “used” I mean it is not written to the memory or used to calculate other values.

Junk code insertion is very easy to implement, and not always easy to solve. There is no silver bullet for it, though optimization is the general method to deal with it. Yes, optimization not only helps compiler generate faster code, it also helps remove unnecessary code. For the interested readers, this script uses LLVM to remove the Trigress VM.

However, in this writeup, we will take a different approach. We will leverage some property of the code generated by TCC and solve it by backward taint analysis.

Writing a deobfuscator

Before I discuss the details of the deobfuscator, I would like to first address the availability of the obfuscator source code. We all know TCC is open-source. And Dennis provided the patch file. So we can look at how the obfuscated binary is generated. This is of course a good thing since we can learn from the obfuscator. And I do recommend that everyone read it since it can show a relatively simple and lightweight way of implementing an obfuscating compiler.

However, this also introduces a problem: in the real-world, we typically do not have the source code for the obfuscator. So we should avoid using too many details from it. Though I still use some – but I try to limit them as few as possible.

Writing a deobfuscator is harder than understanding the obfuscation. I was once hesitant to start tackling this since I know it is going to take a few days. And now when I look at the code I have written, I still remember the hardship that I encountered. But I have succeeded! This is something that I am proud of.

We probably cannot cover every detail of the deobfuscator. It is only 500 LoC but discussing every bit (as well as the reasoning behind it) is beyond the scope of this writeup. But I will cover the major highlights.

Planning

Writing a good deobfuscator needs some planning before actual coding. The first thing we need to consider is tooling. Binary analysis requires lots of tools to proceed. How do we get the disassembly? What is the processing pipeline?

In this writeup, I use BinaryNinja as the primary tool. It has a powerful Python API so it is quite easy to access the disassembled functions, basic blocks, assembly lines, etc. Later I also used Triton for backward taint analysis, which allows me to remove junk code quite effectively.

The goal is simple: produce deobfuscated code. Note, however, one hurdle here is we do not have the ground truth for the obfuscated binary. As a result, we need to write the code, see its result in action, and make modifications and adjustments accordingly. When I deal with the opaque predicate, once my assumption was too wide and the deobfuscated code is empty. Then I have to go back and examine every branch the tool patched out and see which one is wrong (and should not be wiped out). One thing I did is to write a simple test C program, produce both the original binary and an obfuscated binary, and then test my tool on it. This allows me to fix several bugs faster.

Automation is the result we want. However, we also need to make some compromise on this. Ideally, our program should take the binary as input and produce a deobfuscated one. However, I found there are too many corner cases so I decided that my tool will process one basic block a time. This allows me to verify if the result is correct. Later on, I enhanced it to process a function a time – just iterate over the basic blocks in a function and process them one by one. Even this sometimes causes problem and I have to go back to process basic blocks one by one. The good part is my script is pretty robust that almost never needs any manual fixes.

The Skeleton of a BinaryNinja Plugin

BinaryNinja allows a plugin to register a callback on an address.

PluginCommand.register_for_address("Deobfuscate",
                                   "Remove tcc",
                                   bootstrap)

bootstrap is the function that gets called every time we click the Deobfuscate context menu. It is just a wrapper around the simplify_bbl_handler:

def simplify_bbl_handler(bv, addr):
    bbl = bv.get_basic_blocks_at(addr)[0]
    instrs_to_include = simplify_bbl(bv, bbl)
    bv.begin_undo_actions()
    nop_excluded_instrs(bv, bbl, instrs_to_include)
    solve_load_bbl(bv, bbl)
    bv.commit_undo_actions()

We get the basic block at the current address by bv.get_basic_blocks_at(). Then we start the real deobfuscating. Note we also add undo actions which is quite handy during development – since we need to frequently change the code and see its result.

Solving Convoluted Constant Load

The convoluted constant load is the first obfuscation technique we discussed. And it is used a lot across the binary. It is not hard to solve since its operations are simple. The problem is we need to locate it in the binary – where it starts and where it ends. This is trivial for a human reverser, but it is not easy for a program.

The implementation is in the function solve_load_bbl() in the script. The code is long so I cannot show it here. It does some pattern matching. It looks for consecutive arithmetic operations ('add|sub|shl|shr|xor') on registers ['eax', 'ebx', 'ecx', 'edx']. This might not be the best solution, but it works. We have to make some compromise since it is very hard to write the best code for a deobfuscator, which deals with messy things.

After discovering the pattern, it emulates the operations:

def solve_load_ops(bv, ops):
    val = 0
    for opcode, operand in ops:
        if opcode == 'mov':
            addr = int(operand, 16)
            val_bytes = bv.read(addr, 4)
            val = struct.unpack('<I', val_bytes)[0]
            print(hex(val))
        elif opcode == 'add':
            val = (val + int(operand, 16)) & 0xffffffff
        elif opcode == 'sub':
            val = (val - int(operand, 16)) % (1 << 32)
        elif opcode == 'xor':
            val = val ^ int(operand, 16)
        elif opcode == 'shl':
            val = val << int(operand, 16)
            val &= 0xffffffff
        elif opcode == 'shr':
            val = val >> int(operand, 16)
        else:
            print('unknown operation: %s' % opcode)

    return val

After we calculate the final load value, we need to patch the code, which is super convenient in BinaryNinja.

Solving Obfuscated Calls

The obfuscated call needs to be restored. Note the obfuscated code has jmp printf in it, but we need to change it to call printf. And then add a jmp to the next function.

def solve_push_jmp(bv, func):

    for bbl in func.basic_blocks:
        if bbl.instruction_count < 5:
            continue
        
        disassembly_text = bbl.get_disassembly_text()
        if str(disassembly_text[-5]).startswith('call    $+5') and \
            str(disassembly_text[-4]).startswith('pop     eax') and \
            str(disassembly_text[-3]).startswith('add     eax, 0xa') and \
            str(disassembly_text[-2]).startswith('push    eax') and \
            str(disassembly_text[-1]).startswith('jmp'):

            patch_addr = disassembly_text[-5].address
            print('push_jump at: 0x%x' % patch_addr)

            jmp_addr = disassembly_text[-1].address
            callee_offset_bytes = bv.read(jmp_addr + 1, 4)
            caller_offset = struct.unpack('<i', callee_offset_bytes)[0]
            callee_addr = jmp_addr + caller_offset + 5

            dis = 'call 0x%x' % callee_addr
            inst_bytes = arch.assemble(dis, patch_addr)
            bv.write(patch_addr, inst_bytes)
            
            # this sequence is 15 byte long
            return_addr = patch_addr + 15
            jmp_addr = patch_addr + len(inst_bytes)
            dis_jmp = 'jmp 0x%x' % return_addr

            inst_bytes = arch.assemble(dis_jmp, jmp_addr)
            bv.write(jmp_addr, inst_bytes)

We need to do some math to calculate the callee_addr, return_addr, and jmp_addr. Once we finish this the control flow is much better since we now know which functions get called.

Solving Opaque Predicate

BinaryNinja already has a plugin for patching opaque predicates. It relies on the lifted LLIL to see if the flags used in the conditional jump can be deduced from the preceding code, and patch it if so.

However, it does not suit my need because it does not take care of the convoluted constant load. Have a look at the following code:

00401172  mov     eax, dword [data_41c000]
00401178  mov     ecx, dword [data_41c1ac]
0040117e  xor     ecx, 0x32744b9b
00401184  shl     ecx, 0x2
00401187  shl     ecx, 0x4
0040118a  sub     ecx, 0x63fa1799
00401190  shr     ecx, 0x2
00401193  xor     ecx, 0x6a18d496
00401199  sub     ecx, 0x756243af
0040119f  cmp     eax, ecx
004011a1  jge     0x401516

The eax is loaded directly from the memory, and ecx is also a constant. So the result of the comparison is deterministic. However, LLIL does not squash these arithmetic operations so it does not know this is an opaque predicate.

So I wrote my opaque predicate patcher. Here I read the source code of the obfuscator and found out that it only inject two types of opaque predicates: the first one is the sub-and-jump and the second is xor-and-jump. Both are quite easy to find. Then I just search for sub/xor instruction, whose two operands are the same, and it is followed by a conditional jump. If found, I patch it accordingly.

def is_opaque_predicate(instr):

    tokens = instr.tokens
    if tokens[0].text == 'xor' and tokens[2].text == tokens[4].text:
        return True
    if tokens[0].text == 'sub' and tokens[2].text == tokens[4].text:
        return True   
    return False

def solve_opaque_predicate(bv, func):

    for bbl in func.basic_blocks:

        # jne to self
        if bbl.instruction_count == 1:
            instr = bbl.get_disassembly_text()[0]
            if instr.tokens[0].text.startswith('jne'):
                bv.never_branch(instr.address)  
            continue

        instrs = bbl.get_disassembly_text()

        try:
            instr1, instr2 = instrs[-2 :]
        except:
            print('error at: 0x%x' % bbl.start)

        if is_opaque_predicate(instr1):
            if should_patch_to_always_branch(instr2):
                log_info('always branch at: 0x%x' % instr2.address)
                bv.always_branch(instr2.address)
            elif should_patch_to_never_branch(instr2):
                log_info('never branch at: 0x%x' % instr2.address)
                bv.never_branch(instr2.address)