EXE compliled by PureBASIC and its Security
EXE compliled by PureBASIC and its Security
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.
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.
TitaniumT
try to use this:
The code is taken from CodeArchiv and it's little modified.
Those are only procedures but you can use it like:
And then:
That is simply a simple decrypt/encrypt thingy, but that is not secure enough. Just little help for you,
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
Those are only procedures but you can use it like:
Code: Select all
serialnumber=Encrypt("THEserial", "THEpassword")
Code: Select all
decrypted=Decrypt(serialnumber, password)
If decrypted="MUCHA"
; do whatever
Endif
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.
(The password for that is W32DASM
.)
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

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...
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...
Re: EXE compliled by PureBASIC and its Security
> 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?
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?
I compile using 5.31 (x86) on Win 7 Ultimate (64-bit).
"PureBasic won't be object oriented, period" - Fred.
"PureBasic won't be object oriented, period" - Fred.
-
- 666
- Posts: 1033
- Joined: Mon Sep 01, 2003 2:33 pm
Re: EXE compliled by PureBASIC and its Security
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.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?
Re: EXE compliled by PureBASIC and its Security
> dissasemble it, for example, using PE Explorer, and you'll notice the strings
I didn't know that. Thanks for explaining!
I didn't know that. Thanks for explaining!

I compile using 5.31 (x86) on Win 7 Ultimate (64-bit).
"PureBasic won't be object oriented, period" - Fred.
"PureBasic won't be object oriented, period" - Fred.
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.

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.
-
- PureBasic Expert
- Posts: 2812
- Joined: Fri Apr 25, 2003 4:51 pm
- Location: Portugal, Lisbon
- Contact:
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
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
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.
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.
@}--`--,-- A rose by any other name ..
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?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
Maybe a wonder happened

No pm's here yetjosku_x wrote: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?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
Maybe a wonder happened

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


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.
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.
would then be
the idea here is not to make cracking impossible, just to make it very time consuming

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
Code: Select all
n = 0
repeat
.. whatever ..
n = n+dehash(partofkey)
until n = 10
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )