(Relatively) Secure Way to Hide Keys inside a DLL

[Manko]

Tighten security! (Just a wee bit.)

I checked the dll, and it is still easy to read password even before authorization check.

...and as trancexx said it's a onebyte patch... But even without it, you prepare password on the stack so it can be read out...

This is even visible in a dead-listing. (Disassembly...)

Let's eliminate the "check if caller is right then return password" AND make it unreadable. You wont have to do THAT much... but... Simple idea is:

1. You already have a method to checksum exe, right? Use checksum to XOR password in dll.

2. When you call to get password, don't check validity of current callers checksum, just use checksum to XOR password back. If caller is wrong, they get shit...

ciao!

[iShafayet]

Manko, thanks for taking all the trouble to suggest the updates.

I understand that the dll's security is as good as none at all. But using any checksum that works by having user input from autoit exe will loose the purpose of using the dll at all.. The dll is used to store the key and make it accessible to the autoit exe it was designed for only. All that trouble I had to take only because autoit exe's are so easily reverse engineerable.

It's just unfortunate that the dll itself isn't secure...

I was thinkin about a way to scramble and obfuscate the dll itself to make reverse engineering less probable...

[AdmiralAlkex]

But Manko didn't say anything about any user input....

Edited April 11, 2011 by AdmiralAlkex

[iShafayet]

But Manko didn't say anything about any user input....

- Nor did I.

[AdmiralAlkex]

I must be reading wrong then.

But using any checksum that works by having user input from autoit exe will loose the purpose of using the dll at all..

[Manko]

But using any checksum that works by having user input from autoit exe will loose the purpose of using the dll at all.. The dll is used to store the key and make it accessible to the autoit exe it was designed for only. All that trouble I had to take only because autoit exe's are so easily reverse engineerable.

I was thinkin about a way to scramble and obfuscate the dll itself to make reverse engineering less probable...

No, no... I'm not explaining myself well enough!

I am NOT suggesting you do this: $a = RSWHKID_GetKey($checksum) instead you still do: $a = RSWHKID_GetKey() but the dll itself calculates the checksum of the exe. Instead of using it to make certain the right exe is doing the calling you directly use the checksum as a key to decrypt the "string" you hid in the dll. If the wrong app calls, the checksum of that program, used as key to decrypt, will still return something, just not what the rogue expected...

The app that alters and compiles the dll will for the first time calculate checksum of exe and encrypt string and put it in the dll. Now it cannot be read in a decompilation nor by tracing code. Only the right exe will have the valid checksum that decrypts an intelligible "string".

I suggested XOR because it's simple... You could search for something else here or elsewhere for better security...

About obfuscating... You can do that... But with above method, you don't really have to...

[JohnOne]

I think its a great idea to have something like this automated, I cant make head nor tail of the files and what they do, but I done something similar for a friens a while back.

It worked like this.

When a caller attached to dll to ececute some code in it, the caller was hash checked, if it was not a match for the valid exe (it had been decompiled or something) then a flag is set.

When the function in the dll is finally run, it checkes the flag, if its set the function returns sour, if not it returns a sweet.

It worked fine for its purpose, but I quickly got bored when he told me he updated his exe and and the dll didnt work any more

It was fun though, and I learned something.

[iShafayet]

Manko, I get it now! Excellent idea!

I'll be using tougher encryption alg such as aes 256... I'll implement this as soon as I get home.

Thanks again!

[czardas]

Oh, oh, oh! I know something that you will enjoy in that case:

LOL, and that's when I'm trying to write something with clarity. My current project refuses to be accessible, no matter how hard I try.

Edit

The strength in my Entropi encryption has nothing to do with code obscurity. Unfortunately the maths to prove this is a little over my head (but it's closely related to chaos theory). The concepts are simple enough, but my implementation has produced rather obscure looking code. This was not my intention, and I'm sure the code can be improved. The encryption is not uncrackable, but cracking it is never going to be easy or quick. I will make a quantum computer heuristic analysis proof version next. The new version will work on the principle that it will be cracked by a quantum computer, but nobody will be able to take advantage of the fact.

Edited April 22, 2011 by czardas

[Unsigned]

You can't store a password in any way shape or form and have it be inaccessible. If your app can get it, so can somebody else. DLLs are not secure at all, and while they provide some extra layers of obscurity, it's nothing but a little extra time in the long run.

Anything you distribute can be compromised, period.

Adobe CS5 was cracked within hours of release. I'm not delving into gory details, but it's basically as simple as altering the DLL that handles the activation check. If you think you can last longer than a company with that much money, be my guest. But don't kid yourself, you're merely increasing the time required at best. You won't prevent it.

(I should add that Adobe has anti-debugger routines, which makes reverse-engineering slightly harder (but not at all impossible). But nonetheless something your DLL is unlikely to offer.)

There are numerous other failed attempts I could mention, not the least of which is Microsoft's WGA. That's another nightmare of security-through-obscurity.

I'm not one to be discouraging, usually But sometimes bluntness is the best way.

Edited September 30, 2011 by Unsigned

[JohnOne]

Anything you make will be compromised, period.

You cannot possibly know that.

If you can say with absolute certainty that someone somewhere is going to crack every single application made ever, then I'll get my orthepedic shoes on.

[Unsigned]

....someone somewhere is going to crack every single application made ever....

Haha, edited that Hopefully better clarified my meaning.

[JohnOne]

I wouldn't argue with that.

Thing is, it provides a light means to discourage lazy thieves. Its not meant to be bullet proof it never was.

Anyone could get mugged walking along the street, it doesn't mean you should just hand over your wallet and take a kicking.

[Unsigned]

Anyone could get mugged walking along the street, it doesn't mean you should just hand over your wallet and take a kicking.

True, but the law of diminishing returns does apply. If only five competent people take an interest in reverse engineering your project, that's a one-on-five fight. My point was that any additional "security" on the client's is really just obscurity; a facade.

[WinMacBear]

On 4/4/2011 at 7:42 PM, iShafayet said:

(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

This post is a bit old but I am still interested in your idea? But link looks down already. Do you have a backup link for it? Thanks! 

[seadoggie01]

@WinMacBear He hasn't posted since 2011 or visited since July 😐 

[WinMacBear]

5 hours ago, seadoggie01 said:

@WinMacBear He hasn't posted since 2011 or visited since July 😐 

Sorry I should check this late on before I post. Thanks!

[seadoggie01]

No need to apologize, I just wanted you to know  This seems to be the most popular AutoIt encryption method, however, I understand little of encryption and the difference between the use cases being discussed here and in the following thread. It sounds like it would be just as safe to hide keys using CodeCrypter and I'm certainly not taking the time to pick apart an obfuscated script

[RTFC]

On 1/5/2021 at 3:26 PM, seadoggie01 said:

hide keys using CodeCrypter

CodeCrypter does not hide decryption keys at all; instead, they are extracted from the runtime environment in whatever way the user specifies at the encryption stage. The aim is to prevent scripts from running anywhere except a specific sanctioned environment/machine/set of conditions.

 

Edited January 6, 2021 by RTFC

[WinMacBear]

13 hours ago, RTFC said:

CodeCrypter does not hide decryption keys at all; instead, they are extracted from the runtime environment in whatever way the user specifies at the encryption stage. The aim is to prevent scripts from running anywhere except a specific sanctioned environment/machine/set of conditions.

 

Thanks RTFC, You are right I believe so. For most of situation it's good enough though. But I have test the CodeCrypter. For some reason it does not working for me. Maybe I should give it a try again.