A3X Script Extract - detect + extract A3x embedded resource

[Ascend4nt]

A3X Script Extract

---

With newer versions of AutoIT (v3.3.10.0+), the compiled script is no longer appended to files as an overlay, and instead is embedded as a binary resource.  This leads my previous AutoIt-script detection UDF lacking.  However, since that UDF (>PE File Overlay Extraction) was targeted towards overlays in general, its still a worthwhile tool to have.

This UDF on the other hand is pretty specific - it lets you detect and optionally extract A3X scripts from a compiled executable.  The method is rather straightforward - it looks for a resource type of RT_RCDATA with a resource name of "SCRIPT", and then extracts the binary, testing for the A3X signature along the way.

The main UDF has two functions:

• _FileContainsScriptResource()
• _FileContainsA3XScript()

The first of these functions is there only for checking if a resource with "SCRIPT" exists.  Its main purpose is to report on possible embedded scripts.  I made this a separate function primarily because of issues with compressed executables.  Tools like UPX and MPRESS can compress the resources as well as the rest of the executable, so any detection of the A3X signature will fail in those circumstances.  (Note that UPX and MPRESS don't compress overlay data, which is why the older Overlay-Extraction A3X-detection worked regardless)

The second function will both check for and optionally return the A3X script resource as binary.  It also does a signature check for verification.

Anyway, here's an example of its usage.  The main UDF is attached below.

expandcollapse popup

#include <_FileContainsA3XScript.au3>
; ========================================================================================================
; <A3XScriptExtract.au3>
;
; Example of detecting AutoIt Scripts embedded as binary resources (in AutoIt v3.3.10.0+ exe's), and
; extracting them to .A3X files.
;
; This script can be invoked in interactive or command-line mode.
; Passing an executable as a parameter will extract an A3X resource, writing it out to
; an A3X file with the same base name as the executable.
;
; Uses <_FileContainsA3XScript.au3> functions
;
; Author: Ascend4nt
; ========================================================================================================


; ---------------------- MAIN CODE -------------------------------

Local $sFile, $sLastDir, $sLastFile, $binA3X, $iErr, $nA3XSize

; Command-line parameter received? Simply do a direct A3X extraction
If $CmdLine[0] Then
    $sFile = $CmdLine[1]
    If Not FileExists($sFile) Then Exit 1
    $binA3X = _FileContainsA3XScript($sFile, True)
    If @error Then Exit @error
    $nA3XSize = @extended

    Local $nExt = StringInStr($sFile, '.', 0, -1)
    If $nExt Then
        $sFile = StringLeft($sFile, $nExt - 1)
    EndIf
    $sFile &= '.a3x'
    Exit Not FileWrite($sFile, $binA3X)
EndIf

; No command-line parameters, query the user in interactive mode
$sLastDir = @ScriptDir
While 1
    $sFile=FileOpenDialog("Select PE File To Look for Embedded A3X scripts In",$sLastDir,"PE Files (*.exe;*.dll;*.scr)|All Files (*.*)",3,$sLastFile)
    If @error Or $sFile="" Then Exit
    $sLastFile = StringMid($sFile, StringInStr($sFile, '\', 1, -1) + 1)
    $sLastDir = StringLeft($sFile, StringInStr($sFile, '\', 1, -1) - 1)

; Resource 'Script' check
    $bScriptResourceFound = _FileContainsScriptResource($sFile)
    ConsoleWrite("_FileContainsScriptResource() return: " & $bScriptResourceFound & ", @error = " & @error & ", @extended = " & @extended & @CRLF)

; Actual A3X script resource check. True to return the A3X script as binary
    $binA3X = _FileContainsA3XScript($sFile, True)
    $iErr = @error
    $nA3XSize = @extended

    ; No A3X script found?
    If $iErr Or $nA3XSize = 0 Then
        ConsoleWrite("Failed Return from _FileContainsA3XScript(), @error = " & $iErr & ", @extended = " & $nA3XSize & @CRLF)
        MsgBox(64, "No AutoIt A3X script resource Found", "AutoIt A3X script resource not Found!" & @CRLF & _
            ($bScriptResourceFound ? "However, *A* script resource was found" : "No 'Script' resource found either") & @CRLF & _
            "for '" & $sLastFile & "'")
        ContinueLoop
    EndIf

    ConsoleWrite("_FileContainsA3XScript() return type: " & VarGetType($binA3X) & ", value = " & (IsBinary($binA3X) ? "[A3X_Binary]" : $binA3X) & @CRLF)
    ConsoleWrite(@TAB & "@error = " & $iErr & ", @extended = " & $nA3XSize & @CRLF)


    Local $hFileOut = -1, $sOutFile, $iMsgBox, $bSuccess = 0
    $iMsgBox = MsgBox(35, "A3X script resource found in " & $sLastFile, "A3X script resource found. File size: " & FileGetSize($sLastFile) & _
        ", A3X script size: " & $nA3XSize & @CRLF & @CRLF & _
        "Would you like to Extract and save A3X file?")

    If $iMsgBox = 6 Then
;~         If $nA3XSize > 134217728 Then
;~             MsgBox(48, "A3X script is too huge", "A3X script size is > 128MB, skipping..")
;~             ContinueLoop
;~         EndIf
        $sOutFile = FileSaveDialog("A3X script - SAVE: Choose a file to write A3X script data to (from " & $sLastFile&")", _
            $sLastDir, "AutoIt Compiled Sript (*.a3x)|All (*.*)", 2 + 16)
        If @error Then ContinueLoop

        ; Simple check for extension - if none, add .a3x
        If StringInStr($sOutFile, '.') = 0 Then $sOutFile &= ".a3x"

        ; Else
        $hFileOut = FileOpen($sOutFile, 16 + 2)
        If $hFileOut <> - 1 Then
            $bSuccess = FileWrite($hFileOut, $binA3X)
            FileClose($hFileOut)
        EndIf
    Else
        ContinueLoop
    EndIf

    If $bSuccess Then
        ShellExecute(StringLeft($sOutFile,StringInStr($sOutFile,'\',1,-1)-1))
    Else
        MsgBox(64, "Error Opening or writing to file", "Error opening, reading, or saving A3X file")
    EndIf
WEnd
Exit

_FileContainsA3XScript.au3

*edit: Modified example: Now alternatively accepts a command-line parameter for automated script extraction

Edited January 10, 2014 by Ascend4nt

[aminfear]

How can i use this 

sorry im noob

[Melba23]

aminfear,

Welcome to the AutoIt forum.

No problem being new (we all were at one point) but if you have to ask then you do not need to use it - so your question is entirely moot.

M23

[aminfear]

Melba23

Thanks admin !

Ive got the rules of here..

[Melba23]

aminfear,

I am not the Admin - he is far too busy.

And the "rules of here" have nothing to do with this - although you might like to read the Forum rules (there is also a link at bottom right of each page) if you have not already done so. The point is that the purpose and use of this UDF is so evident to anyone who understands AutoIt (and very clearly explained in the first post) that having to ask the question means that you probably would not understand any further answers that were given.

As a complete beginner to AutoIt (which we all were at some point, so no problem there) might I suggest reading the Help file (at least the first few sections - Using AutoIt, Tutorials and the first couple of References) as this will help you enormously. You should also look at this excellent tutorial - you will find other tutorials in the Wiki (the link is at the top of the page). Once you understand how AutoIt works and is compiled, you will see the utility and purpose of this UDF.

And now back to our normal programming...

M23

[guinness]

Nice. It moves on from my _GetSavedSource() function I created. Is there a reason you went for DllCalls and not the relevant functions in WinAPI?

One suggestion, just change A3X to a3x, is just looks better.

Edited January 5, 2014 by guinness

[Ascend4nt]

..

The point is that the purpose and use of this UDF is so evident to anyone who understands AutoIt (and very clearly explained in the first post) that having to ask the question means that you probably would not understand any further answers that were given.

Actually, and not to knock you Melba, but I believe the A3X compiled format isn't documented in enough places, which can cause some to totally not understand it.  Thats probably not exactly what aminfear meant, but I remember not knowing at first that A3X is both an option to use as a compile-to target and also the embedded resource type (or overlay, in previous versions) in an AutoIt executable.

[Ascend4nt]

Nice. It moves on from my _GetSavedSource() function I created. Is there a reason you went for DllCalls and not the relevant functions in WinAPI?

One suggestion, just change A3X to a3x, is just looks better.

The resource code was pretty much copied from an earlier UDF I wrote to read the Manifest (_FileReadManifest).. but I see now that the API functions are now part of the standard AutoIt UDF's.  Ah well, I could write a _WinAPI_... version but at least I know this UDF will work on older versions of AutoIt.   By the way, isnt _GetSaveSource() only for an embedded text file?

I did go ahead and make the appended extension part of the example a lowercase 'a3x'. Thanks

[guinness]

You know I hold the help file close to my heart, a3x is documented in certain parts of the help file. Whether needs to be revised remains to be seen, as Melba23 did add additional information about including a .a3x as though it was a standard .au3 file.

[guinness]

By the way, isnt _GetSaveSource() only for an embedded text file?

Yes, so it's slightly different in that I required a user to have previously used the AutoIt3Wrapper directive. We both "mess around" with the resources of the executable, which is where the similarity ends.

I did go ahead and make the appended extension part of the example a lowercase 'a3x'.

Thanks

[Melba23]

Ascend4nt,

 

I believe the A3X compiled format isn't documented in enough places

[...]

that A3X is both an option to use as a compile-to target and also the embedded resource type (or overlay, in previous versions) in an AutoIt executable

I will take a look tomorow and see what we can do to make it clearer.

M23

[Mobius]

What purpose does extracting the A3X serve since:

* Decompilation is no longer supported.

* The A3X is written as a standalone application which is no good for inclusion in its raw form in another script. (3.3.10.0+)

Vlad

Edited January 6, 2014 by Mobius

[Ascend4nt]

Ascend4nt,

 

I will take a look tomorow and see what we can do to make it clearer.

M23

Melba, here's one place the documentation could be modified:

Macro Reference

- @Compiled returns 1 for A3X scripts also, not just executables

- @AutoItExe will return the path to the AutoIt executable for A3X-compiled scripts

- @ScriptName will return the executable name for scripts compiled to executable. Otherwise it will return the AU3 or A3X name

Along the same notes:

Running another script or compiled executable using /AutoIt3ExecuteScript will cause @AutoItExe to take on the executable name of the program invoking the given script, and otherwise will behave like an A3X-compiled script.

If /AutoIt3ExecuteScript is used on another executable, the script will not have access to resources embedded in the executable without treating it as an external module.

[Ascend4nt]

What purpose does extracting the A3X serve since:

* Decompilation is no longer supported.

* The A3X is written as a standalone application which is no good for inclusion in its raw form in another script. (3.3.10.0+)

Vlad

Mobius,

The A3X file can be used for whatever purpose the person using the script wants it for (including running it standalone or #include'ing it).  It's not my place to say what it should or should not be used for.  The reasoning behind me writing the script is moreso a matter of me asking 'can I?', rather than having some grander plan on what to do with extracted A3X scripts.

While people could potentially use the script for malicious intent, that's not my concern, nor is it my responsibility.  There are plenty of scripts on the forums that can be used for malicious intent (embedding and hiding executables and resources, manipulating Windows' behavior, etc).  This script on its own amounts to little more than a simplified version of resource extraction.  And that in itself is nothing new - anyone can grab a Resourcce Hacker tool to pull out or edit resources.  I just perhaps made it a little more accessible for people.

This whole A3X-detect project grew out of a need to prevent a certain program - namely 'FileOptimizer' - from stripping the A3X overlays from executables (they've since addressed that issue).  That project became >PE File Overlay Extraction, which itself turned out to be a very nice tool for things other than A3X script detection.  For example, if I am suspcious of a certain executable, I can now extract and examine just the overlay to see if there's anything suspicious in it (perhaps identifying it with TrID).

Since I'm a completionist, I decided that the previous project was not fully done, so I wrote more code to detect newer compiled scripts.  And of course I thought it'd be neat to add the option to extract that file in addition to detecting it.  And wa-la, A3X Script Extract.

Anyway, long story short, I wrote this script just because 'it can be done'. I provide it free, and people can make their own decisions on what to do with it.

Oh, and about your points:

- Decompilation: I'm sure someone out there is probably working on updating '3rd party' decompilers for the latest version. Truthfully, it's always bothered me a little that only the developers can decompile our scripts.  Wouldn't it seem more fair that we should be able to encode our scripts so that only we the programmers could extract them?  That's why in general I really don't care about decompilers.

- A3X being #include'd in another script: This can actually be done with many scripts.  You can just put the #include after some code that precedes it.  Not that there's many good reasons to do so.  Its just more interesting that you can detach the A3x script from an EXE and run it on its own, really.

[guinness]

- A3X being #include'd in another script: This can actually be done with many scripts.  You can just put the #include after some code that precedes it.

See I like this, because I can now publish a "closed source" UDF and just have to worry about the documentation.

[Melba23]

Ascend4nt,

 

While people could potentially use the script for malicious intent, that's not my concern, nor is it my responsibility

While understanding your point of view, I am afraid that it is not one with which I can agree - but that discussion is best taken elsewhere.

Thanks for the Help file suggestions - I will see how they can be inserted. I have already added some explanatory text to the <Using Autoit - Compiling Scripts with Aut2Exe> section.

Mobius,

 

The A3X is written as a standalone application which is no good for inclusion in its raw form in another script

But that is exactly what you can do now - 3.3.10.0+ has the ability to include .a3x as well as .au3 files.

M23

[Mobius]

Ascend4nt,

Yes, thankyou for all that

So its a case of "I wrote it because I can", nothing wrong with that at all.

However unlike code that rescues the overlay (pre 3.3.10.0) from the large array of tools that don't support it, which serves an important purpose, extraction of the a3x component from the resource table does not.

One might argue that the extracted a3x of a standalone could indeed be included in another script (which it could from a development standpoint) , said standalone would have to be written unlike a normal standalone because the source from the a3x and the parent script would undoubtedly conflict at runtime, further reducing feasibility.

You are right about 3rd party decompilers, but whose talking about them, I was talking about the once supported official decompiler, a tool that the author of a standalone might use to retrieve their source (or even a tool that one might give to a client so they could validate the product) , which would lend weight to the idea (need) of extracting the a3x from the resource.

As for someone using your code maliciously; no not really, for obvious reasons, one of which you mention yourself.

Anyway, nice example script showing resource manipulation keep at it.

@Melba23

This I am aware of, however once included by Aut2exe is it added in its raw binary form to the a3x structure in much the same way as FileInstall, so it can be executed as a separate entity much like a function, or is the sourcecode extracted from the a3x by Aut2exe which it then adds to the main source like including would normally, I pray the prior but I think the latter.

Vlad

Edited January 9, 2014 by Mobius

[Ascend4nt]

However unlike code that rescues the overlay (pre 3.3.10.0) from the large array of tools that don't support it, which serves an important purpose, extraction of the a3x component from the resource table does not.

Mobius,

Are you saying that A3X extraction doesn't serve any purpose, or just some subjective 'important' purpose?  If its the former, then I'd be calling you out on failure of imagination.  

I'll just give two simple scenarios:

1. You compile a script to executable, but also want an a3x compile target.  Should you be forced to edit the compiler options (thereby modifying the original script), and rerun Obfuscator + Aut2Exe for each script?  This is something you absolutely have to do - you can't compile to both A3X and Exe. It's one or the other.

   Solution? Use a simple A3X-Extract script on the resulting executable - perhaps as a 'Run after' command

    

2. You have an executable but not the original script at hand, and find that you need the smaller footprint that A3X provides.. If AutoIt is installed or available locally, you can simply extract the A3X file and delete the executable (assuming there's no resources or metadata you want to keep from the executable).

There's of course other things you can do with A3X scripts that you can't with executables, some of which has been covered..

One example is using /AutoIt3ExecuteScript to run A3X thats embedded in any other type of file (bitmap, for example).  Its of course a bit of a suspicious thing to do, but nonetheless interesting.

 

[Mobius]

Ascend4nt,

Not sure where I was going when I entered this thread, nowhere productive it seems.

My bad.

Vlad