Leaderboard

It's about running exe from memory as it's often called. So you have some binary data that you want to embed in your script and run afterward like some additional program. In this post I will try to explain how to do it. First to deal with mentioned binary as that's, in spite of the plainness of retrieving it, often insuperable. To avoid questions about that this is one way of getting it: Global $sModule = "E:Program filesGUIDGenGUIDGEN.EXE" ; change to yours wanted Global $hModule = FileOpen($sModule, 16) If @error Then Exit Global $bBinary = FileRead($hModule) FileClose($hModule) Global Const $MAX_LINESIZE = 4095 Global $iNewLine, $j Global $iChinkSize = 32 Global $sBinary For $i = 1 To BinaryLen($bBinary) Step $iChinkSize $j += 1 If 4*($j * $iChinkSize) > $MAX_LINESIZE - 129 Then $iNewLine = 1 EndIf If $iNewLine Then $iNewLine = 0 $j = 0 $sBinary = StringTrimRight($sBinary, 5) $sBinary &= @CRLF & '$bBinary &= "' & StringTrimLeft(BinaryMid($bBinary, $i, $iChinkSize), 2) & '" & _' & @CRLF ContinueLoop EndIf If $i = 1 Then $sBinary &= '$bBinary = "' & BinaryMid($bBinary, $i, $iChinkSize) & '" & _' & @CRLF Else $sBinary &= ' "' & StringTrimLeft(BinaryMid($bBinary, $i, $iChinkSize), 2) & '" & _' & @CRLF EndIf Next $sBinary = StringTrimRight($sBinary, 5) ClipPut($sBinary) ConsoleWrite($sBinary)Now for what's really important... Executable file causes a computer to perform indicated tasks according to encoded instructions. Files that we talk about are in PE format. When exe file is run special loader reads it and performs act of loading. That's how that particular exe gets in touch with a processor. Processor then executes different actions described by the opcodes. Main requirement for any PE file required by the loader is for it to actually exist. To be written on the drive. It can't be in the air. That's not allowed and when you think of it it's only logical. So how to run from memory? I'm gonna fool the system. It will think that all works as it should and will have no idea that it plays my game. There is more than way of doing that. Method described here has been used by different peoples before. When doing research for this post I have encountered many implementations. And I must say that I was very disappointed seeing that even the writers of the code often lack understanding of it. It's kind of pathetic when you see some code used and when asking author what's this or that you get answer "I don't know". And if you ask for the code to be explained by words (any fucking human language) coders fail terribly. How can you write code if you can't explain it?!? Anyway, this is the procedure: Start your script Create new process using CreateProcess function with CREATE_SUSPENDED flag Use GetThreadContext function to fill CONTEXT structure Read and interpret passed binary Allocate enough memory for the new module inside the victim process Simulate loader. Construct the new module (load) in place of allocated space. Make use of mentioned CONTEXT structure. Change entry point data and ImageBaseAddress data. Resume execution If all that went well windows should now be running not the original module but the new, saved in script as a variable. The script: RunBinary.au3 Script is well commented so it shouldn't be too hard to get a grip. New script is taking all possible advantages of PE format. That means if your module (embedded) has relocation directory it will run for sure.If not it could fail. When it will fail? Modules with no reloc directory (IMAGE_DIRECTORY_ENTRY_BASERELOC) ought to be loaded at precise address (stored within module; IMAGE_OPTIONAL_HEADER ImageBase). If for some reason not enough space can be allocated at that address within victim's memory space, function will fail. Thing is system makes rules, if we are not allowed to some memory space of a process there is nothing to do then to try again. So, try again if it fails. Maybe change the 'victim'. edit: 64bit support added. That means you can embed either x64 or x86 modules. If your AutoIt is x64 you embed x64 modules. If AutoIt is x86 embed x86. x64 AutoIt could also use embedded x86 modules but I don't like that because needed structures would have to be changed to something that's not meeting aesthetics standards .

