Ask MalwareTips Request for Independent Malware Analysis: Monzero Wallet GUI v1.0.0 (Windows) –

[username111]

Hello everyone,

I am looking for independent security researchers or malware analysts who can help review the Windows GUI wallet of a relatively new cryptocurrency project called Monzero (XMZ).

I am not claiming that the wallet is malware. I have been investigating its security and build provenance, and I would appreciate an independent technical assessment from people experienced in reverse engineering, malware analysis, and Windows executable inspection.

1. File under investigation
Application: Monzero Wallet GUI v1.0.0
Platform: Windows x64
Executable: monzero-wallet-gui.exe
File size: 120,094,697 bytes

SHA256:

DCD5CB2A919DDC905B45998E464214DA53C50B5F6B9A0C5BB13334025A25E5CC

The downloaded ZIP archive's SHA256 matches the checksum published by the project:

91DACD571E14F974FE52EE378DED3F39019C2EA5254D988ABC3F40513AFCF2C2

The source archive also matches its published checksum:

73C3C382E3037A85D98882DE66AA4A8840E7FA1AC245B930D7D7DB6E07024622

The executable is not Authenticode-signed. I understand that an unsigned executable is not, by itself, evidence of malicious behaviour.

2. Source code and build verification
The project publishes its source code here:

GitHub - Nightglass-Protocol1/monzero: Privacy-focused experimental cryptocurrency protocol and reference implementation

The release includes BUILD_INFO.json and TEST-RESULTS.json.

The Windows executable's SHA256 matches the GUI hash listed in BUILD_INFO.json. However, I found differences between the build and test metadata:

• BUILD_INFO.json identifies GUI commit 4b0cc9e163044282222d2d2845fab1803c6533b5.
• TEST-RESULTS.json identifies GUI source commit 5b45b03670db266152a762b1b5a6ee8b40646d94.
• The test results also refer to a different GUI test executable hash.
• The core commit identifiers in the two files also appear to differ.

I have not established why these differences exist or whether they correspond to separate build stages. I would like an independent assessment of whether the distributed Windows executable can be reliably linked to the published source and build information.

3. Automated security analysis
The executable was also examined using VirusTotal and Hybrid Analysis.

VirusTotal showed a detection from Rising:

HackTool.CoinMiner!8.F154

Acronis reported it as undetected.

Hybrid Analysis reported several potentially interesting indicators, including:

• Anti-debugging-related behaviour involving ProcessDebugPort.
• VM-related registry checks.
• Screenshot API indicators.
• Registry access and deletion-related indicators.
• A process crash involving WerFault.exe.

The analysis did not show relevant DNS or HTTP requests in the observed execution.

I understand that these indicators can also occur in legitimate software, libraries, miners, or software-protection mechanisms. I have not found evidence proving that screenshots are captured and transmitted, or that wallet keys are stolen.

4. Source-code investigation already performed
I have manually inspected several parts of the published source code.

Some findings:

• The reviewed update-checking path appears disabled and returns no update URL.
• QML-originated network requests are routed through a blocking network access manager.
• The reviewed read-only RPC client restricts its endpoint to localhost.
• The P2Pool manager downloads an official P2Pool release and verifies its SHA256 before extraction.
• The wallet contains normal functions for displaying and exporting the seed and private keys.
• The screenshot-related functionality I found appears connected to explicit QR-code import actions.
• The DEX relay code contains cryptographic signing and message-handling functionality, but I have not found evidence that it accesses or transmits the wallet recovery seed.

These are findings from selected source-code paths, not a complete audit of the application.

5. What I would like the community to investigate
I would particularly appreciate help with the following:

1. Does the executable contain suspicious functionality that is not apparent from the published source?
2. Can the distributed Windows executable be independently linked to the exact published source commits?
3. Are the differences between BUILD_INFO.json and TEST-RESULTS.json technically explainable?
4. Do the screenshot, registry and anti-debugging indicators represent normal application behaviour, or do they warrant further investigation?
5. Is there evidence of unexpected network communication, persistence, credential access, wallet seed collection, or data exfiltration?
6. Can anyone perform a meaningful static and dynamic analysis of this specific executable?

6. Project links
Source repository:
GitHub - Nightglass-Protocol1/monzero: Privacy-focused experimental cryptocurrency protocol and reference implementation

Project announcement:
[ANN] Monzero (XMZ) | RandomX CPU privacy coin | no premine | pool live

Final note
My intention is to establish whether the Windows wallet is trustworthy and whether the published source genuinely corresponds to the executable being distributed.

I am not accusing the developers of wrongdoing, and I do not want to label the software malicious without evidence. I am simply looking for an independent technical review.

Thank you for any help, observations, or analysis you can provide.

 

[Bot]

Hello everyone, I am looking for independent security researchers or malware analysts who can help review the Windows GUI wallet of a relatively new cryptocurrency project called Monzero (XMZ). I am not claiming that the wallet is malware. I have been investigating its security and build provenance, […]

Hi username111 — this is appropriately cautious. Based on the evidence available, I would classify the wallet as publisher-consistent but not independently verified. Nothing listed demonstrates malware, but the source/build/test chain is not strong enough to trust the executable with a valuable wallet seed.

What the published information establishes​

The project’s current download page confirms the ZIP hash you supplied, identifies GUI source commit 4b0cc9e... and core source commit c4165784..., and says the 18 October GUI update:

• is not covered by the signed stable-release metadata;
• is not Authenticode-signed;
• has been tested under Wine, while native Windows 10/11 validation remains pending.

The project’s v1.0.0 release notes also explicitly describe its testing as source and test-network verification, not an independent security review.

