Obfuscating - Protecting part of code

[marko001]

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

[Blue_Drache]

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

[AdamUL]

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

[marko001]

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?

[AdamUL]

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

[marko001]

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

[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. If it's there, it can be compromised. Always.

Edited September 30, 2011 by Unsigned