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 .

I have converted and extended the adfunctions.au3 written by Jonathan Clelland to a full AutoIt UDF including help file, examples, ScITE integration etc. The example scripts should run fine without changes. 2016-08-18: Version: 1.4.6.0 As always: Please test before using in production! KNOWN BUGS: (Last changed: ) None AD 1.4.6.0.zip For AutoIt >= 3.3.12.0 AD 1.4.0.0.zip other versions of AutoIt

Compare the X position from the DLLStructGetData($tWindowPos, "X") and the $aWinGetPos[0]. If the new X is greater than the $aWinGetPos[0] then allow the move, if the new X is less than the $aWinGetPos[0] then set the X position using the commented out line.

#include <GUIConstantsEx.au3> #include <StructureConstants.au3> #include <WindowsConstants.au3> Local $hGUI = GUICreate("GUI") GUISetState(@SW_SHOW, $hGUI) GUIRegisterMsg($WM_WINDOWPOSCHANGING, 'WM_WINDOWPOSCHANGING') While (True) Switch (GUIGetMsg()) Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd Func WM_WINDOWPOSCHANGING($hWnd, $iMsg, $wParam, $lParam) #forceref $iMsg, $wParam, $lParam Local $aWinGetPos = WinGetPos($hWnd) If @error Then Return $GUI_RUNDEFMSG Local $tWindowPos = DllStructCreate($tagWINDOWPOS, $lParam) ;~ DllStructSetData($tWindowPos, 'X', $aWinGetPos[0]) ; Lock the X position DllStructSetData($tWindowPos, 'Y', $aWinGetPos[1]) ; Lock the Y position Return $GUI_RUNDEFMSG EndFunc ;==>WM_WINDOWPOSCHANGING

Read: https://www.autoitscript.com/wiki/Interrupting_a_running_function

Have you tried changing An unknown error occurred code to the real corresponding error?

Your code looks too complex to me. You should really add few comments so that others (me - for example) can understand what are you trying to do with each step. Things that look obvious to you may not be that obvious to others. Aside from that, why don't you use WinHttp.au3 in more advanced way? The UDF is probably smarter than you think it is. For example, I just used this code to pick a pic from my comp and upload it to a group: #include "WinHttp.au3" Global Const $sFB_Email = "yaEmail.@domain.com" ;<- your email here Global Const $sFB_sPassword = "p@$$w0rd" ;<- your password here $sGroupID = "5555555555555555" ; group ID you want to post to $sPic = FileOpenDialog("Choose Pic to post", "", "Image (*.jpg;*.png;*.gif;*.bmp)"); choose a file you want to post If $sPic Then ConsoleWrite(FB_PostPicToGroup($sGroupID, $sPic) & @CRLF) Func FB_PostPicToGroup($sGroupID, $sPic) Local $iSuccess = 0 ; preset output (failure) ; Open session Local $hOpen = _WinHttpOpen() ; Connect Local $hConnect = _WinHttpConnect($hOpen, "https://m.facebook.com/") ; Login first (by filling login form) Local $sRead = _WinHttpSimpleFormFill($hConnect, _ ; connection handle "login.php", _ ; target page "login_form", _ ; form identifier "name:email", $sFB_Email, _ ; first field identifier paired with field data "name:pass", $sFB_sPassword) ; second field identifier paired with data ; Check for errors If Not @error And @extended = $HTTP_STATUS_OK Then ; Navigate to the Group and ask for pic upload Local $aRead = _WinHttpSimpleFormFill($hConnect, _ ; connection handle "/groups/" & $sGroupID, _ ; target page "index:1", _ ; form identifier (by index here, because id or name doesn't exist) "name:view_photo", True, _ ; identify submit control and click it "[RETURN_ARRAY]") ; return array because current URL is needed ; Check for errors If Not @error And @extended = $HTTP_STATUS_OK Then ; Read current URL (go with the flow) Local $aURL = _WinHttpCrackUrl($aRead[2]) If Not @error Then ; check for error ; Upload file $aRead = _WinHttpSimpleFormFill($hConnect, _ ; connection handle $aURL[6] & $aURL[7], _ ; target page Default, _ ; form identifier (default is used for simplicity because it's the only form on that page) "name:file1", $sPic, _ ; form field used for file "[RETURN_ARRAY]") ; return array because current URL is needed ; Check for errors If Not @error And @extended = $HTTP_STATUS_OK Then ; Read current URL now $aURL = _WinHttpCrackUrl($aRead[2]) ; check for error If Not @error Then ; Finally submit the post _WinHttpSimpleFormFill($hConnect, _ ; connection handle $aURL[6] & $aURL[7], _ ; target page Default, _ "name:view_post", True) If Not @error And @extended = $HTTP_STATUS_OK Then $iSuccess = 1 EndIf EndIf EndIf EndIf EndIf ; Close handles _WinHttpCloseHandle($hConnect) _WinHttpCloseHandle($hOpen) ; Bye... Return $iSuccess EndFunc Does it do what you want it to do?

After some tests to resolve the problem within the same script, I gave up and followed jdelaney's advice in post #4 in this way: from the main script, i call a compiled script that performs in turn the action of clicking on the main form, opening the modal window, so the main script doesn't stop and statements that follows are executed normaly From the main script: Run("Click_For_Me.exe") ; instead of _IEAction ($oButton,"click") This is the source of the compiled script: #include <IE.au3> ; attach to main web page already opened by the main script $oIE = _IEAttach("BMC Software") ; reference to the Frame Local $oFrame = _IEFrameGetObjByName($oIE, "main-frame") ; reference to the button within the frame Local $oButton = _IEGetObjById($oFrame,"ManageDtls") ; performs the click on that button ; that will open the modal windows _IEAction ($oButton,"click") anyway I still do not understand why this strange problem occurs, i think that autoit should handle this situations. Is it an autoit bug?