That gives us several distinct levels of assurance:

1. The ZIP checksum proves you downloaded the same bytes the website currently advertises.
2. The executable matching BUILD_INFO.json proves those two items are internally consistent.
3. Neither fact proves the executable was compiled from the stated source. The executable and metadata were supplied by the same publisher.
4. Because the GUI update is outside the signed release metadata, the checksum itself has no independent authentication if the website were compromised.

Authenticode would improve publisher authentication, but even that would not prove the software benign or reproducibly built.

The metadata mismatch is the substantive issue​

A TEST-RESULTS.json naming a different source commit and a different executable hash does not attest to the distributed executable. It may document an earlier release candidate, but its results cannot simply be carried over to DCD5CB....

There are benign explanations:

• tests were run against an earlier candidate;
• a GUI-only update was produced after core testing;
• metadata from separate build stages was packaged together;
• TEST-RESULTS.json was simply stale.

But those are explanations to investigate, not conclusions supported by the current package. Since you also found different core identifiers, the “GUI-only change” explanation needs evidence rather than assumption.

The project should publish:

• the exact repository URL for every commit identifier;
• complete GUI, core and recursive submodule SHAs;
• which executable hash was tested;
• a diff between the tested and distributed source trees;
• the compiler, dependency and container/image versions;
• a signed statement linking the final archive and PE hashes to those inputs;
• preferably, instructions that produce a reproducible Windows build.

In the exact GUI repository, these would establish ancestry and changes:

git merge-base --is-ancestor 5b45b03670db266152a762b1b5a6ee8b40646d94 \
                             4b0cc9e163044282222d2d2845fab1803c6533b5

git diff --stat 5b45b03670db266152a762b1b5a6ee8b40646d94 \
                4b0cc9e163044282222d2d2845fab1803c6533b5

git submodule status --recursive

Commit hashes have no chronological order by themselves. A 40-character value may look impressively Git-shaped, but it needs a repository and commit graph before it becomes provenance.

Interpreting the sandbox indicators​

Indicator	Current significance
HackTool.CoinMiner	Low-specificity in a cryptocurrency package containing CPU-mining functionality and RandomX-related code. A single generic/hacktool label is not a malware verdict. An undetected result from another vendor is not a counter-verdict either; antivirus results are not a vote.
ProcessDebugPort	Potential anti-debugging, but the call site and resulting branch matter. Determine whether it is wallet code, a bundled runtime/crash component, or merely a static capability. Concern rises if network or payload behaviour is deliberately withheld under debugging.
VM-related registry access	Could be sandbox evasion, hardware enumeration or mining/CPU tuning. The exact registry paths and whether detection changes execution are essential.
Screenshot APIs	Your QR-import explanation is plausible. Screen-based QR import commonly requires screen-capture APIs. It becomes concerning if capture occurs without the relevant user action, repeats in the background, or feeds an external communication path.
Registry deletion	Meaningless without the keys. Removing application settings is ordinary; touching Run keys, services, security policies, Defender exclusions or unrelated software is materially different.
WerFault.exe	An application crash normally invokes Windows Error Reporting. That is not evidence of injection or manipulation of WerFault; the process tree and handles would have to show that.
No DNS or HTTP	A modest positive observation for that particular run, but not proof of no communication. Wallets and miners can use raw TCP, direct IP addresses, P2P protocols, localhost daemons and child processes. Delayed or feature-triggered activity may also be missed.

The right question for each sandbox rule is not “Did the report display a red icon?” but what exact code executed, with what arguments, in response to which action, and what happened next?

What a meaningful analysis should include​

An analyst should obtain the archive independently from the publisher and confirm both of your hashes before testing.

Static work​

• Inspect PE sections, imports, TLS callbacks, resources, overlay, entropy and debug/PDB information.
• Identify the compiler and bundled Qt/runtime versions.
• Extract embedded QML, configuration and resources.
• Trace every reported anti-debugging, capture and registry operation to its call site.
• Look specifically for persistence mechanisms, process injection, credential-store access, browser-profile access and unrelated wallet-file enumeration.
• Compare .text, .rdata, embedded QML and resources against an independently built binary.

A bit-identical rebuild would be strong evidence. A non-identical hash is not automatically sinister because PE timestamps, build paths and nondeterministic dependencies can differ; in that case, normalized binary and function-level comparison is required.

Dynamic work​

Use a disposable Windows VM with no real seed, credentials or funds. Take snapshots and exercise more than first launch:

• create and restore a throwaway wallet;
• open QR import explicitly;
• start and stop mining and P2Pool features;
• connect to an isolated testnet/local daemon;
• leave it running long enough to catch delayed activity;
• repeat with and without internet access.

Record:

• exact files and registry keys created, changed or deleted;
• child processes, services, tasks, startup entries and WMI persistence;
• process handles and access to other applications;
• DNS, TCP, UDP, loopback and direct-IP traffic for every child process;
• destinations and traffic triggered by each feature.

A unique dummy-wallet value can help trace unintended handling, although encrypted exfiltration will not necessarily expose that value directly in a packet capture.

Bottom line​

At present:

• There is no supplied evidence of seed theft, credential access, persistence or exfiltration.
• The generic sandbox indicators do not establish malicious behaviour.
• The lack of observed networking in one run does not establish its absence.
• The distributed executable has not been independently linked to the published source.
• The differing test executable and commit identifiers are a real release-engineering/provenance gap that needs an explicit explanation.

Until a reproducible build or a convincing binary/source comparison closes that gap, I would restrict this version to an isolated test environment and a disposable wallet—not a production seed or meaningful funds.

Sources

• Downloads & release verification | Monzero (XMZ)
• monzero.org