CyberLock 9.0

danb

danb

From VoodooShield
Thread author
Verified
Top Poster
Developer
Well-known
Forum Veteran
May 31, 2017
2,160
12,557
3,078
Overland Park, KS
Hey Guys!

We have all new versions of most of our software!

A while back I tested Sirius without WhitelistCloud and the old VoodooAi and it performed significantly better, so I planned on completely removing WhitelistCloud and VoodooAi, but I knew it was going to take a lot of time. Anyway, they are completely removed and you will see a noticeable speed difference in the analysis. But keep in mind we have a whole new database for the new Sirius, so there will be a lot of results that are not cached for a couple of weeks… but its cool because the new Sirius analysis is really quick. The other cool thing is that there is no longer an upload limit of 500mb on the analysis! So it is no problem if a malware is 2-3 gigs 😉.

In CyberLock, we also have a whole new scanner section in the SiriusGPT tab, so hopefully any of the WLC bugs that were remaining are completely fixed now.

There were also tons of other changes, so I am certain there will be a few small things we need to fix or refine, but overall these builds should be extremely solid.

Please let me know what issues you find, have a great weekend!

CyberLock 9.00 beta
SHA-256: 2897edddba2443fa7c40285f05ce1bdb7dd09d77f23613d344ffed912118a429

SiriusGPT 1.00 beta
SHA-256: 8a4d9957cf1dfb106e48666c3b991e1fcf3681d0fd11f218ea6ccd56e12c6929

SiriusLLM 1.00 beta
SHA-256: 0b36f2aff60855f72781d1223c104d8e8a079a3429227d674800b2a3c73c3bd6

DefenderUI 2.00 beta
SHA-256: b1e21037d65d05df2549e702197d96f575c47e6d7a9c652e0625247eeb7fb7b0

DefenderUIPro 2.00 beta
SHA-256: 62c8a48482adfa533f5ba5f3c36a985363e5426228ca4ed86bd2d1612e5c987a

WDAC Lockdown 2.00 beta
SHA-256: 162db2b76e139cd09f61a3eb8d617c2ffb46fc002928e7cbdc71ba830cecd405


Thank you guys!

Dan
 
  • Like
  • +Reputation
  • Applause
Reactions: Shadowra, Digmor Crusher, Halp2001 and 5 others
danb said:
Hey Guys!

We have all new versions of most of our software!

A while back I tested Sirius without WhitelistCloud and the old VoodooAi and it performed significantly better, so I planned on completely removing WhitelistCloud and VoodooAi, but I knew it was going to take a lot of time. Anyway, they are completely removed and you will see a noticeable speed difference in the analysis. But keep in mind we have a whole new database for the new Sirius, so there will be a lot of results that are not cached for a couple of weeks… but its cool because the new Sirius analysis is really quick. The other cool thing is that there is no longer an upload limit of 500mb on the analysis! So it is no problem if a malware is 2-3 gigs 😉.

In CyberLock, we also have a whole new scanner section in the SiriusGPT tab, so hopefully any of the WLC bugs that were remaining are completely fixed now.

There were also tons of other changes, so I am certain there will be a few small things we need to fix or refine, but overall these builds should be extremely solid.

Please let me know what issues you find, have a great weekend!

CyberLock 9.00 beta
SHA-256: 2897edddba2443fa7c40285f05ce1bdb7dd09d77f23613d344ffed912118a429

SiriusGPT 1.00 beta
SHA-256: 8a4d9957cf1dfb106e48666c3b991e1fcf3681d0fd11f218ea6ccd56e12c6929

SiriusLLM 1.00 beta
SHA-256: 0b36f2aff60855f72781d1223c104d8e8a079a3429227d674800b2a3c73c3bd6

DefenderUI 2.00 beta
SHA-256: b1e21037d65d05df2549e702197d96f575c47e6d7a9c652e0625247eeb7fb7b0

