[color=rgb(40,40,40)][font=arial]some of this is stuff i've learned over the years. some is lists of tips posted online. some is actual "how-to" or more precisely, "how they do it" info. some is descriptions of various methods implemented in specific AAA titles.[/font][/color]
[color=rgb(51,51,51)][font=helvetica]
my apologies to all for the unedited format. the info was requested in a thread, i didn't have time to clean it up first, but did want to share it.
[/font][/color][color=rgb(51,51,51)][font=helvetica]
these first 5 items:
[/font][/color][color=rgb(51,51,51)][font=helvetica]
[color=rgb(40,40,40)][font=arial]key cd[/font][/color]
[color=rgb(40,40,40)][font=arial]hack resistant code[/font][/color]
[color=rgb(40,40,40)][font=arial]hack resistant keydisc check - multiple checks - separte code for each check - not just one subroutine which can be hacked. all must be hacked.[/font][/color]
[color=rgb(40,40,40)][font=arial]hack resistant exe file (crc check, checksum, filelength check)[/font][/color]
[color=rgb(40,40,40)][font=arial]virtual machine code[/font][/color]
[/font][/color][color=rgb(51,51,51)][font=helvetica]
[color=rgb(40,40,40)][font=arial]is the basic DRM scheme i've evolved over the years. [/font][/color]
[/font][/color][color=rgb(51,51,51)][font=helvetica]
[color=rgb(40,40,40)][font=arial]the following section is highlights of my latest online research.[/font][/color]
[/font][/color][color=rgb(51,51,51)][font=helvetica]
[color=rgb(40,40,40)][font=arial]the next section starting with demo: and full version: [/font][/color][color=rgb(40,40,40)][font=arial]is a more detailed description of my drm method, followed by an analysis of its weaknesses and ways to strengthen it.[/font][/color]
[/font][/color][color=rgb(51,51,51)][font=helvetica]
[color=rgb(40,40,40)][font=arial]the next section starting with [/font][/color][color=rgb(40,40,40)][font=arial]most cd checks are cracked by using wdasm [/font][/color][color=rgb(40,40,40)][font=arial]describes how specific protections are cracked.[/font][/color]
[/font][/color][color=rgb(51,51,51)][font=helvetica]
[color=rgb(40,40,40)][font=arial]the next section is a list of the protections available in PC-GUARD (a typical 3rd party drm solution).[/font][/color]
[/font][/color][color=rgb(51,51,51)][font=helvetica]
[color=rgb(40,40,40)][font=arial]the final section from gammasutra is a description of the copy protection used in Spyro: Year of the Dragon for the PS1. Spyro YOTD didn't get cracked for two months after release.[/font][/color]
[/font][/color][color=rgb(51,51,51)][font=helvetica]
[color=rgb(40,40,40)][font=arial]
copy protection
[/font][/color][/font][/color][color=rgb(40,40,40)][font=arial]key cd[/font][/color]
[color=rgb(40,40,40)][font=arial]hack resistant code[/font][/color]
[color=rgb(40,40,40)][font=arial]hack resistant keydisc check - multiple checks - separte code for each check - not just one subroutine which can be hacked. all must be hacked.[/font][/color]
[color=rgb(40,40,40)][font=arial]hack resistant exe file (crc check, checksum, filelength check)[/font][/color]
[color=rgb(40,40,40)][font=arial]virtual machine code[/font][/color]
[color=rgb(40,40,40)][font=arial]serial number[/font][/color]
[color=rgb(40,40,40)][font=arial]delayed reaction to copy violation - makes it harder to find check code[/font][/color]
[color=rgb(40,40,40)][font=arial]generic error message: please contact tech support[/font][/color]
[color=rgb(40,40,40)][font=arial]use checkcode type procedure names for init var routines - if they hack it, the vars dont get init'ed. dont use checkcode type procedure names like keyCDok() for the checkcode. use something else meaningless or obscure.[/font][/color]
[color=rgb(40,40,40)][font=arial]dont use meaningful filenames like licence.dat[/font][/color]
[color=rgb(40,40,40)][font=arial]Add long delays. Don't warn the user right after a violation is made. Wait later, maybe until the next day or two (crackers hate that).[/font][/color]
[color=rgb(40,40,40)][font=arial]Add short delays. Pause a second or two after a password entry or to your other checking routines to make brute force cracking unfeasible. Simple to do, but rarely done.[/font][/color]
[color=rgb(40,40,40)][font=arial]Store serial numbers in unlikely places like as a property of a database field. Often heard and read: "..give it a DLL file name and store it in the System directory." Too often heard, don't use it. ;-)[/font][/color]
[color=rgb(40,40,40)][font=arial]Store serial numbers in several places.[/font][/color]
[color=rgb(40,40,40)][font=arial]Don't use literal strings that tell the user: "Sorry, but... (whatever)." These are the first things to look for. Build strings dynamically or encrypt them.[/font][/color]
[color=rgb(40,40,40)][font=arial]encrypted strings for "insert key cd", etc[/font][/color]
[color=rgb(40,40,40)][font=arial]Don't use validation functions. Every time you validate the user, write your validation code inline with the current process. That just makes more cracking for the cracker and bewares of just NUL'ing out your routine.[/font][/color]
[color=rgb(40,40,40)][font=arial]Flood the cracker with bogus calls and hard-coded strings. Decoys are fun.[/font][/color]
[color=rgb(40,40,40)][font=arial]Have fun with Spaghetti-Code simply eats his time and nerves..[/font][/color]
[color=rgb(40,40,40)][font=arial]No "disabled" features. If your program doesn't save data in "crapware" edition, don't include a "grayed" menu item. No saving means no saving - the code should not be included in the EXE - that's it. Most programming languages offer you a really easy way to maintain several versions of your code by simply doing the following:[/font][/color]
[color=rgb(40,40,40)][font=arial]{$IFDEF trial}[/font][/color]
[color=rgb(40,40,40)][font=arial]... no action here ...[/font][/color]
[color=rgb(40,40,40)][font=arial]{$ELSE}[/font][/color]
[color=rgb(40,40,40)][font=arial]... advanced functionality for registered user ...[/font][/color]
[color=rgb(40,40,40)][font=arial]{$ENDIF}[/font][/color]
[color=rgb(40,40,40)][font=arial]Release several, slightly modified versions.[/font][/color]
[color=rgb(40,40,40)][font=arial]{$IFDEF Anticrack_Method36}[/font][/color]
[color=rgb(40,40,40)][font=arial]..protection code #36 comes here..[/font][/color]
[color=rgb(40,40,40)][font=arial]{$ENDIF}[/font][/color]
[color=rgb(40,40,40)][font=arial]By doing the an adapted variation of the tip mentioned before, you can easily vary your code and enable/disable it (by defining or undefining the related DEFINE variable) to create slightly different versions of your program executables. This will keep the crackers busy since many of their fellow fans will repeatedly tell them that "crack xy is not working!!!" if they just downloaded the program from somewhere else than the cracker himself did it. Either the software pirates would now be forced to create a number of cracks for each "build", to fill up their server space with a complete setup package of one of your builds along with the crack which works on it or simply to give up on your program.[/font][/color]
[color=rgb(40,40,40)][font=arial]btw., this is also a cool method to make a special build for your registered users or preventing "registered" code to be compiled into the officially downloadable demo release (which crackers can often "enable" with just a few minutes of works as explained elsewhere on this page).[/font][/color]
[color=rgb(40,40,40)][font=arial]Update often. Frequent updates mean: frequently changing code, so the typical (simple) crack which is just patching hard-coded byte positions, will possibly already be outdated when published. Also prevent uploading them to public servers, so that you have better control about where your app sits around and people don't find older versions the cracks can still use. Yes, this doesn't prevent pirates from including the version to the crack package, but IF they do so, you can at least contribute to filling up their harddisks.[/font][/color]
[color=rgb(40,40,40)][font=arial]Create special temporary unlock codes, that work only for a limited amount of time (say 15-30 days). Send this code immediatly upon registration .. then wait a bit (e.g., for the credit charge to be validated). Only then send the unlimited code. That way, the "cracker" will not know that something is wrong and happilly post his code to the warez sites. By the time it spreads, the code will have stopped working. Thus making a fool of the "cracker" amongst his friends for distributing non-working codes. This is a method also handy for beta testers or reviewers.[/font][/color]
[color=rgb(40,40,40)][font=arial]Use strong encryption. Just XORing is not really strong - use something with an algorithm that isn't easily reverse-engineered, and don't put both encryption and decryption code in your app.[/font][/color]
[color=rgb(40,40,40)][font=arial]demo: strip out full verion code using "#IFDEF demo" conditional compilation[/font][/color]
[color=rgb(40,40,40)][font=arial]they cant hack what aint there.[/font][/color]
[color=rgb(40,40,40)][font=arial]full version:[/font][/color]
[color=rgb(40,40,40)][font=arial]keycd. multiple checks. separate inline code for each check. IE no keyCDok() routine.[/font][/color]
[color=rgb(40,40,40)][font=arial]key cd cant be copied. game wont run w/o key cd, unless hacked.[/font][/color]
[color=rgb(40,40,40)][font=arial]hack resistant exe file (crc check, checksum, filelength check).mutiple checks. separate code for each check. spread code out in program no 2 lines together. prevents code being modified.[/font][/color]
[color=rgb(40,40,40)][font=arial]encrypted exe. a vm decripts the encrypted exe, runs the decrypted exe, then erases the decrypted exe. prevents them looking at the exe file.[/font][/color]
[color=rgb(40,40,40)][font=arial]make the entire game one big file:[/font][/color]
[color=rgb(40,40,40)][font=arial]vm exe[/font][/color]
[color=rgb(40,40,40)][font=arial]vm code to decrypt, run, then erase the game[/font][/color]
[color=rgb(40,40,40)][font=arial]the encrypted exe[/font][/color]
[color=rgb(40,40,40)][font=arial]the encrypted data files.[/font][/color]
[color=rgb(40,40,40)][font=arial]all appended together. the vm opens the big game file and loads vm code that reads the remaining files and decrypts them, runs the decrypted game, then erases the decrypted game. encrypt with unique key for each registered copy.[/font][/color]
[color=rgb(40,40,40)][font=arial]they dont get any obvious files to work with. just the one file to decypher. when they look at the beginning of it, its a vm rtm. this is followed by some vm code, and encrypetd game files. they woul d have to translate the vm code and then decrypt the game files to get a look at the exe file[/font][/color]
[color=rgb(40,40,40)][font=arial]write entire game in vm. do speed critical stuff as c subrotines[/font][/color]
[color=rgb(40,40,40)][font=arial]so "run main loop" would be a vm opcode implemented as a big c subroutine.[/font][/color]
[color=rgb(40,40,40)][font=arial]problem: need to check keyCD inside main loop.[/font][/color]
[color=rgb(40,40,40)][font=arial]ok so checkcode must be in main loop wich is machine code in memory. get a dump, disassemble, and you have assembly source code for the checkcode.[/font][/color]
[color=rgb(40,40,40)][font=arial]so the checkcode must be hidden. spead out. with mutiple instances. if a check requires 6 lines of code, do each line at a different place in the main loop.[/font][/color]
[color=rgb(40,40,40)][font=arial]CDcheck should test for both good and bad spots. that way hacking the result to always be bad or good wont work.[/font][/color]
[color=rgb(40,40,40)][font=arial]what about a mini vm that does the check?[/font][/color]
[color=rgb(40,40,40)][font=arial]write the check cd routine in vm:[/font][/color]
[color=rgb(40,40,40)][font=arial]bad sector list is already loaded[/font][/color]
[color=rgb(40,40,40)][font=arial]keycd data file is already open for reading[/font][/color]
[color=rgb(40,40,40)][font=arial]seek badsector1-1[/font][/color]
[color=rgb(40,40,40)][font=arial]read[/font][/color]
[color=rgb(40,40,40)][font=arial]if error terminate program[/font][/color]
[color=rgb(40,40,40)][font=arial]seek badsector1[/font][/color]
[color=rgb(40,40,40)][font=arial]read[/font][/color]
[color=rgb(40,40,40)][font=arial]if no error terminate program[/font][/color]
[color=rgb(40,40,40)][font=arial]seek badsector1+1[/font][/color]
[color=rgb(40,40,40)][font=arial]read[/font][/color]
[color=rgb(40,40,40)][font=arial]if error terminate program[/font][/color]
[color=rgb(40,40,40)][font=arial]repeat for badsector2 etc[/font][/color]
[color=rgb(40,40,40)][font=arial]system id # and registration code. sysid generated from hd, processor etc.[/font][/color]
[color=rgb(40,40,40)][font=arial]give them registration code that only works with that system id. problem: if system changes, systemid changes, and game no longer works.[/font][/color]
[color=rgb(40,40,40)][font=arial]give each registered version a serial number. they must neter reg code for that serial number. problem: they can copy the game and pass along the reg #.[/font][/color]
[color=rgb(40,40,40)][font=arial]problem:[/font][/color]
[color=rgb(40,40,40)][font=arial]check code cant slow the game down. must be fast and infrequent.[/font][/color]
[color=rgb(40,40,40)][font=arial]vm ops for cdcheck:[/font][/color]
[color=rgb(40,40,40)][font=arial]seek some_spot[/font][/color]
[color=rgb(40,40,40)][font=arial]result = read[/font][/color]
[color=rgb(40,40,40)][font=arial]test result[/font][/color]
[color=rgb(40,40,40)][font=arial]abort[/font][/color]
[color=rgb(40,40,40)][font=arial]so they can always see machine code in memory.[/font][/color]
[color=rgb(40,40,40)][font=arial]and they can always translate vm code.[/font][/color]
[color=rgb(40,40,40)][font=arial]so all they have to do is dump the rtm from memory and then use its code to decipher the vm code.[/font][/color]
[color=rgb(40,40,40)][font=arial]so the vm code must be encrypted. that way all they have is the rtm, and an encrypted data file. but the data file must be decrypted for thr rtm to use it. any decrypt ruotine can be deciphered, whether implemented in c or vm. any routine can be deciphered weither in c or vm. vm is more work to decipher. once they disassemble the rtm, they have the asm source code for the vm opcode parser. from that they can easily write a vm disassembler. wiht the vm disassembler they can trsndlste the vm code back to source code and look for copychecks. once they find the copychecks they hack them by editing the vm code, or by making a compiler and recompiling.[/font][/color]
[color=rgb(40,40,40)][font=arial]essentially vm implements the program as a machine code that they must figure out (disassmble and reverse engineer the rtm) and then translate to english by hand or write a vm disassembler. then they must edit vm machine code to hack the game or write a vm compiler.[/font][/color]
[color=rgb(40,40,40)][font=arial]so a vm language translates from english to vm opcodes. a compiler translates english to opcode. a disassembler translates opcode to english.[/font][/color]
[color=rgb(40,40,40)][font=arial]in the end a game is numbers telling the pc what to do.[/font][/color]
[color=rgb(40,40,40)][font=arial]a hacker can change those numbers, making the game work without keyCD.[/font][/color]
[color=rgb(40,40,40)][font=arial]all you can do is makwe it hard. hard to figure out what to change. hard to figure out how to chnage it. lots of work to actually change it.[/font][/color]
[color=rgb(40,40,40)][font=arial]code spread one line at a time all over the main loop. read result stored in flag for later checking. use read result flag and other junk to set various flags, eventually taking action on one if copy violation. this way they have to trace all the flags. they start by tracing file i/o. from therre they find the reads. but the reads just set flags, so they must trace the flags. eventually something uses a flag to degreade or abort.[/font][/color]
[color=rgb(40,40,40)][font=arial]most cd checks are cracked by using wdasm to find the promt string to insert the keycd. so the prompt string should be assembled one char at a time, instead of hard coded.[/font][/color]
[color=rgb(40,40,40)][font=arial]disassembler can find all occurances of any winodws call (IE readfile etc) so it can find cd check by looking for file io routines.[/font][/color]
[color=rgb(40,40,40)][font=arial]most cracking techniques seem to use dialog box text as the way they find the appropriate code. IE they look for text in the code that they see in the program, such as "Please insert game disc".[/font][/color]
[color=rgb(40,40,40)][font=arial]idyle phonebook pro 97 had no text for entering registration key, but had error msgbox w/ the only button in the program for crc check error msg. the hacker in the tutorial couldn't easily find the reg code due to lack of strings. a breakpoint on hmemcpy took him to the realtime reg validation code. his patch triggered the crc check code. that triggered the msgbox, which he then traced via a search for BMSG in softice.[/font][/color]
[color=rgb(40,40,40)][font=arial]another case of looking for program specific text messages (IE "Insert Disk") or windows api calls (mBtn, msgbox, hmemcpy, getdrivetypeA, etc).[/font][/color]
[color=rgb(40,40,40)][font=arial]code for demo spash screen located by setting breakpoint on windows routine loadbitmapA using softice.[/font][/color]
[color=rgb(40,40,40)][font=arial]tracing is done using softice and hex editor. softice can search for symbols, hex editor can search for opcodes.[/font][/color]
[color=rgb(40,40,40)][font=arial]30 day limit traced via windows getlocaltime call.[/font][/color]
[color=rgb(40,40,40)][font=arial]set breakpoint on getlocaltime. step thru code til nag screen appears. unstep thru code looking for suspicious jumps. flow control is manipulated by editing jmp calls. change jmp on greater to jmp on less than, etc. then run the program and see if it worked. if not, undo the edit and try again. routines are bypaased by inserting returns (ret). jumps are bypassed by nop'ing them out. sometimes conditional jumps are changed to non conditional jumps to hack them.[/font][/color]
[color=rgb(40,40,40)][font=arial]trace until nagscreens popup. trace the call to the nagscreen. kill the call to the nagscreen. test it. repeat until no more nags.[/font][/color]
[color=rgb(40,40,40)][font=arial]"[to hack] a registration routine we must breakpoint on [the windows] api ( windows functions) used to read Your name and Your Sn.[/font][/color]
[color=rgb(40,40,40)][font=arial]They are:[/font][/color]
[color=rgb(40,40,40)][font=arial]Getwindowtext[/font][/color]
[color=rgb(40,40,40)][font=arial]GetwindowtextA[/font][/color]
[color=rgb(40,40,40)][font=arial]Getdlgitemtext[/font][/color]
[color=rgb(40,40,40)][font=arial]GetdlgitemtextA[/font][/color]
[color=rgb(40,40,40)][font=arial]Hmemcpy (that's not an api but it's the best)"[/font][/color]
[color=rgb(40,40,40)][font=arial]the api calls are used to locate reg related message screens. they then play around with conditional jumps that appear above these api calls to disable the reg code.[/font][/color]
[color=rgb(40,40,40)][font=arial]many apps store reg info in windows registery, which hackers can hack. dont store info in registry.[/font][/color]
[color=rgb(40,40,40)][font=arial]pcguard:[/font][/color]
[color=rgb(40,40,40)][font=arial]- Advanced software copy protection.[/font][/color]
[color=rgb(40,40,40)][font=arial]Protect software from illegal copying from one computer to another.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Simple and effective protection procedure.[/font][/color]
[color=rgb(40,40,40)][font=arial]No need for additional programming. Source code editing is not required.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Application encryption.[/font][/color]
[color=rgb(40,40,40)][font=arial]Protect software from reverse engineering and analyzing.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Application password protection.[/font][/color]
[color=rgb(40,40,40)][font=arial]Protect access to application with password.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Evaluation (trial) version feature.[/font][/color]
[color=rgb(40,40,40)][font=arial]Easily create demo version of software with execution, date, fixed date and timer limitations.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Serial numbers feature.[/font][/color]
[color=rgb(40,40,40)][font=arial]Mark each copy of your software with unique serial number.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Flexible machine locking.[/font][/color]
[color=rgb(40,40,40)][font=arial]Lock software to target computer. Seven locking parameters are available: HD volume ID, Bios ID, OS ID, CPU ID, Network card ID, HD hardware ID and CD/DVD hardware ID.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Secure distribution.[/font][/color]
[color=rgb(40,40,40)][font=arial]Securely distribute your software over the Internet or on any distribution media CD/DVD/floppy...[/font][/color]
[color=rgb(40,40,40)][font=arial]- Secure and simple license management.[/font][/color]
[color=rgb(40,40,40)][font=arial]Enable licenses by phone, fax or e-mail.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Advanced protection interface system.[/font][/color]
[color=rgb(40,40,40)][font=arial]Easily check license status and interact with protection code directly from your application.[/font][/color]
[color=rgb(40,40,40)][font=arial]- License removal feature.[/font][/color]
[color=rgb(40,40,40)][font=arial]Allow your client to securely remove program licenses from his computer.[/font][/color]
[color=rgb(40,40,40)][font=arial]- License transfer feature.[/font][/color]
[color=rgb(40,40,40)][font=arial]Allow your client to transfer program licenses from one computer to another.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Limited license feature.[/font][/color]
[color=rgb(40,40,40)][font=arial]Rent or lease your software by combining available license limitations (number of runs, number of days, fixed date limitation).[/font][/color]
[color=rgb(40,40,40)][font=arial]- Updates policy feature.[/font][/color]
[color=rgb(40,40,40)][font=arial]Limit free updates by setting updates policy for protected application.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Custom features.[/font][/color]
[color=rgb(40,40,40)][font=arial]Easily enable or disable features (modules) inside your application. 16 features can be passed via standard activation code. Up to 320 additional features can be passed via extended activation codes by using custom counters as sets of features. Feature status can be checked from protected application by using protection interface.[/font][/color]
[color=rgb(40,40,40)][font=arial]- License extension feature.[/font][/color]
[color=rgb(40,40,40)][font=arial]Easily update issued license before it expires. Update features, counters, limitations...[/font][/color]
[color=rgb(40,40,40)][font=arial]- Evaluation period extension feature.[/font][/color]
[color=rgb(40,40,40)][font=arial]Demo (evaluation) period can be extended after it expires by issuing special activation code.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Runtime encryption system.[/font][/color]
[color=rgb(40,40,40)][font=arial]Fragments of code are marked in source code by using special start and end labels. These fragments of code in compiled application are recognized by PC Guard and are additionally encrypted during protection process. Runtime encrypted code always stays encrypted in memory. It is not decrypted during application startup. It's managed by special code each time it should be executed. Once it is executed it's encrypted again.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Language editor.[/font][/color]
[color=rgb(40,40,40)][font=arial]You can manage (edit/load/save) more than 70 interface messages for 15 different languages including messages from all interface dialog boxes.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Custom dialogs feature.[/font][/color]
[color=rgb(40,40,40)][font=arial]Use your own dialogs instead of default interface dialogs![/font][/color]
[color=rgb(40,40,40)][font=arial]- IP Filtering system.[/font][/color]
[color=rgb(40,40,40)][font=arial]Easily enable access to protected application only from computers with specific IP addresses or from specific sub-domains. You can define up to 30 different IP filters (unique IP addresses or sub-domains). IP filtering can be combined with any protection method.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Network licensing.[/font][/color]
[color=rgb(40,40,40)][font=arial]Network protection method is suitable for controlling (limiting) number of workstations simultaneously accessing protected program located on network server. You can combine network protection method with IP filtering feature to additionally lock protected program to target network.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Machine ID feature.[/font][/color]
[color=rgb(40,40,40)][font=arial]Securely check the status of locking parameters in order to prevent false requests for new unlocking codes in the case of HD crash, bios upgrade, disk format, virus attack and similar events.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Easy management of protected program updates.[/font][/color]
[color=rgb(40,40,40)][font=arial]Auto-unlocking feature is available for protected program updates.[/font][/color]
[color=rgb(40,40,40)][font=arial]- "Lock program to installation directory" feature.[/font][/color]
[color=rgb(40,40,40)][font=arial]You can now lock program protected with remote protection method to its installation directory. Once it's unlocked, program can not be started from different directory. This counts for current and all future installations of the same program.[/font][/color]
[color=rgb(40,40,40)][font=arial]- "Limit number of application instances" feature.[/font][/color]
[color=rgb(40,40,40)][font=arial]You can now easily control (limit) number of application instances per computer. For applications running under Windows server terminal services number of instances is valid per server and not per workstation. You can thus use this feature to implement network floating licensing in such environment.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Custom counters feature.[/font][/color]
[color=rgb(40,40,40)][font=arial]You can now securely manage (change/save) 10 custom (long integer) counters directly from your application by using protection interface.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Four customizable buttons for activation dialog box.[/font][/color]
[color=rgb(40,40,40)][font=arial]You can enable/disable four buttons and assign action string for each button. Action string can be a document name, folder name or http link for example. This will allow your client to open your web page, help or license agreement file just by pressing appropriate custom button.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Advanced overlay management code (AOM)[/font][/color]
[color=rgb(40,40,40)][font=arial]Advanced overlay management (AOM) is a new, universal approach for managing protection of non-standard applications with internal overlays.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Unique support for non-standard applications.[/font][/color]
[color=rgb(40,40,40)][font=arial]Special support for the following compilers/applications is available: ACD FotoAngelo, Active e-book compiler, AL Pictures Slideshow Studio, AutoPlay Media Studio, Macromedia Authorware, Macromedia Director, Macromedia Flash, TrainerSoft, FlashJester - Jugglor, Bink video player, Help and manual, Game editor, Linder Setup Builder, Dark Basic compiler, LabView, Microsoft Camcorder, Multimedia fusion, NeoBook, Mediator, Opus Pro, Photoshop droplet files, PPT to Flash Studio, FreeWrap, Power Builder, Real Basic, Adventure Game Studio, Runtime revolution compiler, SecurePack, Techsmith?s Camtasia, Visual DBase, Brilliant Database SDK, WBTExpress, WinBatch, WinDev, Zinc.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Activation center (ACEN)[/font][/color]
[color=rgb(40,40,40)][font=arial]Full featured ASP .NET 2.0 WEB application for online management of clients, programs, orders and licenses with flexible automated activation system. More info...[/font][/color]
[color=rgb(40,40,40)][font=arial]- Support for third party licensing.[/font][/color]
[color=rgb(40,40,40)][font=arial]You can fully control third party licensing with AC Generator.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Support for calculation of activation codes over Internet connection.[/font][/color]
[color=rgb(40,40,40)][font=arial]Easily integrate calculation of activation codes over Internet with AC Generator WEB.[/font][/color]
[color=rgb(40,40,40)][font=arial]- Support for calculation of activation codes from your own application.[/font][/color]
[color=rgb(40,40,40)][font=arial]Easily integrate activation code calculation into your application with AC Generator API.[/font][/color]
[color=rgb(40,40,40)][font=arial]from gammasutra:[/font][/color]
[color=rgb(40,40,40)][font=arial]one company used crc checksums of the program in memory to make sure code was not modified. all checksum code was inline (not in a function). they ran multiple checksums starting at different offests and with different intervals (every byte, every 5th byte, etc) over the same piece of memory. they embedded bytes in the code to make the checksums add up to some predetermined value. they had mutiple implementations of the crc code, each unique, so it was harder to find.[/font][/color]
[color=rgb(40,40,40)][font=arial]Simply doing an XOR of as much of YOTD's code as possible before burning it to the CD means that this technique will not work. It also makes it difficult to match up data in memory with its source on the disk. We worked under the assumption that code can't be modified if it can't be found.[/font][/color]
[color=rgb(40,40,40)][font=arial]Second, we made it as difficult as possible to debug. If you've ever had to debug code that behaves differently when you trace through it, you know how much of a pain debugging can be. We used trace traps to make the code behave differently if breakpoints had been placed. The checksum helped with this, as any software breakpoints used would alter the checksum.[/font][/color]
[color=rgb(40,40,40)][font=arial]In YOTD we had four layers, including the copy protection.[/font][/color]
[color=rgb(40,40,40)][font=arial]The copy protection stopped the game very early.[/font][/color]
[color=rgb(40,40,40)][font=arial]we designed the game to break in ways that weren't immediately obvious. Most of the protection is "off-camera," affecting levels other than the one currently being played. In YOTD the object of the game is to collect eggs and gems, which are then used to open later parts of the game. The protection removed eggs and gems, so that the player could not make progress. We tried to make the game unplayable for any length of time, while at the same time making it difficult to determine exactly where things had gone wrong. If errors accumulated slowly until the game broke, the cracker would not notice such behavior so easily.[/font][/color]
[color=rgb(40,40,40)][font=arial]Other, more obvious protection was done less frequently. Callbacks were corrupted, which made the game crash in odd ways. The European version changed languages randomly. Some of these actions break the game and others are just an annoyance to the player, but if the game is difficult or frustrating to play because of the failed crack, this can be more effective than breaking completely.[/font][/color]
[color=rgb(40,40,40)][font=arial]By making the game behave in as many odd ways as possible, we hoped to cause a lot of confusion. The pirates wouldn't know if the crack didn't work, whether they had just failed to apply the crack correctly, or if the disk had failed to burn correctly. The people who didn't play a lot of the game wouldn't notice that anything was wrong and claim that the crack worked. This happens more than you would think. A lot of people pirate more out of habit than anything else, booting up the game to have a look before moving on quickly. All of this would help to delay a complete crack from being made, because no one would be sure that it was required.[/font][/color]
[color=rgb(40,40,40)][font=arial]Any version of the game with protection included was very difficult to debug, as any software breakpoints would trigger the protection. Beyond a certain point, hardware breakpoints were turned off by the copy protection.[/font][/color]
[color=rgb(40,40,40)][font=arial]exe's are compressed on disk w/ proprietary compression algo. hacker must hack the compression before they can hack the exe. then they must recompress the cracked software. [/font][/color]
[color=rgb(40,40,40)][font=arial]==================================================================================================[/font][/color]
[color=rgb(40,40,40)][font=arial]a comment from my original posting of this info in my old journal:[/font][/color]
[color=rgb(51,51,51)][font=helvetica]
leeor_net said:
[/font][/color][color=rgb(51,51,51)][font=helvetica]
>> But I will reiterate that the first number of suggestions are effectively useless for the above stated reasons (competent crackers will get around any of these 'measures').
[/font][/color][color=rgb(51,51,51)][font=helvetica]
yes, straight forward implementations of things like check sum etc will get bypassed swiftly. as with much of crack protection, its more about obfustification, than the protection algo used. even a 100% secure hardware lock can be bypassed in the code if its implementation is not hidden.
[/font][/color][color=rgb(51,51,51)][font=helvetica]
the idea is to slow them down. you can't stop them. with unlimited resources and time, they will crack anything. you just have to slow them down enough to keep them out until you release a new version. so in the spirit of slowing them down, you want to present to them all the usual hoops to jump through. after all, they'll be expecting them (things like checksums), so why disappoint them? but be clever about it, one checksum out in the open where they expect it, maybe a second easy to find one, and then one or two (or more) hidden ones. and then do likewise for all the "usual suspects" in the way of expected protections. then once they get past all that de-regeur stuff, then they get into the REAL protection methods.
[/font][/color][color=rgb(51,51,51)][font=helvetica]
much of it has to do with the hassle to benefit ratio for the cracker. on the hassle side, you have the difficulty of actually craccking the game. a long and tedious cracck can turn from fun to challenging to frustrating as ttime goes on. on the benefit side, you have the glory of posting the crack, which is a function of game size, price, quality, and popularity. bigger, more expensive, higher quality, popular games = more bragging rights for cracking it. so the cost of implementing protection must be weighed against the chances of getting cracked, based on the game's, popularity, price, quality, and size.
[/font][/color][color=rgb(51,51,51)][font=helvetica]
