[Samstag]

Das Update ist im SP1 (Update 790) enthalten. Die Updates darin werden alle nicht extra aufgeführt, ist aber auch kein Wunder bei über 900 enthaltenen Updates.

Dieser Beitrag wurde von Samstag bearbeitet: 09. Juli 2016 - 17:32

[RalphS]

Läßt sich relativ schnell testen: Du baust zwei kleine Funktionsbibliotheken - sinngemäß reicht auch eine, die Du dann einmal kopierst und die Kopie geringfügig anpaßt --- wo letztlich nur eine exportierte Funktion drin steht, die einmal 'A' ausgibt und einmal 'B' (oder sonstwas) und das bei gleichem Exportmodul (sagen wir test.dll) und gleichem exportierten Funktionsnamen (sagen wir int do_test() ). Dazu eine ausführbare Datei bauen, die bloß eine main() Routine beinhaltet, welche do_test() aufruft und dazu die test.dll dynamisch lädt.

Dann kompilierst Du das Ganze und kriegst so eine do_test.exe sowie eine test.dll, die in denselben Ordner kommt (und "A" ausgibt) und eine test.dll die stattdessen "B" ausgibt und die Du in einen ANDEREN Ordner schiebst (offensichtlich) welcher sich im Systempfad befindet (=> %PATH% Variable).

Dann die EXE-Datei aufrufen und schauen, was zurückgegeben wird. Im Beispiel: wenn A auf den Bildschirm geschrieben wird, ist das Loch da. Wenn stattdessen "B" geschrieben wird, ist das Loch gestopft.

Dieser Beitrag wurde von RalphS bearbeitet: 10. Juli 2016 - 00:12

[RalphS]

Theoretisch ja, praktisch krieg ich grad einen 0xc000:0142 zurück, wenn ich die DLLs austausch, egal wo sie sich befinden.

Was darauf hindeutet, daß das als C++ gebaut wird und nicht als C. Das sagt uns also nicht sonderlich viel. Werd mir das bei Gelegenheit mal anschaun.

Ja, das könnte auch die erwähnte Sicherheitsmaßnahme sein. Glaub ich aber nicht so recht dran.

[RalphS]

Kurzer Zwischenbericht:

- Als x86 funktioniert es, wenn weder im Programmverzeichnis noch im Suchpfad die fragliche DLL gefunden wird. Dann wird die DLL aus CWD genommen.

- Als x64 vergiftet mir irgendwas die Umgebung. Sieht aus, als hätte ich irgendwo eine 32er DLL im 64er Suchpfad oder irgendwie sowas. Muß ich noch weiter testen, was da los ist.

- Das, oder der 64er Linker ist schlauer als ich.

[RalphS]

So, erledigt. Der 64er Linker war tatsächlich schlauer; ich hatte aus Versehen eine DllMain definiert und die hatte die falsche Signatur. Mit x86 hat das noch gepaßt. Mit x64... nicht mehr. DllMain() auskommentiert und nun paßt es.

Anbei ein rudimentäres(!) Test-Tool, einschließlich nicht minder rudimentären Quellcodes und 32 sowie 64bit binaries.

Angelegt wird ein Ordner dll-test, mit Unterverzeichnissen
>> src (für den Quellcode plus eine kleine Build-Batchdatei für MSVC);
>> x86 für die 32er binaries; und
>> x64 für die 64er binaries.

Die beiden x** Verzeichnisse enthalten jeweils ein Verzeichnis DLL1 für eine DLL-Variante namens test.dll, DLL2 für die zweite DLL-Variante desselben Namens und ein Verzeichnis EXE für eine dynamisch gelinkte ausführbare Datei namens dll-test.exe .

Wie es funktioniert:

Wie oben schon angedeutet werden DLL-Funktionen referenziert (dynamic linking; static linking würde den Objektcode kopieren).

Die EXE-Datei referenziert also eine Funktion namens do_test() aus einer Datei namens test.dll .

Die Frage ist: wo kommt das her?

