Leaderboard

Spammer ...whom is now zapped?

Maybe you can use the info here? https://docs.microsoft.com/en-us/windows/win32/inputdev/keyboard-input

ah ....wait a sec: don't tell you are trying to run a file from a google drive directory? Try a script file from a C drive to see if that works..

Same here...Deleted.

1) Couldn't you have just posted an image? 2) This file triggers all kinds of virus warnings 3) Reported!

or the short version: ; disable "www.facebook.com" #RequireAdmin $sURL = "www.facebook.com" $sHostsFile = @WindowsDir & "\system32\drivers\etc\hosts" $iReadonly = StringInStr(FileGetAttrib($sHostsFile), "R") If $iReadonly Then FileSetAttrib($sHostsFile, "-R") If Not StringInStr(FileRead($sHostsFile), $sURL) Then FileWrite($sHostsFile, @CRLF & "127.0.0.1" & @TAB & @TAB & $sURL & @CRLF) If $iReadonly Then FileSetAttrib($sHostsFile, "+R") ShellExecute("Notepad.exe", $sHostsFile)

I think there is a simple explanation: The file is write-protected. Here is a script to enter the URL in the hosts file anyway: ; disable "www.facebook.com" #RequireAdmin $sURL = "www.facebook.com" $sHostsFile = @WindowsDir & "\system32\drivers\etc\hosts" ConsoleWrite(@CRLF & "Admin rights are " & (IsAdmin() ? "" : "NOT ") & "detected." & @CRLF & @CRLF) ConsoleWrite($sHostsFile & " is " & (StringInStr(FileGetAttrib($sHostsFile), "R") ? "readonly." : "writable.") & @CRLF & @CRLF) $sText = FileRead($sHostsFile) ConsoleWrite("Error: " & @error & " Extended: " & @extended & " Line: " & @ScriptLineNumber & @CRLF & @CRLF & $sText & @CRLF & @CRLF) If StringInStr($sText, $sURL) Then ConsoleWrite("URL already present" & @CRLF) Else $iReadonly = StringInStr(FileGetAttrib($sHostsFile), "R") If $iReadonly Then FileSetAttrib($sHostsFile, "-R") ConsoleWrite($sHostsFile & " is " & (StringInStr(FileGetAttrib($sHostsFile), "R") ? "readonly." : "writable.") & @CRLF & @CRLF) $rc = FileWrite($sHostsFile, @CRLF & "127.0.0.1" & @TAB & @TAB & $sURL & @CRLF) ConsoleWrite("Error: " & @error & " Extended: " & @extended & " Line: " & @ScriptLineNumber & " RC: " & $rc & @LF) If $iReadonly Then FileSetAttrib($sHostsFile, "+R") ConsoleWrite($sHostsFile & " is " & (StringInStr(FileGetAttrib($sHostsFile), "R") ? "readonly." : "writable.") & @CRLF & @CRLF) $sText = FileRead($sHostsFile) ConsoleWrite("Error: " & @error & " Extended: " & @extended & " Line: " & @ScriptLineNumber & @CRLF & @CRLF & $sText & @CRLF & @CRLF) EndIf ShellExecuteWait("Notepad.exe", $sHostsFile) ShellExecute("Explorer.exe", StringTrimRight($sHostsFile, 6)) see a short version in next post

I have no explanation why the filewrite on line 12 doesn't work. There seems to be some authorization problem. Try not to name the script "c :\11.au3", but "c :\users\pc\desktop\test.au3 Please put the console log back into a spoiler. Thanks

