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

[111username111]

# MONZERO WALLET v1.0.0
## Preliminary Independent Security Review

**Investigation status: Ongoing — not independently certified as safe**

## 1. Purpose and scope

A preliminary independent security review was conducted to assess the integrity and potential security risks of the Monzero v1.0.0 Windows GUI wallet.

The investigation examined:

- Published files, checksums and executable integrity.
- Available source code and release documentation.
- Network communication and update mechanisms.
- Wallet recovery-seed and private-key handling.
- Screenshot and QR-code functionality.
- Experimental DEX networking components.
- Automated malware-analysis results.
- Potential anti-debugging and detection-evasion behaviour.

The investigation follows an evidence-based approach. Verified findings, technical observations, unresolved questions and potential risks are distinguished throughout. No assumption of malicious intent has been made.

## 2. File integrity and release verification

The following checks were performed:

| Item | Result |
|---|---|
| Windows GUI ZIP checksum | Matches published checksum |
| Source archive checksum | Matches published checksum |
| Windows GUI executable SHA-256 | Matches `BUILD_INFO.json` |
| Authenticode digital signature | Executable is not digitally signed |
| Windows version information | Incomplete |

The GUI executable has the following SHA-256:

`DCD5CB2A919DDC905B45998E464214DA53C50B5F6B9A0C5BB13334025A25E5CC`

The source archive and Windows GUI ZIP also matched their respective published checksums.

The Windows executable's SHA-256 matches the value recorded in `BUILD_INFO.json`. However, it differs from the hash recorded in `TEST-RESULTS.json`.

These results establish consistency with some of the published release information, but do not independently establish that the executable is harmless or that it was built from the exact source code claimed by the project.

The absence of an Authenticode signature and incomplete Windows version information are transparency and verification limitations, not proof of malware.

## 3. Source-code and network investigation

Several areas of the available source code were examined.

### 3.1 Update mechanism

The update-checking functions examined appear disabled.

The reviewed implementation returns without performing the expected update requests. The old upstream update-checking code is disabled, and the update URL function returns an empty value.

No active update request was identified through this specific mechanism.

This does not establish that no other component can communicate externally.

### 3.2 Network communication

The investigation identified several types of network functionality:

- Normal blockchain-node communication.
- Local RPC communication.
- Read-only local RPC functionality.
- P2Pool release downloads from GitHub.
- Experimental DEX relay and networking components.

The reviewed local RPC client imposes restrictions, including loopback-only endpoints, an allowlist of read-only methods, request-size limits and timeouts.

The QML network-access manager also blocks QML-originated network requests. This protection does not automatically cover every direct C++ network call or external process.

No obvious function transmitting the wallet recovery seed to an external server was identified in the source sections examined.

However, the entire application and all dependencies have not yet been exhaustively audited.

### 3.3 P2Pool downloads

The source contains functionality to download a P2Pool release from the official GitHub release infrastructure.

The reviewed code checks the downloaded archive against an expected SHA-256 before extraction.

This is a useful integrity control. It does not replace verification of the complete application build and its dependencies.

### 3.4 Public wallet profiles

Project documentation describes an optional public-wallet-profile feature.

According to the documentation, users may choose to publish:

- A public wallet address.
- A public address together with a wallet-reported balance snapshot.

The documentation describes the feature as opt-in and states that private keys are not uploaded.

However, the corresponding implementation has not yet been independently verified. The claims in the documentation must therefore remain unconfirmed.

The documentation also states that previously published copies cannot necessarily be erased and that stopping publication requires server acknowledgement.

These details deserve particular attention because they concern the disclosure and persistence of wallet information.

## 4. DEX functionality and relay investigation

The reviewed DEX source contains cryptographic signatures, public keys, message validation, settlement commitments and relay functionality.

### 4.1 Relay and message handling

The reviewed relay code:

- Uses an already connected TCP socket.
- Validates messages before sending them.
- Checks message sequence numbers and expiration.
- Verifies cryptographic receipts.
- Acknowledges messages only after valid receipt verification.

The relay outbox uses local storage protections, including file-permission checks, size limits, message validation and atomic file saving.

The stored messages are Base64-encoded. Base64 is not encryption, but the reviewed implementation does not indicate that private wallet recovery keys are stored in this outbox.

### 4.2 Cryptographic identity

The reviewed DEX identity code uses Ed25519 signatures and encrypted identity material.

The identity implementation uses Argon2id and XChaCha20-Poly1305 to protect its Ed25519 seed.

This is a separate DEX identity mechanism and should not be confused with the main wallet recovery seed.

### 4.3 DEX build configuration

The CMake configuration disables the DEX prototype by default.

The reviewed application code also requires a specific environment variable to enable the private DEX prototype.

However, the exact build configuration used to produce the distributed Windows executable has not been established.

It is therefore not yet possible to confirm independently whether the DEX prototype is present or enabled in the released executable.

## 5. Wallet recovery seed and private keys

The investigation followed references to the wallet recovery seed and sensitive key-handling functions.

The GUI contains normal wallet-export functionality that can display:

- The mnemonic recovery seed.
- The secret view key.
- The secret spend key.

The application also supports generating QR codes containing wallet information. Depending on the selected export type, these QR codes may contain sensitive key material.

The wallet wizard passes the recovery seed into a variable named `walletOptionsSeed`.

This variable and its complete subsequent data flow have not yet been fully traced.

No evidence of automatic transmission of the recovery seed or private keys was identified in the reviewed source sections.

Nevertheless, this investigation cannot yet exclude every possible route through which sensitive information might be accessed or transmitted.

**The complete recovery-seed data flow remains an outstanding investigation task.**

## 6. Screenshot and QR-code functionality

The source code contains functionality capable of capturing the primary screen and scanning it for QR codes.

The identified call sites are explicit QR-import actions in the address book and transaction pages.

The reviewed implementation temporarily hides wallet windows and captures the primary screen to identify QR codes.

No evidence was found in the reviewed screenshot implementation that captured screenshots are automatically saved or transmitted externally.

The existence of screenshot-related APIs is not, by itself, proof of spyware.

However, because wallet applications handle recovery phrases, private keys and financial information, the purpose and scope of all screen-capture functionality should be clearly documented and independently verified.

## 7. Malware indicators and potential detection-evasion techniques

Modern malware can use techniques designed to avoid antivirus detection and automated security analysis.

Examples include:

- **Code obfuscation and packing:** making internal executable behaviour harder to inspect.
- **Anti-debugging:** detecting whether a program is being examined by a debugger.
- **Virtual-machine and sandbox detection:** changing behaviour when an analysis environment is detected.
- **Delayed or conditional execution:** activating functionality only after a particular date, event or operation.
- **Encrypted or dynamically loaded payloads:** making malicious code harder to identify through static inspection.
- **Process injection and fileless execution:** reducing the visibility of malicious activity in ordinary file-based scans.
- **Selective network communication:** contacting external infrastructure only under particular conditions.

These are general techniques used by some malware. Their existence in the wider software ecosystem does not establish that Monzero uses them maliciously.

### 7.1 Hybrid Analysis findings

Hybrid Analysis reported several indicators that deserve further investigation:

- Anti-debugging behaviour involving `ProcessDebugPort`.
- Virtual-machine-related registry checks.
- Screenshot-related API indicators.
- Registry deletion operations.
- Cryptographic service-provider key-container API usage.

Some of these operations can have legitimate explanations.

For example, cryptographic applications may interact with operating-system key containers, while applications may use screen-capture functionality for legitimate QR-import operations.

However, anti-debugging and virtual-machine detection can also be used to identify and evade automated security analysis.

The reported indicators therefore raise technical questions that should not be dismissed without further investigation.

### 7.2 Runtime observations

Hybrid Analysis also reported a process crash involving `WerFault.exe`.

No relevant DNS or HTTP activity was identified during the observed execution.

This is useful information, but it cannot exclude delayed, conditional, encrypted or environment-dependent communications.

**Important distinction:** The investigation has identified indicators compatible with behaviours that can occur in malware evasion. It has not established that Monzero contains a concealed malicious payload.

## 8. Automated security-analysis results

The available automated-analysis results include:

**Hybrid Analysis**

- Anti-debugging indicators.
- Virtual-machine-related registry checks.
- Screenshot-related API indicators.
- Registry operations.
- Cryptographic key-container API activity.
- A process crash.
- No relevant DNS or HTTP activity observed during the analysed execution.

**VirusTotal**

- Rising reported `HackTool.CoinMiner!8.F154`.
- Acronis reported no detection.

A cryptocurrency wallet or mining-related executable may trigger security detections because of its functionality. Equally, an absence of detections from other engines does not prove that a file is safe.

These results are inconclusive and require technical investigation rather than automatic classification as either harmless or malicious.

## 9. Release documentation and SHA-256 discrepancy

An inconsistency was identified between `BUILD_INFO.json` and `TEST-RESULTS.json`.

The documents contain different GUI source commit identifiers and different executable SHA-256 values.

The Windows executable's SHA-256 matches the value recorded in `BUILD_INFO.json`, but it does not match the different hash recorded in `TEST-RESULTS.json`.

The documents also contain different core commit identifiers.

In addition, the test-results documentation indicates that native Windows testing was not performed.

This creates an unresolved question about the relationship between:

- The distributed Windows executable.
- The source commit used to build it.
- The source archive supplied with the release.
- The executable used during testing.
- The published build and test records.

