Jump to content

Creating Encrypted .dat and use with Resources()


marko001
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

  • Moderators

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.

Link to comment
Share on other sites

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!"

Link to comment
Share on other sites

  • Moderators

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.

Link to comment
Share on other sites

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.

.

Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...