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 !
You need a lot of lessons on how serials are cracked before you start coding. Creating a message box is the worst idea.
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
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.
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
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:
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
With tasm , who can give me the sources , Thanks !
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.
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
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
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
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.
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
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
Many times i've seen protections shemes that look like this:
call CheckSerial
or eax, eax
je Success
...
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
mov eax, offset success
push eax
...
(100 lines of other code)
...
pop ebx
jmp ebx
>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).
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.
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
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).