Sign in to follow this  
Followers 0
marko001

Obfuscating - Protecting part of code

7 posts in this topic

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

Share this post


Link to post
Share on other sites



#2 ·  Posted (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 by Blue_Drache

Lofting the cyberwinds on teknoleather wings, I am...The Blue Drache

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

#5 ·  Posted (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.

#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 by AdamUL
1 person likes this

Share this post


Link to post
Share on other sites

#6 ·  Posted (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 by marko001

Share this post


Link to post
Share on other sites

#7 ·  Posted (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. :graduated: If it's there, it can be compromised. Always.

Edited by Unsigned
1 person likes this

LA-based actor, part-time freelance security analyst and assembly/C/C++ kernel developer. (Extra cash is goooood.)

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  
Followers 0