The discrepancy may reflect different build or test artifacts, outdated documentation or another explanation. It is not proof of malicious activity.

However, it should be clarified with verifiable build information.

### 9.1 SHA-256 verification: what has actually been established?

| Verification | Result |
|---|---|
| Downloaded Windows ZIP vs published checksum | Match |
| Downloaded source archive vs published checksum | Match |
| Windows GUI executable vs `BUILD_INFO.json` | Match |
| Windows GUI executable vs `TEST-RESULTS.json` | Different hash |
| GUI source commit in both documents | Different |
| Core source commit in both documents | Different |
| Independent reproducible build | Not yet performed |

A matching SHA-256 proves that two files are identical. It does not prove that the file is safe, nor that it was compiled from the source code claimed by its publisher.

The central unresolved issue is whether the executable distributed to Windows users can be independently linked to its exact source commit and build process.

## 10. Could hidden malware remain undetected?

Yes. It is technically possible for malicious functionality to remain undetected during a limited source review or a single automated execution.

For example, malicious functionality could:

- Activate only after a particular date.
- Activate only when a specific wallet operation occurs.
- Remain inactive inside virtual machines or sandboxes.
- Require a particular response from an external server.
- Exist inside a third-party dependency.
- Be present in the executable but absent from the supplied source archive.

These are possible scenarios, not established findings about Monzero.

A clean antivirus result, matching checksum or apparently normal initial execution cannot independently guarantee that an application is free from hidden malicious behaviour.

## 11. Current findings and outstanding risks

| Area | Current status | Why it matters |
|---|---|---|
| Published GUI ZIP checksum | Verified match | Establishes consistency with published archive information |
| Source archive checksum | Verified match | Establishes consistency with published source archive information |
| Executable hash | Matches `BUILD_INFO.json` | Does not independently prove source-to-binary correspondence |
| Different build hashes | Unresolved | `TEST-RESULTS.json` contains a different hash and commit |
| Recovery-seed data flow | Incomplete | Every use of sensitive recovery information must be traced |
| `ProcessDebugPort` | Unresolved | Could be used to detect security analysis |
| Virtual-machine registry checks | Unresolved | Could be used to detect or avoid sandbox environments |
| Screenshot functionality | Partially investigated | Screen capture can expose sensitive information |
| Registry deletion | Unresolved | Purpose and context of the operations need clarification |
| DEX networking | Incomplete | Exact configuration of the distributed executable is unknown |
| External dependencies | Incomplete | Third-party components can introduce vulnerabilities or malicious behaviour |
| Public wallet profiles | Unverified | Documentation claims have not been fully confirmed in implementation |

The table identifies areas requiring further investigation. It does not mean that every listed capability is malicious or that malware has been discovered.

## 12. Questions for the Monzero development team

A technically verifiable response is requested on the following points.

### 12.1 Source code and executable identity

**1. Which exact source commit was used to build the distributed Windows executable?**

The response should identify the GUI and core commits used for the release.

**2. Is the distributed Windows GUI executable an official release build?**

The project should confirm its release status and the build process used to produce it.

### 12.2 SHA-256 integrity and build verification

**3. What is the exact SHA-256 hash of the official Monzero v1.0.0 Windows GUI executable?**

The project should explicitly identify the official executable hash and its corresponding release file.

**4. Why do `BUILD_INFO.json` and `TEST-RESULTS.json` contain different executable SHA-256 hashes?**

The distributed executable matches the hash recorded in `BUILD_INFO.json`. The different hash in `TEST-RESULTS.json` needs a technical explanation.

**5. Which of these two hashes corresponds to the executable actually distributed to Windows users, and which corresponds to the executable used during testing?**

The project should identify the files associated with both hashes.

**6. Why do the two documents identify different GUI source commits and different core source commits?**

The development team should explain whether these records refer to different builds, testing stages or release artifacts.

**7. Can the development team provide the original executable used for testing, together with its SHA-256 hash?**

This would allow an independent comparison with the distributed executable.

**8. Can the development team demonstrate that the distributed Windows executable was built from the exact source commits identified in `BUILD_INFO.json`?**

A verifiable build record or reproducible build would help establish this relationship.

**9. Can the development team provide the exact matching source archive, reproducible build instructions and verifiable checksums?**

Ideally, an independent researcher should be able to compile the source and compare the resulting executable with the distributed release.

**10. Can the development team provide signed release manifests or another independently verifiable method of authenticating the official executable and its checksums?**

This would provide an additional way to establish the authenticity and integrity of future releases.

### 12.3 Security-analysis indicators

**11. Can the development team explain the screenshot, registry and anti-analysis detections reported by Hybrid Analysis?**

The explanation should identify the relevant source functions, their intended purpose and the circumstances under which they execute.

### 12.4 Build configuration and testing

**12. Was the distributed Windows executable compiled with `WITH_DEX_PROTOTYPE` enabled?**

The exact configuration and relevant build options should be disclosed.

**13. Why does the test-results documentation indicate that native Windows testing was not performed?**

The project should clarify what testing was actually performed on the distributed Windows build.

These questions are intended to establish a verifiable relationship between the distributed executable, the source code, the build process and the published release documentation.

## 13. Real-world examples of compromised legitimate software

The following documented incidents demonstrate why software integrity, build provenance and dependency verification matter.

### 13.1 3CX supply-chain attack (2023)

Attackers compromised legitimate 3CX desktop software and distributed malicious code through an infected software component. The compromised application downloaded additional malicious components.

**Relevance to Monzero:** An executable can appear legitimate while containing malicious functionality. Verification of source code, dependencies and the distributed binary is essential.

### 13.2 CCleaner supply-chain attack (2017)

A legitimate version of CCleaner was distributed with a malicious backdoor after attackers compromised the software development and distribution process.

**Relevance to Monzero:** A legitimate project name, official download or matching published checksum does not independently guarantee that software is harmless.

### 13.3 Copay cryptocurrency wallet compromise (2018)

A compromised JavaScript dependency used by the Copay cryptocurrency wallet introduced malicious functionality designed to steal cryptocurrency funds.

**Relevance to Monzero:** Third-party dependencies can introduce malicious functionality even when the main application appears legitimate.

### 13.4 SolarWinds SUNBURST attack (2020)

Attackers inserted a backdoor into legitimate SolarWinds software updates. The malicious functionality used delayed and selective execution before communicating with external infrastructure.

**Relevance to Monzero:** A clean initial execution or the absence of suspicious network traffic during one analysis does not necessarily rule out conditional or delayed malicious behaviour.

### What these incidents demonstrate

1. Legitimate software can be compromised during development or distribution.
2. Third-party dependencies can introduce malicious functionality.
3. Digital signatures and published checksums do not prove that software is harmless.
4. Malware can use delayed or conditional execution to avoid detection.
5. Independent verification of source code, dependencies, build processes and executable files is essential.

These historical incidents are not evidence that Monzero is compromised. They explain why the outstanding technical questions deserve proper answers.

## 14. Next steps

The investigation remains open.

The next technical tasks are:

1. Trace every use of the wallet recovery seed and private keys.
2. Establish the exact DEX configuration used in the distributed Windows executable.
3. Resolve the SHA-256 and source-commit discrepancies between the published build and test records.
4. Examine the remaining source code and third-party dependencies.
5. Investigate the purpose of the anti-debugging and virtual-machine detection indicators.
6. Examine the screenshot and registry operations in their full execution context.
7. Monitor the executable's real network activity in a controlled environment.
8. Where possible, reproduce the Windows executable from the exact source commit and compare the resulting SHA-256 hash.

A controlled runtime investigation should also examine behaviour during wallet creation, wallet opening, recovery-seed display, transactions, QR imports and other sensitive operations.

## 15. Final assessment

The investigation has identified no confirmed evidence of wallet-seed theft, automatic screenshot transmission or an obvious malicious data-upload mechanism in the source-code areas examined.

Several reviewed components appear to implement conventional security practices, including cryptographic signatures, local storage protections, read-only RPC restrictions and checksum verification.

Nevertheless, the Hybrid Analysis indicators, incomplete recovery-seed tracing, unresolved SHA-256 and release-documentation discrepancies, unverified public-profile implementation and unknown configuration of the distributed executable prevent a complete independent assessment.

The investigation has not established that Monzero contains intentionally concealed malware. It has also not established that the Windows wallet is completely safe.

**Current finding: No confirmed evidence of malicious wallet behaviour has been discovered in the areas examined. However, the available evidence is insufficient to certify the wallet as safe or rule out hidden malicious functionality.**

A complete independent security audit, including controlled runtime monitoring, dependency examination and verification of the executable's relationship to its exact source code, remains necessary before the software can be considered independently verified and trustworthy.

**The investigation is not closed.**

All findings will continue to be documented, and explanations provided by the development team should be checked against independently verifiable technical evidence.

Transparency is essential when users are trusting software with their private keys and funds.

[monzero-coin]

I will bring out a new wallet for windows what im going to have to do is remove the miner from the binary for windows as it causes issues with signing. So that being said I will bring out a version for windows with Wallet & Gui Seperated.

Kind Regards
Monzero Team

# MONZERO WALLET v1.0.0
## Preliminary Independent Security Review

**Investigation status: Ongoing — not independently certified as safe**

## 1. Purpose and scope

