Many of the readers must have read my former article DevExpress Build #48: A Haunting in Nevada and earlier article DevExpress Build #48: security analysis.
Illegal users
Since the last two blog posts, DevExpress has taken certain security measures to prevent illegal users from using their DevExpress VCL products and more security measures.
Since the last haunting, your reviewer looks at certain security measures DevExpress has put in place and advises more security measures to prevent illegal users from using DevExpress VCL products.
Will it stop the Fiend and his friend DarkCraptor?
It will take a long shot to stop them, but the current Build #50 has positive steps to prevent the Fiend from sharing his DevExpress license with the whole world.
Your reviewer suggests:
Change the AES encryption algorithm slightly and changing keys on every build.
While the AES algorithm used to secure the DevExpress payload containing sources is secure, the key used is symmetric. Meaning, that the key did not change from Build #49 to Build #50. Thus, the Fiend could re-use his old unpacking codes on the newer version with little effort. Changing the AES encryption a little will raise the bar: It would require some serious coding to reconstruct the customized AES algorithm and unlock codes to unpack DevExpress payload.
Take out the start/stop code comment markers.
Your reviewer found certain comments fashioned in a manner which could expose how the code re-ordering works. If someone re-formats the sources and observe closely, there are certain markers which expose the where the start/stop of the code re-ording segments are. Take them out, pretty please.
Start to watermark the demos and help files.
Think about it... Since the demos and help files can be put in the customer's download section (hint: make it harder for illegal users to get help) why not watermark the files? It would be fun to put some "extra" information before the download process starts and then monitor "certain" forums for these files... download it and remove the user. 'Nuff said.
Webservices download instead and in-memory DLLs
Since few builds ago, DevExpress started to use in-memory DLLs. Here's a step further: Download extra DLLs in-memory from the DevExpress license service and then execute them on-the-fly, like extra decryption modules, and extra protection modules.
Watermark other files
Your reviewer thinks adding a couple of WaterMarked EXE files raises the bar further. Since there's a skin configuration file, why not watermark the EXE and then encrypt the EXE file?
Consider some files to be non-source and with watermarks
Your reviewer thinks it will be joy when ebars.pas, dxskin.pas are no longer distributed and only available in DCU versions. The other codes are available. That will raise the bar a little since it's a bit harder to remove DCU watermarks.
Download on demand
Your reviewer thinks: No payload. Download on-demand what the user licensed. That would be wonderful idea.
Find another vendor other than VmProtect.Ru
Your reviewer looked at many of the security features offered in VmProtect.Ru (VMProtect is used to encrypt the current DevExpress build #50 setup) and found it was garbage and toy copy protection. It will stop the casual hackers... but it may not be sufficient to stop a crap.
Your reviewer received certain emails about the last posts -
Fan Mail: The ***** us all trip
Your reviewer will continue to annoy a certain segment of the Delphi community.
Fan Mail: Tips for other Delphi Developers
Your reviewer hopes other vendors find these tips to be valuable to secure their products.
Conclusions
Since the last two builds, DevExpress has raised the bar, doing interesting watermarking, like re-ordering source code files, to the annoyance of some customers, but a necessary step to prevent software piracy. Your reviewer, a licensee of DevExpress products, hopes these suggestions will greatly deter cheat and lying Delphi developers.
7 comments:
Fan Mail: The ***** us all trip
Your reviewer will continue to annoy a certain segment of the Delphi community.
not annoyed, just amused
Fan Mail: Tips for other Delphi Developers
Your reviewer hopes other vendors find these tips to be valuable to secure their products.
won't work
cya 'round
hi there,
Already with build #50 the methods DevExpress uses are very good to deter many would-be Delphi developers from releasing their licensed version of DevExpress.VCL product.
The only person to release it today is this DR person. The suggestions I have put forth and suggested will stop him fully.
And if the DR person is seeing this, ask him to break Add-in-Express copy-protection. He can't do a shit about it.
If DeveloperExpress implements watermarking on download itself, like Add-in-Express, there will be some dark humor...
Could it be? No more cheat and lying Delphi developer who has not paid anything to DevExpress for a license cannot use DevExpress VCL product any more? It is coming true very soon :)
I understand your points and, as a developer myself, i can't approve those attempting to sale software without proper licenses but we must agree, subscription schemes are killing small software vendors, they simply can't afford development costs that's what most people are seeking in cracked components today: development time
"Your reviewer", it seems, is losing his mind. His entire blog is based on the premise of hating Delphi, and now his latest rants on how to help DevExpress protect their source code. What an absolute joke.
If "your reviewer" was as smart as he believes himself to be, then he would know that there's NOTHING that can be done to prevent components from being copied/spread/leaked. I will repeat that once more, in case "your reviewer" is too obtuse to understand: there is NOTHING that anyone can do to prevent software from being copied/leaked/cracked.
You can rant and rave all you want about encryption, but the more you do it, the more it shows your ignorance. "Watermarking" is the brainchild of utter idiots, because it does absolutely nothing except create 5 or 10 minutes of extra work for someone to find it and remove it.
Component developers make their money by selling SOURCE CODE. You can't protect source code if you have to give it to your customers.
With all the time WASTED on these efforts, try and imagine how much better a developer's software could be if he spent that same amount of time on improving his software rather than wasting his time trying to "protect" it.
The more you try to "protect" software, the more inconvenience you create for your PAYING customers. If you want a perfect example, look at the the latest fiasco created by Ubisoft. Their "uncrackable" protection scheme on Silent Hunter 5 was cracked in 15 minutes.
People who actually PAID for the game are required to run it on computers with an active internet connection. Without a live connection, they can't play the game. Meanwhile, a cracked copy can be played on ANY machined, connected or not.
So what did Ubisoft accomplish? Absolutely nothing, except pissing off a great number of customers who have vowed never to BUY another Ubisoft title again in the future. Think of all the hours and days spent on this idiotic "protection" scheme, and think about the fact that it was cracked in a few minutes. Think of all the bugs that could've been fixed during all those hours and days that were wasted on "protecting" the software.
What an absolute joke.
Conspiracy theory:
Hi war,
I'm sad to see your rants removed on a certain forum?
:)
Hi warzone_74,
I see you are busy leeching-up DevExpress v50, TMS libraries, recently - Greatis component suite, AppControls, and many other libraries there. The joy of having so many benefits and not paying for them.
Spare a thought for those who work hard, for what seems to be zero wages.
Even flipping burgers can earn more more than being a Delphi developer. Do you agree?
:)
Oh sorry, I have post to wrong discussion topic.
Vmprotect is designed to virtualize selected part of binary code. It is not mutation of one Intel ASM instruction to set of other Intel ASM instructions. Each Intel ASM instruction converts to instructions of virtual processor. The virtual instruction is unique to each build of the protected application. Virtualization processor is not based on Intel or RISC architecture. So you can not use usual tools(debugers and decompilers) to analyze virtualyzed code. Virtualized code allows to hide program logic and prevent patches of the Virtualized code. Also VMProtect allows to encrypt selected virualized code with symmetric key. The main problem of virualization technology it is slow down execution of the virualization code (So you can not virtulize all protected application). The other problem antivirus vendors also cannot analyze virtualized code created by VMProtect and this feature widely used by virus and malware developers (This cause false positives to normal application protected by VMProtect).
So It is NOT toy technology. As I know there is no working tool that allow to convert VMProtect virualized code to Intel ASM instruction.
Post a Comment