sry aber ich bin echt neu in dem gebiet...darum bisher kein spinlock verwendet
spinlock ist doch dafür da, dass man mehrere threads synchronisiert.
durch interlockedexchange macht das doch aber das betriebssystem, oder irre ich mich da?

so viel zum hooken, jetzt zum unhooken von der SSDT, die unbekannt gehookt ist:

die originalfunktionsadresse (also der pointer, der in der SSDT stehen müsste) ist bekannt (auslesen aus der kernel-exe)
-->kein problem, den pointer auf ungültigen mist zu setzen
-spinlock unnötig, basierend auf obiger annahme
-wenn jmd andres vorher entfernt hat, änder ich nix mehr
-originaladresse bekannt->kein prob
-gegen solche annahmen, wie dass eine gehookte funktion auf einer andren gehookt basiert, kann ich nix machen.
einzige variante um das halbwegs auszumerzen wäre, alle prozessoren zu locken (IRQL erhöhen) und dann erst zu enthooken
bringt immer noch probleme, wenn ein aufruf gerade mittendrin ist...in meinen problemen bisher aber kein thema. ich kann annehmen, dass das nicht der fall ist.

"Rootkit" ist i.A. ja schon ein treiber, der bestimmten zugriff verhindert. ich versuche derzeit das "rootkit" XTrap auszuschalten...

was (leider) auch viel zu einfach möglich war, ist den antivir service zu beenden (aus usermode ohne treiber, aber mit adminrechten unter xpSP3), was ich als test mal gemacht hatte. antivir hat mein programm nicht bemängelt o.ä. nichtmal als verdächtig

und zu uallring0: es ging um das entfernen. und da reicht es schreibzugriff auf kernelspeicher zu erhalten. und das geht mit adminrechten über mapping recht elegant. im internet kursieren noch einige anleitungen zu ähnlichen vorgehensweisen über \\physicalmemory (oder so)

PS: das buch hab ich z.b. aus der slub geliehen

Flamefire hat folgendes geschrieben :

sry aber ich bin echt neu in dem gebiet...darum bisher kein spinlock verwendet spinlock ist doch dafür da, dass man mehrere threads synchronisiert.

Spinlocks sind dazu da, dass kein anderer Prozessor (oder Kern) zu diesem Zeitpunkt was machen kann.

Flamefire hat folgendes geschrieben :

durch interlockedexchange macht das doch aber das betriebssystem, oder irre ich mich da?

Implementiert wird das auf CPU-Ebene indem der Adressbus fuer die Dauer eines Opcodes gesperrt wird, wenn ich mich recht entsinne.

Flamefire hat folgendes geschrieben :

die originalfunktionsadresse (also der pointer, der in der SSDT stehen müsste) ist bekannt (auslesen aus der kernel-exe)

Aus welcher "kernel-exe"?

Zum Rest auessere ich mich nicht mehr. Es scheint sinnlos zu sein. Viel "Erfolg".

öhm. sry. wollte dich nicht vergraulen. ich hab nur einen teil gelesen und leite daraus (für mich) logische schlüsse ab.
wenn ich mich in irgendeinem punkt vertan habe, dann würde ich mich schon über berichtigungen freuen.

denn z.b. wozu brauche ich ein spinlock, wenn der komplette adressbus gesperrt ist? besser kann man doch kaum schützen, oder?
spinlocks basieren eh auf den interlocked-funktionen (oder auf vergleichbaren, da sonst die sperrvariable zum problem wird)

mit "kernel-exe" meinte ich die derzeit geladenen. das ermittle ich per QuerySystemInformation. wollte damit eben genau das andeuten, dass ich auch die richtige nehme.

das einzige problem bei enthooken sehe ich nur, dass ein laufender aufruf von einem anderen abhängt, der gerade entfernt wurde

wie gesagt: nimm bitte meine äußerungen nicht als "was du sagst intressiert mich nicht" o.ä. sondern ich versuche nur, darzustellen und zu erklären, was ich bisher kenne.

Flamefire hat folgendes geschrieben :

denn z.b. wozu brauche ich ein spinlock, wenn der komplette adressbus gesperrt ist? besser kann man doch kaum schützen, oder?

Ich konkretisiere:

Assarbad hat folgendes geschrieben :

Implementiert wird das auf CPU-Ebene indem der Adressbus fuer die Dauer eines Opcodes gesperrt wird, wenn ich mich recht entsinne.

