(Relatively) Secure Way to Hide Keys inside a DLL

[iShafayet]

(Relatively) Secure Way to Hide Keys inside a DLL

This is a way to Securely store a small amount of Data inside a DLL. As we all know, autoIt Executables can be prone to decompilation (and thus easy reverse engineering). But if a vital piece of information (like the encryption key of a database) is put inside a c dll that can not be so easily decompiled. So, even though the algorithms inside the au3 is compromised, the Data is NOT compromised as it is encrypted with the key stored in the dll.

I've spent few hours on it.. Please try it if you have a few moments to spare.

What's Included?

1. The DLL Creation Wizard (+tcc compiler)

2. Complete Video Tutorial. HOT!

3. Source for the entire thing.

P.S. Any kind of comments and suggestions are welcome.

Download

0.01 Pre-Alpha - (Program FIles + Video Tutorial)

Regards

Sayem Shafayet

[MrCreatoR]

I think we can encrypt the password inside AutoIt script:

#include <String.au3>

;This is how you get the password key, then remove this line from the script and use the key in $sCryptedPass
;~ ClipPut(_StringEncrypt(1, "qwerty", "qwerty", 2))

$sCryptedPass = 'E3A867A30EFC51508A2B2290A4CBDC754A63F613FB9C7BC5'

$sPassInput = InputBox('Password', 'Enter your password (qwerty):', '', '*')
If @error Then Exit

If _StringEncrypt(0, $sCryptedPass, $sPassInput, 2) = $sPassInput Then
    MsgBox(64, 'OK', '"' & $sPassInput & '" accepted.')
Else
    MsgBox(48, 'Failed', '"' & $sPassInput & '" denied.')
EndIf

[iShafayet]

MrCreatoR, Thanks for commenting. But I don't get your point. Certainly we can encrypt a text inside autoit. I fail to see how that is relevant.

You are having to put the key INSIDE the autoit exe. Thus your key is compromised if someone decompiles your executable.

$sCryptedPass = 'E3A867A30EFC51508A2B2290A4CBDC754A63F613FB9C7BC5'

RSWHKID makes it possible to store & retrieve key from the dll (which will ONLY work for the exe it is intended to work with). So, when you distribute your project, end user can not reverse engineer your key even if they decompile the Executable, the dll (and thus the key inside) remains not compromised.

[jvanegmond]

Very interesting. I will have some fun trying to crack this.

Edit: Hacked it & automated hack (~10 lines code). PMed iShafayet with details on the exploit. If he doesn't reply wanting to fix this then I'll just post the script here and this encryption will go where it belongs.

Edited April 4, 2011 by Manadar

[iShafayet]

Manadar, thanks a lot for the enlightment. Indeed, I forgot that string literals are stored in dll's quite directly. (my bad)... I'm lookin for a way to counter cracking.

Should I succeed or fail, I'll post the way you cracked it, with the next update (if any)...

[MrCreatoR]

You are having to put the key INSIDE the autoit exe. Thus your key is compromised if someone decompiles your executable.

Ok, here is an executable, please try to get the password from it: Edited April 4, 2011 by MrCreatoR

[AdmiralAlkex]

Ok, here is an executable, please try to get the password from it:

Just press OK and it's accepted.

[iShafayet]

MrCreatoR, I understand what you are trying to tell me. This is indeed a very secure way... But what I'm trying to achieve is to make the Key exclusive to the Executable, not to the user...

That means, my quest is to find a way to store (and get) the key securely without any action from user.

[iShafayet]

Just press OK and it's accepted.

lol... that was funny

[MrCreatoR]

Just press OK and it's accepted.

Oops, but that's not the point, try it now: CrackMe.zip

But what I'm trying to achieve is to make the Key exclusive to the Executable, not to the user...

I am sorry, i don't understand what you mean by exclusive to the executable?

[MrCreatoR]

That means, my quest is to find a way to store (and get) the key securely without any action from user.

But with your method the user must do much more than with my method

[iShafayet]

MrCreatoR, dude. I thought it is obvious what I meant. Maybe I wasn't able to explain properly.

In your method, the user must enter the password each time... This would be a way to prevent other users to access the data.

But I don't intend that. I intend to prevent other Applications to access the data.

I hope I made my point clear, this time.

And about the user doing much more work, the 'user' here is the end user (who will use an app that uses the created dll) not the developer/programmer. Alright?

[ProgAndy]

The DLL should validate the executable with a checksum. Using only the executable name is not enough

[Mat]

I don't know much about encryption, but following on from ProgAndy's post: Can you use the checksum (or something similar) of the exe as a key for encryption? Now that would be pretty cool indeed.

[iShafayet]

The DLL should validate the executable with a checksum. Using only the executable name is not enough

- It Exactly does that. I've implemented md5 checksum. The checksum is put inside the dll in compile time. At runtime the dll gets the md5 hash of calling exe and then returns the stored key only if both md5 hashes are matched.

I don't know much about encryption, but following on from ProgAndy's post: Can you use the checksum (or something similar) of the exe as a key for encryption? Now that would be pretty cool indeed.

- It's already there. Look inside the rswhkid.c in the \res\ folder.

[ProgAndy]

- It Exactly does that. I've implemented md5 checksum. The checksum is put inside the dll in compile time. At runtime the dll gets the md5 hash of calling exe and then returns the stored key only if both md5 hashes are matched.

Oh, I just took a quick look, so I must have missed that. Edited April 4, 2011 by ProgAndy

[Valik]

This is no more secure than AutoIt. This is security by obscurity and hoping nobody cares enough to invest time to crack it. I'm not saying it won't help, just realize it is what it is and don't think it's nothing more than that.

[trancexx]

This is not secure at all unfortunately. One byte crack.

Everything else surrounding that one byte is rather nice. 5 stars for that from me.

[MrCreatoR]

MrCreatoR, dude. I thought it is obvious what I meant. Maybe I wasn't able to explain properly.

In your method, the user must enter the password each time... This would be a way to prevent other users to access the data.

But I don't intend that. I intend to prevent other Applications to access the data.

I hope I made my point clear, this time.

And about the user doing much more work, the 'user' here is the end user (who will use an app that uses the created dll) not the developer/programmer. Alright?

Ok, got it now, thanks for the explanations.

And no need to be mad

P.S

And in my method it is only an example, user don't have to enter anything, we could use that method to store the password, for example for the sending mail function.

And also, the same way we could store the data inside AutoIt script, and other programs also could not get an easy access.

Edited April 4, 2011 by MrCreatoR

[jvanegmond]

This is no more secure than AutoIt. This is security by obscurity and hoping nobody cares enough to invest time to crack it. I'm not saying it won't help, just realize it is what it is and don't think it's nothing more than that.

I PMed Shafayet saying the same thing. He would have to add layer on top of layer to make this more secure than how AutoIt stores the scripts.