Cyph Crypt v3 — PE loader & obfuscator

$450 for a month? That's steep even for this market.

What's the difference between this and open-source donut/hazelnut loaders that do essentially the same thing for free?

Also, syscall rotation isn't new — every AV has signatures for that pattern now. What's your actual differentiation? Serious questions before I consider spending that kind of money.

@trapice

$450 for a month? What's the difference vs donut

Fair critiques. Open source loaders (donut, etc): public signatures within 48 hours of release, no active maintenance, flagged by Windows Defender behavioral ML immediately.

This tool: private stub generation (each license gets a unique compile with unique constants), active maintenance (I update hash rotation schemes when detections increase), bypasses AMSI/ETW by default (disabled in donut), includes anti-sandbox checks.

Differentiation isn't the syscall method — it's that the tool generates unique stubs per license. Your builds won't match other users' builds. $450 reflects development time + maintenance. If that's too expensive, this tool isn't for your use case. Budget options exist elsewhere. Not claiming revolutionary tech. Claiming private, maintained, and functional.

Was part of closed beta (Dec 2025 – Feb 2026) for this tool before public release. Findings from 40+ builds:

Works as described. Generated stubs are unique per license — I compared section hashes with another beta tester, completely different.

Detection timeline (Defender): build date Dec 20, first detection Jan 8 (19 days), unusable by Jan 15 (26 days). That's actually decent lifespan for an automated tool.

Issues: initial version crashed on payloads over 5MB (fixed in v3). Syscall rotation broke on Win11 22H2 (fixed in update). License activation fails if you change GPU (HWID issue, vendor provided reset within 24 hours).

Verdict: pricey but functional. If you're doing 10+ files per month, cheaper than per-file services. If you're doing 2–3 files, overkill.

Question about the AMSI bypass implementation:

Does your tool patch amsi.dll in memory at runtime or does it use the amsi.fail style method of just returning AMSI_RESULT_CLEAN?

Also, does the obfuscation maintain Authenticode signatures or strip them entirely? Wondering if the output maintains valid MS signature appearance.

@rdtscp

AMSI bypass / Authenticode

AMSI: runtime patch via NtWriteVirtualMemory to patch functions in amsi.dll. Not the fail method — that pattern is heavily signatured now. Specifically patches AmsiScanBuffer to return AMSI_RESULT_CLEAN (0) via inline hook. The patch is applied in newly allocated memory, not inline in the original function (reduces detection).

Authenticode: stripped entirely. The tool outputs unsigned binaries. Attempting to maintain signatures through obfuscation is pointless — they'll be invalid immediately. If you need signed appearance, we offer optional catalog signing as an add-on ($50 per build, not recommended).

Bought 1-month license yesterday. Payment confirmed via escrow.

Downloaded installer, extracted, ran CyphCrypt.exe: Error: MSVCP140.dll not found. Already installed VC redistributables 2015–2022. Tried VC++ 2019 specific. Still same error. Running Windows 11 23H2 clean install.

@int3loop please advise. License active but can't use the tool.

@kuser

MSVCP140.dll not found

Known issue with dependency versioning. Tool was compiled with specific VC++ 2019 build 14.28.29914 which is newer than “latest” redistributable.

Solution: download link sent via PM for the exact required runtime. Alternative: use the portable version (no install, extract and run, includes all dependencies). Portable version upload sent via PM — not posting binaries in the thread.

Will update OP with the correct runtime requirement. Apologies for version confusion. Escrow release approved? Mark as delivered once you confirm working.

Portable version works. Tool launches correctly.

First test build successful. VT result: 5/72 on a fresh stub (day 1). Marking escrow as delivered. Product functional as described. Thanks for quick support (6 hours).

Bought 3-month license after watching the thread for 10 days.

Installation: smooth (used portable version). Interface: basic but functional (file browser, options checkbox, build button). Build time: ~45 seconds. Output: test payload executed successfully.

VT: before obfuscation 62/72 detected. After: 7/72 (acceptable day 1). Re-scan after 5 days: 19/72 (expected degradation).

The tool actually generates different stubs each build — confirmed by comparing two builds of the same input file. Section names, entry points, import tables all unique.

Previously skeptical due to high price. After testing, pricing is justified if you have volume. One suggestion: add a preserve file version info option. Currently strips all version metadata.

v3.1 released (current license holders auto-updated)

• Fixed MSVCP140 dependency hell (required runtime included in portable now)
• Added @rcustall's suggestion: optional version info preservation
• Payload size warning for files over 10MB (unstable, not recommended)
• Improved error logging (logs to %temp%\cyph_err.log)

No price change for the current licensing period.

Roadmap for v3.2 (estimated April): DLL payload support (experimental), alternative syscall method (SysWhispers2 integration option). DLL support will be beta — likely unstable initially.

Builds failing with a specific payload type. Payload: .NET executable (obviously not supported per OP, but trying anyway).

Error: “Payload analysis failed: CLR detected”. Expected behavior, but the error message could be clearer. Suggest adding an explicit check and a user-friendly error: “.NET not supported” instead of a cryptic error code. Minor UX suggestion.

Monthly vendor compliance check:

@int3loop license bond status: current (0.4 BTC). Update frequency: confirmed (3 updates since Mar 15). Customer dispute resolution: 1 dispute filed, resolved via escrow in buyer's favor (acceptable).

Tool maintains Verified status. Reminder: all software sales require a clear TOS. Ensure buyers understand subscription vs perpetual license distinction.

