REVERSE TO REVOLUTiONiZE

LennarDigital.Sylenth1.v3.0.72.Incl.Patched.and.Keygen.READ.NFO

SUPPLiER : TEAM R2R
CRACKER : TEAM R2R

Santa cosplayed witches say,

Here is one of the most over-
protected synthesizer in the scene! It is
now fully keygened except RSA2048 key is
replaced to R2R one. (It's mathematically
nearly impossible to factor the 2048bit

Unlike legit version, our release
does not overwrite (hook)
ZwProtectVirtualMemory in NTDLL.DLL,
which is the MemoryProtect function
of VMProtect. It will make more
stabler than legit version.

Why did it take so long? Because we
are lazy witches! We had simpler crack
which enable sharing legit licenses since
V3 out. No one of us wanted to spend extra
time for the public release. Till. Now.

Merry Xmas, Check our extra protection
note below for the fun!

PROTECTiON NOTE - YEAH, YOU LiKE THiS!

There are 4 parts in the protection.

[1] C&R Protection by Lennard

This is the main protection. Classic Challenge & Response protection (or
Web Auth) using License File.

License File Structure for maniacs.

Size  Usage

0x004 Last 4 bytes of Config.xml magic value.
0x001 Current License Number.
0x001 Max License Number.
0x100 RSA2048 Encrypted Chunk.
0x100 Extra Protection Chunk.
0x004 CRC32 of (RSA2048 + Extra) Chunks.

After you activate, RSA2048 Chunk + Extra Chunk + CRC32 Chunk will be
copied to Config dir as "License.dat". Size = 0x100 + 0x100 + 0x04 = 0x204.

[2] Anti Search Encryption by Lennard

Most of the auth contents are encrypted. If beginner crackers are trying to
search the memory, they can find nothing. Everytime content is needed, it
decrypts before using. There are many en/decryption algorithm made by him.
They are not strong cryptography but it's enough to stop beginner crackers.

[3] AntiDebugs and SYSCALL by Lennard

Apart from the VMProtect, Lennard put many homemade antidebugs. One of the
interesting way is using SYSCALL instruction to detect debugger. We rarely
see SYSCALL in user application in 2022. SYSCALL is usually used in Win32API.
The behavior of SYSCALL is not documented by Microsoft. The argument
parameters for SYSCALL are different per Windows versions. If developer uses
SYSCALL, he needs to reverse certain Win32API and implement for every version
of Windows OS. When Windows has new update, application may stop working.

See how different SYSCALL values are.
https://j00ru.vexillium.org/syscalls/nt/64/

[4] VMProtect

Yes, this is a main problem for crackers. Said to be one of the strongest
solution if it is used efficiently (but the fact is that many developers
dont!).

In Sylenth1 V3, following protection is performed :

- PE Protector : Code decryption at startup. All DLL calls are proxied.
Code modification will be detected at startup.

- Code obfuscation and virtualization : Code of authorization related stuff
is translated to un-disassemble-able one from Intel x86 or AMD64 opcodes.
This will kill any CPU optimization of compiler.

- Memory Protection : To block the memory attack from the hacker, VMProtect
overwrites and hooks ZwProtectVirtualMemory in NTDLL.DLL (very important
system DLL). After that, typical Win32API like VirtualProtect will be
controlled by VMProtect. Of course, this behavior is incompatible with
any other plugins doing the same hooking approach. When it happens,
application may crash when ZwProtectVirtualMemory is called.

The VMProtect usage in Sylenth1 is enough efficient (unlike some others lol).
But that is an aspect of anti-piracy. The protection behavior do has serious
side effect. Especially, hooking NTDLL is obviously crazy for 1 audio plugin.

Example of API hooking crash syndrome by overdoing protections:

https://vi-control.net/community/threads/make-my-own-cubase-ilok.81969/
https://www.kvraudio.com/forum/viewtopic.php?t=465317&start=15
https://www.kvraudio.com/forum/viewtopic.php?t=442754

NOTE : PACE already deprecated hooking CreateThread 5+ years ago.

While VMProtect has good reputation to protect the software, it is not made
for plugin system, which one EXE loads tons of DLL made by many developers.
It is not possible for VMProtect to offer their best protections while
keeping the compatibility and stability.

Summary : What R2R think

There are many homemade protections inside Sylenth1. It is also VMProtect-ed.
However, an experienced cracker who can attack to VMProtect will not be
bothered by those homemade protection. Considering that those homemade ones
have lots of side effects for performance, developing, compatibility
(especially the SYSCALL), there are no good reasons to do that. It is not
year 2005. Lennard seriously needs to update his knowledge to catch up.

Using VMProtect is OK. His choice. But hooking NTDLL.DLL is not acceptable.
Because Mac is now ARM based, and VMProtect supports Intel CPU only, we
don't think VMProtect is a good choice for protecting Win/Mac hybrid audio
applications in 2022, especially after we made keygen for all part except
RSA2048. Nothing need to be obfuscated or virtualized anymore :)

Next Scenario : Fastidious legit users start using R2R version because it
has less issue caused by DRM.

Time Waste Table for Cracking Sylenth1

0.5 (Man-Day) for checking protection.
1.0 for cracking protection in the debugger.
1.0 for coding sweet tools for VST/VST3/AAX.
0.5 for coding keygen.
1.0 for final testing and fixing for extra checks

About 30 Man-Hours. Ask Lennard whether it's shorter or longer than he
expected.

Is Xmas over?

"Yes it is." A witch said, and she explained they spent expensive shipping
expenses to deliver Syntronik2 library this year. They didn't have enough
money to hire more sexy santa witches.

One day, a man came to my house and said "Would you like to buy these gongs
for $29?"