Sowas sieht dann so aus:

Flamefire hat folgendes geschrieben :

spinlocks basieren eh auf den interlocked-funktionen (oder auf vergleichbaren, da sonst die sperrvariable zum problem wird)

Das ist hardware-spezifisch und daher im HAL. Fuer x86 basiert der Teil auf BTS (mit LOCK Praefix). Und wenn ich das in IDA jetzt auf die Schnelle korrekt gesehen habe, wird danach der PAUSE-Opcode benutzt um den Prozessor schlafenzulegen.

Zitat:

Description Improves the performance of spin-wait loops. When executing a “spin-wait loop,” a Pentium 4 or Intel Xeon processor suffers a severe performance penalty when exiting the loop because it detects a possible memory order violation. The PAUSE instruction provides a hint to the processor that the code sequence is a spin-wait loop. The processor uses this hint to avoid the memory order violation in most situations, which greatly improves processor performance. For this reason, it is recommended that a PAUSE instruction be placed in all spin-wait loops. An additional function of the PAUSE instruction is to reduce the power consumed by a Pentium 4 processor while executing a spin loop. The Pentium 4 processor can execute a spin-wait loop extremely quickly, causing the processor to consume a lot of power while it waits for the resource it is spinning on to become available. Inserting a pause instruction in a spin-wait loop greatly reduces the processor’s power consumption. This instruction was introduced in the Pentium 4 processors, but is backward compatible with all IA-32 processors. In earlier IA-32 processors, the PAUSE instruction operates like a NOP instruction. The Pentium 4 and Intel Xeon processors implement the PAUSE instruction as a pre-defined delay. The delay is finite and can be zero for some processors. This instruction does not change the architectural state of the processor (that is, it performs essentially a delaying no-op operation). This instruction’s operation is the same in non-64-bit modes and 64-bit mode. ([url=www.intel.com/Assets...67.pdf]Quelle[/url])

Flamefire hat folgendes geschrieben :

mit "kernel-exe" meinte ich die derzeit geladenen. das ermittle ich per QuerySystemInformation. wollte damit eben genau das andeuten, dass ich auch die richtige nehme.

Dann ist der Teil i.O.

Flamefire hat folgendes geschrieben :

das einzige problem bei enthooken sehe ich nur, dass ein laufender aufruf von einem anderen abhängt, der gerade entfernt wurde

Und wie willst Du das unter Kontrolle bekommen? Und vor allem sollte der Beitrag von Skywing hier vielleicht mal bei Dir gesunde Zweifel an dem was Du versuchst aufkommen lassen (irgendwie zweifelst Du scheinbar zuerst an Fakten oder Aussagen anderer und dann an Deinen Ideen). Dazu vielleicht nochmal direkt der Link zur NTDEV-Liste wo ich 2004 (also bevor ich beruflich mit Treibern zu tun hatte) von Don Burn zusammengeschissen wurde. Das Thema hat Skywing von seinem Beitrag aus verlinkt. Also: einfach mal zuerst das NTDEV-Thema von 2004 und danach den Blogbeitrag von Skywing zu Gemuete fuehren und danach reden wir weiter.

was ist der nutzen eines spinlocks gegenüber der interlocked operation beim enthooken unabhängiger funktionen (also ohne den sonderfall, das eine gehookte funktion, von einer anderen abhängig ist)

den sonderfall unter Kontrolle zu bekommen, ist, (denke ich) nicht möglich. AFAIK ist es nicht möglich, festzustellen, ob ein prozess gerade in einer funktion ist, und wenn ja, diesen daraus zu "entlassen" und dann erst weiterzumachen (ok...alle PEB->unterstrukturen auf EIP prüfen und ggfls warten wäre ne variante aber immer noch unsicher)

den blogbeitrag hab ich gelesen. recht intressant, auch wenn ich bei einigen teilen nicht ganz mitkomme.

z.B. den teil, warum ein SSDT hook per pointer modification zu nem deadlock führt

i.A. sind die fehler im code zu ca 50% synchronisierungsprobleme...die hat man fast immer
der rest ist...unvorsichtiges zeug. also zb das mit dem status, und dem kernel handle

aber echt nicht schlecht. an vieles denkt man wirklich nicht so schnell

Flamefire hat folgendes geschrieben :