Updated Terms of Service (added to OP).

Clarification on “unlimited builds”: fair use limit 200 builds per month. Exceeding the limit triggers a license review. Excessive use may indicate redistribution (prohibited). Most users avg 15–30 builds/month (limit was 10× above realistic usage).

Added per @btfid's UX suggestion: v3.1.1 hotfix — better error messages for unsupported payload types (.NET, ELF, etc).

Disappointed. License expired after 30 days as advertised, attempted to renew.

Renewal price: $450 expected. Actual charged: $500 (“price adjustment”).

@int3loop claims price increase to $500/month effective Apr 1, but this wasn't communicated when I bought Mar 16 at $450. Feels like bait-and-switch. Escrow dispute possible? I have screenshots of original purchase at $450.

@kptinote

bait-and-switch / $500 renewal

Fair dispute. My error in communication. Price increase WAS announced in thread (post #11, Mar 28) but buried in the changelog. Should have been a separate announcement post.

Resolution options: 1) honor original $450 price for your renewal (one time grandfather). 2) refund prorated difference if you paid $500. The $450 price was introductory launch pricing. Sustained development costs require $500/month ongoing.

Accept fault for poor price change communication. Will make future pricing adjustments explicit separate posts. Your choice on resolution method.

Accepted option 1 ($450 grandfather renewal). Appreciate vendor acknowledging communication failure. Separate pricing announcement posts would prevent this. Escrow dispute withdrawn.

Tool itself remains a quality product. Renewing at grandfathered rate. Warning to potential buyers: current price is $500/mo, not $450 as shown in some earlier thread posts. Factor this into ROI calculations.

75 days of continuous use (2.5 months on a 3-month license).

Pattern observation: the syscall rotation updates happen approx every 10–14 days. After each update, detection drops back to 3–6/72 range briefly, then climbs over 7–10 days. Update mechanism works. The vendor is actually maintaining the tool as promised.

Comparison to fire-and-forget crypters that never update: Cyph Crypt justifies the subscription model through active maintenance.

Feature request: scheduled build option? Queue multiple files for overnight processing? Currently building 20+ files at once takes significant time.

@pooltag

scheduled / batch builds

Batch processing feature added to v3.2 (released today): queue up to 50 files, auto-build with sleep intervals (random 2–5 min between builds to prevent pattern detection), output to a timestamped folder, error log for failed builds.

v3.2 also adds experimental DLL support (very beta). Known issues: only works with simple exports, complex dependencies often crash, recommended for testing only. Major features, same $500/month pricing. Current license holders get v3.2 immediately.

Reverse engineered the v3.2 stub (with vendor permission for a security audit):

Obfuscation quality 7/10. String encryption: XOR with per-build key (adequate, not exceptional). API resolution: custom hash (not standard libraries). Syscall method: HellsGate with rotation as claimed. Anti-debug: basic IsDebuggerPresent checks (easily bypassed, but sufficient for AV evasion).

No malicious behavior in the stub itself (good — some crypters backdoor their stubs). No phone-home or C2 communication detected. Builds are legitimately unique per license key. Section name generation uses a license-specific seed.

Verdict: clean implementation. Vendor delivers technically on promises. No magic but competent software engineering. Pricing fair for a maintained tool.

v3.2 bug report: batch processing fails if the queued file list contains spaces in filenames.

Example: “my payload.exe” crashes the build process. “my_payload.exe” works fine. Workaround: rename files to remove spaces.

@int3loop should sanitize input or enforce a naming convention.

@sysenter

spaces in filenames crash batch

Confirmed. Path parsing bug in the batch processor. v3.2.1 hotfix deployed. Fix: properly handles quoted paths with spaces. Also added input validation: rejects filenames with special characters that break processing.

Thanks for the report. This is why the subscription model works — continuous bug fixes vs abandoned software.

PRICING ADJUSTMENT NOTICE

Effective August 1, 2026: 1 month $550 (was $500). 3 month $1,400 (was $1,150).

Reasons: increased infrastructure costs (dedicated build server, CDN for updates), additional development time (hired second dev), market rate adjustment.

Current active licenses grandfathered at current rate until expiration. Early renewal option: current license holders can renew early at old pricing if renewed before Aug 1. Advance notice: 31 days. Questions via PM.

Renewed 3-month license early at $1,150 rate before Aug 1 price increase.

4 months of usage: 340 builds, average cost per build $3.38, average lifespan 9.2 days. Compared to per-file crypts at $140 each: this tool paid for itself 4× over.

The price increase to $550 is steep but justifiable given active maintenance. Comparison vendors charge $600+ with worse lifespans. Recommendation: buy before Aug 1 if on the fence. New price still competitive but old price was exceptional value.

Any progress on Linux ELF support mentioned in the March roadmap?

Currently have to use a separate toolchain for Linux payloads. Would prefer a unified solution. Understand if deprioritized — Windows market is the larger priority.

@zydis

Linux ELF support

ELF support: deprioritized indefinitely. Technical reason: Linux syscall architecture is fundamentally different (arch-specific syscall numbers). Would require a complete codebase fork.

Current focus: Windows stability (ongoing), DLL support improvements (out of beta by Oct), possibly macOS Mach-O (higher demand than ELF). ELF not on the 2026 roadmap. May reconsider 2027 if sustained demand. For Linux payloads, recommend dedicated ELF crypters.