Hey, I guess any cracker would probably let the app run until it gets to the point where it (for example) compares the serial number you entered to one generated or embedded into the application - and that's where it gets hairy.
As most crackers first attempt to dump and deassemble the code of your application, they quickly find out which methods do what by reading symbols left in your binary. After that they set a debugger (gdb for instance) to break at the said method, letting it step through it instruction by instruction until they find the golden "if" or "if not()" and, depending on the code, simply overwrite it with NOP-instructions, causing it to get skipped and never executed again. Most deadly are MsgBox()es, telling the user that the serial number was invalid - those block code execution and make it even easier to step into the debugger and figure out what happends during verification. Here is a list of things you can do to make crackers suffer when they touch your application: - write bogus code around the actual registration check: for example do calculations in loops, many if-statements and method calls before and after the actual code is checked or accepted (don't foget to use the code entered by the user and play around with that) - add some "cracked" serial numbers to your code and hide them, distribute them certain forums. If one enters one of those "cracked" serials, tell them that your application accepted the serial and internally block some random features - like adding pirate messages at random times or screw up any output your applciation makes with "PIRATE" all over the printout, for example. - don't rely on plugnis for critical information - those can be hijacked easily. - sign your code in some kind of way, for example use a binary packer and let it add a stub that checksum's your binary prior execution (hard) - check for changed resources within your application and let behave differently (hard) 2007/4/8, Chad Bullock <[EMAIL PROTECTED]>: > I've been reading up on the archives about various ways to do serial > algorithms, and there are definitely lots of good ideas. If anyone knows the > answers to any of these questions, it'd be much appreciated (I couldn't find > it in the archives). I'm working on redoing a bit of my registration stuff - > and realize it *will* be cracked regardless, but want to make it at least a > little tough/fun for them... > > 1a) Having "include function names"=false, is obviously more ideal to deter > hackers in final builds. From past discussions it seems that when set to > false, method names are encoded in the binary in base64 - or maybe I read > that wrong. Is this the case? > > 1b) In any case, if a cracker was attempting to figure out my registration > system is there a benefit to naming methods and parameters odd things that > don't raise attention as much. E.g. Would a function named "WaterTheLawn" be > less likely to be noticed than one named "CheckSerialNumber"? > > > 2) Another idea is to spread some data around the app in different places. > Out of curiosity, what happens in the following cases: > > a) I have one module with 10 int properties. In the binary (or while it's > running) are these stored in relatively consecutive blocks in memory? > > b) If I create 10 different modules with 1 int property in each, does this > spread the space that they're stored in memory? > > > 3) When someone is trying to decompile my app and watching it's output, if I > have a function that declares 2 things: > > Dim a as string = "secret" > dim a as new MemoryBlock(7) > a.PString(0)="secret" //in real usage, I'd jumble it up a bit. But just for > a simple example > > ...Would it be any easier/harder to get the value of either one of these? > > Hmm...that's about it for now. I'm sure I'll have more :) > Thanks for any ideas, I hope that helps for now. Laters. -- Best regards, Bastian Bense Meet me at the #rbcafe IRC channel! More Information: http://basti.neo.de/index.php/REALbasic_Cafe _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