was ist der nutzen eines spinlocks gegenüber der interlocked operation beim enthooken unabhängiger funktionen (also ohne den sonderfall, das eine gehookte funktion, von einer anderen abhängig ist)

Die Tatsache, dass das Entfernen kaum mit einer einzigen Aktion (also einem Opcode) geschehen kann. Oder habe ich was verpasst?

Wie gesagt, wenn es sich um was handelt was deine Rechner nie verlaesst, ist die Stabilitaet ja auch zweitrangig. Aber beim Kunden brauchste auch mit einer Sicherheitsanwendung nicht antanzen wenn bei deren Benutzung u.U. der Server blau macht ... und wie oft oeffentlich zugaenglicher aber nur prototypenreifer Code mal eben in kommerziellen Anwendungen landet will ich garnicht wissen. ... auch nicht an wievielen der kommerziellen Anwendungen Menschenleben haengen.

Flamefire hat folgendes geschrieben :

i.A. sind die fehler im code zu ca 50% synchronisierungsprobleme...die hat man fast immer

... nur dass sie im Kernelmode zu einem Systemabsturz fuehren, im Usermode aber "nur" zu einem Programmabsturz. Und deine bisherigen Einwuerfe klangen nicht danach dass Du auch nur die "offensichtlichen" Probleme alle erkannt haettest

ähm...das entfernen läuft so:
-herausfinden der adresse des eintrags in der ssdt (offset)
-herausfinden des originalptr
-schreiben das originalptr an die adresse

kritischer abschnitt ist das letzte. durch interlocked funktioniert das. rest kann nicht verändert werden
damit habe ich nur einen opcode, oder?

ja ich weiß...programmfehler im treiber-->bsod
hatte ich oft genug. aber probier ja noch rum um erst mal gut reinzukommen. inzwischen krieg ich aber die teile recht gut hin ohne bsod. bisher noch ohne validation aber das kommt ja noch. und für meine anwendung wird das ding nicht sehr groß, wodurch es da (hoffentlich) kaum probleme zu suchen gibt.

Flamefire hat folgendes geschrieben :

ähm...das entfernen läuft so: -herausfinden der adresse des eintrags in der ssdt (offset) -herausfinden des originalptr -schreiben das originalptr an die adresse kritischer abschnitt ist das letzte. durch interlocked funktioniert das. rest kann nicht verändert werden damit habe ich nur einen opcode, oder?

Und wo bleibt das Überprüfen ob jemand schon vor Dir dran rumgefummelt hat? Nichtmal InterlockedCompareExchange bekommt das hin. Das Ergebnis des Vergleichs bekommst Du so höchstens nach der Austauschaktion. Aber ist ja okay, war ja nur ein kleines Detail von dutzenden die man übersehen könnte ...

So, das war jetzt mein letzter Beitrag zum Thema . Wir haben es lange genug durchgekaut. Das Szenario mit dem Überprüfen vor Austausch übrigens auch, aber das hattest Du innerhalb weniger Beiträge wieder "vergessen".

Flamefire hat folgendes geschrieben :

bisher noch ohne validation aber das kommt ja noch. und für meine anwendung wird das ding nicht sehr groß, wodurch es da (hoffentlich) kaum probleme zu suchen gibt.

Eins noch. Wenn Du Validierung über's WHQL meinst, informier Dich lieber vorher nochmals, sonst könnte Dein Geschäftsmodell infrage stehen. Treiber für VIsta und neue müssen übrigens immer als x86 und x64 bereitstehen, was mit KM-Hooks und Patchguard ab Vista x64 nicht mehr so einfach ist.

als validierung meinte ich hier eine mehr oder weniger vollständige analyse des codes auf fehler wie den besprochenen, bzw im blog genannten.

ich verstehe immer noch nicht, was ich denn bei der SSDT überprüfen sollte?

ich lese. vergleiche den gelesenen wert mit dem original. alles in meinem speicher, den ich einfach mal als konsistent und nicht von außen veränderlich ansehe. (man kann ja davon ausgehen, dass niemand grade in seinem laufenden programm variablen ändert, und wenn doch, ist das nicht mein problem)
wenn vergleich negativ-->ssdt eintrag gehookt-->enthooken
ob den da schon jmd vorher enthookt hat, ist mir doch egal. dann überschreibe ich halt den originaleintrag mit dem originaleintrag...passiert doch nix, oder?

darum habe ich das nicht vergessen, sondern mit obiger argumentation als nicht sinnvoll angesehn.