marko001 Posted September 15, 2011 Share Posted September 15, 2011 Hi all mates,I already had long discussions with Melba and Zedna about ofbuscation vs. virus false-positive recognition.So I can't use the obfuscate tool (in any way!) to harden the life of a possible reverse-engineer. But my problem is another. Since my code contains access to an internet db, I HAVE to give inside the script some clean datas:address, username, password, db, tables,cells,... Mainly i'm not so traumatized about the possibility of a reverse engineering, but I'd like at least to protect few part of the code (like the ones stated here). How (if) is possible to manage it? Thanks again, Marco Link to comment Share on other sites More sharing options...
Blue_Drache Posted September 15, 2011 Share Posted September 15, 2011 (edited) It's often better to pass in the so-called "clean datas" you're speaking of via command line options or GUI text-boxes. That way, they're not "in the clear" and hard-coded. Edited September 15, 2011 by Blue_Drache Lofting the cyberwinds on teknoleather wings, I am...The Blue Drache Link to comment Share on other sites More sharing options...
AdamUL Posted September 15, 2011 Share Posted September 15, 2011 In situations like this, when I need to do it, I usually have the data encrypted in an inconspicuously named DAT file on the system that the script will be running on. If you must have the data with the script, you could store the data, encrypted, in a file in the resources. Then use Zedna's to get the string data and decrypt it. Those are just a few ideas. Adam Link to comment Share on other sites More sharing options...
marko001 Posted September 22, 2011 Author Share Posted September 22, 2011 Hi Adam, sorry for the late reply: I don't know how to encrypt them in a .dat file ... can you help me with that? Link to comment Share on other sites More sharing options...
AdamUL Posted September 28, 2011 Share Posted September 28, 2011 (edited) When I use a DAT file for storing data, I use _StringEncrypt to encrypt the data. I then keep the DAT file separate from the main script, somewhere on the PC that it will be used on. I also use delimiters when I encrypt and I do not identify what the values are in the DAT file. You then decrypt the file and parse the data in main script to extract the data. Also extract the _StringEncrypt from String.au3, rename the function and the variables in it to something totally unrelated to encryption, when you use it to decrypt the file in the main script. This makes it a little harder, if someone gets your source, to determine what the function is doing. An Example to create DAT file.#include <String.au3> ;Data to encrypt. $sDB1 = "DB1" $sUserName1 = "User1" $sPassword1 = "Password1" $sDB2 = "DB2" $sUserName2 = "User2" $sPassword2 = "Password2" $sDB3 = "DB3" $sUserName3 = "User3" $sPassword3 = "Password3" $sDATFile = "Test.dat" $sData = $sDB1 & "," & $sDB2 & "," & $sDB3 & @CRLF & $sUserName1 & "," & $sUserName2 & "," & $sUserName3 & @CRLF & $sPassword1 & "," & $sPassword2 & "," & $sPassword3 & @CRLF $sDataEncrypted = _StringEncrypt(1, $sData, "EncryptPassword", 10) FileWrite($sDATFile, $sDataEncrypted) In this example, when this file is decrypted, it can be parsed from a CSV format into an array with function with the -1 format option. You are then able to use the data in the main script. This example uses an unrenamed _StringEncrypt function for demonstration to decrypt the DAT file, and _ParseCSV to parse the unencrypted string. Using the previously created DAT file from above. Array.au3 used for _ArrayDisplay only.expandcollapse popup#include <String.au3> #include <Array.au3> $sDATFile = "Test.dat" $sData = FileRead($sDATFile) $sData = _StringEncrypt(0, $sData, "EncryptPassword", 10) $aData = _ParseCSV($sData, "", "", -1) _ArrayDisplay($aData) ; #FUNCTION# ==================================================================================================================== ; Name...........: _ParseCSV ; Description ...: Reads a CSV-file ; Syntax.........: _ParseCSV($sFile, $sDelimiters=',', $sQuote='"', $iFormat=0) ; Parameters ....: $sFile - File to read or string to parse ; $sDelimiters - [optional] Fieldseparators of CSV, mulitple are allowed (default: ,;) ; $sQuote - [optional] Character to quote strings (default: ") ; $iFormat - [optional] Encoding of the file (default: 0): ; |-1 - No file, plain data given ; |0 or 1 - automatic (ASCII) ; |2 - Unicode UTF16 Little Endian reading ; |3 - Unicode UTF16 Big Endian reading ; |4 or 5 - Unicode UTF8 reading ; Return values .: Success - 2D-Array with CSV data (0-based) ; Failure - 0, sets @error to: ; |1 - could not open file ; |2 - error on parsing data ; |3 - wrong format chosen ; Author ........: ProgAndy ; Modified.......: ; Remarks .......: ; Related .......: _WriteCSV ; Link ..........: ; Example .......: ; =============================================================================================================================== Func _ParseCSV($sFile, $sDelimiters=',;', $sQuote='"', $iFormat=0) Local Static $aEncoding[6] = [0, 0, 32, 64, 128, 256] If $iFormat < -1 Or $iFormat > 6 Then Return SetError(3,0,0) ElseIf $iFormat > -1 Then Local $hFile = FileOpen($sFile, $aEncoding[$iFormat]), $sLine, $aTemp, $aCSV[1], $iReserved, $iCount If @error Then Return SetError(1,@error,0) $sFile = FileRead($hFile) FileClose($hFile) EndIf If $sDelimiters = "" Or IsKeyword($sDelimiters) Then $sDelimiters = ',;' If $sQuote = "" Or IsKeyword($sQuote) Then $sQuote = '"' $sQuote = StringLeft($sQuote, 1) Local $srDelimiters = StringRegExpReplace($sDelimiters, '[\\\^\-\[\]]', '\\\0') Local $srQuote = StringRegExpReplace($sQuote, '[\\\^\-\[\]]', '\\\0') Local $sPattern = StringReplace(StringReplace('(?m)(?:^|[,])\h*(["](?:[^"]|["]{2})*["]|[^,\r\n]*)(\v+)?',',', $srDelimiters, 0, 1),'"', $srQuote, 0, 1) Local $aREgex = StringRegExp($sFile, $sPattern, 3) If @error Then Return SetError(2,@error,0) $sFile = '' ; save memory Local $iBound = UBound($aREgex), $iIndex=0, $iSubBound = 1, $iSub = 0 Local $aResult[$iBound][$iSubBound] For $i = 0 To $iBound-1 If $iSub = $iSubBound Then $iSubBound += 1 ReDim $aResult[$iBound][$iSubBound] EndIf Select Case StringLen($aREgex[$i])<3 And StringInStr(@CRLF, $aREgex[$i]) $iIndex += 1 $iSub = 0 ContinueLoop Case StringLeft(StringStripWS($aREgex[$i], 1),1)=$sQuote $aREgex[$i] = StringStripWS($aREgex[$i], 3) $aResult[$iIndex][$iSub] = StringReplace(StringMid($aREgex[$i], 2, StringLen($aREgex[$i])-2), $sQuote&$sQuote, $sQuote, 0, 1) Case Else $aResult[$iIndex][$iSub] = $aREgex[$i] EndSelect $aREgex[$i]=0 ; save memory $iSub += 1 Next If $iIndex = 0 Then $iIndex=1 ReDim $aResult[$iIndex][$iSubBound] Return $aResult EndFunc Edit: Added #include <String.au3> to the second example. Adam Edited September 29, 2011 by AdamUL VenusProject2 1 Link to comment Share on other sites More sharing options...
marko001 Posted September 28, 2011 Author Share Posted September 28, 2011 (edited) Yes, this way works fine. What about embedding the .dat directly in the .exe? Do you think it's possible using Resources.au3? Edit: Just did it ... works perfectly! M. Edited September 29, 2011 by marko001 Link to comment Share on other sites More sharing options...
Unsigned Posted September 30, 2011 Share Posted September 30, 2011 (edited) 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. Edited September 30, 2011 by Unsigned VenusProject2 1 . 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