With the release of RAD Studio XE3 Embarcadero made changes to the IDE’s copy protection. Those changes are ineffective because they are a no brainer for those who crack the software. Despite this the changes cause the IDE to start much slower. Even on a SSD you feel the difference between XE2 and XE3. And on a HDD you can get almost 2 cups of coffee while the IDE starts.
The updated copy protection loads every DLL file that is in the $(BDS)\bin directory into memory to verify (WinTrust.dll) that it is a correctly signed DLL and then unloads it again. The higher your SKU is the more DLL files you have, the longer you have to wait for the IDE to start. That wouldn’t be such a huge problem (for me) if the IDE would be stable as a rock. But we all know the IDE. And if you develop IDE plugins, you restart the IDE frequently. While I work on my plugins I spend most of the time waiting for the IDE to start. And I can’t drink that much coffee.
Why is it a no brainer for Crackers? Well, they know how to inject a DLL. And verifying that the DLL on disk is correctly signed has no effect on the already loaded DLL. Windows doesn’t load DLLs again if there is already one with the exact same name in memory, even if the DLL is in another directory. Alternatively the Crackers can sign their DLL and be happy. So where is the additional security from this? The only thing I can think of is that Embarcadero saw that their IDE starts much faster now and that they don’t want the IDE to start fast.
Why should I make the IDE faster and faster with my IDEFixPack if Embarcadero tries to slow it down? And no, I won’t tamper with the copy protection. Embarcadero is the only one who can remove this useless and ineffective change in the copy protection legally.
From the FindFirstFile call that reads all files (why all and not just the DLL files? Well that’s the problem of IOUtils.TDirectory.GetFiles) to the last CloseHandle call.
CPU: Core 2 Quad Q6600 @ 2.4 GHz
SSD (bds.exe on virus scanner’s exclude list):
HDD (no virus scanner installed):