[Registry-wrapping] Nightingale

[nait]

Hi!

Nachdem ich in den letzten Monaten an chronischem Zeitmangel gelitten habe, konnte ich wenigstens dieses Programm halbwegs fertig stellen... Der Name "Nightingale" ist, wie üblich, das Ergebnis einer spontanen Laune.

Dieses mal geht es um die Portabilität von Programmen auf USB-Sticks. Da viele Programme von der Registry abhängig sind, habe ich mir überlegt ob es nicht eine einfache Lösung gibt, um sie davon zu lösen.
Das Ergebnis ist eine kleine DLL, die die Registry-Funktionen wrapped und den Datentransfer für bekannte Einträge übernimmt.

Weitere Informationen und natürlich auch die Sourcen sind unter
http://www.deneke.biz/nightingale/
zu finden.

Wenn ihr Verbesserungsvorschläge oder Diskussionsbedarf habt, schreibt einfach. ;-)

[morpheus]

Ich denke es waere fuer die naechsten Releases auf jeden Fall sinnvoll ein kleines Helper Tool zu schreiben, welches die Schritte unter Usage automatisiert erledigt? Ich denke das sollte schnell geschrieben sein und es erspart einem doch einiges an Arbeit, wenn das Programm diverse DLLs einsetzt. Wobei "Repeat for dlls that also belong to the program." nicht ganz so einfach sein kann, wenn die DLLs ueberall im System verstreut sind.

Das zweite waere noch:
http://validator.w3.org/check?verbos...nightingale%2F

[nait]

Asche auf mein Haupt, das übliche Problem wieder. ;-)
Ich werd's korrigieren und bei Gelegenheit auch mal 'nen 'Installationstool' schreiben.

[CryptoCrack]

Hi, nait!

Nettes Tool, wobei es auch noch von meiner Seite ein paar Verbesserungsvorschläge gibt

Zitat von nait

Asche auf mein Haupt, das übliche Problem wieder. ;-)
Ich werd's korrigieren und bei Gelegenheit auch mal 'nen 'Installationstool' schreiben.

Die Frage ist bloß, wie das Ganze funktionieren soll. Imho ist es ein wenig problematisch, einfach alle Vorkommnisse von ADVAPI32 in den betroffenen Files durch ADVAP132 zu ersetzen, da z.B. gepackte PEs mit verschlüsselten oder komprimierten Import-Tables weiterhin die originale Library laden werden. Zudem wird es relativ schwierig sein, den Schritt "Repeat for dlls that also belong to the program." automatisch durchzuführen (man beachte neben gepackten Executables und DLLs auch VB6-Programme, die DLL-Funktionen immer per Umweg über die VB-Runtimes aufrufen, sowie mittels LoadLibrary nachgeladene DLLs). Ich weiß nicht, inwiefern sich der Aufwand rentieren würde, aber es bietet sich an, das Projekt in zwei Komponenten aufzuspalten: Die Hauptarbeit übernimmt weiterhin die Wrapper-DLL, welche Registry-Zugriffe auf die dynamische Registry-Table umleitet. Zusätzlich könnte man einen Nightingale-Loader entwickeln, der zunächst das Target startet, wartet, bis die advapi32.dll-DLL geladen ist, die Nightingale-DLL per DLL-Injection nachlädt und alle Funktionen der ursprünglichen advapi32.dll hooked, sodass entsprechende Aufrufe auf die Nightingale-DLL umleitet werden. Vorteil der Sache wäre, dass man keinerlei Änderungen an diversen Files vornehmen müsste und das Tool auch einwandfrei mit gepackten und geschützten PEs arbeiten würde. Nachteil wiederrum, dass das Ganze unter älteren Betriebssystemen vermutlich nicht mehr reibungsfrei funktioniert und man womöglich nicht immer die benötigten Rechte haben wird, die DLL-Injection und das Inline-Hooking durchzuführen. Immerhin wäre das eine Alternative, um Problemen beim Patchen der Programmdateien aus dem Weg zu gehen.

