Kann mir jmd den unterschied zw hooken und patchen erklären?
Unterschied schrieb: > Kann mir jmd den unterschied zw hooken und patchen erklären? Hooken ist: du klinkst deinen Code an irgendeiner Schnittstelle ein. Patchen ist: du manipulierst direkt den Zielcode.
In Ergänzung zu obiger Antwort: Beim Hooken ist das üblicherweise vom Entwickler so beabsichtigt, beim Patchen nicht.
Die Definitionsversuche treffen ja dann trotzdem zu, man muss sie nur beide anwenden :) Ach ja: Patchen hat sonst noch mindestens zwei weitere Bedeutungen in der IT von denen ich weiß, sollte man vieleich auch nochmal erwähnen.
Patch (engl. Pflaster): Pflaster um einen Fehler zu beheben (Wunde bedecken, etwas zusammenpflastern) Hook (engl. Haken oder einhängen): Einhängen eines Codes irgendwo. Zum Beispiel einen Zusatzcode in einen Interrupt. Meist nicht zur Fehlerbehebung, sondern als Erweiterung. Und praktisch nur, wenn es über einen Funktionsaufruf in der Sprache hinaus geht. Also das Aufrufen einer Funktion in einer ISR ist KEIN Hook. Das umleiten eines Interruptvektors und nachträgliches Aufrufen der ursprünglichen Routine schon eher.
Eins N00B schrieb: > In Ergänzung zu obiger Antwort: Beim Hooken ist das üblicherweise vom > Entwickler so beabsichtigt Darauf würde ich nicht wetten... Sprich: das kann so sein, wenn eben die "Schnittstelle" vom Entwickler genau dafür vorgesehen war. Es kann aber auch durchaus ungewollt passieren. An allen anderen "Schnittstellen"... Und: es kann sogar an dafür vorgesehenen Schnittstellen unerwünschte Hooks geben. Typisch sind da z.B. root kits, die installieren sowas. Die machen das, um den Kern der Sache zu verbergen. Gegenüber aller regulären Tools, die eben diese regulären Schnittstellen verwenden.
A. S. schrieb: > Patch (engl. Pflaster): Pflaster um einen Fehler zu beheben (Wunde > bedecken, etwas zusammenpflastern) Oder die Funktionalität zu verändern. > Hook (engl. Haken oder einhängen): Einhängen eines Codes irgendwo. Zum > Beispiel einen Zusatzcode in einen Interrupt. Meist nicht zur > Fehlerbehebung, sondern als Erweiterung. Und praktisch nur, wenn es über > einen Funktionsaufruf in der Sprache hinaus geht. Also das Aufrufen > einer Funktion in einer ISR ist KEIN Hook. Das würde ich so pauschal nicht stehen lassen. ZB:
1 | void user_function(void) __attribute__((weak)) {} |
2 | |
3 | void isr_handler(void) { |
4 | user_function(); |
5 | }
|
In dem Fall wäre user_function() schon ein Hook für mein Verständnis. > Das umleiten eines > Interruptvektors und nachträgliches Aufrufen der ursprünglichen Routine > schon eher. Und das wäre für mich ein Patchen der ISR-Tabelle. c-hater schrieb: > Sprich: das kann so sein, wenn eben die "Schnittstelle" vom Entwickler > genau dafür vorgesehen war. Es kann aber auch durchaus ungewollt > passieren. An allen anderen "Schnittstellen"... Aber ist das dann noch die Nutzung eines Hooks oder eine andere Methode, Code zu injizieren? Beispiel: die Nutzung von LD_LIBRARY_PRELOAD unter Linux, um Programmen eine alternative Implementation von Systemaufrufen unterzuschieben (zB ein anderes open, um hardcoded Dateipfade zu ändern) würde ich zB auch nicht als Hook bezeichnen, obwohl das sogar eine definierte Schnittstelle ist. > Und: es kann sogar an dafür vorgesehenen Schnittstellen unerwünschte > Hooks geben. Typisch sind da z.B. root kits, die installieren sowas. Die > machen das, um den Kern der Sache zu verbergen. Gegenüber aller > regulären Tools, die eben diese regulären Schnittstellen verwenden. Patchen die nicht Systembibliotheken, um sich zu verstecken? Patchen in dem Sinne, dass sie (unter Windows) die Funktionalität einiger System-DLLs abändern? Ich wüsste nicht, dass es dafür Hook-Schnittstellen gibt. Und selbst wenn: Patches sind wohl das besser versteck, sonst könnte der Virenscanner ja einfach die registrierten Hooks durchegehen oder sowas.
Eins N00B schrieb: > In dem Fall wäre user_function() schon ein Hook für mein Verständnis. Nach der Beschreibung im verlinkten Wikipedia-Artikel (zitiert aus "Einschubmethoden") hast Du sicher recht. Das ist für mich aber eher ein Callback, Rückruffunktion, API. Meine Auffassung von Hook war früher, dass man sich irgendwo einhängt, wo es nicht explizit designed, aber möglich war.
A. S. schrieb: > dass man sich irgendwo einhängt, wo es > nicht explizit designed, aber möglich war. Möglich sollte es immer sein, wenn man hardwarenah programmiert - man ersetzt z.B. 3 Befehle durch einen Sprungbefehl, führt diese 3 nach dem zusätzlichen Code aus und springt an die Absprungstelle plus 3 zurück. Üblich, aber so hat sich der Designer das ganz sicher nicht vorgestellt. Georg
Das Verb "hooken" gibt's im Informatiksprachgebrauch nicht. Wenn das jemand im Zusammenhang mit Computern benutzt, weiß man, dass er weder von Computern noch von Golf Ahnung hat.
A. S. schrieb: > Das ist für mich aber eher ein Callback, Rückruffunktion, API. Meine > Auffassung von Hook war früher, dass man sich irgendwo einhängt, wo es > nicht explizit designed, aber möglich war. Ein Callback bzw. eine Rückruffunktion wird in meinem Verständnis hingegen als Funktionsobjekt/-zeiger übergeben, meistens per Parameter. Interessant, wie das so auseinanderlaufen kann. Ich kann deine Interpretation des Begriffs durchaus nachvollziehen und auf eine Art erscheint es mir sogar die logischere, wenn man von dem Begriff aus kommt. Wenn man von dem Konzept ausgeht, lande ich wieder bei meiner ☺ . foobar schrieb: > Das Verb "hooken" gibt's im Informatiksprachgebrauch nicht. Wenn > das > jemand im Zusammenhang mit Computern benutzt, weiß man, dass er weder > von Computern noch von Golf Ahnung hat. Das halte ich für etwas voreilig und ziemlich arrogant (scheint in diesem Forum aber recht verbreitet zu sein; siehe Justage vs Kalibrierung).
Eins N00B schrieb: > Patchen die nicht Systembibliotheken, um sich zu verstecken? Meist nicht. Wäre zuviel Aufwand. > Ich wüsste nicht, dass es dafür > Hook-Schnittstellen gibt. Doch die gibt es natürlich. Es sind einfach die "Einsprünge" (Funktionszeiger) der DLLs. Die biegt der Angreifer einfach auf eigenen Code um und filtert entweder die Parameter oder das Ergebnis oder beides und ruft zwischendurch den tatsächlich adressierten Code auf. Und das funktioniert natürlich unter Linux ganz genauso, auch wenn dort DLLs nicht DLL heißen. Das Prinzip ist dasselbe: irgendwo im Adressraum des Prozesses gibt es eine Tabelle von Funktionszeigern. Die kann man manipulieren und auf eigenen Code umlenken. > Und selbst wenn: Patches sind wohl das besser > versteck, sonst könnte der Virenscanner ja einfach die registrierten > Hooks durchegehen oder sowas. Looser. Virenscanner benutzen was? Die u.U. bereits manipulierten Interfaces des Systems... Genau das ist der Witz: es gibt keine vollständige Code-Sicherheit. Die Angreifer manipulieren und versuchen, die Manipulation bestmöglich zu verbergen, die Verteidiger machen aber im Prinzip exakt dasselbe. Mal gewinnt der, mal der. Das Problem ist: es genügt, wenn der Angreifer einmal gewonnen hat. Dann kann er den Verteidiger dauerhaft Kacken schicken und zwar so, dass niemand INNERHALB des Systems es bemerken kann. Ist dann nur ein Frage des Aufwands auf Angreifer-Seite. Die muss dann sicherstellen, dass der Verteidiger für den Benutzer jederzeit immer hübsche plausible Meldungen liefert, die sinngemäß besagen, dass alles in Ordnung wäre... Der einzige Weg, sowas zu finden, ist die Analyse von AUSSERHALB des Systems.
Wo ist eigenltich der Unterschied zwischen Hook und Interceptorpattern? Das müsste doch das selbe sein oder?
Unterschied schrieb: > Kann mir jmd den unterschied zw hooken und patchen erklären? Der Thread hat es bereits angedeutet, aber... Nun, letztlich geht es in allden Fällen darum, das Verhalten einer Software zu verändern. Dazu gibt es viele Möglichkeiten; die einfachste und vermutlich gebräuchlichste ist, ihren Quelltext zu verändern, indem ein Patch appliziert wird. Aus dem traditionellen UNIX- und Linux-Umfeld kennen Entwickler daher die zwei Programme diff(1) und patch(1): das Erste sieht sich zwei (die alte und die neue) Versionen des Quellcodes einer Software an und erstellt daraus eine Datei, die oft ebenso "Patch" genannt wird. Diese Datei kann dann verschickt werden, und andere Entwickler können ihre alte Version der Software mit dem Programm patch(1) und der betreffenden Datei auf den neuen Stand bringen. Diese Technik wurde früher häufig in Entwicklerteams genutzt, und heute basieren so ziemlich alle SCM-Systeme wie CVS, Subversion und Git auf diesem Prinzip -- im Wesentlichen geht es dabei um die Synchronisierung verschiedener Versionsstände von Quellcode. Ein Patch ist immer vom Entwickler intendiert und erwünscht. Ein Hook hingegen ist eine Veränderung des Programmverhaltens zur Laufzeit und kann vom Entwickler vorgesehen sein, und das ist auch die Regel. Dazu hat der Entwickler meistens bewußt an einer oder mehreren bestimmten Stellen seines Programms Möglichkeiten eingebaut, andere oder zusätzliche Funktionen aufzurufen. Ein Hook ist üblicherweise vom Entwickler so vorgesehen. Ein Beispiel im Linux-Kernel wäre das (zum Glück unbekannte) Modul "binfmt_misc". Davon zu unterscheiden ist ein Callback: auch der verändert das Laufzeitverhalten eines Programms, ist aber auf jeden Fall vom Entwickler vorgesehen. Dabei geht es üblicherweise darum, daß eine bereits in dem Programm vorhandene Funktion als Funktionszeiger übergeben und dann aufgerufen wird. Denk zum Beispiel an einen Taschenrechner, der addieren, subtrahieren, multiplizieren und dividieren kann: abhängig vom eingegebenen mathematischen Symbol wird die korrekte mathematische Operation für Deine Eingaben ausgeführt. Ansonsten ist ein Callback eher dazu geeignet, die richtige Funktion an der richtigen Stelle aufzurufen. Dann gibt es noch den Begriff des "Monkey Patching". "Patch" ist hier an sich nicht ganz das richtige Wort, denn auch dabei geht es im Wesentlichen um eine Veränderung des Laufzeitverhaltens einer konkreten Instanz eines Programms. Ein gutes Beispiel für diese Technik ist das Programm valgrind(1); es ersetzt die Systemaufrufe zur Allokation und Deallokation von Arbeitsspeicher (malloc(3), free(3), new, delete, placement-new und placement-delete) durch seine Versionen mit eingebauten Speicherchecks. Letztlich fürchte ich allerdings, daß Deine Frage hier in diesem Forum ein wenig deplatziert ist. Die meisten Entwickler haben allenfalls -- über ihr SCM-System -- mit Patches zu tun. Diese Aussage betrifft nicht nur Embedded-Entwickler, vor allem aber genau diese! Denn auf einem Mikrocontroller kannst Du in der Regel keine dieser Techniken mit Ausnahme von Callbacks implementieren... ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.