Your reviewer found a superb example of watermarking. Your reviewer call this "Total Code Reordering", where the Implementation part of the unit is totally randomized and watermarked. This deterred some people from releasing vendor's source codes.
Who should use this?
The first person your reviewer thinks should use this is Mr. Michael Philippenko, the Fast Reports vendor. The watermarks are always removed from the files and files made public. Your reviewer won't say how exactly FR source codes are watermarked, but with this technique, Mr. Michael Philippenko can trace down who exactly leaked Fast Reports next time.
Same goes for LMD, TMS, and other vendors who sell with source codes. With the latest version of TMS, files are watermarked, but this technique goes one step further -- with all files randomized, it becomes impossible to do a "difference" search between each version to remove the watermarks in those files.
Source code preparation.
1) Split the source-codes into interface and implementation. Make a program to make 1 procedure or 1 function as 1 line entries.
2) Encrypt the files using AES with a strong key. Make sure you do not embed the key in the EXE file.
Source code install:
1) On decrypt the file, since each line = 1 entry, translate the key into an ordered scheme where you can reverse or work out back who leaked the source codes
2) Reorder the implementation section and combine with interface. It will compile since a procedure can be anywhere inside the implementation section.
3) Add your additional watermarks, etc.
4) Run the GExperts code re-format in-memory where new line on begin, new line on end option and statements on each line makes the source codes readable again and then save result file to disk.
On Software Pirate's PC:
The software pirate using Fast Report source codes is dying to release the source codes but needs to remove the watermarks. Since the source code implementation section is randomized, the compare shows many, many changes and since comparing it takes long time (have to trace many changes including new features, etc.), that frustrates software pirate and since he paid it with his money or fake credit card/ (or begged for it from vendor).
Your reviewer pays, pays, pays, the free-loaders don't. Now they will...
Every year, your reviewer pays for the licenses, there are lots of Delphi developers who have very high morale and donate lot of money to Church, etc. but do not know what the left-hand does and what the right-hand do and deny about it. These Delphi developers cheer the vendors for releasing new products, but sales are very slow.
Now that knowledge of this technique is made public, almost all the vendors will certainly implement this scheme to protect their source codes.
What will happen...
1) Developer sales will start to jump from 1's, 2's, 3's to maybe 50 or 60 copies per month.
2) With strong sales, more people get hired.
3) People will think twice about leaking source codes out.
4) Vendors who sweat blood and tears to make new products will not face what is happening today - Ruin and famine with no end in sight.
5 comments:
While I do understand your point, as a vendor one also needs to keep the customers in mind and some DO change stuff in the sources of components. With randomizing this will become an utter nightmare. And yes, bad componet design makes that even more an issue as customers can't create descendants instead. BUT even on well designed component the need arises sometimes to actually change code, especially with visual ones (and taking the cumbersome visual inheritance of modern IDEs into account).
So, not an issue for some component sets, big issue for others. In short there's unfortunately not one solution that fits all.
Personally I wouldn't like to see TMS or DevEx put something like this in place as it would make my job (as customer) of maintaining versions significantly harder.
(just my thoughts)
Yeah, great. The problem of Delphi isn't that after years of "improvements" the product isn't even worth pirating anymore. It's the lack of DRM!
Yeah! Scramble the source. And give hell to those pesky pirates and their fancy version control systems. Anyway who except pirates needs to fix bugs and write patches anyway.
That's quite easy to defeat. The pirate just has to reorder the methods by their name alphabetically, problem solve ;)
There are much more techniques than scrambling the source.
Additional you can change fixed numbers in statements to hex, octal or decimal and watermark it.
There are techniques which uses Tabs, Whitespaces and empty LF's.
Function names and reordering aren't neccessary. The techniques above aren't disabling bugfixing.
Hannes,
the vendors you mentioned are implementing parts or *all* of the copy-protection schemes that are mentioned on this site.
:)
Post a Comment