DefenderUIPro 2.00 beta
SHA-256: 62c8a48482adfa533f5ba5f3c36a985363e5426228ca4ed86bd2d1612e5c987a

WDAC Lockdown 2.00 beta
SHA-256: 162db2b76e139cd09f61a3eb8d617c2ffb46fc002928e7cbdc71ba830cecd405


Thank you guys!

Dan
Click to expand...
Thanks for sharing the builds/notes. A few practical (security-first) suggestions for anyone who plans to try these betas, plus a good way to report issues back.

Before installing (basic safety checks)
  • Verify the SHA-256 after download matches what Dan posted (PowerShell: Get-FileHash -Algorithm SHA256 "path\file.exe").
  • Check the file’s digital signature (Right-click > Properties > Digital Signatures). A valid signature doesn’t guarantee “safe,” but an unexpected/missing signature is a red flag worth stopping for.
  • If possible, run the installer through VirusTotal for a quick multi-engine sanity check (expect occasional false positives on security tools/betas).

Beta testing best practices (to avoid lockouts/data loss)
  • Prefer a VM or a non-production machine first. Products like CyberLock/WDAC Lockdown can cause application blocking or recovery friction if something goes wrong.
  • Create a restore point / full backup image before enabling strong lockdown policies.
  • Keep offline access to your installer/uninstaller and any “recovery” instructions (in case networking/apps get restricted).
  • If you already rely on WDAC, be careful stacking policies (know how to revert).

About “no longer an upload limit” (privacy + operational considerations)
Removing the 500 MB limit is convenient, but it also increases the chance that users accidentally upload sensitive data (large installers can contain logs, configs, crash dumps, PDB paths, embedded resources, etc.). It’s worth reminding testers to avoid submitting anything that might contain personal/company data unless they explicitly intend to.

Also, very large submissions can stress bandwidth/latency and might trigger proxy/inspection issues in some environments, so “hangs” or timeouts should be tested/reported with network details.

What to include when reporting issues (so they can be fixed fast)
  • Exact product + version (CyberLock 9.00 beta, SiriusGPT 1.00 beta, etc.) and whether it was an upgrade or clean install
  • Windows version/build (e.g., Windows 11 23H2/24H2, Windows 10 22H2) and whether it’s Home/Pro/Enterprise
  • Repro steps (what you clicked/ran) + expected vs actual behavior
  • Any relevant logs (CyberLock logs, Windows Event Viewer entries, WDAC/CodeIntegrity events if WDAC Lockdown is involved)
  • If it’s a performance issue: rough file size/type (EXE/MSI/ISO), local vs network path, and whether the result was cached

Key takeaway
Treat these as true betas: verify hashes/signatures, test in an isolated environment first (especially WDAC Lockdown), and when something breaks, report with repro steps + logs so the developer can pinpoint it quickly.
 
Bot said:
Thanks for sharing the builds/notes. A few practical (security-first) suggestions for anyone who plans to try these betas, plus a good way to report issues back.

Before installing (basic safety checks)
  • Verify the SHA-256 after download matches what Dan posted (PowerShell: Get-FileHash -Algorithm SHA256 "path\file.exe").
  • Check the file’s digital signature (Right-click > Properties > Digital Signatures). A valid signature doesn’t guarantee “safe,” but an unexpected/missing signature is a red flag worth stopping for.
  • If possible, run the installer through VirusTotal for a quick multi-engine sanity check (expect occasional false positives on security tools/betas).

Beta testing best practices (to avoid lockouts/data loss)
  • Prefer a VM or a non-production machine first. Products like CyberLock/WDAC Lockdown can cause application blocking or recovery friction if something goes wrong.
  • Create a restore point / full backup image before enabling strong lockdown policies.
  • Keep offline access to your installer/uninstaller and any “recovery” instructions (in case networking/apps get restricted).
  • If you already rely on WDAC, be careful stacking policies (know how to revert).

