Another FM video with cracked Sylenth. ...and Martin Garrix.

[billcarroll]

thank you.
i love you too!!!
now we must get used to it,the industry is promoting warez,maybe it feels a bit unusual but it is certainly the way to go,no?

Holy shit!!! Reading your post puts things in a different light!!! You might be on to something here. Maybe I missed the fact that this is the future and there's nothing we can do about it except roll with it because there is a behavioral trend of which at one time was unthinkable but now there are forces of fate working around us stating that it is an accepted practice in this day and age. Hell we don't see Orange Force or any of those guys on here bitching about it. But yet I'm ready to take up arms against this guy who represents the future. Maybe he's right and I'm wrong. Maybe all these successful cracked software using producers are the hip futuristic forward thinking leaders of tomorrow, and me the knight in shining armor with morals has been made into the dinosaur by way of changes around us that I refused to see. Thank you tee three tee succeeded by four o's. You have aligned my thinking with your purest form of logic which I embarrassingly overlooked. I bid you all farewell from this thread for I Sir Orbit-50 bow to the future of change. I will say no more on this subject.


.-.

Hi Sir Orbit-50
Sorry to go off topic, but since you mentioned me specifically (Orange Force)
I won't be "bitching about it" here because I no longer work for Ohm Force...

Anyway, one interesting fact that I learned during my years at Ohm Force about these successful DJs/Producers is that many of them don't want to spend their time buying and installing plug-ins. Instead, they hire one (or more) assistant to take care of all that.
I could be wrong, but I'm pretty sure that these successful "artists" aren't even aware that they're using pirated softwares sometimes.

I had no idea this is a stolen car officer .... Plausible stupidity or or just theft? Most, if not all, of these producers know they are stealing.

[Uedi]

...

[Uedi]

...

[billcarroll]

Anyway, one interesting fact that I learned during my years at Ohm Force about these successful DJs/Producers is that many of them don't want to spend their time buying and installing plug-ins. Instead, they hire one (or more) assistant to take care of all that.
I could be wrong, but I'm pretty sure that these successful "artists" aren't even aware that they're using pirated softwares sometimes.

that assistant excuse was given by aoki. according to wiki he is active since... 1999.
I would expect that someone like that should be extremely meticulous and careful about his studio, and software installations. but no, he's just very good at caking and champagne showers.

Aoki's father, who was a white collar criminal who pled guilty to insider trading, was the founder of Benihana and incredibly wealthy. No shortage of cash or excuse there for pirated software. Aoki does have a seriously hot sister though, so he's got that going for him.

[Urs]

Actually, also, we don't seed the cracks. The cracks are cracks cracked by crackers, they're not fake cracks seeded by us. We just add extra demo limitations that only work if the software detects that it is actually cracked.

Hah.

So the piece of code that detects if it's cracked doesn't itself get cracked? I just can't see how you make it work against the omnipotent, omniscient powers a cracker has. It's like bringing a knife to a gun fight and opponent gets to delete your knife.

There's two things that makes a cracker omnipotent: Their toolset, or their Savant Syndrome. As I doubt that a skilled infividual with latter would have missed the most embarrassing date check in ACE, I suspect it's former.

We had a very close look at their tools, and we've learned to use them to reverse engineer their cracking methods. We also developed a concept where these don't work. A quick rundown:

- moder disassemblers make any algorithm a piece of cake to crack. So distribute the copy protection across many regions of code, not just one, and make sure that much of those bits are used by the software's feature set (lots of calls in and out provide for a call trace nightmare)

- Crackers use system calls and identified regions as landmarks, and then identify code that is specific to CP. So don't use any system call (and strlen, strcmp, that stuff) just for cp, always wrap system calls (abstraction) and also use them for features within the software

- make as much as possible of CP event driven, so that static binary analysis is useless, make it crackable only at runtime (change toolset from disassembler to debugger)

- Crackers love to trace memory access and set breakpoints. Take that away by storing decrypted serial/keyfile in 100+ objects, and access that stuff randomly for useful thigs such as seeding pseudo random generators

- on an abstract level, move CP from program flow to a data model

- then, create a matrix of possible methods of cracking, possible methods of detecting those and possible triggers for delayed checks. Then fill the matrix with possible "invitations to buy" to make sure every case is covered on at least two positions. As each of those should reuse existing code (e.g. to display a message on the GUI) each trigger, detection and demo limitation should not exceed 10 lines of code. 10 time bombs with up to 30 lines of code should do, and provide for a strong secondary protection layer to meet the omnipotence of crackers specialised in audio software plug-ins (Team Assign typically found 2-3 time bombs, R2R circumvented 4 by surprise, before we did the matrix properly)

There you go. The myths of undefeatable crackers have become rather entertaining. I used to get frustrated when people preached myths of crackers, but nowadays I'm happy to let them have their believes.

- Urs

(also, any developer looking for more specifics, we still run that secret developer forum, but you need to have commercial products on the market to get access. Most information is there.)

