[DEC] TProtection classes

[Meflin]

Hi,
gibt es da eine möglichkeit, eingabefelder vor keyloggern (keyboard hooks basierten) zu schützen (mit den protection classes). gibts eigentlich irgendwo ne doku für das dec :roll:

[Meflin]

[push]

[Meflin]

[push] :roll:

[Meflin]

[push] :x

[Luckie]

Kuck mal in meinem Keylogger Opensource Thread, da hat Hagen so was gepostet.

[c113plpbr]

Ich bezweifle, dass es ne doku gibt, aber schick NegaH doch ne PM und frag ihn

[Meflin]

Zitat:

Zitat von Luckie

Kuck mal in meinem Keylogger Opensource Thread, da hat Hagen so was gepostet.

ich weis, leider ist das ohne sourcen!

[shmia]

Zitat:

Zitat von Meflin

gibt es da eine möglichkeit, eingabefelder vor keyloggern (keyboard hooks basierten) zu schützen

Du könntest einen eigenen Keyboard-Hook installieren und die Funktion CallNextHookEx nicht aufrufen.
Damit müssten alle anderen Keyboard-Hooks aus dem Rennen sein.

Zitat:

Zitat von Meflin

(mit den protection classes)

Kenne ich nicht. Was meinst du damit ?

Zitat:

Zitat von Meflin

gibts eigentlich irgendwo ne doku für das dec

Was meinst du mit dec ? Für mich sagt diese Abkürzung nur Digital Equipment Corp.

[Meflin]

das dec ist das delphi encryption compendium (siehst du auchbeim drüberfahren mit der maus)

[negaH]

In DEC Part I Version 3.0 ist eine solche Funktionalität nicht integriert. Dies hat mehrere Gründe
1.) konzeptionell gehört sowas nicht da rein
2.) solche Funktionalität ist eine Ausbesserung der "Fehler" des Betriebsystemes, hat also primär nichts mit Kryptographie zu tun
3.) jede halbwegs vernünftige Lösung des Problemes läuft auf die Vermeidung von Edit Feldern und des Keyboards hinaus, da es NIEMALS verhindert werden kann das Tastatureingaben gesnifft werden. Als kleines Beipiel: ich habe einen ATTiny Mikroprozessor programmiert der in einen PS2 Stecker eingebaut wird. Dieser Spezial Stecker, der sich in NICHTS von einem echten Stecker unterscheidet sitzt nun zwischen Keyboard und PC. Er protokolliert alle Eingaben des Benutzers und kann bei Eingabe eines Passwortes diese Eingaben an den PC senden. Desweiteren gibt es sogar Fern-Spionage-Systeme die einfach auf Funktechnischen Wege das Keyboard und den Bildschirm abhören können.
Wenn aber schon die Hardware nicht sicher zu bekommen ist dann kann es eine Softwaretechnische Lösung niemals geben.

Im besagtem Thread zeigte ich denoch eine Möglichkeit wie man fast alle Software-Spyer austricksen kann. Die Idee ist es NICHT den Spyer zu erkennen und zu deaktivieren, dies ist falsch (Keyboard Hook usw.), sondern ein Sperrfeuer von vielen Tastaturanschlägen zu prouzieren. Innerhalb dieses Sperrfeuers befinden sich die realen Tastaturereignisse. Der Clou dabei ist es eine Methode zu erfinden die es deiner Software, die ja das Sperrfeuer produziert, ermöglicht weiterhin zwischen den echten und unechten Tastaturevents zu unterscheiden. Fazit: deine Anwendung produziert viele sinnlose Tastaturanschläge, markiert diese aber mit einem komplexen und nicht reproduzierbaren Verfahren. Somit kann nur deinen Anwendung die echten Tastenevents rausfiltern und die Eingabe in einem geschützten Speicherbereich zusammenbauen. Eine primitive Spysoftware wird dagegen aber alle Tastenevents protokollieren und der Angreifer kann nicht mehr den inhaltlich richtigen Kontext reproduzieren. Er sieht eine rießige Anzahl von sinnlosen Tastenanschlägen zwischen denen sich die echten Events verstecken.

