At first I doubted this, because it’s been discussed for some time now that neither 4 nor 5 were ever successfully cracked. But it appears you are right. I’m wondering what other option are there – is “challenge-response” feasible? Or is iLok a better protection? One likes to think that talented engineers could invent an effective protection scheme…but then of course equally talented hackers are always gonna be able to crack it
The more you try and make code inaccessible to hackers/crackers the more you make it inaccessible to the legit user. This was the case with Cubase SX2, SX3 and early versions of 4.
Peppered with so many dongle calls on audio engine operations that many things took what seemed like forever to happen. Especially as the time delay was compounded with ever more complex projects.
It’s like having 20 padlocks on each door in your house. You’ll never get burgled but life will hardly be worth living there.
Maybe so Paul Woodlock but Steinberg make very stable apps and personally I don’t care how long things take so long as they work and I don’t lose my work.
It has gone far beyond “dongle checking”. There was a point in the SX cycle where it would take 3 or 4 seconds to “authenticate” when you click the ‘e’. It has improved, but it is still intrusive. The part that pissed me off was the borgz denying that it was the dongle. Even after it was proven with sniffer traces, the best we got was “dongle optimiation” comment or some such. No admission of how intensely overused the dongle calls were. I don’t recall that they ever acknowledged the dongles affecting Cubase performance, even though it was obvious. Anyhow, that’s a rant from long ago and far away.