CyberLock 9.0

  • danb Thread starter danb
  • Start date Start date
  • 363 Replies
  • 66,413 Views
  • Featured
I am having an issues with 9.15 where CyberLock 9.15 Smart Firewall in Recommended mode blocks WinRM/WS-Man connections to a Hyper-V host on TCP 5985. Test-NetConnection host -Port 5985 succeeds, but Test-WSMan host fails and curl reports Bad access. Disabling Smart Firewall immediately restores both Test-WSMan and Hyper-V Manager connectivity. Adding an outbound firewall rule for mmc.exe does not resolve it. Is there a Smart Firewall exclusion for WinRM/WS-Man or a trusted IP/port?
Hi, probably the best thing to do is the select Recommended mode, then adjust the firewall rules manually by clicking the little firewall icon to the right and then adjust them by clicking Advanced Settings. If that does not work for some reason, please let me know, thank you!
 
Hi, probably the best thing to do is the select Recommended mode, then adjust the firewall rules manually by clicking the little firewall icon to the right and then adjust them by clicking Advanced Settings. If that does not work for some reason, please let me know, thank you!
That worked like a charm....I was thinking Cyberlock did something else with the firewall stuff so it didn't even occur for me to look for rules from Cyberlock. We are good to go now....sorry to have troubled you.
 
That worked like a charm....I was thinking Cyberlock did something else with the firewall stuff so it didn't even occur for me to look for rules from Cyberlock. We are good to go now....sorry to have troubled you.
Sure, no problem at all. We could build out this feature to control Windows Firewall, but there are already great tools for that. Thank you!
 
Sure, no problem at all. We could build out this feature to control Windows Firewall, but there are already great tools for that. Thank you!

But your version of a Firewall Controller would be better. Look at what you did for Defender, with DefenderUI and DefenderUI Pro. I'd pay for a good firewall controller gui, sans Malwarebytes ugliness.
 
But your version of a Firewall Controller would be better. Look at what you did for Defender, with DefenderUI and DefenderUI Pro. I'd pay for a good firewall controller gui, sans Malwarebytes ugliness.
I appreciate that, thank you! Maybe some day... I am just not sure we would want it to be integrated into CyberLock, we want to keep CyberLock as lean and mean as possible. I could certainly see integrating it into DefenderUI though ;).
 
@danb - Ungoogled Chromium 154.0.8037.92-1.1

Total tokens: 0 (0 request / 0 response)

File path: c:\users\coco\appdata\local\chromium\application\chrome.exe
File hash: 906ce85fcc9ab0d3a0a0ef0539775c9e2d5c74a45d0b635cf95486415ff574b4
File size: 4.21 MB
File publisher: This file is a signable file type but has not been digitally signed.

Final Verdict: Not Safe with 92% confidence.

=== SiriusGPT analysis started at: 10/5/2026 6:50:16 PM ===

## Analysis Summary

This file presents a complex case requiring careful evaluation. The executable claims to be Chromium browser (chrome.exe) with matching version information and file paths consistent with a Chromium installation. However, critical security indicators are absent: the file is **completely unsigned** despite being a signable PE file, and it exhibits several anomalies including suspicious export functions and unusual string artifacts. The combination of legitimate-appearing metadata with missing security controls and atypical technical characteristics warrants significant concern.

## Detailed Analysis

### File Metadata and Version Information
The version information appears professionally crafted: "Chromium" as product name, "chrome.exe" as original filename, and copyright attribution to "The Chromium Authors" with 2026 date. The file path `c:\users\coco\appdata\local\chromium\application\chrome.exe` follows expected Chromium installation patterns. However, **the complete absence of digital signature** on a modern browser executable is highly anomalous—legitimate Chromium builds from Google or official sources are always signed. The `ValidSecurityDir: False` and `CertificateTableSize: 0` confirm no signature data exists.

### PE Structure and Entropy Analysis
The file contains 11 sections with generally reasonable entropy values (6.46, 5.62, 2.54, 6.08, etc.), though SectionEntropy3 at 2.54 suggests possible compressed or sparse data. The overlay entropy of 0.00 with zero overlay size indicates no appended data. Section flags appear standard with expected combinations of executable, readable, and writable permissions. The CLRRuntimeHeaderSize of 0 confirms this is native code, not .NET.

### Execution and Security Controls
ASLR and DEP are enabled (`OptionalHeaderDllCharacteristics: 0xC160`), indicating modern security-conscious compilation. The `asInvoker` execution level is standard for browsers. However, the `OptionalHeaderCheckSum: 0x00000000` is unusual—while not strictly required, most legitimate executables include a valid checksum.