Diese Methode habe ich in einer experimentellen DEC Version entwickelt und erfunden. Sie funktionierte mit 99% aller Spyer zuverlässig auf allen Windows Systemen. Ein effektiver Software-Spyer muß demzufolge auf einer höheren Ebene ansetzen, nämlich dem Treiber-Kernel oder den Tastatur-Port manuell auslesen.
Die meisten, doch recht primitiven Spyer, gehen über die Keyboard Hooks oder Window Hooks etc.

Gruß Hagen

[negaH]

Achso: TProtection als Klasse hat demzufolge rein garnichts mit solchen Methoden zu tun. Eventuelle habe ich den Klassennamen ungünstig und misverständlich gewählt ;)

Gruß Hagen

[Meflin]

ok, alles kalr. ein mann ein wort ;-)
aber ich finde du solltest echt mal eine dokumentation schreiben!

[negaH]

Oh mann, Die Geister die ich rief, nun werd' ich sie nicht mehr los ;)

Ich glaube Chakotey hier im Forum hat sich mal die Mühe gemacht.
Selber habe ich keine Dokumentation geplant, sorry.

Gruß Hagen

[webtom]

Wo bekommt man denn den Source dafür her um so ein Passworteingabefeld vor Keyloggern zu schützen? Würde gerne sowas für mein Programm benutzen.

Hier im Forum kann ich nix finden über TProtection classes, oder der von Hagen entwickelten Komponente.

[DGL-luke]

na selber machen ;)

wie bereits gesagt, ne masse an key messages generieren (sendkeys() o.ä.), die DU auf Echtheit prüfen kannst, ein Keylogger aber nicht.

Also z.B.

Delphi-Quellcode:

c := chr((GetTickCount mod 26) + 65);

Das wär schon mal n (etwas zu) einfacher Weg, einen Key zu generieren. Wenn er ankommt, überprüft du, ob er der aktuelle "spoofkey" ist - wenn nein, wird er angenommen.

[Meflin]

Das ist ja noch der leichte Teil - aber wie soll man letztendlich überprüfen ob der Key von der Tastatur komm oder von meiner Software?

[Kedariodakon]

Du kennst den Algo :zwinker:

Bye

[Meflin]

Zitat:

Zitat von Kedariodakon

Du kennst den Algo :zwinker:

:gruebel: also irgendwie - nein. ich erzeuge via sendkey o.ä. simulierte tastatureingaben - woher soll ich wissen, ob das "a" vom user kommt oder vom sendkey? so ganz kann ich nicht folgen... es gibt ja keinen großartigen algorithmus?

[DaFox]

Hi,

Zitat:

Zitat von Meflin

woher soll ich wissen, ob das "a" vom user kommt oder vom sendkey?

Du erzeugst Pseudotastenanschläge und speicherst diese. Bei einem OnKeyX-Event überprüfst Du den aktuellen "Key" mit Deiner Liste. Entspricht der erste Eintrag der Liste dem "Key" löschst Du das Element und lässt den "Key" unter den Teppich fallen. Stimmen sie nicht überein kommt der Key vom Benutzer (bzw. nicht von Deinem Programm).

Gruß,
Markus

[negaH]

Schaue dir die Funktion keybd_event() im API ganz genau an. Der letzte Parameter ist wichtig, da über ihn die mit keyb_event() erzeugte Botschaft quasi "markiert" werden kann. Die Fensterprozedur deines Edit Control kann mit GetMessageExtraInfo() diesen Wert abfragen.

Wichtig ist es nun das diese "Markierung" nach einem Muster erfolgt das nicht durch einen Keylogger nachvollzogen werden kann, dh. nur deine Fensterprozedur des Edit Controls sollte das unterscheiden können.

