marko001 Posted September 26, 2011 Share Posted September 26, 2011 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 More sharing options...
czardas Posted September 26, 2011 Share Posted September 26, 2011 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? operator64 ArrayWorkshop Link to comment Share on other sites More sharing options...
marko001 Posted September 26, 2011 Author Share Posted September 26, 2011 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 More sharing options...
czardas Posted September 26, 2011 Share Posted September 26, 2011 (edited) 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 September 26, 2011 by czardas operator64 ArrayWorkshop Link to comment Share on other sites More sharing options...
Moderators SmOke_N Posted September 26, 2011 Moderators Share Posted September 26, 2011 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 More sharing options...
marko001 Posted September 26, 2011 Author Share Posted September 26, 2011 You right, Smoke_N, without doubt. Question is if there is a way to avoid that. Link to comment Share on other sites More sharing options...
GEOSoft Posted September 26, 2011 Share Posted September 26, 2011 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 More sharing options...
Moderators SmOke_N Posted September 26, 2011 Moderators Share Posted September 26, 2011 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 More sharing options...
czardas Posted September 26, 2011 Share Posted September 26, 2011 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. operator64 ArrayWorkshop Link to comment Share on other sites More sharing options...
marko001 Posted September 26, 2011 Author Share Posted September 26, 2011 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. Link to comment Share on other sites More sharing options...
Unsigned Posted September 30, 2011 Share Posted September 30, 2011 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. If it's there, it can be compromised. Always. . Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now