This reminds me of Cubase 3 (software for music production). In 2005 the scene group H2O needed 1500 manhours for cracking it, from their NFO (iNFO notice from

This reminds me of Cubase 3 (software for music production). In 2005 the scene group H2O needed 1500 manhours for cracking it, from their NFO (iNFO notice from the scene group about the release) for Steinberg.Cubase.SX.v3.0.2.623: H2O does it again.........!!! Although everybody thought that Syncrosoft and Steinberg had found the ultimate protection, we prove otherwise. We admit that it's getting harder and harder to do and this one may possibly be the last one we do. Due to the complex nature of the protection we thought of approaching it from another direction. The Emulation is now done on driver-level, which means that the Emu essentially mimics a dongle, look in the License Control Center to view the applications the Emu supports. By writing the Emu at driver-level we probably went beyond cracking an application. The amount of effort invested in this project is staggering, estimated at over 1500 manhours during cracking, developing & testing, and probably will never be done again. (...) Note to protection coders: Unbelievable way you transform an application. We estimate that between 30% & 40% of the application are wrapped in the script protection. Protection is one thing but this surely effects an application performance. You probably could get a performance gain of 50% without the protection!! NFO for Steinberg.Cubase.SX.v3.1.1.944 has more details on the way the protection works and its impact on performance: Note to Steinberg/End-Users: It seems that our prior Release Note stirred something in the Audio Community (Yes, we can read). To get some of the facts straight we're going to reveal some secrets about the copy protection itself, and why we stated that it severely impacts performance. Info from Syncrosoft website: [QUOTE] "Syncrosoft's protection solution is different from mainstream software copy protection methods. It is based on a secure executer, the eLicenser, and the patented MCFACT technology" "At runtime, the transformed program code does not reveal its semantics. The eLicenser's crypto-services are called from time to time by the transformed program code." "The transformed program code is represented as tables in the computers memory. An adversary can not reverse- engineer or debug the tables, because a reverse transformation from the tables to original program code is not feasible. If the tables are manipulated, the transformed program code will crash or produce invalid results."[ENDQUOTE] So it's not crackable?... Now here is the explanation for what really goes on: Transformation is based on replacing ordinary machine code into tables representing results from calculations Example: Adding 2 numbers. Normal machine-code would look something like: Add eax, ebx This will take 1 CPU cycle to execute. Now comes MCFACT: 1) Transform the first number into a table 2) Transform the second number into a table 3) Do allot of manipulation of these tables 4) More manipulation 5) Transform the Tables back to the numbers 6) Add the 2 numbers This entire piece takes up hundreds of machine code lines and a lot of loops inside this code...estimated CPU-cycles <insert number greater than 1 here> No performance loss? We don't think so.......... And this code runs all the time!!......The dongle in fact is only called 1 out of 10 times inside these scripts......... A good example is the protection build in the midi- part. This is entirely wrapped in the script-crap. Try moving a note and swirl it around.....you should notice a sluggishness in the movement. In fact u will notice an improvement in version 3.1 prior to the 3.0 release. This is not due to improvements made by Steinberg (the midi-engine is still the same) but improvements made by Syncrosoft! (They optimized the script engine)!!!!!!! To give the end user some peace of mind: the scripts aren't built into the real-time audio-engine.....this is impossible because of the performance loss u would have from the MCFACT.