MemoryDLL - Problem

Seikuassi

Ich benutze jetzt die Resources.au3 und die RunBinary.au3, um alle Daten und Dateien in einer Datei "verpackt" sind.
Das Letzte, was ich noch erreichen möchte, ist eine DLL zu inkludieren und intern, d.h. vom Speicher bzw. von HEX-Daten, die Funktionen aufzurufen.
Ich habe zwar schon die MemoryDLL.au3 (http://www.autoitscript.com/forum/topic/77…ns-from-memory/) versucht, allerdings ohne Erfolg.

Hier mein Testskript, das nicht funktioniert:

[autoit]

#Include 'MemoryDll.au3'

[/autoit][autoit][/autoit][autoit]

main()

[/autoit][autoit][/autoit][autoit]

Func main()
Local $DllFile_0 = FileOpen('D:\WINDOWS\system32\User32.dll',16)
Local $DllBin_0 = FileRead($DllFile_0)
FileClose($DllFile_0)

[/autoit][autoit][/autoit][autoit]

$DLL_handle_0 = MemoryDllOpen ($DllBin_0)
MemoryDllCall($DllBin,'int','MessageBox','hwnd',0,'str','Some text','str','Some title','int',0)
MemoryDllClose ($DLL_handle_0)
Exit
EndFunc

[/autoit]

Warum funktioniert das nicht bzw. hat jemand eine Alternative UDF für mich?

MfG

Seikuassi

P.S.: Mein WINDOWS-Ordner befindet sich auf dem Laufwerk D:\.

PainTain

Hast du schon mal auf @error bzw. die Rückgabe von den Funktionen überprüft?

MfG

Seikuassi

Ups! Fehler entdeckt aber noch nicht komplett gelöst.

Der Code müsste eigentlich so aussehen:

[autoit]

#Include 'MemoryDll.au3'

[/autoit][autoit][/autoit][autoit]

Main()
Func Main()
Local $DllFile_0 = FileOpen('D:\WINDOWS\system32\User32.dll',16)
Local $DllBin_0 = FileRead($DllFile_0)
FileClose($DllFile_0)

[/autoit][autoit][/autoit][autoit]

$DLL_handle_0 = MemoryDllOpen ($DllBin_0)
MemoryDllCall($DLL_handle_0,'int','MessageBox','hwnd',0,'str','Some text','str','Some title','int',0)
MemoryDllClose ($DLL_handle_0)
Exit
EndFunc

[/autoit]

PainTain:
Kann ich nicht, weil Windows bei dem Skript ein Problem festgestellt hat (dieser Dialog mit "Problembericht senden" und "Nicht senden"). Er beendet also das Skript, ohne, dass ich die Rückgabewerte überprüfen könnte.

Alle meine anderen Skripte (ohne MemoryDLL.au3) laufen einwandfrei.

MfG

Seikuassi

**chesstiger**

Ich weiß ja nicht, was du für eine Dll da verwendest, aber vielleicht ist es ja eine Dll, die die C-Aufrufkonvention verwendet?
Nimm mal als Rückgabewert für den DllCall "int:cdecl".

lg

Seikuassi

"int:cdecl" hat leider nicht funktioniert (noch immer die Fehlermeldung von Windows).
Liegt das Problem vllt. an meinem Betriebssystem Windows XP SP3 32-bit?
Oder gibt es vllt. eine andere vergleichbare UDF?

Zitat

Ich weiß ja nicht, was du für eine Dll da verwendest

Wie im Quellcode angegeben, die User32.dll vom system32-Ordner.

MfG

**chesstiger**

Ups, sorry: Das hab ich glatt übersehen, hab nur drübergeschaut.

Kannst du die Dll denn normal aufrufen, also aus dem Windows-Ordner?

lg

Seikuassi

Zitat

Kannst du die Dll denn normal aufrufen, also aus dem Windows-Ordner?

Siehe Post #1: leider nicht. Gibt es nicht eine alternative UDF?
Sogar DllCallHac geht nicht!

Ich versuche noch mal AutoIT neu zu installieren (allerdings glaube ich nicht, dass dadurch das Problem behoben wird, da ja alle anderen Programme funktionieren).

MfG

Seikuassi

PainTain

Zitat von Seikuassi

Siehe Post #1: leider nicht. Gibt es nicht eine alternative UDF?
Sogar DllCallHac geht nicht!

Ich glaube, chessi hat das so gemeint:

[autoit]

DllCall("D:\WINDOWS\system32\User32.dll", "int", "MessageBox", "hwnd", 0, "str", "Some text", "str", "Some title", "int", 0)

[/autoit]

MfG

Seikuassi

Ja, das funktioniert (leider...).
Gibt es eine Möglichkeit, eine DLL zu einer EXE zu konvertieren (wahrscheinlich nicht ) und dann per RunBinary zu öffnen?

Danke im Voraus!

MfG

Seikuassi

Gibt es vllt. eine Möglichkeit mit DllStructCreate eine DLL zu kopieren? (Wahrscheinlich nicht, da dies ja nur eine Struktur ist...)
Ich möchte ja nur im Prinzip eine DLL in hexadezimaler Form (mithilfe des Befehls StringtoBinary ()) aufrufen und ein Handle für DllCall erhalten.

Gibt s da vllt. eine UDF (vllt. sogar ohne externe DLL's) oder ein Programm (.exe), das einen binären Code in eine DLL umwandelt, um dann vom Speicher aus Funktionen abzurufen.

Denn die MemoryDLL benutzt externe DLL´s. (Ich weiß, dass das eigentlich nur wenig Sinn gibt, aber ich will nur wissen, ob es auch ohne externe DLL geht).

Danke im Voraus!

MfG

Seikuassi

James · AutoIt Version (Prod): 3.3.14.2

Es gibt UDFs, die die in einer DLL enthaltenen Funktionen auflisten können. Da sollte es ja eigentlich auch kein Problem sein, auf ähnliche Art und Weise die Adresse dieser Funktion zu finden. Das könnte man dann vielleicht mit DllCallAddress verbinden.

Vielleicht. Ich habe sowas noch nicht probiert, aber es klingt (für mich) zumindest logisch.

Edit: https://autoit.de/www.autoit.de/…;threadID=22280

**Andy**

Hi,
generell ist es möglich, eine DLL einfach in den Speicher zu kopieren und dort die Funktionen per Offset (und Startadresse des Speicherbereichs) aufzurufen.
Das funktioniert natürlich nur so lange, wie die Funktionen in der DLL von dieser Methode "wissen", bzw. auf diese Methode hin programmiert wurden!
Bspw. können Sprungbefehle einmal als "feste" Adresse, oder als "springe 53 Bytes vorwärts" kodiert werden, oder feste Adressen werden zum Speichern von Variablen verwendet.
Was passiert nun, wenn die "feste Adresse" als Sprungziel in der DLL verwendet wird, oder als Speicherstelle 0xD345FFA2?
Da die DLL beim einfachen kopieren in den Speicher an einer x-beliebigen Adresse stehen kann, führt der Sprung zu einer festen Adresse natürlich zu einem Absturz, weil der Code an dieser "festen" Sprungadresse irgend ein x-beliebiger Code sein kann!
Wie kann man dieses Problem umgehen?
Man (der Compiler) erzeugt beim Erstellen einer DLL eine Liste (in der DLL) , in der diese "festen" Adressen im Code enthalten sind.
Wird nun, wie bspw. durch DllOpen() diese DLL an eine bestimmte Speicheradresse geladen, werden die "festen" Adressen im Code mit den Listenadressen abgeglichen, und das aktuelle Offset mit ihnen verrechnet und die "richtige" Adresse in den Code geschrieben.
tranceexx hat diese Methode bei ihrer "Subrogation" verwendet, also gewissermassen "DLL laden zu Fuß". Damit ist es auch kein Problem, eine im Script enthaltene Dll in den Speicher zu laden und dort auszuführen.

Wenn man Funktionen in einer DLL verwenden möchte, die "geheim" bleiben sollen, dann könnte man natürlich im Vorfeld per Disassembler oder GetProcAddress() die Startadresse innerhalb der Funktion herausfinden und dann einfach per CallAddress() anspringen!
Ein DllCall( "dll", "return type", "function" [, type1, param1...) im Code offenbart direkt die verwendete Funktion und Dll, aber aus einem DllCallAddress("int",$Func_address, $type1, $para1) liest niemand heraus, ob nun eine Kernelfunktion, oder eine Funktion einer eigenen Dll angesprungen wird!

Seikuassi

Und wie lautet dann dazu eine FUnktion in AutoIT dazu?
Es gibt ja die Binary UDF von Ward (http://www.autoitscript.com/forum/topic/131037-binary-udf/).

Dort gibt es folgende Funktion, die evtl. interessant sein könnten:

_BinaryToMemory($Binary, $Ptr)
_BinaryFromMemory($Ptr, $Size)
_BinaryToDLLStruct($Binary)
_BinaryFromDLLStruct(ByRef $DLLStruct)
_BinaryFillDLLStruct($Binary, ByRef $DLLStruct)

Gibt es nicht dort eine Möglichkeit, einen binären Code zu einer DLL umzuwandeln und dann zu nutzen?
Ich werde mir mal die Funktion genauer anschauen. Vllt. hat jemand schon eine Idee ?

Danke im Voraus!

MfG

Seikuassi

**Andy**

Zitat

Und die Funktion?

steht in meinem Post und ist nicht von Ward...

Wenn du Fragen zu Wards Funktionen hast, frag ihn selbst oder schau dir an, was seine Funktionen machen! Wo steht dort, dass ein anderes Verfahren als bei DllOpen() verwendet wird?
Du dast nichtmal in die Funktion hereingeschaut!!!
Ward verwendet einfach nur eine undokumentierte MS-Funktion "LocalCompact()" um damit die "LoadLibraryA()" aus der Kernel32.dll aufzurufen!?

Nochmal, du hast keine Ahnung vom Thema und willst dich auch nicht damit beschäftigen. Du willst dich auch nicht mit dem PE-Format und schon garnicht mit den Relocations befassen.
Das ist völlig in Ordnung so!
Nicht in Ordnung ist, dass du alles andere ausser "auf einen Link zur passenden Funktion klicken" ignorierst.

Und die Binary-UDF hat in keinster Weise etwas mit dem Thema zu tun, dort gehts darum, ZEICHENKETTEN zu bearbeiten!

Zitat

Gibt es nicht dort eine Möglichkeit, einen binären Code zu einer DLL umzuwandeln und dann zu nutzen?

Nein, s.o.

Btw, hier mal dein funktionierendes Beispiel...

Spoiler anzeigen

[autoit]

#Include <MemoryDll.au3>

[/autoit] [autoit][/autoit] [autoit]

main()

[/autoit] [autoit][/autoit] [autoit]

Func main()
Local $DllFile_0 = FileOpen('c:\WINDOWS\system32\User32.dll',16)
Local $DllBin_0 = FileRead($DllFile_0)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $DllBin_0 = ' & stringleft($DllBin_0,100) & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
FileClose($DllFile_0)

[/autoit] [autoit][/autoit] [autoit]

$DLL_handle_0 = MemoryDllOpen ($DllBin_0)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $DLL_handle_0 = ' & $DLL_handle_0 & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
$a=MemoryDllCall($Dll_Handle_0,'int','MessageBoxA','hwnd',0,'str','Some text','str','Some title','int',2)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $a = ' & $a[0] & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console

[/autoit] [autoit][/autoit] [autoit]

;MemoryDllClose ($Dll_Handle_0)
Exit
EndFunc

[/autoit]

PainTain

Was spricht eigentlich dagegen, die DLL mithilfe von "FileInstall" oder BugFix's Fremddateien "includen" (ohne FileInstall) zu includen?

MfG

**Andy**

PainTain,
soweit ist er schon^^
Jetzt möchte er nur diese "includierte" Datei direkt aus dem Speicher ausführen, und nicht vorher auf die Platte auslagern

PainTain

Zitat von Andy

PainTain,
soweit ist er schon^^
Jetzt möchte er nur diese "includierte" Datei direkt aus dem Speicher ausführen, und nicht vorher auf die Platte auslagern

Das war mit einer Frage eigentlich gemeint...
Warum das ein solches Problem ist, die DLL irgendwo auf der Platte auszulagern...

MfG

**Andy**

Zitat

Das war mit einer Frage eigentlich gemeint...
Warum das ein solches Problem ist, die DLL irgendwo auf der Platte auszulagern...

genau so hatte ich das auch verstanden!
IdR gibt es dafür keinen Grund, du müsstest mal den TE fragen!
Allerdings hat dieser schon Probleme, einen einfachen API-Aufruf zu tätigen...