DXGIDebug.dll wird angeblich von mit WinRar erzeugter Setup-Exe geladen

[hoika]

Hallo,
so habe gerade mal schnell eine Dll geschrieben,
und in der Tat, die DLL wird geöffnet,
aber nicht über LoadLibrary, sondern über CreateFile.
Und dann kommt ein Hinweis, dass diese Datei entfernt werden muss,
sonst geht es nicht weiter.

Hm.

[himitsu]

Ist das jetzt nur ein DLL-Hook-Schutz
oder doch gar 'ne Art autmatsche gefundene DLL-Plugin-System?

[hoika]

Hallo,
so richtig werde ich damit auch nicht schlau.

[himitsu]

Nja, aktuell sieht es ja erstmal nur so aus, dass "diese" DLLs nur zur Analyse binär geladen werden.
k.A. ob und was passiert, wenn eine DLL den Test besteht.

Also LoadLibraryEx mit LOAD_LIBRARY_AS_DATAFILE und DONT_RESOLVE_DLL_REFERENCES,
aber auf keinen Fall mit LOAD_LIBRARY_SEARCH_APPLICATION_DIR.
Oder einfach direkt LOAD_LIBRARY_SEARCH_SYSTEM32.
Abgesehn davon, dass Windows selbst schon jahrelang einen Schutz integriert hat, wodurch System-DLLs nicht aus dem Programmverzeichnis geladen werden, damit man z.B. keine kernel32.dll als billigen Hook da rein legen kann.

Ich sag ja 7zip, dann hättest dir jetzt den Quellcode des Self-Extract angucken können.



Ich dachte erst da findete man 200 Milliarden Einträge zu winrar load dll, aber geht scheinbar alles nur um UNACEV2.DLL und viele Seiten sind nur Kopieen des selben Artikels.

und mittendrin: Nordkoreas neues Antivirusprogramm ist eigentlich eine über 10 Jahre alte Antivirus-Engine von Trend Micro, mit vielen Whitlists der eigenen Staatstrojaner.
Da frag ich mich grade, ob der deutsche Staatstrojaner von unseren Programmen gefunden wird.


Wir haben doch unseren eigenen Antivirusguru hier im Forum.
Hatte vergesen wie er hieß, aber mußte hier ja nur nach Neuseeland suchen, und dann nochmal nach Island, als ich meinen Fehler bemerkte.
Falls es was Böses ist, dann weiß Assarbad es bestimmt zuerst.

[hoika]

Hallo,
so, bin etwas weiter.

Aktuelle WinRar-Version 5.80:
Das Laden der DirectX-Dll und aller weiteren wird jetzt verhindert.

Aber:
Es gibt ein QueryImage "<pi-ms-win-core-synch-l1-2-0.dll" (ja mit < am Anfang, was laut Dateisystem gar nicht geht)
Was ist das denn?

[Incocnito]

Waren das auf der Komandozeile nicht diese Pipes mit denen man Dinge übergeben kann oder umgekehrt die Ausgabe umleiten kann?

vgl.:
echo Hallo > C:\Test.log

Nur so eine Idee!?

MfG
Incocnito

[TiGü]

Einfach mal eine E-Mail an WinRAR schreiben?

[himitsu]

Nicht alle Zeichen, welche "du" nicht nutzen kannst, sind auch verboten, bzw. nicht alles kann in jedem Programm genutzt vwerden.
Beispiel: versuche mal im Explorer oder mit Notepad die Datei .htaccess zu erstellen.
Fast überall sind im Windows "leere" Dateinamen nicht möglich und auch ein Punk am Ende wird oft abgeschnitten, da leere Dateiendung.

z.B. in der Registry kann/darf auch eine #0 im Namen vorkommen, was geil ist, da die C-Programme dann den Rest abschneiden, somit nicht darauf zugreifen können und man so Daten verstecken kann. (außer jemand nutzt native API)
Auch für Dateizugriffe gibt es die nativen APIs, aber ich hab grade nicht im Kopf was dort z.B. bei NtCreateFile geht, was CreateFile nicht kann.

Nicht alles ist überall beschränkt, bzw. es kommt erst in höheren Schichten dazu:
* im Dateisystem nicht erlaubt (es gibt mehrere Versionen)
* im Dateisystemtreiber nicht möglich (es gibt unterschiedliche Treiber und Versionen)
* in der nativen/interen WindowsAPI nicht möglich (bzw. nur vom Kernelmode aus)
* in der höheren WindowsAPI nicht möglich
* im Programm nicht verwendbar

Wenn ich mich recht erinner, dann ist NTFS im Grunde case-sensive, aber der Dateisystemtreiber vom Windows bügelt die Zugriffe dann glatt, weswegen wir nichts von mitbekommen.


Und ist es auch wirklich ein < und nicht vielleicht ein Zeichen, was zufällig nur so aussieht? (bzw. bei Konvertierung von Unicode zu ANSI dann in dieses übersetzt wurde)

@incongnito: per se ist das > ein Steuerzeichen der Console ... kann also gut sein, dass es im NTFS dennoch erlaubt ist.