A preliminary independent security review was conducted to assess the integrity and potential security risks of the Monzero v1.0.0 Windows GUI wallet.

The investigation examined:

- Published files, checksums and executable integrity.
- Available source code and release documentation.
- Network communication and update mechanisms.
- Wallet recovery-seed and private-key handling.
- Screenshot and QR-code functionality.
- Experimental DEX networking components.
- Automated malware-analysis results.
- Potential anti-debugging and detection-evasion behaviour.

The investigation follows an evidence-based approach. Verified findings, technical observations, unresolved questions and potential risks are distinguished throughout. No assumption of malicious intent has been made.

## 2. File integrity and release verification

The following checks were performed:

| Item | Result |
|---|---|
| Windows GUI ZIP checksum | Matches published checksum |
| Source archive checksum | Matches published checksum |
| Windows GUI executable SHA-256 | Matches `BUILD_INFO.json` |
| Authenticode digital signature | Executable is not digitally signed |
| Windows version information | Incomplete |

The GUI executable has the following SHA-256:

`DCD5CB2A919DDC905B45998E464214DA53C50B5F6B9A0C5BB13334025A25E5CC`

The source archive and Windows GUI ZIP also matched their respective published checksums.

The Windows executable's SHA-256 matches the value recorded in `BUILD_INFO.json`. However, it differs from the hash recorded in `TEST-RESULTS.json`.

These results establish consistency with some of the published release information, but do not independently establish that the executable is harmless or that it was built from the exact source code claimed by the project.

The absence of an Authenticode signature and incomplete Windows version information are transparency and verification limitations, not proof of malware.

## 3. Source-code and network investigation

Several areas of the available source code were examined.

### 3.1 Update mechanism

The update-checking functions examined appear disabled.

The reviewed implementation returns without performing the expected update requests. The old upstream update-checking code is disabled, and the update URL function returns an empty value.

No active update request was identified through this specific mechanism.

This does not establish that no other component can communicate externally.

### 3.2 Network communication

The investigation identified several types of network functionality:

- Normal blockchain-node communication.
- Local RPC communication.
- Read-only local RPC functionality.
- P2Pool release downloads from GitHub.
- Experimental DEX relay and networking components.

The reviewed local RPC client imposes restrictions, including loopback-only endpoints, an allowlist of read-only methods, request-size limits and timeouts.

The QML network-access manager also blocks QML-originated network requests. This protection does not automatically cover every direct C++ network call or external process.

No obvious function transmitting the wallet recovery seed to an external server was identified in the source sections examined.

However, the entire application and all dependencies have not yet been exhaustively audited.

### 3.3 P2Pool downloads

The source contains functionality to download a P2Pool release from the official GitHub release infrastructure.

The reviewed code checks the downloaded archive against an expected SHA-256 before extraction.

This is a useful integrity control. It does not replace verification of the complete application build and its dependencies.

### 3.4 Public wallet profiles

Project documentation describes an optional public-wallet-profile feature.

According to the documentation, users may choose to publish:

- A public wallet address.
- A public address together with a wallet-reported balance snapshot.

The documentation describes the feature as opt-in and states that private keys are not uploaded.

However, the corresponding implementation has not yet been independently verified. The claims in the documentation must therefore remain unconfirmed.

The documentation also states that previously published copies cannot necessarily be erased and that stopping publication requires server acknowledgement.

These details deserve particular attention because they concern the disclosure and persistence of wallet information.

## 4. DEX functionality and relay investigation

The reviewed DEX source contains cryptographic signatures, public keys, message validation, settlement commitments and relay functionality.

### 4.1 Relay and message handling

The reviewed relay code:

- Uses an already connected TCP socket.
- Validates messages before sending them.
- Checks message sequence numbers and expiration.
- Verifies cryptographic receipts.
- Acknowledges messages only after valid receipt verification.

The relay outbox uses local storage protections, including file-permission checks, size limits, message validation and atomic file saving.

The stored messages are Base64-encoded. Base64 is not encryption, but the reviewed implementation does not indicate that private wallet recovery keys are stored in this outbox.

### 4.2 Cryptographic identity

The reviewed DEX identity code uses Ed25519 signatures and encrypted identity material.

The identity implementation uses Argon2id and XChaCha20-Poly1305 to protect its Ed25519 seed.

This is a separate DEX identity mechanism and should not be confused with the main wallet recovery seed.

### 4.3 DEX build configuration

The CMake configuration disables the DEX prototype by default.

The reviewed application code also requires a specific environment variable to enable the private DEX prototype.

However, the exact build configuration used to produce the distributed Windows executable has not been established.

It is therefore not yet possible to confirm independently whether the DEX prototype is present or enabled in the released executable.

## 5. Wallet recovery seed and private keys

The investigation followed references to the wallet recovery seed and sensitive key-handling functions.

The GUI contains normal wallet-export functionality that can display:

- The mnemonic recovery seed.
- The secret view key.
- The secret spend key.

The application also supports generating QR codes containing wallet information. Depending on the selected export type, these QR codes may contain sensitive key material.

The wallet wizard passes the recovery seed into a variable named `walletOptionsSeed`.

This variable and its complete subsequent data flow have not yet been fully traced.

No evidence of automatic transmission of the recovery seed or private keys was identified in the reviewed source sections.

Nevertheless, this investigation cannot yet exclude every possible route through which sensitive information might be accessed or transmitted.

**The complete recovery-seed data flow remains an outstanding investigation task.**

## 6. Screenshot and QR-code functionality

The source code contains functionality capable of capturing the primary screen and scanning it for QR codes.

The identified call sites are explicit QR-import actions in the address book and transaction pages.

The reviewed implementation temporarily hides wallet windows and captures the primary screen to identify QR codes.

No evidence was found in the reviewed screenshot implementation that captured screenshots are automatically saved or transmitted externally.

The existence of screenshot-related APIs is not, by itself, proof of spyware.

However, because wallet applications handle recovery phrases, private keys and financial information, the purpose and scope of all screen-capture functionality should be clearly documented and independently verified.

## 7. Malware indicators and potential detection-evasion techniques

Modern malware can use techniques designed to avoid antivirus detection and automated security analysis.

Examples include:

- **Code obfuscation and packing:** making internal executable behaviour harder to inspect.
- **Anti-debugging:** detecting whether a program is being examined by a debugger.
- **Virtual-machine and sandbox detection:** changing behaviour when an analysis environment is detected.
- **Delayed or conditional execution:** activating functionality only after a particular date, event or operation.
- **Encrypted or dynamically loaded payloads:** making malicious code harder to identify through static inspection.
- **Process injection and fileless execution:** reducing the visibility of malicious activity in ordinary file-based scans.
- **Selective network communication:** contacting external infrastructure only under particular conditions.

These are general techniques used by some malware. Their existence in the wider software ecosystem does not establish that Monzero uses them maliciously.

### 7.1 Hybrid Analysis findings

Hybrid Analysis reported several indicators that deserve further investigation:

- Anti-debugging behaviour involving `ProcessDebugPort`.
- Virtual-machine-related registry checks.
- Screenshot-related API indicators.
- Registry deletion operations.
- Cryptographic service-provider key-container API usage.

Some of these operations can have legitimate explanations.

For example, cryptographic applications may interact with operating-system key containers, while applications may use screen-capture functionality for legitimate QR-import operations.

However, anti-debugging and virtual-machine detection can also be used to identify and evade automated security analysis.

The reported indicators therefore raise technical questions that should not be dismissed without further investigation.

### 7.2 Runtime observations

Hybrid Analysis also reported a process crash involving `WerFault.exe`.

No relevant DNS or HTTP activity was identified during the observed execution.

This is useful information, but it cannot exclude delayed, conditional, encrypted or environment-dependent communications.

**Important distinction:** The investigation has identified indicators compatible with behaviours that can occur in malware evasion. It has not established that Monzero contains a concealed malicious payload.

## 8. Automated security-analysis results

The available automated-analysis results include:

**Hybrid Analysis**

- Anti-debugging indicators.
- Virtual-machine-related registry checks.
- Screenshot-related API indicators.
- Registry operations.
- Cryptographic key-container API activity.
- A process crash.
- No relevant DNS or HTTP activity observed during the analysed execution.

**VirusTotal**

- Rising reported `HackTool.CoinMiner!8.F154`.
- Acronis reported no detection.

A cryptocurrency wallet or mining-related executable may trigger security detections because of its functionality. Equally, an absence of detections from other engines does not prove that a file is safe.

These results are inconclusive and require technical investigation rather than automatic classification as either harmless or malicious.

## 9. Release documentation and SHA-256 discrepancy

An inconsistency was identified between `BUILD_INFO.json` and `TEST-RESULTS.json`.

The documents contain different GUI source commit identifiers and different executable SHA-256 values.

The Windows executable's SHA-256 matches the value recorded in `BUILD_INFO.json`, but it does not match the different hash recorded in `TEST-RESULTS.json`.

The documents also contain different core commit identifiers.

In addition, the test-results documentation indicates that native Windows testing was not performed.

This creates an unresolved question about the relationship between:

- The distributed Windows executable.
- The source commit used to build it.
- The source archive supplied with the release.
- The executable used during testing.
- The published build and test records.

The discrepancy may reflect different build or test artifacts, outdated documentation or another explanation. It is not proof of malicious activity.

However, it should be clarified with verifiable build information.

### 9.1 SHA-256 verification: what has actually been established?

