Jump to content
Sign in to follow this  
marko001

Creating Encrypted .dat and use with Resources()

Recommended Posts

marko001

Hi all,

I read a lot about securing/protecting/etc etc.

What I mainly need is to store my reserved datas (login/credentials/addresses) used by the main .au3 in a .dat encrypted file.

It has been told to me to use Resources() by Zedna.

It seems a good idea, but I have some questions about:

I can create the .dat as a .txt encrypted (To Encrypt Files Use [Crypt Files.au3], )

Now shall I use Resources() by Zedna or the Encrypt version by V3000?

It seems that the V3000 version uses this format:

_ResourceGetAsString ( $ResName, $ResType = $RT_RCDATA, $ResLang = 0, $DLL = -1, $Pass = '', $tALG_ID = $CALG_RC4 )

and the Zedna version:

_ResourceGetAsString($ResName, $ResType = $RT_RCDATA, $ResLang = 0, $DLL = -1)

Probably, given the pw used to encrypt I should use the V3000 version, isnt'it?

But if this is the case the problem still remains: the command _resourcegetasstring() ask me the decrypt password.

Now reversing the procedure, if someone goes .exe -> .au3 can see the pw and go back with a decrypt() of the .dat.

Any idea?

M.

Share this post


Link to post
Share on other sites
czardas

I don't get why anyone can get the key. If you make it so that the key has to be typed by the user at startup then how is the key available? If the key is in the code, that's not such a great idea. How are you intending to implement this?

Share this post


Link to post
Share on other sites
marko001

That's why I'm trying to understand how to do that:

What I need is the following:

Beginning: I have inside the .au3 some passwords (i.e. _EzMySql_Open("SERVER", "LOGIN", "PASSWORD", "DATABASE", "PORT")

I don't want them to be visible there, so I create a .txt file containing all these datas.

Then I crypt it to create myfile.txt.encrypted. I rename it Myfile.dat

Then I use Resources() to embeed it into the .au3 and string->array to use the lines

Resources (by V3000) asks the pw to decrypt it. This pw needs to be clear.

What I want is to use my .dat without giving hints on how to retrieve the pw.

M.

Share this post


Link to post
Share on other sites
czardas

I'm interested to hear what other people might have to say. The only thing I can think of is sending the data to the user in encrypted form along with an activation code, or something like that. The key should only make the data available to the program. Whether it can easily be hacked or not depends on how it's done, I don't really know. You might get some ideas from Valuter's

Edited by czardas

Share this post


Link to post
Share on other sites
SmOke_N

The way you/most are going about it, is like an endless loop. Somewhere in the code, you're going to have to have your decryption/decipher method. Which ultimately means that someone can reverse engineer it.


Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

Share this post


Link to post
Share on other sites
marko001

You right, Smoke_N, without doubt.

Question is if there is a way to avoid that.

Share this post


Link to post
Share on other sites
GEOSoft

No.

Given the need or desire any code you write can be looked at with a hex editor and if the person is sharp enough they will see what you did.


George

Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.

Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.***

The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number.

Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else.

"Old age and treachery will always overcome youth and skill!"

Share this post


Link to post
Share on other sites
SmOke_N

You right, Smoke_N, without doubt.

Question is if there is a way to avoid that.

Probably not without using 3rd party apps/tools ( other language dlls/exe's ) that have the cipher/decipher unique to the user already built into them.

Where the management code is within those apps/tools themselves.


Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

Share this post


Link to post
Share on other sites
czardas

It was good to read the input in this thread. Considering the amount of hacked software there is out there, it seems to be a big uphill struggle for developers to find ways to avoid it.

Share this post


Link to post
Share on other sites
marko001

Ok, good to know (but I imagined that was the answer).

I just will think of a snakey code or something harder to recognize, I'll be back unless some good developer here can give us an hint or a suggestion.

M.

Share this post


Link to post
Share on other sites
Unsigned

I'm going to throw my two cents in here, from an extensive background in security analysis (I get paid to reverse-engineer/compromise systems by the owner(s), and then tell them how to close the holes.)

Don't use AutoIt to deal extremely sensitive data. Period. AutoIt is at heart an interpreted language and is very vulnerable to reverse engineering attacks. Obfuscation is like putting a second lock on a door that is being pounded with a battering ram. It may slow things down, but it will not prevent entry. Trust me.

An external DAT file will not even slow down a determined opponent. One of the first orders of business in compromising any program is monitoring the filesystem, network, and registry APIs. A file access on an obscure, seemingly unrelated file will raise instant suspicion.

My advice, write the sensitive portions (at least) of your app in C/C++, and wrap them in a DLL to call from your main AutoIt program. Any security-related logic should not be native AutoIt. Native code can be reverse engineered, but not as easily or as quickly. A good optimizer can also help obscure the logic and decrease the feasibility of an automated decompiler.

Also, look into using asymmetric encryption for communication with the server. (Public/private key pairs.)

Lastly, if you really cannot abide something being discovered, don't put it on another user's system. :graduated: If it's there, it can be compromised. Always.


.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×