Can you please run the following code and post the complete console log in a spoiler. ; disable "www.facebook.com" #RequireAdmin $sURL = "www.facebook.com" $sHostsFile = @WindowsDir & "\system32\drivers\etc\hosts" $sText = FileRead($sHostsFile) ConsoleWrite("Error: " & @error & " Extended: " & @extended & " Line: " & @ScriptLineNumber & @CRLF & @CRLF & $sText & @CRLF & @CRLF) If StringInStr($sText, $sURL) Then ConsoleWrite("URL already present" & @CRLF) Else $rc = FileWrite($sHostsFile, @CRLF & "127.0.0.1" & @TAB & @TAB & $sURL & @CRLF) ConsoleWrite("Error: " & @error & " Extended: " & @extended & " Line: " & @ScriptLineNumber & " RC: " & $rc & @LF) EndIf $sText = FileRead($sHostsFile) ConsoleWrite("Error: " & @error & " Extended: " & @extended & " Line: " & @ScriptLineNumber & @CRLF & @CRLF & $sText & @CRLF & @CRLF) ShellExecute("Notepad.exe", $sHostsFile)

Executing Object Methods through VBScriptIn IPC Techniques through ROT Objects (Data types section) the AutoIt data types have been tested based on the example for the VarGetType() function in the help file. The data types are sent from Sender to Receiver with these results: $aArray : Array variable type. $dBinary : Binary variable type. $bBoolean : Bool variable type. $pPtr : Int32 variable type. $hWnd : Int32 variable type. $iInt : Int32 variable type. $fFloat : Double variable type. $oObject : Object variable type. $sString : String variable type. $tStruct : Not recognized as a valid variable type. $vKeyword : Keyword variable type. fuMsgBox : Not recognized as a valid variable type. $fuFunc : Not recognized as a valid variable type. $fuUserFunc : Not recognized as a valid variable type. Note that an AutoIt object is a data type that is sent correctly from one process to another through a ROT Object. What does it mean that an object is sent correctly from one process to another? This means that the object instance (the specific representation of the object) of the receiving process is exactly the same as the object instance of the sending process. The object of receiver and sender is simply the same object. It's the implementation of the ROT Object that ensures that the object of receiver and sender is the same. If an object $oHexEdit is sent from AutoIt code to VBScript code in this way: Local $sDictionaryData = "DictionaryData" ROT_RegisterObject( Default, $sDictionaryData ) ; Default => Object = Dictionary object Local $oROTobj = ObjGet( $sDictionaryData ) ; Dictionary object $oROTobj( "oHexEdit" ) = $oHexEdit and received in the VBScript code in this way: Dim oROTobj, oHexEdit Set oROTobj = GetObject( "DictionaryData" ) Set oHexEdit = oROTobj( "oHexEdit" ) then the $oHexEdit object in the AutoIt code and oHexEdit object in the VBScript code is the same object. Type mismatch errorWhat can all this be used for? This is an example of a Hex Editor ActiveX control based on this CodeProject article. A simple AutoIt implementation can look like this (HexEdit0.au3) #AutoIt3Wrapper_Au3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7 Opt( "MustDeclareVars", 1 ) #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> Example() Func Example() ; Create GUI GUICreate( "Hex Editor", 420, 420 ) ; Create COM error handler Local $oMyError = ObjEvent( "AutoIt.Error", "MyErrFunc" ) ; Create Com object Local $oHexEdit = ObjCreate( "HEXEDIT.HexEditCtrl.1" ) If Not IsObj( $oHexEdit ) Then Return ConsoleWrite( "$oHexEdit ERR" & @CRLF ) ConsoleWrite( "$oHexEdit OK" & @CRLF ) ; Create ActiveX control GUICtrlCreateObj( $oHexEdit, 10, 10, 400, 400 ) ; Show GUI GUISetState() ; Load HexEditDlg.exe into ActiveX control Local $hFile = FileOpen( "HexEditDlg.exe", 16 ), $dBinary = FileRead( $hFile ), $i = FileClose( $hFile ) ; 16 = $FO_BINARY $oHexEdit.SetData( $dBinary, 0 ) ; Loop While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd #forceref $oMyError, $i EndFunc Func MyErrFunc( $oError ) ConsoleWrite(@ScriptName & " (" & $oError.scriptline & ") : ==> COM Error intercepted !" & @CRLF & _ @TAB & "err.number is: " & @TAB & @TAB & "0x" & Hex($oError.number) & @CRLF & _ @TAB & "err.windescription:" & @TAB & $oError.windescription & @CRLF & _ @TAB & "err.description is: " & @TAB & $oError.description & @CRLF & _ @TAB & "err.source is: " & @TAB & @TAB & $oError.source & @CRLF & _ @TAB & "err.helpfile is: " & @TAB & $oError.helpfile & @CRLF & _ @TAB & "err.helpcontext is: " & @TAB & $oError.helpcontext & @CRLF & _ @TAB & "err.lastdllerror is: " & @TAB & $oError.lastdllerror & @CRLF & _ @TAB & "err.scriptline is: " & @TAB & $oError.scriptline & @CRLF & _ @TAB & "err.retcode is: " & @TAB & "0x" & Hex($oError.retcode) & @CRLF & @CRLF) EndFunc The HexEdit ActiveX control must be registered in an elevated Command Prompt with HexEditorOcx\register.bat included in the 7z-file below. HexEditDlg.exe is the test file that is loaded into the ActiveX control. Also contained in the 7z-file. You can also download it all directly from the CodeProject article. HexEditDlg.exe is the demo project. When you run the script in SciTE with F5 you'll see the following COM error in the console: $oHexEdit OK HexEdit0.au3 (30) : ==> COM Error intercepted ! err.number is: 0x80020005 err.windescription: Type mismatch. err.description is: err.source is: err.helpfile is: err.helpcontext is: err.lastdllerror is: 0 err.scriptline is: 30 err.retcode is: 0x00000000 Line 30 is this line: $oHexEdit.SetData( $dBinary, 0 ) The error is due to the binary data in $dBinary not being transferred correctly to the SetData() method. The first lines of the implementation of the SetData() method in HexEditCtl.cpp (not included in the 7z-file but can be downloaded from the article) looks like this: SCODE CHexEditCtrl::SetData(VARIANT FAR* pData, long dwStartAddr) { if ( ( pData->vt != (VT_ARRAY | VT_UI1) && pData->vt != (VT_ARRAY | VT_I1) ) || ::SafeArrayGetDim(pData->parray) != 1) VARIANT FAR* pData and pData->vt == (VT_ARRAY | VT_UI1) means that the first parameter in Setdata() must be a pointer to a variant, where the data field in the variant can contain a pointer to a safearray of bytes. A safearray of bytes is also referred to as a bytearray. In AutoIt, a bytearray is represented by the Binary data type. Since there are no other data types in AutoIt that correspond to a bytearray, there is actually not really anything to do about the error. The internal AutoIt code is capable of transferring the vast majority of parameter data types to an object method in the correct way. However, there are still several examples of parameter data types being passed incorrectly resulting in a data type mismatch error. And here the VBScript code comes into play. The VBScript language is coded by Microsoft, and Microsoft obviously knows how to pass data to an object method. The idea is to transfer both the $oHexEdit object and the binary data in $dBinary to a VBScript through a ROT Object and then execute the SetData() method directly in the VBScript. Executing VBScript codeHexEdit1.au3: #AutoIt3Wrapper_Au3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7 Opt( "MustDeclareVars", 1 ) #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> #include "IRunningObjectTable.au3" Example() Func Example() ; Create GUI GUICreate( "Hex Editor", 420, 420 ) ; Create COM error handler Local $oMyError = ObjEvent( "AutoIt.Error", "MyErrFunc" ) ; Create Com object Local $oHexEdit = ObjCreate( "HEXEDIT.HexEditCtrl.1" ) If Not IsObj( $oHexEdit ) Then Return ConsoleWrite( "$oHexEdit ERR" & @CRLF ) ConsoleWrite( "$oHexEdit OK" & @CRLF ) ; Create ActiveX control GUICtrlCreateObj( $oHexEdit, 10, 10, 400, 400 ) ; Show GUI GUISetState() ; Load HexEditDlg.exe into ActiveX control Local $hFile = FileOpen( "HexEditDlg.exe", 16 ), $dBinary = FileRead( $hFile ), $i = FileClose( $hFile ) ; 16 = $FO_BINARY Local $sDictionaryData = "DictionaryData" ROT_RegisterObject( Default, $sDictionaryData ) ; Default => Object = Dictionary object Local $oROTobj = ObjGet( $sDictionaryData ) ; Dictionary object $oROTobj( "oHexEdit" ) = $oHexEdit $oROTobj( "dBinary" ) = $dBinary RunWait( 'wscript.exe "HexEdit1.vbs"' ) ; Loop While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd #forceref $oMyError, $i EndFunc Func MyErrFunc( $oError ) ConsoleWrite(@ScriptName & " (" & $oError.scriptline & ") : ==> COM Error intercepted !" & @CRLF & _ @TAB & "err.number is: " & @TAB & @TAB & "0x" & Hex($oError.number) & @CRLF & _ @TAB & "err.windescription:" & @TAB & $oError.windescription & @CRLF & _ @TAB & "err.description is: " & @TAB & $oError.description & @CRLF & _ @TAB & "err.source is: " & @TAB & @TAB & $oError.source & @CRLF & _ @TAB & "err.helpfile is: " & @TAB & $oError.helpfile & @CRLF & _ @TAB & "err.helpcontext is: " & @TAB & $oError.helpcontext & @CRLF & _ @TAB & "err.lastdllerror is: " & @TAB & $oError.lastdllerror & @CRLF & _ @TAB & "err.scriptline is: " & @TAB & $oError.scriptline & @CRLF & _ @TAB & "err.retcode is: " & @TAB & "0x" & Hex($oError.retcode) & @CRLF & @CRLF) EndFunc HexEdit1.vbs: Dim oROTobj, oHexEdit, dBinary Set oROTobj = GetObject( "DictionaryData" ) Set oHexEdit = oROTobj( "oHexEdit" ) dBinary = oROTobj( "dBinary" ) oHexEdit.SetData dBinary, 0 The ActiveX control in the AutoIt GUI is updated directly through the code in the VBScript: Hopefully someone will take up the challenge and implement a more complete Hex Editor. This is just a Hex Viewer. 7z-fileThe 7z-file contains all the necessary code and data. You need AutoIt 3.3.12 or later. Tested on Windows 7 and Windows 10. HexEdit is a 32 bit control. The code only runs as 32 bit code. Comments are welcome. Let me know if there are any issues. ObjectMethods.7z

@TheXman:Thanks a bunch for scrutinising my patched version! I will implement the fixes soon. I did have a look at your CNG version 1.7, but as you already noted, the improvements you made were not going to impact CodeCrypter performance to any great extent, and I'm still not a fan of object-based notation, but I do appreciate your continuing efforts to make CNG the best it can possibly be. Sorry for the oversights on my part in adapting your work (bit distracted at the moment). @quimao: fix uploaded. Thanks for notifying me.

@RTFC I see a few differences between your modified version of CryptoNG and the original version that could be problematic. When comparing the version of CryptotNG.au3 that you distribute, which appears to be my v1.6.1, I think the following differences may need to be corrected. The last correction listed below, is definitely the reason why the hashing result is not being returned in the post above. In __CryptoNG_BCryptCreateHash, the following line should be changed from DllStructSetData($tHMACSecretBuffer,"data",$vHMACSecret) to DllStructSetData($tHMACSecretBuffer,"data",$xHMACSecret) In __CryptoNG_BCryptEncrypt_CBC, the following line should be changed from DllStructSetData($tIVBuffer,"data",$vIV) to DllStructSetData($tIVBuffer,"data",Binary($vIV)) In __CryptoNG_BCryptFinishHash, the following line should be changed from ;All is good DllStructGetData($tDataBuffer,"data") to $xHash = DllStructGetData($tDataBuffer,"data") For the record, as of this evening, CryptoNG is up to v1.7.0. There's not a major difference in functionality between v1.6.1 and v1.7.0. However, it does have several function header corrections and the getting/setting of structure fields was changed back to the object-based way of doing it. There are a few more small additions, modifications, and optimizations, but not really enough to warrant switching to the newest version, unless you wanted to of course.

My nick is Nine not Demain. But glad it is working for you.