(Relatively) Secure Way to Hide Keys inside a DLL

[Digisoul]

nice effort iShafayet! 5 stars from me

  On 4/4/2011 at 3:05 PM, 'MrCreatoR said:

try it now: CrackMe.zip

here is your "$SCRYPTEDPASS"

$SCRYPTEDPASS = "E26B94DCBEBEC62F03DB6AB1C813D63266E40DAC1D008C5A138B6F15B17E59E40CEE61F266414EA53E6263A868CB2E9125A6EA3D3FF7D7E8BB7A4CE5"

[MrCreatoR]

  On 4/5/2011 at 7:47 AM, 'Digisoul said:

here is your "$SCRYPTEDPASS"

$SCRYPTEDPASS = "E26B94DCBEBEC62F03DB6AB1C813D63266E40DAC1D008C5A138B6F15B17E59E40CEE61F266414EA53E6263A868CB2E9125A6EA3D3FF7D7E8BB7A4CE5"

Where? where is the real password?

[wraithdu]

The password is encrypted with itself, so this would require either brute forcing it or finding a vulnerability in the _ScringEncrypt algorithm. No thanks... unless you want to give us the password length and character makeup.

Edited April 5, 2011 by wraithdu

[iShafayet]

  On 4/4/2011 at 6:20 PM, 'Valik said:

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.

- Yes. That's true. But it would be much more securer if the dll could not be cracked so easily.

  On 4/4/2011 at 6:55 PM, 'trancexx said:

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.

- Thanks, trancexx. I was wondering if it would be possible anyway to bypass this vulnerability.

  On 4/4/2011 at 8:36 PM, 'MrCreatoR said:

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.

- Can you present an example where the user doesn't have to enter anything?

  On 4/5/2011 at 7:29 AM, 'Manadar said:

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.

- I'd be doing it soon. Thanks again for the tips.

[iShafayet]

  On 4/5/2011 at 7:47 AM, 'Digisoul said:

nice effort iShafayet! 5 stars from me

- Thank you Digisoul

  On 4/5/2011 at 9:50 AM, 'MrCreatoR said:

Where? where is the real password?

- MrCreatoR, I hardly see the point. We are not discussing how strong the algorithm is. We are rather working on it's usability in this particular scenario where the user's input is not wanted.

[wraithdu]

I think this exercise is futile. There are so many things to consider. I'll just list randomly:

1) If this should work without user interaction, they you're already defeated. Anyone interested in the data simply needs to figure out how the application gets access to it and duplicate the process. You're giving someone nothing less than all the puzzle pieces.

2) If we are securing an AutoIt EXE, such as a license key, then it is far easier to crack the EXE's licensing mechanism than trying to get your key data. AutoIt is the weak link here, as it is trivial to decompile the EXE to script and modify it to remove the protection.

Do you really want to go through this effort for a bit of obscurity? AutoIt's internal protection is far more complex that what you could accomplish in script, and it is trivial to break. Having AutoIt anywhere in this keychain makes all the work irrelevant.

The only way I see to make this even semi-useful, is to do all the work in the DLL itself. The DLL should neither send or receive anything to or from AutoIt. AutoIt should only be used to invoke the DLL. Even then, it depends highly on what you want to do with the data in the DLL and the security of the data as it leaves the DLL (network connection, etc).

Edited April 5, 2011 by wraithdu

[MrCreatoR]

  On 4/5/2011 at 3:18 PM, 'wraithdu said:

unless you want to give us the password length and character makeup.

I don't mind, i can give you the password itself . The point is not to crack the password, it's about storing the password inside autoit script.

  On 4/5/2011 at 5:19 PM, 'iShafayet said:

- Can you present an example where the user doesn't have to enter anything?

Oops, i thouth it would be like this:

If MsgBox(52, 'Mail Sender', 'Send mail?') = 6 Then
    $s_SmtpServer = "smtp.gmail.com"
    $s_FromName = "Tester"
    $s_FromAddress = "mymail@gmail.com"
    $s_ToAddress = "sendtomail@yahoo.com"
    $s_Subject = "Test mail"
    $s_Body = "Hello from test"
    $s_AttachFiles = ""
    $s_CcAddress = ""
    $s_BccAddress = ""
    $s_Username = "mymail"
    $s_Password = _StringEncrypt(0, "E3A867A30EFC51508A2B2290A4CBDC754A63F613FB9C7BC5", $sPassInput, 2) ;qwerty
    $IPPort = 465
    $ssl = 1
    
    _INetSmtpMailCom($s_SmtpServer, $s_FromName, $s_FromAddress, $s_ToAddress, _
        $s_Subject, $s_Body, $s_AttachFiles, $s_CcAddress, $s_BccAddress, $s_Username, $s_Password, $IPPort, $ssl)
    
    MsgBox(64, 'Mail Sender', 'Mail sent.', 5)