| Verification | Result |
|---|---|
| Downloaded Windows ZIP vs published checksum | Match |
| Downloaded source archive vs published checksum | Match |
| Windows GUI executable vs `BUILD_INFO.json` | Match |
| Windows GUI executable vs `TEST-RESULTS.json` | Different hash |
| GUI source commit in both documents | Different |
| Core source commit in both documents | Different |
| Independent reproducible build | Not yet performed |

A matching SHA-256 proves that two files are identical. It does not prove that the file is safe, nor that it was compiled from the source code claimed by its publisher.

The central unresolved issue is whether the executable distributed to Windows users can be independently linked to its exact source commit and build process.

## 10. Could hidden malware remain undetected?

Yes. It is technically possible for malicious functionality to remain undetected during a limited source review or a single automated execution.

For example, malicious functionality could:

- Activate only after a particular date.
- Activate only when a specific wallet operation occurs.
- Remain inactive inside virtual machines or sandboxes.
- Require a particular response from an external server.
- Exist inside a third-party dependency.
- Be present in the executable but absent from the supplied source archive.

These are possible scenarios, not established findings about Monzero.

A clean antivirus result, matching checksum or apparently normal initial execution cannot independently guarantee that an application is free from hidden malicious behaviour.

## 11. Current findings and outstanding risks

| Area | Current status | Why it matters |
|---|---|---|
| Published GUI ZIP checksum | Verified match | Establishes consistency with published archive information |
| Source archive checksum | Verified match | Establishes consistency with published source archive information |
| Executable hash | Matches `BUILD_INFO.json` | Does not independently prove source-to-binary correspondence |
| Different build hashes | Unresolved | `TEST-RESULTS.json` contains a different hash and commit |
| Recovery-seed data flow | Incomplete | Every use of sensitive recovery information must be traced |
| `ProcessDebugPort` | Unresolved | Could be used to detect security analysis |
| Virtual-machine registry checks | Unresolved | Could be used to detect or avoid sandbox environments |
| Screenshot functionality | Partially investigated | Screen capture can expose sensitive information |
| Registry deletion | Unresolved | Purpose and context of the operations need clarification |
| DEX networking | Incomplete | Exact configuration of the distributed executable is unknown |
| External dependencies | Incomplete | Third-party components can introduce vulnerabilities or malicious behaviour |
| Public wallet profiles | Unverified | Documentation claims have not been fully confirmed in implementation |

The table identifies areas requiring further investigation. It does not mean that every listed capability is malicious or that malware has been discovered.

## 12. Questions for the Monzero development team

A technically verifiable response is requested on the following points.

### 12.1 Source code and executable identity

**1. Which exact source commit was used to build the distributed Windows executable?**

The response should identify the GUI and core commits used for the release.

**2. Is the distributed Windows GUI executable an official release build?**

The project should confirm its release status and the build process used to produce it.

### 12.2 SHA-256 integrity and build verification

**3. What is the exact SHA-256 hash of the official Monzero v1.0.0 Windows GUI executable?**

The project should explicitly identify the official executable hash and its corresponding release file.

**4. Why do `BUILD_INFO.json` and `TEST-RESULTS.json` contain different executable SHA-256 hashes?**

The distributed executable matches the hash recorded in `BUILD_INFO.json`. The different hash in `TEST-RESULTS.json` needs a technical explanation.

**5. Which of these two hashes corresponds to the executable actually distributed to Windows users, and which corresponds to the executable used during testing?**

The project should identify the files associated with both hashes.

**6. Why do the two documents identify different GUI source commits and different core source commits?**

The development team should explain whether these records refer to different builds, testing stages or release artifacts.

**7. Can the development team provide the original executable used for testing, together with its SHA-256 hash?**

This would allow an independent comparison with the distributed executable.

**8. Can the development team demonstrate that the distributed Windows executable was built from the exact source commits identified in `BUILD_INFO.json`?**

A verifiable build record or reproducible build would help establish this relationship.

**9. Can the development team provide the exact matching source archive, reproducible build instructions and verifiable checksums?**

Ideally, an independent researcher should be able to compile the source and compare the resulting executable with the distributed release.

**10. Can the development team provide signed release manifests or another independently verifiable method of authenticating the official executable and its checksums?**

This would provide an additional way to establish the authenticity and integrity of future releases.

### 12.3 Security-analysis indicators

**11. Can the development team explain the screenshot, registry and anti-analysis detections reported by Hybrid Analysis?**

The explanation should identify the relevant source functions, their intended purpose and the circumstances under which they execute.

### 12.4 Build configuration and testing

**12. Was the distributed Windows executable compiled with `WITH_DEX_PROTOTYPE` enabled?**

The exact configuration and relevant build options should be disclosed.

**13. Why does the test-results documentation indicate that native Windows testing was not performed?**

The project should clarify what testing was actually performed on the distributed Windows build.

These questions are intended to establish a verifiable relationship between the distributed executable, the source code, the build process and the published release documentation.

## 13. Real-world examples of compromised legitimate software

The following documented incidents demonstrate why software integrity, build provenance and dependency verification matter.

### 13.1 3CX supply-chain attack (2023)

Attackers compromised legitimate 3CX desktop software and distributed malicious code through an infected software component. The compromised application downloaded additional malicious components.

**Relevance to Monzero:** An executable can appear legitimate while containing malicious functionality. Verification of source code, dependencies and the distributed binary is essential.

### 13.2 CCleaner supply-chain attack (2017)

A legitimate version of CCleaner was distributed with a malicious backdoor after attackers compromised the software development and distribution process.

**Relevance to Monzero:** A legitimate project name, official download or matching published checksum does not independently guarantee that software is harmless.

### 13.3 Copay cryptocurrency wallet compromise (2018)

A compromised JavaScript dependency used by the Copay cryptocurrency wallet introduced malicious functionality designed to steal cryptocurrency funds.

**Relevance to Monzero:** Third-party dependencies can introduce malicious functionality even when the main application appears legitimate.

### 13.4 SolarWinds SUNBURST attack (2020)

Attackers inserted a backdoor into legitimate SolarWinds software updates. The malicious functionality used delayed and selective execution before communicating with external infrastructure.

**Relevance to Monzero:** A clean initial execution or the absence of suspicious network traffic during one analysis does not necessarily rule out conditional or delayed malicious behaviour.

### What these incidents demonstrate

1. Legitimate software can be compromised during development or distribution.
2. Third-party dependencies can introduce malicious functionality.
3. Digital signatures and published checksums do not prove that software is harmless.
4. Malware can use delayed or conditional execution to avoid detection.
5. Independent verification of source code, dependencies, build processes and executable files is essential.

These historical incidents are not evidence that Monzero is compromised. They explain why the outstanding technical questions deserve proper answers.

## 14. Next steps

The investigation remains open.

The next technical tasks are:

1. Trace every use of the wallet recovery seed and private keys.
2. Establish the exact DEX configuration used in the distributed Windows executable.
3. Resolve the SHA-256 and source-commit discrepancies between the published build and test records.
4. Examine the remaining source code and third-party dependencies.
5. Investigate the purpose of the anti-debugging and virtual-machine detection indicators.
6. Examine the screenshot and registry operations in their full execution context.
7. Monitor the executable's real network activity in a controlled environment.
8. Where possible, reproduce the Windows executable from the exact source commit and compare the resulting SHA-256 hash.

A controlled runtime investigation should also examine behaviour during wallet creation, wallet opening, recovery-seed display, transactions, QR imports and other sensitive operations.

## 15. Final assessment

The investigation has identified no confirmed evidence of wallet-seed theft, automatic screenshot transmission or an obvious malicious data-upload mechanism in the source-code areas examined.

Several reviewed components appear to implement conventional security practices, including cryptographic signatures, local storage protections, read-only RPC restrictions and checksum verification.

Nevertheless, the Hybrid Analysis indicators, incomplete recovery-seed tracing, unresolved SHA-256 and release-documentation discrepancies, unverified public-profile implementation and unknown configuration of the distributed executable prevent a complete independent assessment.

The investigation has not established that Monzero contains intentionally concealed malware. It has also not established that the Windows wallet is completely safe.

**Current finding: No confirmed evidence of malicious wallet behaviour has been discovered in the areas examined. However, the available evidence is insufficient to certify the wallet as safe or rule out hidden malicious functionality.**

A complete independent security audit, including controlled runtime monitoring, dependency examination and verification of the executable's relationship to its exact source code, remains necessary before the software can be considered independently verified and trustworthy.

**The investigation is not closed.**

All findings will continue to be documented, and explanations provided by the development team should be checked against independently verifiable technical evidence.

Transparency is essential when users are trusting software with their private keys and funds.

These are the kind of replies I need! Nice analysis, I however Agree with the entire thing. I completely understand why it comes to the conclusions it does there for I will have to work on the windows side of the build a bit more I think as I posted in my other reply microsoft wouldnt let me build applications with the miner built at the point where you sign it off so that has not been done yet. However that being said I will make it my next move for this project to work on the windows build where I split the miner from the Wallet as I think this is the best way forward. If anything people can still use the XMRig to mine with the blockchain.


Thankyou for the work you put in

[KONGKING33]

But besides your fluent bla bla bla.... have you ever gave a reply for the questions made by this gentleman???



## 12. Questions for the Monzero development team

A technically verifiable response is requested on the following points.