[aciddose]

Another tip is that you can use more advanced tools during link, allowing you to for example, build "stub functions" which do not push/pop the stack and utilize conditional jump instructions between themselves, driven by the data. This becomes impossible to analyze statically or dynamically if the controller is a "true random" source.

It isn't even possible to disassemble reliably if you fold data unaligned inside the code, between valid instructions.

Best experience is by cracking stuff yourself btw

I think one of the biggest hurdles you can throw is merely by switching from ancient procedural c code to fully dynamic oo c++. Of course I consider this to take "zero effort" but only because I see the benefits of this style of code as far more important for completely unrelated reasons.

My first step when reversing is to begin labeling objects and procedures based upon any information linked to them. You only need a single system call or string to get the process started, at which point it is game-over. By making the CP code both dynamically triggered and non-procedural in combination with a complete lack of any identifying components (strings, common addresses or offsets) that definitely throws a wrench into the crack machinery.

[DavenH]

(also, any developer looking for more specifics, we still run that secret developer forum, but you need to have commercial products on the market to get access. Most information is there.)

Thanks for the specifics. Makes me amused to think Team AiR probably browses these forums for ideas, and our devs browse theirs.

Secret dev forum huh, never got that invite. Some day I'll be cool enough.

[DavenH]

My first step when reversing is to begin labeling objects and procedures based upon any information linked to them. You only need a single system call or string to get the process started, at which point it is game-over. By making the CP code both dynamically triggered and non-procedural in combination with a complete lack of any identifying components (strings, common addresses or offsets) that definitely throws a wrench into the crack machinery.

I do understand most of the (anti) reversing concepts. But supposing you used every trick in the book, a stumbling block I couldn't find any solution to is how would you conspicuously persist data regarding the authenticity of a plugin, if it only performs validation rarely. I thought maybe steganography, but any file system change would be easily found with a diff or some other tool.

[aciddose]

You can't, this is all just obfuscation. Of course it is easy to obfuscate beyond the ability of a human to deal with however tools will continue to evolve. The real question is exactly how sophisticated will crackers become? Well, very. It's an arms race with no end in sight. What has been discussed here are some of the most obvious "easy for author, hard for cracker" solutions but ultimately these are all simply obfuscation. If it can run on the system, it can be broken. Simple as that.

The solution for audio software is reaching the point where it is no longer worth the effort of the cracker at the level of sophistication required to deal with it. Fortunately for us, this is quite low. Most crackers do what they do for fun and it is quite easy to make it no longer much fun.

[dune_rave]

As aciddose wrote:
"How do you know he hasn't bought a license and just uses the cracked versions because it's more reliable?"

And yes, there's a possibility, that he owns a license, still the software he uses on the Youtube video is a cracked one.
How could this be? Suppose none of us keeps all the softwares up to date day by day.
There are several reasons to stick to an older version, including you don't know if you install over an existing instance, what happens..

[Urs]

The solution for audio software is reaching the point where it is no longer worth the effort of the cracker at the level of sophistication required to deal with it. Fortunately for us, this is quite low. Most crackers do what they do for fun and it is quite easy to make it no longer much fun.

That's exactly what I believe.

[crimsonwarlock]

The solution for audio software is reaching the point where it is no longer worth the effort of the cracker at the level of sophistication required to deal with it. Fortunately for us, this is quite low. Most crackers do what they do for fun and it is quite easy to make it no longer much fun.

That's exactly what I believe.

It is a clear fact that there are no physical locks (door locks, etc.) that can not be picked or broken, but that they are meant to make the task of getting access too big of a hurdle in relation of what could be gained.

Same thing

[Urs]

It isn't even possible to disassemble reliably if you fold data unaligned inside the code, between valid instructions.

I've been wondering about that, doesn't IDA Pro usually catch that stuff?

[chk071]

The solution for audio software is reaching the point where it is no longer worth the effort of the cracker at the level of sophistication required to deal with it. Fortunately for us, this is quite low. Most crackers do what they do for fun and it is quite easy to make it no longer much fun.

That's exactly what I believe.

I'm still quite stunned about the amount of work you put in anti piracy measures. Would be a good idea to think about making it available for others too, as i can't imagine every developer being able and willing to put so much effort in it.

[aciddose]

It isn't even possible to disassemble reliably if you fold data unaligned inside the code, between valid instructions.

I've been wondering about that, doesn't IDA Pro usually catch that stuff?

No, which is actually what inspired it. IDA fails horribly at this, at least in the demo.

It depends on the alignments you use for data, but if you pick things the right way you can make it impossible for it to determine what is or is not code, as the valid data is also valid code in that position. If you also pad stub functions with garbage it will lose the ability to start decoding the data as code and you'll get get a lump of data, sometimes extending way beyond into "normal" code regions. Exceptionally frustrating when reversing and needing to step through with the debugger to mark data as code. Of course by calling the stub functions at random through a hash you can create situations where stepping through is impossible.

Of course it's related to the halting problem.