Damit hast du nun eine Möglichkeit zwischen den "falschen virtuellen" Tasten und den echten Benutzereingaben zu unterscheiden. Denn der Wert den GetMessageExtraInfo() liefert kann so überprüft werden das nur die faked virtullen Tasten die richtige "Prüfsumme" liefern.

Aus Sicht der meisten Keylogger passiert nun folgendes:
Sobald das Edit Control den Fokus erhält erzeugt ein Thread im Hintergrund ca. virtuell 120 Tastenanschläge pro Sekunde. Das macht diese Thread Funktion solange wie das Edit den Focus hält. Zwischen diesen vielen Tastenanschlägen verstecken sich aber vereinzelt die echten Benutzereingaben. Der Keylogger protokolliert aber ohne Unterschiede BEIDE Eingabemöglichkeiten und kann da er, GetMessageExtraInfo() nicht auswertet oder nicht reproduzierbar auswerten/filtern kann, keine Unterscheidungen treffen. Der Angreifer sieht also im Logfile eine Menge von sinnlosen Eingaben und darin verstecken sich vereinzelt und quasi zufällig die richtigen Eingaben.

Aus dieser Sicht ist klar

1.) das Logfile enthält alle notwendigen Informationen um ein Password denoch wiederherstellen zu können
2.) diese Technik ist eine reine "Tarnen & Täuschen" Taktik
3.) sie ist also nicht wirklich mathematisch beweisebar sicher, was auch der Grund dafür ist das ich sie nur ungern anspreche

Gruß Hagen

PS: die Fensterprozedur des Edit Control sollte natürlich auch den Passworttext selber in einem sicheren Datenbereich zusamenbauen. Dh. .Caption oder .Text oder wm_GetText/wm_SetText sollte man vermeiden und stattdessen den realen Passwortstring in der Fensterprozedur selber zusammensetzen, statt diesen wieder per API quasi sichtbar zu speichern. Denn es nützt ja nichts über aufwendige Keyboard Tricks das loggen der Eingaben zu verhindern wenn wir später das eingegebene Passwort selber per API abspeichern. Denn dann kann ein Angreifer mit GetWindowText() darauf zugreifen. Übrigens DIE Schwachstelle beim Windows-Passwordchar-Edit-Control das ja nur die Anzeige per GDI unterdrückt aber NICHT die Speicherung der realen Eingabe in die Fenster Caption/Text.

[Meflin]

Zitat:

Zitat von negaH

PS: die Fensterprozedur des Edit Control sollte natürlich auch den Passworttext selber in einem sicheren Datenbereich zusamenbauen. Dh. .Caption oder .Text oder wm_GetText/wm_SetText sollte man vermeiden und stattdessen den realen Passwortstring in der Fensterprozedur selber zusammensetzen, statt diesen wieder per API quasi sichtbar zu speichern. Denn es nützt ja nichts über aufwendige Keyboard Tricks das loggen der Eingaben zu verhindern wenn wir später das eingegebene Passwort selber per API abspeichern. Denn dann kann ein Angreifer mit GetWindowText() darauf zugreifen. Übrigens DIE Schwachstelle beim Windows-Passwordchar-Edit-Control das ja nur die Anzeige per GDI unterdrückt aber NICHT die Speicherung der realen Eingabe in die Fenster Caption/Text.

DAS habe ich schon kapiert ja, bzw mir schon selber gedacht. Und da ich dank deiner Antwort jetzt das nötige Know-How habe werde ich das tun was ich vorhatte, nämlich mir eine kleine aber feine Passwort-Input Komponente schreiben ;)
Mir ist durchaus klar dass das noch lange nicht sicher ist, weil es ja auch beispielsweise hardwarebasierte Keylogger gibt (Keyghost etc), wie du glaube ich in diesem Thread schonmal erwähnt hast, aber deswegen muss man ja trotzdem nicht auf die äußerst zweckundienliche Standardkomponente zurückgreifen.