[DEC] TProtection classes

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

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

Bye

[Meflin]

Zitat von Kedariodakon:

Du kennst den Algo

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