Wenn man auf der Kommmandozeile ins Verzeichnis ... dll1 wechselt und von dort die EXE-Datei aufruft (per ..\exe\dll-test.exe) dann wird die EXE-Datei erwartungsgemäß aus dem aktuellen Arbeitsverzeichnis (CWD) die dort befindliche DLL laden, die darin enthaltene Funktion do_test() ausführen und "DLL #A" auf den Bildschirm schreiben.

Macht man das Ganze nun aus dem Verzeichnis ...dll2 heraus, passiert formal genau dasselbe. Die DLL ist aber eine andere. Deshalb wird der Aufruf derSELBEN Exe-Datei (es gibt ja nur die eine) ein anderes Ergebnis ausgeben (aus der zweiten DLL) und zum "Beweis" ein "DLL #B" auf dem Bildschirm ausgeben.

Dabei ist egal, gegen welche DLL ursprünglich gelinkt wurde, solange nur der Funktionsbestand in beiden DLLs gleichermaßen bereitgestellt wird (hier: nur do_test() ); denn auch der Linkvergang arbeitet mit Referenzen und schreibt diese in die zugehörige Import-Tabelle der EXE-Datei ein.

Wer MSVC installiert hat, bekommt diese Liste mit dumpbin /exports ausgegeben.

Mit einer unixoiden Umgebung und binutils kriegt man dasselbe mit

 nm -B <Pfad zur DLL-Datei> | grep ' T '

heraus (links und rechts des großen T befindet sich jeweils ein einzelnes Leerzeichen). Note: nm schreibt *alle* referenzierten Funktionen auf den Bildschirm, auch die, die gar nicht genutzt wurden. do_test sollte als Funktionsname aber in der Liste mit auftauchen.


Entsprechend kann man sich, wenn man das will, eine eigene test.dll kompilieren, die zumindest die Funktion void do_test() ohne Parameter beinhaltet, zB einen Ordner dll3 anlegen und die da rein tun und dann von hier aus die beigelegte EXE-Datei ausführen. Wichtig ist an dieser Stelle nur, daß die neue DLL irgendwelchen Code beinhaltet, daß man auch sieht, daß sie geladen wurde.

Zu kompilieren ist die DLL unter MSVC mit dem Befehl

cl /FD <dll_source.c> /LINK /OUT:test.dll 

und die entstehende Datei test.dll an einen eindeutigen Ort packen, wo sie keine andere überschreibt.

Der Code ist aber auch mit GCC und CLang kompilierbar und lauffähig (getestet). Hierzu gibt es im Untervrzeichnis "C" ein einzelnes Bash-Script namens build.sh, welches unter msys2/64 mit clang erstellt und getestet wurde. Die Parameter für GCC sind aber dieselben; jedes Auftreten von "clang" kann daher problemlos in ein "gcc" umgebaut werden. Das Script funktioniert wie bereitgestellt, wenn es aus dem src-Ordner heraus aufgerufen wird (und eine msys2-Umgebung samt clang installiert ist; cygwin sollte aber ebenfalls tun und MinGW/32 bzw msys1 jeweils mit gcc und Scriptanpassung ebenfalls).


Insbesondere sei an dieser Stelle auch darauf hingewiesen, daß die beiden Beispiel-DLLs (in 32- und 64-bit Form) aufs Byte genau gleich lang sind. Es ist daher nicht auf den ersten Blick erkennbar, welche DLL nun welche ist. Mit einer Authenticode-Signatur wäre das nicht möglich gewesen; man hätte dann die "richtige" bzw die "falsche" DLL schnell identifizieren und ggf entfernen können.

Jeder kann Quellcode bauen; MSVC ist seit Ewigkeiten als Express, später als Community Edition frei verfügbar und CLang/GCC gibt es ebenfalls schon seit Jahren auch für Windows-Systeme. DLLs erstellen ist kein Hexenwerk; wenn jemand CWD-in-search-path ausnutzen will, dann ist das ein Leichtes und " mir kann sowas nicht passieren" leider ein gravierender Trugschluß.

Angehängte Datei(en)

•  dll-test.7z (118,29K)
  Anzahl der Downloads: 221

Dieser Beitrag wurde von RalphS bearbeitet: 18. Juli 2017 - 02:08