Was man imo auch noch hinzufügen sollte (ich hab' mir die Sources jedoch noch nicht durchgeschaut und weiß daher auch nicht, ob so etwas in der Art schon implementiert ist), wäre eine Funktion, welche sämtliche Zugriffe auf die Registry unterbindet und im Fall, dass ein bestimmter Schlüssel oder Wert in der Registry-Table nicht existiert, einfach den Default-Wert oder einen anderen, zuvor festgelegten String zurückgibt. Es kann unter Umständen nervig sein, wenn man meint, dem Wrapper alle Rückgabewerte für Registry-Zugriffe beigebracht zu haben und später doch noch irgendwo ein Wert von einem Fremdsystem ausgelesen und ständig benutzt wird. Man könnte den Wert zwar manuell in der Table fixen, aber einfacher fände ich es, wenn in einem bestimmten Modus erst gar keine neuen Werte aus der Registry aufgenommen werden.

Wo wir gerade schon bei der Überwachung von Änderungen in der Table sind, hätte ich noch den Vorschlag, eine Logging-Funktion einbauen. Sollte diese aktiviert sein (das ließe sich z.B. über eine kleine INI im Programmverzeichnis steuern), so werden alle Registry-Zugriffe oder wahlweise auch nur das Hinzufügen neuer Table-Entries in einer Textdatei geloggt. Das kann zwar zu Startverzögerungen führen, aber man hätte einen guten Überblick über die aufgerufenen Keys bzw. die neuen Einträge in der Registry-Tabelle (manche Keys möchte man für den portablen Einsatz eventuell anpassen).

Ich hoffe, dass du mit meinen Anregungen etwas anfangen kannst und dass das Projekt gut vorankommt. Ich könnte das Tool selbst gut gebrauchen, da ich gerade versuche, eine ganze Menge meiner wichtigsten Applikationen portabel zu machen und es doch relativ mühsam ist, alle Registry-Zugriffe manuell umzubiegen

Grüße, CryptoCrack

[nait]

So, der Validator ist wieder friedlich. ;-) Danke CryptoCrack.

Übrigens bin ich am Loader dran, er sollte in den nächsten Tagen fertig sein. Der Hinweis mit der DLL-Injection war der nötige Tipp, so ist das halt mit dem Wald und den Bäumen. Danke.

Was das Logging betrifft, kannst du in reg_tree.h das
#if 0
in Zeile 26 rausnehmen und damit das loggen aktivieren. Ist zwar nicht so schön, war aber eigentlich auch nicht als Feature gedacht. ;-)

[CryptoCrack]

Hi!

Mir ist eben noch eine Idee gekommen, wie man den Loader etwas kompatibler gestalten könnte: Anstatt einer separaten PE, welche die eigentliche Executable startet, könnte man doch auch einen Stub am Einsprungspunkt des Targets eingefügen, der sämtliche Aufgaben übernimmt (noch besser wäre es, wie die meisten Packer vorzugehen und eine neue Section hinzuzufügen). Dieser könnte dann per LoadLibrary die nightingale.dll nachladen und das Inline-Hooking durchführen. Der beste Ansatz wäre hier vermutlich, alle Exports der advapi32.dll oder nightingale.dll (sollten im Prinzip dieselben sein) durchzulaufen, per GetProcAddress die jeweiligen Adressen auszulesen und dann zu hooken.

Vom Ablauf her läuft im Prinzip alles gleich wie bei einem externen Loader, wobei jedoch keine Zugriffe aus Fremdprozessen erfolgen müssten (die DLL-Injection würde auch wegfallen und es sollte keine Probleme mit nicht vorhandenen Rechten geben).

Zitat von nait

Was das Logging betrifft, kannst du in reg_tree.h das
#if 0
in Zeile 26 rausnehmen und damit das loggen aktivieren. Ist zwar nicht so schön, war aber eigentlich auch nicht als Feature gedacht. ;-)

Thx, ich hab' mir die Sources mittlerweile ein wenig durchgeschaut und das "Feature" gefunden

CryptoCrack