### 12.1 Source code and executable identity

**1. Which exact source commit was used to build the distributed Windows executable?**

The response should identify the GUI and core commits used for the release.

**2. Is the distributed Windows GUI executable an official release build?**

The project should confirm its release status and the build process used to produce it.

### 12.2 SHA-256 integrity and build verification

**3. What is the exact SHA-256 hash of the official Monzero v1.0.0 Windows GUI executable?**

The project should explicitly identify the official executable hash and its corresponding release file.

**4. Why do `BUILD_INFO.json` and `TEST-RESULTS.json` contain different executable SHA-256 hashes?**

The distributed executable matches the hash recorded in `BUILD_INFO.json`. The different hash in `TEST-RESULTS.json` needs a technical explanation.

**5. Which of these two hashes corresponds to the executable actually distributed to Windows users, and which corresponds to the executable used during testing?**

The project should identify the files associated with both hashes.

**6. Why do the two documents identify different GUI source commits and different core source commits?**

The development team should explain whether these records refer to different builds, testing stages or release artifacts.

**7. Can the development team provide the original executable used for testing, together with its SHA-256 hash?**

This would allow an independent comparison with the distributed executable.

**8. Can the development team demonstrate that the distributed Windows executable was built from the exact source commits identified in `BUILD_INFO.json`?**

A verifiable build record or reproducible build would help establish this relationship.

**9. Can the development team provide the exact matching source archive, reproducible build instructions and verifiable checksums?**

Ideally, an independent researcher should be able to compile the source and compare the resulting executable with the distributed release.

**10. Can the development team provide signed release manifests or another independently verifiable method of authenticating the official executable and its checksums?**



sorry guys, anyone saw a reply for the questions or mostly an evasive answer that makes you looks even more suspicious???




A new download alone isn't an answer to the original security review.
sorry 2-0 and counting
  🤣 **How to handle a security investigation — Developer Edition**

Community: "Can you answer a few questions about the suspicious wallet binary, its hashes, signatures, build process and those strange security indicators?"

Developer: *Silence.*

Community: "Could you at least clarify whether the Windows build was properly tested?"

Developer: *Silence.*

Developer, a few days later: "Good news! Here's another wallet! 🎉"

Community: "But what about the questions?"

Developer: "NEW WALLET. NEW BEGINNING. 😂"

Apparently, the easiest way to fix a security audit is not to answer it, but to release another ZIP file.

**Problem solved. Nothing to see here!** 🤣

🤣 **And then there's the mystery TEMP files...**

We also found 12 suspicious `.tmp.node` files sitting in the Windows TEMP folder.

Same size, same SHA-256 hash, under camouflage unsigned executables, and no clear explanation of which application created them.

Are they legitimate temporary files? Maybe. Are they malware? We haven't established that either.

The problem is simple: **nobody knows what created them or exactly what they're doing there.**

And when you ask questions about suspicious files, the last thing you need is another ZIP file and a new wallet release instead of proper technical answers.

"Don't worry, here's a new wallet!" 😂

**Security by replacement: if you can't explain the old binary, just release a new one!**

I have a wallet with sodium thiopental.  truth serum. please install it. The proof is in the pudding

[monzero-coin]

Thank you for the detailed review, and sorry it took this long to answer properly. The questions are fair, and every answer below can be checked with sha256sum and gpg. Short version: the executable you downloaded is exactly the build its BUILD_INFO.json describes; the second hash in TEST-RESULTS.json belongs to an earlier test build, and recording it that way was our mistake. The details:

Which file you reviewed
The 18 October Windows GUI update: monzero-v1.0.0-windows-gui-profiles-20261018-x64.zip, SHA-256 91dacd571e14f974fe52ee378ded3f39019c2ea5254d988abc3f40513afcf2c2.

1, 2, 3. Commits, release status and the official executable hash

• GUI source commit 4b0cc9e163044282222d2d2845fab1803c6533b5, core commit c4165784db57d8ae410fc8af58861e4178ee1a42 (the v1.0.0 core).
• monzero-wallet-gui.exe in that ZIP: SHA-256 dcd5cb2a919ddc905b45998e464214da53c50b5f6b9a0c5bb13334025a25e5cc, exactly as in its BUILD_INFO.json.
• It was a project-approved GUI update, published with its own checksum file and manifest (/releases/gui-profiles-20261018.json). Unlike the original v1.0.0 archives, it was not covered by the signed release file. Signatures are now added (see 10).
• The other three programs in the ZIP (monzerod.exe, monzero-wallet-cli.exe, monzero-wallet-rpc.exe) are byte-identical to the signed v1.0.0 Windows GUI archive (monzero-v1.0.0-windows-gui-x64.zip, SHA-256 6be94574fd731e7c58fa40fcb22a3202db9a38f2a38b6801ae6929b44c204ad2, listed in the signed /releases/v1.0.0.json). Unzip both and compare: only the GUI executable differs.

4, 5, 6. Why BUILD_INFO.json and TEST-RESULTS.json show different hashes
TEST-RESULTS.json is a cumulative test log covering three successive GUI builds made on 18 October, and its top-level fields describe the first of them:

• 5b45b03 (usability and mining update): SHA-256 0b83284c98ebba1c773495fd890bb87f846cc5d41314e353739062dea295bb9c. This is the build the Wine mining tests ran on, and the hash at the top of TEST-RESULTS.json.
• 7bd819c (graphics follow-up) and 4b0cc9e (public wallet profiles): recorded only in the follow-up sections of the same file, without their own executable hashes.

The distributed executable is the last one, 4b0cc9e (dcd5cb2a…). Both documents name the same core commit, c4165784. Leaving the first build's hash at the top of the log was a record-keeping mistake, and we should have said so straight away. The same file also says "nativeWindowsTested": false: that build was tested under Wine and on native Linux, not on native Windows.

7. The executable used for testing
Published for comparison, for verification only, not for use as a wallet:
monzero-gui-test-build-5b45b03-20261018.zip, SHA-256 e6525b7ad2ad8d462c0551151bdd8d7390fcf41d371049678eb2e77754875004. The executable inside has SHA-256 0b83284c…bb9c.

8, 9. Source and builds

• Matching source: monzero-gui-profiles-20261018-source.tar.gz, SHA-256 22640117e4b189b6e85c983ce98950a5ba3f9e76f6cd827968a52475622d8760; all source is also at github.com/Nightglass-Protocol1/Monzero-source.
• The Windows GUI is cross-compiled in a pinned container: the Monero GUI's Dockerfile.windows, with depends from Monero v0.18.5.1 and Qt 5.15.19, in Release mode with static linking.
• Honest status: our ZIP packaging is deterministic (we build every archive twice and compare), and the v1.0.0 core has a reproduction guide (INDEPENDENT_REPRODUCTION.md in every archive). Bit-for-bit reproduction of the GUI executable has not been independently verified yet. We'd welcome anyone who wants to try, and we'll help with the build environment.

10. Signed manifests
Both GUI update manifests are now signed with the Monzero release key (fingerprint 4C37 C618 789F 86D8 1FEF 28DF 390A EFB7 35F2 70D6, published at /releases/monzero-release-public.asc):

Code:

curl -sO https://monzero.org/releases/gui-profiles-20261018.json
curl -sO https://monzero.org/releases/gui-profiles-20261018.json.asc
curl -sO https://monzero.org/releases/gui-update-20261101.json
curl -sO https://monzero.org/releases/gui-update-20261101.json.asc
gpg --verify gui-profiles-20261018.json.asc gui-profiles-20261018.json
gpg --verify gui-update-20261101.json.asc gui-update-20261101.json

Each manifest lists the ZIP and source SHA-256s; BUILD_INFO.json inside each ZIP lists every executable's SHA-256.

The current Windows release (1 November)
monzero-v1.0.0-windows-gui-20261101-x64.zip, SHA-256 8dc218a430ad86ec07e3b482aecfb922f862ae7cd59376c492eaf0ee9836fa22, GUI commit f47734d337316fc0172be31021bf9b0a8b20c2f9. In this one BUILD_INFO.json and TEST-RESULTS.json name the same executable (fcb6ebe930fe9bf0cd744088eb0d81266ba9d8aefa4da5fd654219e7ed116172). It was tested on native Windows 11: wallet creation, the built-in node syncing to the network tip, and mining start/stop confirmed by the node itself. Its node and CLI programs are again byte-identical to the signed v1.0.0 archive. A new release doesn't replace answers, which is why this post goes through the old one point by point.

Antivirus detections
Some heuristic engines flag Monero-family binaries because they contain RandomX, the proof-of-work algorithm. A node needs it to verify every block, even when mining is off. Microsoft Defender's machine-learning engine flagged monzero-wallet-rpc.exe as Program:Win32/Contebrew.A!ml (a "potentially unwanted program" class); we have submitted it to Microsoft as a false positive. If you have a specific detection name or VirusTotal link, please post it and we'll look at it.

The .tmp.node files in TEMP
These aren't from Monzero. .node files are Node.js native add-ons, which Node- and Electron-based apps unpack into TEMP at runtime. Monzero's programs are C++/Qt, contain no Node.js runtime, and contain no "tmp.node" string or Node add-on interface (strings and imports are easy to check). If you post their SHA-256 we'll help identify them. A VirusTotal lookup of that hash usually names the app that ships them.

