PureBasic Forums - English

Posted: **Sat Dec 10, 2005 2:03 pm**

Hi all !

I create a small application using PureBasic. I also make a serial number to unlock that program. But when I try W32DASM to crack my program. I see all the key (all variable, text and everything I hide in my program).

Is there a way to secure my EXE ? I compress it using UPX but it still easy to crack.

Posted: **Sat Dec 10, 2005 2:11 pm**

try to use this:

Code: Select all

Procedure.l CalculateSeed(InputNumber.l) 
  ProcedureReturn Int(Log(InputNumber) * Cos(InputNumber) * 137) 
EndProcedure 
Procedure.l GetPasswordValue(Password.s) 
  ASCII_Vals.l 
  
  For i = 1 To Len(Password) 
    ASCII_Vals = ASCII_Vals + Asc(Mid(Password, i, 1)) 
  Next i 
  
  If ASCII_Vals > Len(Password) 
    ProcedureReturn Int(CalculateSeed(ASCII_Vals) / CalculateSeed(Len(Password) + 1)) 
  Else 
    ProcedureReturn CalculateSeed(ASCII_Vals) 
  EndIf 
EndProcedure 
Procedure.l WrapNumber(lngNumber.l, lngMinimum.l, lngMaximum.l) 
  DefType.l Range, check 
  Range = lngMaximum - lngMinimum 
  check = lngNumber 
  
  If lngNumber > lngMaximum 
    Repeat 
      check = check - Range 
    Until check <= lngMaximum 
  ElseIf lngNumber < lngMinimum 
    Repeat 
      check = check + Range 
    Until check >= lngMinimum 
  EndIf 
  ProcedureReturn check 
EndProcedure 
Procedure.s Encrypt(Password.s, Input.s) 
  DefType.l PasswordVal, CurrentChar, CurrentMod 
  enctxt.s  
  PasswordVal = GetPasswordValue(Password) 
    
  CurrentMod = 2 
    
  For i = 1 To Len(Input) 
    CurrentChar = Asc(Mid(Input, i, 1)) 
    CurrentChar = CurrentChar + PasswordVal 
    CurrentChar = CurrentChar - CalculateSeed(CurrentMod) 
    CurrentChar = WrapNumber(CurrentChar, 0, 255) 
    enctxt = enctxt + Chr(CurrentChar) 
    CurrentMod = CurrentMod + 1 
    
    If CurrentMod > 30 
      CurrentMod = 2 
    EndIf 
  Next i 
  ProcedureReturn enctxt  
EndProcedure 
Procedure.s Decrypt(Password.s, Input.s) 
  DefType.l PasswordVal, CurrentChar, CurrentMod 
  dectxt.s  
  PasswordVal = GetPasswordValue(Password) 
  CurrentMod = 2 
    
  For i = 1 To Len(Input) 
    CurrentChar = Asc(Mid(Input, i, 1)) 
    CurrentChar = CurrentChar - PasswordVal 
    CurrentChar = CurrentChar + CalculateSeed(CurrentMod) 
    CurrentChar = WrapNumber(CurrentChar, 0, 255) 
    dectxt = dectxt + Chr(CurrentChar) 
    CurrentMod = CurrentMod + 1 
    
    If CurrentMod > 30 
      CurrentMod = 2 
    EndIf 
  Next i 
  ProcedureReturn dectxt    
EndProcedure

The code is taken from CodeArchiv and it's little modified.
Those are only procedures but you can use it like:

Code: Select all

serialnumber=Encrypt("THEserial", "THEpassword")

And then:

Code: Select all

decrypted=Decrypt(serialnumber, password)
If decrypted="MUCHA"
; do whatever
Endif

That is simply a simple decrypt/encrypt thingy, but that is not secure enough. Just little help for you,

Posted: **Sat Dec 10, 2005 3:09 pm**

For an average program, MD5 should be fine. Instead of storing the password, store the MD5 hash of it, then when you get the input, hash that, and compare.

Code: Select all

HashedPassword.s = "3766d47c78d1dbef9de81233c2a108d3"

Input.s = InputRequester("Password", "Enter password:", "")
Input = LCase(Input)

If MD5Fingerprint(Input, Len(Input)) = HashedPassword
   MessageRequester("Correct", "Correct password!")
Else
   MessageRequester("Incorrect", "Incorrect password.")
EndIf

(The password for that is W32DASM

.)

Posted: **Sat Dec 10, 2005 10:21 pm**

well in that case why not cracking the application by doing something like changing the = to a <> in asm ? - it could be done, if you know the address of the md5 hash string, then you can know where its being used on the asm source and do your grace..

Why not, if you want a little more security.. split the hash string into multiple strings? then when you have to check, join them.

The problem is that even if they cant find an md5 string (an entire one), they will know you're using md5 if they got a little of experience - easy to find out - so if they find multiple strings that appears like a splitted md5 hash, they might know that is the hash...

Posted: **Sun Dec 11, 2005 1:35 am**

> I see all the key (all variable, text and everything I hide in my program)

You may like to check out MrMat's tip at this post:

viewtopic.php?t=13553&postdays=0&postorder=asc&start=15

Might be useful for storing small pieces of text in your exe?

Posted: **Sun Dec 11, 2005 2:33 am**

also, embedding data in images/files can be quite a usefull thing. somebody replaces a file, your program breaks... you know where they are stored, just make it pretty random how often you check things and HOW you check things

Posted: **Sun Dec 11, 2005 7:40 am**