P.S.: Mir ist gerade noch aufgefallen, dass die advapi32.dll zum Zeitpunkt, an dem der Stub ausgeführt wird, eventuell noch gar nicht geladen ist (wenn z.B. ein Packer verwendet wird, der die Imports erst nach dem Nightingale Loader verarbeitet). Umgehen könnte man das beispielsweise, indem man das Hooking nicht sofort durchführt, sondern einen Thread erstellt, der wartet, bis die DLL in den Adressraum geladen wurde und dann seine Arbeit verrichtet. Problematisch wird es, wenn das Programm bereits Funktionen der advapi32.dll verwendet, bevor der Thread Wind von der geladenen Library bekommt - allerdings besteht dieses Problem auch bei einem externen Tool... Mir fällt hierzu atm keine saubere Lösung ein (außer einem Breakpoint auf die LoadLibrary-Funktion, was auch wieder zu Schwierigkeiten führen könnte), aber vielleicht hast du noch eine passende Idee.

[nait]

Ich hatte auch schon überlegt den Loader als Stub vor die eigentliche Datei zu hängen, allerdings würde man dann wieder direkt in die Datei eingreifen und bekäme unter umständen dadurch mehr Probleme als Vereinfachungen (z.B. durch false positives von Virenscannern).

Im Moment löse ich das Problem durch die Annahme, dass es keine DLL gibt die auf nightingale verweist. Aus diesem Grund kann ich (obwohl in der MSDN 'must not' steht) in der DLLmain LoadLibrary für die ADVAPI32.dll verwenden. natürlich ist das nicht wirklich sauber...
Die Alternative wäre zu argumentieren, dass eh keine DLL in ihrer Main-Funktion Reg-Funktionen aufrufen kann ohne die DLL geladen zu haben (was ja 'verboten' ist). Das heißt es gäbe bis zum (TLS-)Entrypoint keine Möglichkeit, das etwas am nightingale-System vorbeiläuft. Durch den Loader wird am (TLS-)Entrypoint angehalten, die DLL injectet, der EIP auf die Init-Funktion umgebogen. Die Init-Funktion übernimmt das Hooking und kehrt nicht mit einem RET sondern einem JMP zum EP zurück, so dass kein Unterschied zu erkennen sein wird.
Der Vorteil ist, dass diese Methode auch für Programme funktioniert, die Checksummen über sich selbst berechnen.

Ich denke das werde ich auch so implementieren.

[Zaesar]

OffTopic:
Das Gerücht, dass man für einen Loader, der DLL-Injection o.ä. macht, erweiterte Rechte braucht, hält sich zwar schon eine Weile, stimmt aber trotzdem nicht:

Zitat von http://msdn2.microsoft.com/en-us/library/ms684880.aspx

The handle returned by the CreateProcess function has PROCESS_ALL_ACCESS access to the process object.

Egal was für Rechte oder Privilegien man hat, auf einen Prozess, den man selber mit CreateProcess gestartet hat, hat man immer vollen Zugriff. Nur bei CreateProcessAsUser oder CreateProcessWithLogonW (wahrscheinlich auch bei CreateProcessWithToken) sieht das anders aus, aber die wären für einen solchen Loader auch ungewöhnlich.

[nait]

Eigentlich wollte ich ja bis morgen warten, aber da ich gerade nach Hause gekommen bin und eh noch nicht schlafen kann...

Nach einer langen Zeit ohne Updates, kann ich endlich eine neue Version präsentieren. Im Vergleich zum vorherigen Stand gab es einige massive Änderungen. Hier ein kurzer Überblick:

• Zusätzlich zu den Keys können jetzt auch Values verarbeitet werden (RegQueryValue*)
• Es werden jetzt auch die RegEnum*-Funktionen unterstützt
• Sowohl Unicode als auch ASCII Funktionen sind vollständig vorhanden
• Es gibt einen Loader der die Verwendung von nightingale wesentlich komfortabler macht
• Bei Bedarf kann eine Log-Funktion zugeschaltet werden, die alle Registry-Aufrufe mitlogt

Der Link ist gleich geblieben:
http://deneke.biz/nightingale

Auch hier nochmal vielen Dank an CryptoCrack für den ausgiebigen Support beim Testen und dem Umbau der Seite.

[nait]

Die Sourcen sind jetzt auch wieder online.

[echox]

Eigentlich koennten wir das auf Buha spiegeln?

[nait]

Ich habe noch einen Bug-Fix für das Problem beim Wrappen von Anwendungen die Sockets verwenden erstellt. Damit ist das Problem auch behoben. :-)