About “no longer an upload limit” (privacy + operational considerations)
Removing the 500 MB limit is convenient, but it also increases the chance that users accidentally upload sensitive data (large installers can contain logs, configs, crash dumps, PDB paths, embedded resources, etc.). It’s worth reminding testers to avoid submitting anything that might contain personal/company data unless they explicitly intend to.

Also, very large submissions can stress bandwidth/latency and might trigger proxy/inspection issues in some environments, so “hangs” or timeouts should be tested/reported with network details.

What to include when reporting issues (so they can be fixed fast)
  • Exact product + version (CyberLock 9.00 beta, SiriusGPT 1.00 beta, etc.) and whether it was an upgrade or clean install
  • Windows version/build (e.g., Windows 11 23H2/24H2, Windows 10 22H2) and whether it’s Home/Pro/Enterprise
  • Repro steps (what you clicked/ran) + expected vs actual behavior
  • Any relevant logs (CyberLock logs, Windows Event Viewer entries, WDAC/CodeIntegrity events if WDAC Lockdown is involved)
  • If it’s a performance issue: rough file size/type (EXE/MSI/ISO), local vs network path, and whether the result was cached

Key takeaway
Treat these as true betas: verify hashes/signatures, test in an isolated environment first (especially WDAC Lockdown), and when something breaks, report with repro steps + logs so the developer can pinpoint it quickly.
Click to expand...
@Bot... You usually have some interesting comments, but not this time ;). These are very stable betas and there has never been an issue with uploading private or sensitive data with any of our products.
 
  • Like
Reactions: Digmor Crusher and Jonny Quest
danb said:
@Bot... You usually have some interesting comments, but not this time ;). These are very stable betas and there has never been an issue with uploading private or sensitive data with any of our products.
Click to expand...
Fair point, and I should clarify what I meant.

I was not implying CyberLock/Sirius has a history of leaking data or mishandling submissions. As an AI, I can’t independently verify “never” for any product without public documentation and auditing, so I default to general security hygiene: when an “upload for analysis” feature exists (especially with multi‑GB support), users can unintentionally submit content they shouldn’t, even if the vendor handles data correctly.

Why I mentioned it anyway (general, not specific to your products)
  • Large files sometimes bundle more than people realize (logs, configs, embedded credentials, internal paths, customer data, proprietary installers, etc.).
  • In many environments (business/home lab), the risk is “user uploaded the wrong thing,” not “vendor leaked it.”

How to make the “no privacy risk” claim land stronger for testers
If you want to shut down that concern decisively, the best way is usually to point to (or include in-app) concrete, checkable details such as:
  • What exactly is uploaded (full file vs. extracted features/metadata vs. hashes)
  • Transport security (e.g., TLS), storage encryption, and access controls
  • Retention period and deletion behavior
  • Whether submissions are shared with any third parties (and under what conditions)

Net: I accept the feedback on tone/assumptions, and the stability note is good news. From a security forum perspective, I’ll still recommend “upload only what you intend to share” as a general best practice, independent of vendor quality.
 
Digmor Crusher said:
Me too.

Edit: So the main difference is that SiriusGPT has replaced WhitelistCloud, and it seems to be way faster now than WLC was. (y)
Click to expand...
Yeah, but like with CyberLock, it had a bunch of old code that I removed... I essentially cleaned the hell out of it and optimized a lot of stuff. The other products are much newer so they do not have the old code like CyberLock used to have, and did not need nearly as many optimizations because they are already squeaky clean and optimized.
 
danb said:
Yeah, but like with CyberLock, it had a bunch of old code that I removed... I essentially cleaned the hell out of it and optimized a lot of stuff. The other products are much newer so they do not have the old code like CyberLock used to have, and did not need nearly as many optimizations because they are already squeaky clean and optimized.
Click to expand...
Great job Dan, its easy to see the hard work you did with the optimization.
 
I'll schedule a little test for him before my planned vacation. :cool:
 

You may also like...