If anything above doesn't check out on your side, post the command and output and we'll go through it. Security problems can also be reported privately to security@monzero.org.

as for "But besides your fluent bla bla bla.... have you ever gave a reply for the questions made by this gentleman???" Well i'm an extremely busy individual I work a 37hr a week job and also have been developing this since August. this is apps for people to get there freedom from exchanges, using atomic swaps no custodians or middlemen. Im working very hard at this application... So give me a break....

If you dont trust it dont use it simple as.

Monzero Team

A new download alone isn't an answer to the original security review.
sorry 2-0 and counting
 Grin Grin Grin Grin
🤣 **How to handle a security investigation — Developer Edition**

Community: "Can you answer a few questions about the suspicious wallet binary, its hashes, signatures, build process and those strange security indicators?"

Developer: *Silence.*

Community: "Could you at least clarify whether the Windows build was properly tested?"

Developer: *Silence.*

Developer, a few days later: "Good news! Here's another wallet! 🎉"

Community: "But what about the questions?"

Developer: "NEW WALLET. NEW BEGINNING. 😂"

Apparently, the easiest way to fix a security audit is not to answer it, but to release another ZIP file.

**Problem solved. Nothing to see here!** 🤣

🤣 **And then there's the mystery TEMP files...**

We also found 12 suspicious `.tmp.node` files sitting in the Windows TEMP folder.

Same size, same SHA-256 hash, under camouflage unsigned executables, and no clear explanation of which application created them.

Are they legitimate temporary files? Maybe. Are they malware? We haven't established that either.

The problem is simple: **nobody knows what created them or exactly what they're doing there.**

And when you ask questions about suspicious files, the last thing you need is another ZIP file and a new wallet release instead of proper technical answers.

"Don't worry, here's a new wallet!" 😂

**Security by replacement: if you can't explain the old binary, just release a new one!**

Fair point: a new download isn't an answer to a security review, and we should have replied to your questions first. The full point-by-point answer is in the post above, with hashes you can check yourself. In short:

• The executable you reviewed is exactly the build its BUILD_INFO.json describes (GUI 4b0cc9e, core c4165784, SHA-256 dcd5cb2a…25e5cc). Its node and CLI programs are byte-identical to the signed v1.0.0 archive.
• The other hash in TEST-RESULTS.json (0b83284c…bb9c) is an earlier test build of the same day. Leaving it at the top of the test log was our mistake. That executable is now published so anyone can compare the two.
• Was it properly tested? Under Wine and on native Linux, not on native Windows. The file says so ("nativeWindowsTested": false). The 1 November release was tested on native Windows 11.
• Both GUI updates' manifests are now signed with the release key, with gpg commands in the post above.

On the .tmp.node files: .node is the file type of a Node.js native add-on, and those get unpacked into TEMP by Node- or Electron-based apps (many desktop apps and wallets are built that way). Monzero's programs are C++/Qt with no Node.js runtime and no "tmp.node" string in them, which anyone can confirm with strings or a PE viewer. Post the SHA-256 of one of them and we'll help find which app ships it; a VirusTotal search of the hash usually names it straight away.

If anything doesn't check out on your side, post the command and the output and we'll go through it.

[111username111]

Thank you for providing a more detailed response. I appreciate the clarification regarding the earlier test build, the commit references, and the lack of native Windows testing in the original release. Acknowledging the documentation mistake is also appreciated.

However, a few important security questions remain open.

1. **Digital signatures:** You mention that both GUI update manifests are now signed. Are the actual Windows executables also Authenticode-signed, or are only the manifests signed? These are two different things.

2. **Hybrid Analysis findings:** Could you provide a technical explanation for the anti-debugging checks, VM detection, registry operations and other behaviours identified in the analysis? These findings deserve an explanation beyond saying that the application is legitimate.

3. **Wallet security:** Has the complete handling of recovery seeds and private keys been reviewed or independently audited? Is there any technical documentation or test evidence available?

4. **Windows 11 testing:** Can you provide the exact version tested, its SHA-256 hash, and the corresponding test results?

I appreciate the additional transparency, and I am willing to verify the new information independently. My intention is not to accuse the project of malicious behaviour, but to establish whether users can safely trust the Windows wallet with their funds.

The hash and build information are a good start. The remaining security questions still need clear answers.Windows wallet remain unverified.

[Hackerman555]

Recommended software to scan my computer with for strange stuff after trying this project out?

Thanks in advance.

[monzero-coin]

Thank you for providing a more detailed response. I appreciate the clarification regarding the earlier test build, the commit references, and the lack of native Windows testing in the original release. Acknowledging the documentation mistake is also appreciated.

However, a few important security questions remain open.

1. **Digital signatures:** You mention that both GUI update manifests are now signed. Are the actual Windows executables also Authenticode-signed, or are only the manifests signed? These are two different things.

2. **Hybrid Analysis findings:** Could you provide a technical explanation for the anti-debugging checks, VM detection, registry operations and other behaviours identified in the analysis? These findings deserve an explanation beyond saying that the application is legitimate.

3. **Wallet security:** Has the complete handling of recovery seeds and private keys been reviewed or independently audited? Is there any technical documentation or test evidence available?

4. **Windows 11 testing:** Can you provide the exact version tested, its SHA-256 hash, and the corresponding test results?

I appreciate the additional transparency, and I am willing to verify the new information independently. My intention is not to accuse the project of malicious behaviour, but to establish whether users can safely trust the Windows wallet with their funds.

The hash and build information are a good start. The remaining security questions still need clear answers.Windows wallet remain unverified.

Thanks — these are fair, and I'll answer each directly, including where we fall short. First, let me be completely straight with you about the Windows situation, because I think the honest context matters more than any single hash.

Straight context from the dev. I'll level with you: I'm the developer, and I'm a full-time Linux user. Monzero is built and developed on Linux, and that's where essentially all the testing and real-world use happens. The Windows build exists because a user asked for it — it was made on demand, not as a core focus. So far I've only tested it in a Windows VM and under Wine; I haven't yet put the serious work into getting the native Windows build and its toolchain done properly. That — plain and simple — is why the Windows side looks lacklustre: it's time and priorities, not unwillingness, and there is nothing malicious in the software. My plan is honest about the order of things: I'm heads-down finishing the DEX I'm building, and I'll come back and do the Windows application properly — and make sure it's working correctly — before I launch the DEX live. I'd rather tell you that than pretend the Windows build has had attention it hasn't.

With that said, here are the specifics:

1. Authenticode signing of the executables. You're right to separate these. The honest answer: the .exe files are not yet Authenticode-signed — only the release manifests are (GPG/PGP signed). So today you can verify integrity and origin against the project's signed hashes, but not via a Windows-trusted Authenticode chain. We're fixing exactly this — acquiring a code-signing certificate (Certum) and Authenticode-signing the Windows binaries, which also reduces SmartScreen/AV friction. Until that's live I won't claim the binaries are signed, because they aren't; when it's done I'll post the certificate fingerprint here.

2. Hybrid Analysis behaviours. These flags are expected for a Monero-family, RandomX proof-of-work wallet, and each has a concrete cause:
- "Anti-debugging" / memory guarding: the wallet locks secret-key memory (VirtualLock) and avoids core dumps so your spend key can't be paged to disk or captured in a crash. Heuristics read that as anti-debugging; it's actually protecting your keys.
- "VM / sandbox detection": RandomX runs cpuid to detect AES-NI, SSE/AVX and large-page support and pick a fast/slow path. Sandboxes read CPU-feature probing as environment detection — it's performance tuning, not evasion.
- RWX / "self-modifying code": RandomX JIT-compiles its hashing program into executable memory (VirtualAlloc + VirtualProtect) — inherent to RandomX (the same verification every node does for every block), and why it's CPU-fast.
- Registry operations: the GUI is Qt; QSettings stores UI preferences under HKCU\Software. No system-wide, startup or persistence keys.

None of this needs taking my word — it's all in the open source. If you share the specific Hybrid Analysis link or the file's SHA-256, I'll map each finding to the exact function, rather than answer in general terms.

3. Wallet / seed / key handling. Monzero is a fork of Monero, and the wallet, 25-word mnemonic, key derivation and encrypted-wallet-file handling are inherited essentially unchanged from Monero, whose cryptography and wallet code have been independently audited and are among the most-reviewed in the space. Our diff against upstream Monero is small and reviewable. Honest limitation: Monzero itself has not had a separate paid third-party audit — I've said that consistently and won't claim otherwise. What's available: the full source, a reproduction guide in every archive, and a community security-testing kit with a private channel at security@monzero.org.

4. Windows 11 test build.
- File: monzero-v1.0.0-windows-gui-20261101-x64.zip
- ZIP SHA-256: 8dc218a430ad86ec07e3b482aecfb922f862ae7cd59376c492eaf0ee9836fa22
- monzero-wallet-gui.exe SHA-256: fcb6ebe930fe9bf0cd744088eb0d81266ba9d8aefa4da5fd654219e7ed116172
- GUI commit f47734d337316fc0172be31021bf9b0a8b20c2f9