### Import Analysis
The import table contains 254 functions with a diverse set of capabilities:

**Process and Memory Manipulation:**
- `CreateProcessW`, `CreateRemoteThread`, `OpenProcess`, `ReadProcessMemory`, `WriteProcessMemory`, `VirtualAllocEx`, `VirtualProtectEx` — these enable process injection and memory manipulation common in malware
- `CreateJobObjectW`, `SetInformationJobObject`, `TerminateJobObject` — job object management for process control

**Persistence and System Integration:**
- `CreateFileW`, `CreateDirectoryW`, `SetFileAttributesW`, `MoveFileW`, `ReplaceFileW` — file system operations for payload deployment
- `CreateNamedPipeW`, `ConnectNamedPipe`, `TransactNamedPipe` — inter-process communication mechanisms

**Evasion and Monitoring:**
- `IsDebuggerPresent`, `AddVectoredExceptionHandler`, `RemoveVectoredExceptionHandler` — anti-debugging and exception handling
- `NtQueryInformationProcess`, `NtQueryObject` — low-level system information queries

**Legitimate Browser Indicators:**
- Extensive locale and internationalization functions (`GetSystemDefaultLCID`, `GetUserDefaultLocaleName`, `EnumSystemLocalesEx`, etc.)
- Console and standard I/O handling
- Memory-mapped file operations for efficient resource loading

The `DangerousImportedLibrariesNormalized: 32.37 / 100` score reflects elevated but not extreme risk from imports. The presence of `dbghelp.dll` symbols and debugging functions suggests either development/debug build characteristics or intentional symbol manipulation.

### Export Analysis
Only **2 exports** are present:
- `GetHandleVerifier`
- `IsSandboxedProcess`

These are **highly suspicious** for a browser executable. Legitimate Chromium exports dozens to hundreds of functions for component integration. `IsSandboxedProcess` specifically relates to Chromium's sandbox security model, but the minimal export table suggests either:
1. A stripped/hollowed executable
2. A loader or wrapper around legitimate Chromium code
3. Malware masquerading as Chromium with minimal implementation

### String Analysis
Critical findings from meaningful strings:

**Rust Runtime Artifacts:**
- `RUST_BACKTRACE`, `panicked at`, `thread panicked while processing panic`, `memory allocation of bytes failed`
- These indicate Rust language compilation, which **Chromium does not use**—Chromium is primarily C++ with some Rust components only in very recent experimental builds, not in core browser executables

**Debug and Symbol References:**
- `dbghelp.dll`, `SymInitializeW`, `SymGetOptions`, `EnumerateLoadedModulesW64` — Windows debugging symbols
- `stack backtrace:` — Rust panic handling

**Internal Module References (suspicious):**
- `icon_reaM3`, `n_readerM3Y`, `print_baH3`, `_backendL3F`, `screen_aH3`, `xr_compoM3Y`, `pdf_convM3Y`, `proxy_reM3Y`, `resolverM3Y`
- These appear to be mangled or obfuscated internal module names, possibly indicating packed or modified code

**System Error Strings:**
- Standard POSIX-style error messages (`Operation not permitted`, `No such file or directory`, etc.) — unusual in Windows executables unless cross-platform compatibility layer present

## Speculative Software Assessment

This executable **does not appear to be legitimate Chromium**. The evidence suggests:

1. **Possible Malware Disguised as Chromium:** The matching metadata and paths with completely absent signature, minimal exports, and Rust compilation artifacts (incompatible with Chromium's actual codebase) strongly suggest impersonation.

2. **Potential Loader or Dropper:** The process manipulation imports, minimal exports, and module-like internal references could indicate a loader that deploys additional payloads while masquerading as a browser.

3. **Modified or Repackaged Binary:** The combination of legitimate-appearing version info with technical inconsistencies (Rust strings, no signature, suspicious exports) suggests modification of a legitimate binary or complete fabrication of metadata.

The file's characteristics align more closely with **sophisticated malware using brand impersonation** than with any legitimate software category. The technical sophistication (ASLR/DEP enabled, diverse API imports) combined with identity deception indicators creates a high-risk profile.

Malware type: Trojan.ChromiumImpersonator
Malware name: Dropper.RustLoader

Final verdict: Malicious with 92% confidence.
 
@danb - Ungoogled Chromium 154.0.8037.92-1.1
Thank you @oldschool. Yes, Sirius is instructed to be especially cautious with specific types of apps such as web apps, email clients and cybersecurity software, and expects them to be signed. If they are not signed, they can be easily compromised. So in this case, unfortunately the only real way Sirius is going to render a Safe verdict is if they start signing the files. And really, it is not a huge ask to have devs sign their work in this day and age.
 
I have noticed the following behavior with CyberLock: I use Windows Hello facial recognition to sign in to my PC (running Windows 11) and to wake it from sleep mode. To wake the PC, I press a key on the keyboard; the sign-in screen then appears, and the camera activates. When CyberLock is installed, however, this only works intermittently. Often, the camera fails to turn on after I press a key, requiring me to press a key a second time. It is only a minor issue, but perhaps it could be avoided?
 
I have noticed the following behavior with CyberLock: I use Windows Hello facial recognition to sign in to my PC (running Windows 11) and to wake it from sleep mode. To wake the PC, I press a key on the keyboard; the sign-in screen then appears, and the camera activates. When CyberLock is installed, however, this only works intermittently. Often, the camera fails to turn on after I press a key, requiring me to press a key a second time. It is only a minor issue, but perhaps it could be avoided?
Very interesting, thank you for letting me know! The next time this happens, can you please email (support at cyberlock.global) this log right afterwards: C:\ProgramData\CyberLock\DeveloperLog.log

Also, is this for CyberLock 9.10 or 9.15? Thank you!
 
Very interesting, thank you for letting me know! The next time this happens, can you please email (support at cyberlock.global) this log right afterwards: C:\ProgramData\CyberLock\DeveloperLog.log

Also, is this for CyberLock 9.10 or 9.15? Thank you!
Yes, I will send the file over. It is for CyberLock 9.15. However, this behavior was already present in version 9.10 as well.
 
Yes, I will send the file over. It is for CyberLock 9.15. However, this behavior was already present in version 9.10 as well.
I think there is an 80% chance that this issue is now fixed in the version below, so can you please try it and let me know how it goes?

If it is still not working correctly, please send me the developer logs again and that should tell me the next step to isolate this bug: C:\ProgramData\CyberLock\DeveloperLog.log

https://www.cyberlock.global/downloads/InstallCyberLock915Test2.exe

And if anyone else is interested in trying this version, please let me know if there are any issues. There was a very simple but significant change to this version. I have been trying to figure out exactly how to handle all of the AI Agents within our products. They currently work well with AI Agents, but I think we can optimize it a little more, so that is what I am working on... getting close ;). Thank you guys!
 
Hello Dan,
the error reappeared immediately, in a more pronounced form. On the login screen, the message "Preparing" appeared and remained there. I pressed a key on the keyboard a second time, but the "Preparing" message persisted. The camera did not turn on. I had to enter my login code.
During another attempt, the message "Preparing..." did not appear. The camera only turned on after a second press of the button, and I was logged in.
I have sent both developer log files via email.

Miraculix
 
My program does not auto update, I was still on 9.10 and when I hit update check( your currently running the latest Cyberlock!) Is the reason 9.10 is the last stable version or is there a glitch?
Hi, no glitch at all... I just have not pushed the 9.15 update yet. Once I fix this last bug, we will see if people can run 9.16 for a couple of weeks, and then push the update. Thank you!
 
Hello Dan,
the error reappeared immediately, in a more pronounced form. On the login screen, the message "Preparing" appeared and remained there. I pressed a key on the keyboard a second time, but the "Preparing" message persisted. The camera did not turn on. I had to enter my login code.
During another attempt, the message "Preparing..." did not appear. The camera only turned on after a second press of the button, and I was logged in.
I have sent both developer log files via email.

Miraculix
Sounds great, thank you, I will review the logs you sent me and we will figure this out. I think the problem is that CyberLock is used to the standard Windows login, which does not start CyberLock until certain events occur. But then when an HP login takes over, CyberLock is already running, but you cannot see the block ;). Does that sound like what is happening? I have to say, this is one of the strangest, but interesting bugs I have ever seen ;).
 
Sounds great, thank you, I will review the logs you sent me and we will figure this out. I think the problem is that CyberLock is used to the standard Windows login, which does not start CyberLock until certain events occur. But then when an HP login takes over, CyberLock is already running, but you cannot see the block ;). Does that sound like what is happening? I have to say, this is one of the strangest, but interesting bugs I have ever seen ;).
The error never occurs when starting the computer. It only happens when I "wake" the computer from power-saving mode.
 

Recently browsing

Members who viewed this thread in the last 5 minutes

Back
Top