PB wrote:> I see all the key (all variable, text and everything I hide in my program)

You may like to check out MrMat's tip at this post:

viewtopic.php?t=13553&postdays=0&postorder=asc&start=15

Might be useful for storing small pieces of text in your exe?

PB, reason of why I didnt suggest this little tip is because it doesnt protect anything. You just wont be able to notice the strings by reading the exe in notepad (doh).. But dissasemble it, for example, using PE Explorer, and you'll notice the strings are still totally visible, just as before applying MrMat's tip. I'm pretty sure of this.

Posted: **Sun Dec 11, 2005 8:00 am**

> dissasemble it, for example, using PE Explorer, and you'll notice the strings

I didn't know that. Thanks for explaining!

Posted: **Sun Dec 11, 2005 8:21 am**

I didnt really explain anything

I just know its no way of protection since I once had some spare hours to waste and I was trying out different types of tips regarding protection like that one, found out that at the end there was no protection at all.. just a waste of time.

Just don't rely on it unless theres anything else that could be done to protect a string.. what I personally do is encrypt them, but then if they know which encryption algo you're using, you're in the same spot as before!.. so you could use a custom one + a known one.. it would be slower than not encrypting the strings but ..... we want protection, dont we?... so then they will have to find out your algorithm as well, but eh that if they really want to get the contents of your strings... you should however do this for your program's title and all those strings like copyrights, etc.

Posted: **Sun Dec 11, 2005 9:50 am**

Thanks for all of you !

I will try now.

Posted: **Sun Dec 11, 2005 12:17 pm**

For a little extra security use a PE-Packer like PE-Spin...

It will not only reduce the size of the exe by compressing it, but also make those ascii strings impossible to read unless you unpack the exe...

You could also add a few protected sections inside your app, so when PE-Spin packs it, it also encrypts and secures then, you can take a look here:

viewtopic.php?t=16419

Posted: **Sun Dec 11, 2005 12:25 pm**

I am no cracker, but I have always wondered why, if you can follow the flow of a program using some debugger, you can't just change the critical point where the program branches. Change a conditional branch to an unconditional?

Regardless of what levels and methods of protection are applied.

After all, the thing cannot be crunched, encrypted and obsfucated to the point where it cannot run.

Posted: **Sun Dec 11, 2005 1:36 pm**

Num3 wrote:For a little extra security use a PE-Packer like PE-Spin...

It will not only reduce the size of the exe by compressing it, but also make those ascii strings impossible to read unless you unpack the exe...

You could also add a few protected sections inside your app, so when PE-Spin packs it, it also encrypts and secures then, you can take a look here:

viewtopic.php?t=16419

Is this also trustable? I'll PM thefool, he cracked my crackme's, which were packed with MoleBox, and thefool could see everything in the time when the string was used. And you say just that macro is good enough?

Maybe a wonder happened

Posted: **Sun Dec 11, 2005 5:08 pm**

josku_x wrote:
Num3 wrote:For a little extra security use a PE-Packer like PE-Spin...

It will not only reduce the size of the exe by compressing it, but also make those ascii strings impossible to read unless you unpack the exe...

You could also add a few protected sections inside your app, so when PE-Spin packs it, it also encrypts and secures then, you can take a look here:

viewtopic.php?t=16419
Is this also trustable? I'll PM thefool, he cracked my crackme's, which were packed with MoleBox, and thefool could see everything in the time when the string was used. And you say just that macro is good enough?

Maybe a wonder happened

No pm's here yet

About pe-spin: http://programmerstools.org/node/213
a decryptor for it

However not for the newest version, but i dont need a decryptor to crack things.. like with molebox

About that macro, the strings will get decrypted in memory, so not secure. Only from a hex editor

A thing to do it a little harder is to decrypt the strings FIRST when they are needed, and empty them afterwards. But again, one can always stop the execution. So a macro wont help. And i wouldnt dream of looking in a file with a hexeditor before i grapped my debugger and disassembler

And if i couldnt see anything with a stringlister, i would execute the app with my debugger, and then list them again. About using upx and that stuff, even scrambling can be simply undone. There is not many good things wich protects against such loaders, unless the protector is smart enough to check the memory space for changes! But this can be unddone too.

Posted: **Sun Dec 11, 2005 9:13 pm**

haven't dropped this yet, cause it might be one day of some use to myself, but what the heck... don't even know if it makes any sense

what you could do is make some 'constants' in your code depend on the result of the hash / encryption algortim

what i mean is this: create a key, that contains multiple sections

- for each new version you release add a check for another (yes t unused) section of the key (obvious thing to do)

- build in a few 'hidden constants' in your key, that are the result of a certain hash / dehash

- check validity of the key itself on a hash over the whole key, so faultive keys will give a warning, to protect innocent users

- now if a hacker runs your code, he will have to do a few additional checks, to figure out why a refular for / next loop is using the result of a dehash of part of the key

best would be to call that dehash the moment you need it, so there's little indication of it being a constant, ie.

Code: Select all

n = 0
repeat
  ... whatever ...
  n = n+1
until n = 10

would then be

Code: Select all

n = 0
repeat
  .. whatever ..
  n = n+dehash(partofkey)
until n = 10

the idea here is not to make cracking impossible, just to make it very time consuming

PureBasic Forums - English

EXE compliled by PureBASIC and its Security

EXE compliled by PureBASIC and its Security

Re: EXE compliled by PureBASIC and its Security

Re: EXE compliled by PureBASIC and its Security

Re: EXE compliled by PureBASIC and its Security

THanks