[DEC] TProtection classes

[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.