EndIf

but abviously we need the $sPassInput

[AdmiralAlkex]

  On 4/5/2011 at 6:27 PM, 'MrCreatoR said:

I don't mind, i can give you the password itself

Can I get it?

[UEZ]

Is the password 15 chars long?

Br,

UEZ

[MrCreatoR]

  On 4/5/2011 at 6:29 PM, 'AdmiralAlkex said:

Can I get it?

Sorry, i don't remember it actualy , it's something about "super password", or maybe "crypted password", and there is underscore between the words i think... but what for you need it?

[AdmiralAlkex]

What do wraithdu need it for?

[wraithdu]

I don't need it at all. The challenge was to crack the pwd. I said it couldn't be done except for brute forcing it, and I wasn't going to give that a shot without a password length and character makeup.

[trancexx]

  On 4/5/2011 at 5:19 PM, 'iShafayet said:

- Thanks, trancexx. I was wondering if it would be possible anyway to bypass this vulnerability.

No. You can use some clandestinity method to divert attention from it, but it will always be there. It's trivial now to bypass it.

wraithdu is right of course. Extending... If security is wanted then it has to be compiler (Aut2exe) doing the job. au3 and a3x should be on one side and exe (self sufficient compiled script) on the other side of the stick. Current implementation of exe production is terrible from the aspect of security. Also considering that all the bad things related to AutoIt (virii) are the result of that implementation, the conclusion can be that even though the idea behind Aut2exe is nice, it does more damage than good.

[Mobius]

  On 4/5/2011 at 8:09 PM, 'trancexx said:

No. You can use some clandestinity method to divert attention from it, but it will always be there. It's trivial now to bypass it.

wraithdu is right of course. Extending... If security is wanted then it has to be compiler (Aut2exe) doing the job. au3 and a3x should be on one side and exe (self sufficient compiled script) on the other side of the stick. Current implementation of exe production is terrible from the aspect of security. Also considering that all the bad things related to AutoIt (virii) are the result of that implementation, the conclusion can be that even though the idea behind Aut2exe is nice, it does more damage than good.

There you go again dude, okay for the sake of mild curiosity how exactly would you improve upon it?

[JohnOne]

Is this package missing a video, or am I missing brain cells?

[AdmiralAlkex]

  On 4/6/2011 at 10:14 AM, 'JohnOne said:

Is this package missing a video, or am I missing brain cells?

In the help folder:

\(Relatively) Secure Way to Hide Keys inside a DLL\Help\Vid Tut Pre-alpha.avi

[JohnOne]

Hmm, there is no help folder in the download.

[JohnOne]

Scrap that, I had the wrong download.

heers AdmiralAlkex

[Manko]

  On 4/5/2011 at 5:38 PM, 'wraithdu said:

The only way I see to make this even semi-useful, is to do all the work in the DLL itself. The DLL should neither send or receive anything to or from AutoIt. AutoIt should only be used to invoke the DLL. Even then, it depends highly on what you want to do with the data in the DLL and the security of the data as it leaves the DLL (network connection, etc).

It is funny because more and more we decide NOT to work in autoit... But to continue:

If the aim was to ensure that only the right application uses functions in the dll:

1. If they're on your computer... game over!

2. If you want to make them work for it... make code convoluted and inefficient. (obfuscate dll.... nested calls and rewrites of simple functions shuffling and crypting things insanely... You have to have an insane amount of different ways to do simple stuff very tedious and change between them alot to make automated de-obfuscation hard...)

Have to admit: Many thoughts ran through my mind, both helping and defeating ones, but as I lost track of your true aim, I realise I should wait till I know more specifically what you want to use this for...

/Manko

[jvanegmond]

  On 4/8/2011 at 10:34 AM, 'Manko said:

2. If you want to make them work for it... make code convoluted and inefficient. (obfuscate dll.... nested calls and rewrites of simple functions shuffling and crypting things insanely... You have to have an insane amount of different ways to do simple stuff very tedious and change between them alot to make automated de-obfuscation hard...)

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