Tested on native Windows 11 ("nativeWindowsTested": true in the archive's TEST-RESULTS.json): wallet creation, the built-in node syncing to the network tip, and mining start/stop confirmed by the node. The node and CLI binaries here are byte-identical to the signed v1.0.0 archive.

So to be realistic about where things stand: the Windows wallet works but hasn't had the engineering attention the Linux build has, and I'd treat it as experimental until I give it a proper pass — which I will, before the DEX goes live. If you want the most-tested path today, the Linux builds and the web wallet are where the real mileage is. Send me that Hybrid Analysis hash and I'll go through it finding-by-finding, and security concerns can go privately to security@monzero.org.

Thanks for pushing on this — it's the right thing to do, and honestly it's a useful nudge to get the Windows build properly sorted.
Monzero

[111username111]

https://hybrid-analysis.com/sample/dcd5cb2a919ddc905b45998e464214da53c50b5f6b9a0c5bb13334025a25e5cc/6ae541d858d33684e20e8fbf




Thanks for the detailed response. However, I want to be clear: **you have addressed some of my concerns, but you still have not answered all of the technical questions I raised.** I appreciate the transparency about the Windows build, the lack of Authenticode signing, and the absence of an independent Monzero security audit. But explanations in general terms are not the same as evidence tied to the actual executable I analysed.

There are several specific points that remain unanswered:

**1. Hybrid Analysis findings — I need evidence, not just plausible explanations.**

You explained that RandomX uses CPU-feature detection and JIT compilation, and that the wallet protects sensitive memory. Those explanations may account for some behaviours, but they do not automatically explain every indicator in my report.

In particular:

- Why does the executable query `ProcessDebugPort`? Which exact function in the source code is responsible?
- Which exact code performs the VM-related registry checks? CPU-feature detection through CPUID does not, by itself, explain registry access.
- Why does the executable use screenshot-capable APIs?
- What code is responsible for the registry deletion operations?
- Can you map each of these behaviours to a specific source file, function, and code path in the exact GUI commit I analysed (`4b0cc9e...6533b5`)?

Please address each finding individually. Saying that these behaviours are expected in a Monero-family wallet is not sufficient.

**2. Wallet seed and private-key security.**

You refer to Monero's established codebase and its previous audits. I understand that Monzero inherits much of its wallet implementation from Monero, but a fork is not automatically covered by the security guarantees of its upstream project.

Have you reviewed the differences between Monero and Monzero specifically in the wallet, mnemonic generation, key derivation, encryption and private-key handling? If so, please identify the relevant changes and provide the review or reproducible comparison.

I understand that Monzero has not undergone a separate paid third-party audit. I am asking what verification has actually been performed on the fork itself.

**3. The new Windows 11 build does not resolve the old executable's findings.**

You have provided new hashes and test results for the 1 November build. That is useful, but it does not establish that the previous executable I analysed was safe.

Have the behaviours flagged by Hybrid Analysis been investigated in the old build? Were any of them removed, changed or confirmed as legitimate? If the new build differs, please provide a meaningful comparison.

**4. Signed manifests versus signed executables.**

Thank you for confirming that the executables are currently not Authenticode-signed. I understand that the GPG-signed manifests allow users to verify published hashes, but they do not provide a Windows-trusted Authenticode signature on the actual `.exe` files.

Please publish the promised certificate fingerprint and signed Windows binaries once available.

I am not accusing you of deliberately distributing malicious software. I am asking for technical answers because the original Windows executable produced several security indicators that deserve proper investigation.

**To be clear, the central issue remains unresolved:** I need a finding-by-finding explanation tied to the actual source code and executable I analysed, not just general explanations of how RandomX or Monero-family wallets work.


plus



**5. Unexplained Slavic-language strings embedded in the executable.**

There is another detail that has not been addressed: during my analysis, I found the following strings embedded in the Windows executable:

- `Napredne postavk`
- `Exportovat pe`

These appear to be fragments of Slavic-language interface text, including a Czech export-menu label.

I am not claiming that these strings are malicious. However, given the other unexplained indicators, I would like to know why they are present.

Are these remnants of Qt translation files, inherited Monero components, third-party libraries, or something else? Can you identify their origin in the source tree and explain why they are included in this particular Windows build?

Please don't dismiss this as harmless localization without identifying where the strings come from. I am asking for their actual origin in the executable.


Transparency is appreciated, but it must be accompanied by verifiable technical evidence. I hope you can address the remaining points directly.

Recommended software to scan my computer with for strange stuff after trying this project out?

Thanks in advance.

If you've tried the Monzero Windows wallet and want to check your system afterwards, I'd recommend starting with reputable, on-demand security tools rather than downloading random "PC cleaner" or malware-removal utilities.

My suggestions:

Microsoft Safety Scanner (MSERT) — download it directly from Microsoft's website and run a Full Scan.

Malwarebytes Free — use it for a second-opinion scan.

Kaspersky Virus Removal Tool (KVRT) — another on-demand scanner that can provide an additional check.

Microsoft Defender Offline Scan — if Microsoft Defender is installed and working on your system, this can help detect threats that are difficult to scan while Windows is running.

Also check your startup applications and installed programs for anything unfamiliar.

One important point: a detection by an antivirus does not automatically mean your computer is infected. Cryptocurrency wallets and RandomX-related software can trigger heuristic detections. Equally, a clean scan cannot guarantee that a system is completely safe.

If you find anything suspicious, save the detection name and file hash before deleting it, so it can be investigated properly.

Download scanners only from their official websites. Better to be cautious than to install several questionable security tools.
If you suspect a deliberately concealed, sophisticated malware infection, don't rely solely on antivirus scans. The safest option may be to completely wipe the system drive and perform a clean Windows installation using official Microsoft media.

After that, change all your passwords from a separate, known-clean device, especially email, banking, cryptocurrency exchanges and other important accounts. Enable two-factor authentication wherever possible.

A well-designed hidden infection may evade conventional scanners, so a clean reinstall and securing your accounts are sensible precautions when there is credible evidence of compromise.
One more thing: directing users to private email whenever security concerns are raised publicly can also shift attention away from the actual issue.

If a problem is being discussed in a public forum, the technical questions and their answers should remain public whenever possible. Otherwise, the discussion loses transparency, other users cannot see whether the concerns have been properly addressed, and the same questions may have to be asked repeatedly.

Private email is perfectly reasonable for sensitive information or responsible vulnerability disclosure. But it should not become a substitute for answering legitimate public questions about the security of software distributed to the community.

If the project is open source and the developer is committed to transparency, then the explanations and evidence should be available for everyone to review.

Because it's white and bottled maybe, just maybe is not milk......

[monzero-coin]

Thanks for keeping this public. You're right that it belongs here rather than in email. Below is a finding-by-finding answer tied to the source and to your report. It can all be checked independently, and where I don't have an answer yet I say so.

First, what your report itself shows
- 0 malicious indicators and no verdict (5 suspicious, 100 informational).
- No DNS requests, no contacted hosts and no HTTP traffic during the run. Nothing left the machine.
- The wallet crashed: the process tree shows WerFault.exe launched three times against PID 2788. The sandbox therefore mostly recorded startup plus Windows' crash handling, not the wallet running normally. The crash is a real bug and I'm reproducing it on a clean Windows 10 VM.
- I'm checking the SHA-256 you analysed (dcd5cb2a…25e5cc) against our published manifests and will confirm in tomorrow's update which release it is.

1. Indicators, mapped to code
- Screenshot APIs: gui/src/main/oshelper.cpp → screenshot() → QGuiApplication::primaryScreen()->grabWindow(0). Its only caller is OSHelper::grabQrCodesFromScreen(), the "scan QR code from screen" button inherited from Monero GUI. It hides the wallet's windows, decodes any QR codes in memory and discards the image. Nothing is saved or sent.
- Key container within a CSP / Enhanced Cryptographic Provider: core/src/crypto/random.c → CryptAcquireContext + CryptGenRandom. This is the Windows randomness source used to generate wallet keys, identical to upstream Monero.
- Clipboard: clipboardAdapter, used by the "copy address" buttons.
- Registry reads/writes/deletes: OSHelper::installed() reads HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Monzero GUI Wallet_is1 to check for an installed copy. GUI settings are stored with Qt's QSettings (gui/src/qt/MoneroSettings.cpp), which on Windows is the registry under HKCU\Software\monzero-project\monzero-core. If any deleted key in your full report is outside that path, please post it. That would be a real finding.
- ProcessDebugPort: not present anywhere in Monzero core, the GUI or upstream Monero. When a process crashes, Windows' own unhandled-exception handling queries ProcessDebugPort to check for a debugger before launching WerFault, and your run crashed. I believe that's the source but haven't proven it with a stack trace yet. I'll post the trace when I have it.
- "Reads VM-specific registry key": not explained yet. The slim report hides which key was read (registry-172/173/177/33 are marked "not all sources available"). There is no VM-detection code in our source. If you have the full report, the key path would let me trace the module responsible. Until then it's open, not dismissed.
- Most of the 100 informational items are "contains API string" matches that any large, statically linked Qt application produces. Some are pattern false positives: "Exchange transport agent (.NET)" can't apply, since this is a native C++ binary with no .NET.

5. The Slavic strings
They're the GUI's built-in translations, compiled into the exe as Qt resources (gui/translations/, inherited from upstream monero-gui):
- "Napredne postavke" = Croatian "Advanced settings" (monero-core_hr.ts)
- "Samo za pregledavanje" = Croatian "View only" (monero-core_hr.ts)
- "Exportovat peněženku" = Czech "Export wallet" (monero-core_cs.ts, the Export button in pages/Keys.qml)
- "Importovať" = Slovak "Import" (monero-core_sk.ts)
Your strings tool cut each one at its first non-ASCII letter (ě, ť), which is why they look like fragments.

2. What has actually been verified on the fork
I diffed Monzero core against upstream Monero v0.18.5.1. Reproduce by cloning both and running diff -r on each directory:
- src/mnemonics (seed words), src/device (hardware wallets), src/ringct: byte-identical to upstream.
- src/crypto: one change, in crypto-ops.c, replacing left-shifts of negative integers (undefined behaviour in C) with equivalent multiplications. Same arithmetic result.
- src/wallet: the inactive asset prototype, a Monzero marker in the keys file so the wallet refuses to open Monero wallet files, display-unit handling and branding. Seed generation, key derivation and keys-file encryption are unchanged from Monero.
- Across all of the core src, the only new hostnames are node.monzero.org (default node) and monzero.org in the welcome text. No new outbound endpoints.
For transparency, the GUI has two optional network features inherited from Monero GUI, which explain URLs you'll see in strings:
- fiat price display (CoinGecko / Kraken / CryptoCompare), off by default;
- P2Pool download from the official SChernykh/p2pool GitHub releases, only if you choose P2Pool mining.
Neither ran in your session, consistent with the zero network activity.
To be clear: this is a source comparison done by me, not an independent audit, and I'm not presenting it as one.

3. The Windows build: being withdrawn
Agreed, a clean new build doesn't clear the old one. Rather than ask anyone to trust it in the meantime, I'm withdrawing the Windows GUI download from monzero.org today. Its hashes, release notes and source will stay listed so anyone can still verify what was published. Linux builds, the Windows CLI and all source remain available.

It comes back only when:
- the sandbox crash is reproduced, explained and fixed;
- the ProcessDebugPort query and the VM registry read are both traced to a specific module, with evidence posted here and on GitHub;
- the new build has been run through the same analysis, with results posted side by side with yours.

I'll be straight about where this is heading: if the Windows build keeps being this problematic (unsigned binaries, heuristic flags and crashes in sandboxes), we will likely stop providing official Windows builds altogether and focus on Linux. Windows users would still be able to build from source, and community-built binaries would be welcome if they're independently reproducible.

If you ran the old Windows build and want peace of mind, the scanner advice above is sensible. Moving funds to a freshly generated wallet costs nothing.

For now my recommendation is the Linux build. It's the platform Monzero is developed and tested on, you can build it from source yourself in a few commands, and you don't need to trust my binary at all. Honestly, for a privacy coin, Linux is where you want to be anyway.

4. Signing
Correct: GPG-signed hash manifests are not Authenticode, and the .exe files are unsigned and labelled that way. If Windows builds continue, signed binaries and the certificate fingerprint will be posted here before the Windows GUI returns. I won't promise a date I can't guarantee.

Source and issue tracking
All Monzero source (core, desktop GUI, Android wallet and miner) is public in one repository:
https://github.com/Nightglass-Protocol1/Monzero-source
The GUI is under gui/: src/main/oshelper.cpp, src/qt/MoneroSettings.cpp and translations/ cover the items above. The repo was consolidated from the separate release repositories at v1.0.0 (GUI imported from monzero-gui 44eef24d4), so older GUI commit hashes such as 4b0cc9e aren't in its history. I'll post exactly where 4b0cc9e sits relative to that import, and the diff between them.
Please open a GitHub issue there for each open finding, or anything new, so the evidence stays public and tied to specific commits. I'll link the results there as well as here.

Summary
Four of the flagged behaviours map to specific, legitimate code (screen QR scan, key entropy, clipboard, settings storage), and the translation strings are fully explained. Two items are still open: the ProcessDebugPort trace, which I believe comes from the crash, and the VM registry key. The Windows GUI is being withdrawn today, and official Windows builds may be dropped for good if the problems continue.

I'm quite busy today, so I'll post an update here tomorrow with more findings: the hash confirmation, where 4b0cc9e sits, and progress on the crash and the two open indicators. If you can share the full report's registry key paths before then, that will help me close the last one. Please keep pushing if anything doesn't hold up.Yesterday's promised update. I now have a finding-by-finding answer, and the two items I said were open — the hash and which build you analysed — are closed. Everything below is reproducible from the public source and the published artifacts.

The headline: I identified your exact binary.

Your SHA-256

Code:

dcd5cb2a919ddc905b45998e464214da53c50b5f6b9a0c5bb13334025a25e5cc

is our monzero-wallet-gui.exe from the Oct-18 "public wallet profiles" preview build (monzero-v1.0.0-windows-gui-profiles-20261018-x64.zip), built from the commit you named, 4b0cc9e…6533b5. It is byte-identical to our own build artifact, so it is authentically our code compiled by us — not a repackage or an injected binary.

It is not the v1.0.0 release. The shipped v1.0.0 GUI executable is a different file:

Code:

77202a6795da48154c6adfddfb8160b79da2c5399d6b3ed97fbbed2d7ed5f927  (monzero-v1.0.0-windows-gui-x64.zip)

So you analysed a pre-release preview of an experimental feature (public wallet profiles, which adds optional HTTPS fetching) that was removed before v1.0.0. It crashed at startup in your run, so that feature never executed — consistent with the zero network activity in your report.

2. What's actually different from Monero (reproduced with diff -r against the real v0.18.5.1 tag):

• src/mnemonics (seed words), src/device (hardware wallets), src/ringct, and src/cryptonote_basic/account.cpp (key derivation): byte-identical to upstream.
• src/crypto: a single change, in crypto-ops.c — "carryN << 26" replaced by "carryN * (1 << 26)". A left-shift of a possibly-negative signed int is undefined behaviour in C; the multiply is well-defined and arithmetically identical. Nothing cryptographic changes.
• src/wallet: the changes are an asset-transaction prototype plus a plaintext Monzero keys-file marker (so a Monzero keys file won't open as a Monero one) and branding. Seed generation, key derivation and keys-file encryption are unchanged — the ChaCha keys-file encryption code is identical; only the marker was added.
• The asset prototype is inactive: gated behind HF_VERSION_MONZERO_ASSETS = 18; the code returns "asset transfers are not active at the daemon's current hard fork".
• Outbound endpoints across all of core/src: only node.monzero.org, monzero.org and donate.monzero.org are new (the rest are inherited Monero URLs in comments/defaults). No telemetry, no paste sites, nothing unexpected.

Reproduce it yourself: clone monero-project/monero at v0.18.5.1 and run diff -r against core/src/.

1. Your indicators, mapped to code (checked at your exact commit 4b0cc9e, at v1.0.0, and upstream):

• ProcessDebugPort / anti-debug (IsDebuggerPresent, CheckRemoteDebugger, NtQueryInformationProcess): zero matches anywhere in our source. Your run crashed (WerFault x3); Windows' own unhandled-exception path queries ProcessDebugPort before launching WerFault. The live stack trace is the one thing that still needs a Windows VM repro, which I'm doing.
• VM-specific registry read: no VM-detection code of any kind in our source. Your slim report hides which key was read (registry-172/173/177/33, "not all sources available"). Post the actual key path and I'll trace the module the same day.
• Screenshots: gui/src/main/oshelper.cpp -> grabWindow(0), sole caller grabQrCodesFromScreen() — the "scan QR from screen" button. Decodes QR in memory, discards the image, saves/sends nothing.
• Registry writes/deletes: Qt QSettings under HKCU\Software\monzero-project\monzero-core; Qt removes a key when a setting is cleared, plus a read of the Uninstall key to detect an installed copy. If any deleted key in your full report is outside that path, post it — that would be a real finding.
• Key container (CSP): core/src/crypto/random.c -> CryptAcquireContext + CryptGenRandom, the Windows randomness source for key generation, identical to Monero.

5. The Slavic strings — compiled Qt translations in gui/translations/ (inherited from monero-gui):

• Napredne postavke = Croatian "Advanced settings" (monero-core_hr.ts)
• Exportovat peněženku = Czech "Export wallet" (monero-core_cs.ts)
• Samo za pregledavanje = Croatian "View only" (monero-core_hr.ts); Slovak lives in monero-core_sk.ts.

Your strings tool cut each at its first non-ASCII letter (ě), which is why they looked like fragments.

4. Signing: confirmed — the .exe files are unsigned and labelled as such; the GPG-signed manifests cover published hashes only, not Authenticode. If Windows builds continue, signed binaries and the certificate fingerprint go here first.

3. Old vs new build: addressed above — you analysed the Oct-18 profiles preview, a different binary from v1.0.0 whose feature was removed. The Windows GUI is being withdrawn regardless; hashes and source stay listed for
verification.

Summary

• Your binary is identified and authenticated: our Oct-18 public-profiles preview (dcd5cb2a…)entical to our build output, not the v1.0.0 release (77202a67…).
• Every flagged behaviour maps to legitimate, reproducible code; the seed/key/encryption path is byte-identical to Monero; the asset prototype is inactive; no anti-debug/VM code exists in our source; no unexpected network
  endpoints.
• Still genuinely open: the live ProcessDebugPort stack trace (needs the Windows repro) and the exact VM-registry key (needs your full report's key paths). Post those and I'll close both.

Please open a GitHub issue per open item at github.com/Nightglass-Protocol1/Monzero-source. Thanks forreading, the Linux build remains the recommendation: you compile it yourself and don't have to trust my binary at all.