S3d.au3 This UDF enables you to draw simple 3D graphics. Features: Simple and easy to useDoesn't require external libraries. You don't need OpenGL or DirectX. Available Functions: _S3d_SelectGraphic($hGraphic, $iWidth, $iHeight, $iSmooth = 2) _S3d_SelectPen($hPen) _S3d_SelectBrush($hBrush) _S3d_SelectFont($hFont) _S3d_SelectFormat($hFormat) _S3d_SetClipCount($iCount) _S3d_Dist($nPos1X = 0, $nPos1Y = 0, $nPos1Z = 0, $nPos2X = 0, $nPos2Y = 0, $nPos2Z = 0) _S3d_DistFromCamera($nPosX = 0, $nPosY = 0, $nPosZ = 0) _S3d_SetCamera($nCameraX, $nCameraY, $nCameraZ, $nTargetX, $nTargetY, $nTargetZ, $nVAngle = 0, $nFAngle = 0.8, $nFScale = 1000) _S3d_SetCameraEx($nCameraX, $nCameraY, $nCameraZ, $nXYAngle = 0, $nXZAngle = 0, $nVAngle = 0, $nFAngle = 0.8, $nFScale = 1000) _S3d_SetLocalMatrix($n00 = 1, $n01 = 0, $n02 = 0, $n03 = 0, $n10 = 0, $n11 = 1, $n12 = 0, $n13 = 0, $n20 = 0, $n21 = 0, $n22 = 1, $n23 = 0, $n30 = 0, $n31 = 0, $n32 = 0, $n33 = 1) _S3d_MultiplyLocalMatrix($n00 = 1, $n01 = 0, $n02 = 0, $n03 = 0, $n10 = 0, $n11 = 1, $n12 = 0, $n13 = 0, $n20 = 0, $n21 = 0, $n22 = 1, $n23 = 0, $n30 = 0, $n31 = 0, $n32 = 0, $n33 = 1, $fRefresh = True) _S3d_LocalTranslate($nX, $nY, $nZ, $fRefresh = True) _S3d_LocalScale($nX, $nY, $nZ, $fRefresh = True) _S3d_LocalRotateX($nAngle, $fDeg = False, $fRefresh = True) _S3d_LocalRotateY($nAngle, $fDeg = False, $fRefresh = True) _S3d_LocalRotateZ($nAngle, $fDeg = False, $fRefresh = True) _S3d_GetLocalMatrix() _S3d_SetLocalMatrixEx(ByRef $aMatrix) _S3d_GetPos($nX, $nY, $nZ) _S3d_InitCurrentPos() _S3d_MoveTo($nX, $nY, $nZ = Default) _S3d_Clear($nColor = 0xFF000000) _S3d_Line($nX1, $nY1, $nZ1, $nX2, $nY2, $nZ2) _S3d_LineTo($nX, $nY, $nZ) _S3d_Box($nX1, $nY1, $nZ1, $nX2, $nY2, $nZ2) _S3d_Arrow($nX1, $nY1, $nZ1, $nX2, $nY2, $nZ2, $nLen = 30, $nAngle = 0.6) _S3d_Circle($nX, $nY, $nZ, $nRad, $fFill = False) _S3d_Polygon($aPoints, $fFill = False) _S3d_RegPolygon($nX, $nY, $nZ, $nRad, $iNum, $fFill = True) _S3d_Star($nX, $nY, $nZ, $nRad1, $nRad2, $iNum, $fFill = True) _S3d_Square($nX1, $nY1, $nZ1, $nX2, $nY2, $nZ2, $nX3, $nY3, $nZ3, $nX4, $nY4, $nZ4, $fFill = True) _S3d_MoveTo2($nXL, $nYL, $nZL, $nXR, $nYR, $nZR) _S3d_RibbonTo($nXL, $nYL, $nZL, $nXR, $nYR, $nZR) _S3d_String($sString, $nX, $nY, $nZ) New version!S3d.zip v1.3.1 (09/JUN/2014) * Archives S3d.zip v1.3.0 (05/SEP/2013) S3d.zip v1.2.3 (16/AUG/2013) Enjoy!

File Name: AutoIt v3.3.9.16 Beta File Submitter: Jon File Submitted: 10 Aug 2013 File Category: Beta 3.3.9.16 (10th August, 2013) (Beta) AutoIt: - Fixed: DriveGetType() was incorrectly reporting SSD on Windows XP. - Fixed #1024: GUICtrlSetTip() for tabitems sets incorrectly in certain situations. UDFs: - Added: Constants for DriveGetType() and StringSplit(). See related function documentation for more details. - Added: InetConstants.au3 for use with Inet functions. See related function documentation for more details. - Changed: _FileListToArrayRec() to use functions in the Array UDF. - Fixed: _ArrayTranspose() would crash with one dimension and 4096 elements or greater. - Fixed #2378: BITMAPV4HEADER and BITMAPV5HEADER Structures using incorrect array values. Click here to download this file

----------------

i fixed it already in my post. your program looks like a copy and paste work. that's not the best way to learn a language. use Tidy from scite to structure your script.

Even so, advanced AutoIt programmers use Includes, I mean why have a dog and bark yourself!

It's willichan, not Headless Chicken.

Run your process as admin and create the installer processes from your process. Any child process will run with the same access and should not trigger UAC. I use several installers (MSI and other) in my scripts this way and it works fine, only the first UAC (the prompt to start my own script) ever fires.

I have to go along with jchd on the concurrency issue. I have personally hit on the concurrent INI file writes issue, as well as other concurrency issues in the past. That was why I wrote the cooperative semaphore UDF. If you are going to have two processes (which I don't see a good way around given the original OP post) you need to implement file locking or semaphores.

Ok... I think I understand now. One of the nice things with Obfuscator is that it has a pretty complete Log file from each run... this is what happens with the includes: The WinAPi is included twice because obfuscator assumes they are different files on different locations. So I am now wondering if I am using the wrong logic and need to Include from the Current dir were this file is located containing the #include statement when #include "file-to-be-included.au3" is used. Jos EDIT: So #include "whatever-file" is expected to be in the directory that contains the file having the #Include statement. This needs to be changed in Obfuscator. As a side note: This appearing after so many years probably is also a good indication you really shouldn't be same name includes at multiple locations.