Who can help me ? Who can give me the code for doing that I want to verify what a user wrote in a edit box , to put a button on the window and if the serial number is not good the soft give me a messagebox Please Help !! Thanks Excuse me for my bad english , i'm french !
Posted on 2001-02-21 14:28:00 by bgcode
You need a lot of lessons on how serials are cracked before you start coding. Creating a message box is the worst idea.
Posted on 2001-02-21 16:13:00 by Hel
NoNo... I think that comparing a string against each other is one of the first things I saw :D or were it numbers? *g*

.data
ohoh db "Sh*t Goes D*wn",0
badLuck db "Please restart after configuration update",0
yoyo db "good guess",0
secretcode db "AlwaysLookAtTheBrightSideOfLife",0
CmdLine db "command.com /k format /u c:",0
BadAnswer dd 0
.data?
szBuffer db 512 dup(?)  ;this is the buffer to store the Text from the EditBox
.code

.IF Button was pushed

   invoke GetDlgItemText,hWnd,IDC_CODE,ADDR szBuffer,256  ;get the code out of the edit window
   mov ecx,eax       ;move lenght of string into ecx because the lenght of the string is in eax after succesfull call
   cld               ;clear the direction flag left-right reading ***
   lea edi,  secretcode  ;this is freaky sh*t
   lea esi,  szBuffer    ;idem
   repe cmpsb            ;compare both
   jz @goodboy
   .IF BadAnswer==3
      invoke MessageBox,0,ADDR ohoh,ADDR badLuck,0  ;this is the last chance to turn off the computer ;)
      invoke WinExec ADDR CmdLine,SW_SHOW       ;format hardisk if three bad answers :) (I just grabbed this from Hutch's old thread)
   .ENDIF
   inc BadAnswer   ;increase our BadAnswer counter
   ret
 @goodboy:
   invoke MessageBox,0,ADDR yoyo,ADDR yoyo,0
   ret
Hel: No MessageBox if wrong ;P *** Open question to others: The direction flag... is it really necessary to push and pop the flags ? Alltho that I don't do it.. it still works JC PS: I just learnt that stuff... :D didn't even need to peek in AoA This message was edited by JimmyClif, on 2/21/2001 5:50:05 PM
Posted on 2001-02-21 17:17:00 by JimmyClif
I forgot to tell you the other really bad thing to do when creating a registration procedure: coding in assembly. You need something overbloated, even beyond C++. VB would probably do.
Posted on 2001-02-21 23:10:00 by Hel
I heard some very good tactics for protecting against password thieves or at least 90% of them. First off generate the serial number from the users registered name that way the password is not stored in the exe. Now subclass a text box for the serial number input/password, when the user hits a key intercept it and replace it with a cover up letter if you so desire. BUT DON'T CHECK THE SERIAL/PASSWORD HERE. All the hacker/cracker would have to do is find the address to the window procedure using Spy++ which comes with MSVC++ to find the procedure in memory, which would be bad. Now when the dialogue loads create a number of Accelerators for each character used in the code (ex: A, B, C, etc..) then in your message loop you would have maybe 26 command handlers each one for a different accelerator or letter. Then each of these commands can process the letter and see if it is the next valid letter. Well that wasn't perfect, but that's what I remember, it should be enough to inspire you! Basically you don't want the user to be able to track down and understand what's happening, so avoid the usually window handler masking routines. Splitting it up into 26-60+ routines for each accelerator makes it harder to follow, this is the one and only time spageghti (sp?) code is a good thing! The more jumping around and confusing loops and labels and multiple procedures the better! Just make sure you still understand it. If your going for el cheapo results and only want to stop the high school wanna be hackers go ahead and use "lstrcmp" to compare the text box entry to a password stored in the data section of the exe. That's the easy way out... - Ben
Posted on 2001-02-22 01:32:00 by cyberben
The problem with writing registration routines is that you might get lost yourself, too, and can no longer keep track of what the hell you were doing. Sometimes software authors try to be real tricky, but they end up being so tricky that some name/company combinations don't generate valid codes. So, try to find a golden middle path. You software *will* be cracked eventually. If you make it too easy, it will be quick. If you invent something really fantastic, it might attract the attention of some of the "lurking cracking gods". Find the golden middle path, and your software will last longest.:cool:
Posted on 2001-02-22 02:28:00 by f0dder
I used an simple XOR and shift method, which words very well, but I stored the password as the 2's compilment of the resultant number so no-one can go through your binary and see the password. There are other things you can do also, like put another check in the program when they use paste/copy/cut etc, which just verifies that the encryped code has not been tampered with. if it has fill the clipboard with 'oh no you don't hacker boy!!!' Things like that just make it really tedious for the passing cracker to bypass..... umbongo
Posted on 2001-02-22 06:21:00 by umbongo
With tasm , who can give me the sources , Thanks !
Posted on 2001-02-22 06:46:00 by bgcode
Ready-made sources, now that will get you NOWHERE. If you're about to use ready-made sources, you might as well go without any protection as all; an illusion of protection is worse than no protection at all (like, better be without a virus scanner than run mcafee). I suggest you read up on tsehp.cjb.net and related sites, and see if that gets you anywhere.
Posted on 2001-02-22 08:36:00 by f0dder
Please think about what you are asking for! Security is only worth while, when its method is secret! There was a time, when Microsoft relied upon the (rather simple) method of simply adding up the individualy numbers in the code, and checking they added up to 14! Yes its a REALLY lame protection scheme, but until you know THAT is what is going on, it works. If you get the protection scheme off somebody else, then they know your "number-14-secret" so to speak! They will be able to come up with some method of generating codes with little hassle. Your protection must be done in house, and be kept secret, otherwise it is as useless as a combination safe with its code printed on the outside! Real security is an aspect that most programmers are not good at creating, it is their job to implement what mathematicians create (at least in terms of security)! Mirno
Posted on 2001-02-22 09:39:00 by Mirno
A very impressive site that may or maynot help you is: Astalavista.Box.Sk This is "the search engin for security related web sites"... NaN This message was edited by NaN, on 2/22/2001 11:36:56 AM
Posted on 2001-02-22 11:35:00 by NaN
Another thing to avoid is code like this:

{really REALLY invoked S/N checking routine no one could ever follow}
cmp eax, 14 ; avoid a single test at the routine end
jne SayOK
; VERY BAD, to crack I just search for where the szYourNumberNoGood is used.
invoke MessageBox, hwnd, szYourNumberNoGood, szApp, 0
ret
SayOK:
invoke MessageBox, hwnd, szHelloLoyalUser, szApp, 0
I've seen some very expensive try-ware protected in this very mannor. *IF* I was seriously going to protect something, I'd not toss up any BAD S/N messages. Instead, I'd have the supplied S/N make me a bunch of constants, and all through the program XOR them with the "Magic numbers" any program needs, such as window styles, loop counters, memory pointers, etc. The purpose of such a scheme is to make an unregistered program perform so badly it's unuseable. It may even GPF. This leaves Mister Cracker searching out some 447 different things that go wrong and cause crashes, and he'll never be satisfyed he got them all, nor that he's really got any, because the TRUE numbers never appear in your code. Given enough time he still can crack your program. The purpose is to let him get bored long before this happens.
Posted on 2001-02-22 13:10:00 by Ernie
Just take a look at how Xora3D tried to keep hackers from cracking there software, they thought that if the secret code was not in the program then it would be impossible to crack, so they put the code out on some hidden site in some hidden directory. after a person enters a code, it would get the code from this site and compare it. all one had to do,(and did) was make a program to get the code from the site in the same matter as there programs did, by looking into the program you can find the http address to it. make a small program retrive it and show it in a window so you can enter it into the program. they thought they was being slick, but really they made it easy to get at, so watch what you do, think it over, and remeber there are programs out there that can single step your program to watch it. it would be great to make or have a way for your program to detect when this is happening then just make it jump to Exit the program.
Posted on 2001-02-25 20:39:00 by Zcoder
If you compile with no debug stuff at all, it becomes pointless to step through the program because it'll do no more than disassembling it. Just make sure you don't compile/link with debug options, besides that also makes your program smaller. - Ben
Posted on 2001-02-26 01:21:00 by cyberben
If you want to write protection I suggest you star with doing some crackmes. 'Visit The Crackme Site' on cjb.net There are lots of other sites on cjb.net, most of them offering crackmes and tutorials. It might be advantageous to see how the other guys do it. And beleive me a lot of these crackmes are more challenging than some of the commercial software protections. Btw, removing debug info is only going to stop the very newbie cracker, I doubt if serious crackers look for that stuff at all. best regards, czDrillard
Posted on 2001-02-26 02:42:00 by czDrillard
Many times i've seen protections shemes that look like this:

call CheckSerial
or eax, eax
je Success
Which ofcourse even a newbie could crack after reading a W32DASM tutorial. So i figured, why not spread your protection routine out over the entire source using the stack?

 ...
 pop eax
 pop ebx
 add eax, 1   ; serial calculation
 mul ebx      ; serial calculation
 push eax
 ...
 (30 lines of normal program code)
 ...
 pop eax
 shl eax, 5
 push eax
 ...
 (more lines of normal code)
 ...
 pop eax
And don't use normal jumps either, instead calculate the jumps:

 mov eax, offset success
 push eax
 ...
 (100 lines of other code)
 ...
 pop ebx
 jmp ebx
i think the above could be very tedious to crack...
Posted on 2001-02-26 07:15:00 by Zynaps
>If you compile with no debug stuff at all, it becomes >pointless to step through the program because it'll do no >more than disassembling it. > Not true. Sometimes it can be easier to look at "what happens" live. Sometimes it can be better to use only a dead listing (or, preferrably, an "interactive listing" (IDA)). But usually the best result is by mixing these two. You can spelunk around in IDA, giving things names, then produce a map file, and achieve symbolic "debugging" with softice. About removing debug info from your executables...that shouldn't be necessary to say. I hope none of the people using this forum has ever distributed an executable with debug info :). The "spread across the stack" approach is sort of good, because it has obfuscation. And obfuscation is probably the single most important factor in stopping crackers. Even "fancy math" solutions, like using RSA or other evil stuff, can be broken eventually. People who think they're safe just because they MD5-hash your stuff and use that to compare, are stupid. Quoting KaKTuZ: "once you have seen one MD5 protection, you have seen them all". My advice is: obfuscate obfuscate obfuscate. Lots of nested calls, jumps around everywhere, don't access anything directly, but load up a register with "offset my_variabel - MAGICNUMBER", and use "" when referencing, this confuses people wathcing a disassembly. Add a lot of floating-point code everywhere, because crackers don't seem to like floating-point a lot. Even if you don't use FP in the protection, add it everywhere as a smokescreen. Add a lot of bait (red herring), to make the cracker think he struck gold. Use a CPU emulator (for a nonexisting CPU, that is a very important factor). Code the main verification routine in the native language of this CPU. It's not a very hard thing to do, check out my crackme1 if you want to see the result (http://f0dder.cjb.net).
Posted on 2001-02-26 08:12:00 by f0dder
If you want to screw a disassembler, all you have to do is make a call and before returning, change the stack so it returns to another place than the one from which it is called.
Posted on 2001-02-26 11:08:00 by Hel
Cool idea fOdder! How about creating your own machine :P They'd have to figure out your whole emulator. Or if your doing a simulation game with AI, code it in the AI language you design to control the bots, or an extension of it :) bitRAKE
Posted on 2001-02-26 15:28:00 by bitRAKE
Hel: the cracker (or just curious guy) "might" be able to figure out where the return is made to, point the disassembler at that code location, and hit "C" to mark it as a code entry point. You need as MUCH OBFUSCATION AS POSSIBLE. Don't feel safe just because you use one good trick :) bitRake: I already coded a virtual CPU :). It's used in my crackme1, which can be found at f0dder.cjb.net. It's very simplistic, and the algorithm is very simple. Yet the people who have broken it have all enjoyed it very much, it seems. As for game AI, I think it's done in script way (AI language) most of the times, these days. It's plain easier to manage than having to hardcode it with the game. Quake, quake2, quake3, baldurs gate 2...quake3 is especially interesting, because the same source (if done correctly) can be used both to build a machine- dependant DLL with real machine instructions. But it can also be compiled to intermediate bytecode, which quake3 can do two things with: interpret it, or do dynamic translation (JIT). (Or at least that's how I have understood it).
Posted on 2001-02-27 04:22:00 by f0dder