ToAscii verändert Zustand der Tastatur

[Shaman]

Hey there

Ich habe Probleme, bei einem Keylogger mit diakritischen Zeichen umzugehen. Wenn ich den KeyCode, welcher mir korrekt vom Hook geliefert wird, über ToAscii umwandle, werden Zeichen wie ^ ´ ¨ nicht mehr richtig ausgegeben.

Ich habe das auf ein kleines Testprogramm runtergebrochen. Ich möchte im OnKeyDown eines Memos anhand des KeyCodes die Zeichen finden, die nachher im OnKeyPress im Memo erscheinen:

Delphi-Quellcode:

type
  DChar = array[0..1] of Char;

function VKeyToChar(vkCode: Word; out Buffer: DChar): Integer;
var
  KS: TKeyboardState;
  I: Integer;
begin
  GetKeyboardState(KS);
  Buffer:= #0#0;
  Result:= ToAscii(vkCode, MapVirtualKey(vkCode, 2), KS, @Buffer, 0);
end;

procedure TMainForm.Memo1KeyDown(Sender: TObject; var Key: Word;
  Shift: TShiftState);
var
  B: DChar;
begin
  Edit1.Text:= IntToStr(Key);
  if VKeyToChar(Key, B) >= 0 then
    Edit2.Text:= B
  else
    Edit2.Text:= '[DEAD]';
end;

Problem: Wenn z.B. ^ gedrückt wird, liefert VKeyToChar '^^', aber im Memo selbst ändert sich nichts...
Kann mir hier jemand weiterhelfen?

[smallsmoker]

Ich belebe diesen alten Thread mal neu !

Ich habe dasselbe Problem, und hoffe das jemand in der Zwischenzeit ein workaround oder ähnliches gefunden hat.

Ich selbst bin auf das hier gestoßen:

http://www.docdroppers.org/wiki/inde...ing_Keyloggers

Er greift direkt auf die Dll zu in der das Tastatur Layout drinne steckt, baut also quasi die Funktionalität von toAscii nach.

sowie das hier wo man sich z.b. kbd.h besorgen kann

http://www.assembla.com/code/rkm/sub...eylogger?rev=4

leider bin ich nicht so fitt in c++ und ehrlich gesagt hoffe ich das es einfacher geht ...

Mit freundlichen Grüßen

smallsmoker

[p80286]

Wo liegt jetzt Dein Problem?

Wenn Du schon irgendwie an der Tastatureingabe "herumspielst" weißt Du ja wahrscheinlich wie die Tastatur am PC funktioniert.

Taste Drücken -> Tastencode wird an PC geschickt (manchmal einer für drücken und einer für loslassen ist Sache des Controlers) -> Tastaturtreiber macht daraus 0..x Zeichen

da ich nicht weiß, wo in dieser Verarbeitungskette Du aufsetzt, ist es schwierig zu Deinem Problem etwas zu sagen.
Angenommen, der VK wird vor dem Tastaturtreiber abgegriffen dann erkannt man das Zeichen ^ oder besser die Taste auf der das Zeichen^ aufgemahlt ist. Nach dem Weg durch den Tastaturtreiber bleibt da zunächst nichts von übrig, da für die Zeichenausgabe ein weiteres Zeichen notwendig ist. Also ein a für â oder ein o für ô oder ein m für ^m.

Das Beispiel in #1 konnte allerdins nicht richtig funktionieren, da der Buffer ein wenig klein war (2 <> 265).
Und toascii ist ja von der installierten Sprache/Landesinformation abhängig, also für eine unabhängige Verarbeitung nicht zu gebrauchen.

Gruß
K-H

[Reinhard Kern]

Zitat von p80286:

Taste Drücken -> Tastencode wird an PC geschickt (manchmal einer für drücken und einer für loslassen ist Sache des Controlers) -> Tastaturtreiber macht daraus 0..x Zeichen

Hallo,

eben deshalb kann die ursprüngliche Funktion garnicht sicher funktionieren - da wird eine Taste VKey übergeben von irgendeinem Zeitpunkt t-x und dazu der Shiftstatus zum Zeitpunkt t neu abgefragt (anstatt den Shiftstatus aus KeyDown zu verwenden), natürlich sind diese Infos nicht mehr synchron. Wenn sich dazwischen was geändert hat, kann nur Unsinn rauskommen.

Gruss Reinhard

[Reinhard Kern]

Zitat von p80286:

Taste Drücken -> Tastencode wird an PC geschickt (manchmal einer für drücken und einer für loslassen ist Sache des Controlers) -> Tastaturtreiber macht daraus 0..x Zeichen

Hallo,

eben deshalb kann die ursprüngliche Funktion garnicht sicher funktionieren - da wird eine Taste VKey übergeben von irgendeinem Zeitpunkt t-x und dazu der Shiftstatus zum Zeitpunkt t neu abgefragt (anstatt den Shiftstatus aus KeyDown zu verwenden), natürlich sind diese Infos nicht mehr synchron. Wenn sich dazwischen was geändert hat, kann nur Unsinn rauskommen.

Gruss Reinhard

Fehlfunktion, bitte löschen!

[smallsmoker]

Habe die Frage nun auch HIER gestellt (CROSSPOST)

darum geht es nicht ...

es ist ein bekanntes problem das ToAscii sowie ToUnicode den Tastatur-Buffer löschen.

Das hat nichts damit zu tuhen das der KeyboardState nicht genau von dem zeitpunkt stammt.

Ich habe ewig im internet recherchiert und wirklich viele haben dieses problem !

Beispiele:

ToAscii/ToUnicode in a keyboard hook destroys dead keys.

oder von der Seite die ich gepostet habe:

Zitat:

ToUnicode() does not only provide no support for dead keys, it also interferes with them to the point of not being able to type accented letters anymore. [...] Unless Microsoft reworks its implementation of ToUnicode(), we have to make our own improved version. This is going to be way longer than calling ToUnicode().

oder:

Using ToAscii inside keyboard hook modifies the keyboard result

oder:

Zitat:

NOTE: One could also use ToAscii() or ToUnicode() functions of the WindowsAPI to convert the keystrokes into text. However, these functions often behave in a strange manner (such as with accentuation and shift state)[...]

von hier

Eine lösung wäre vieleicht den buffer irgendwie wiederherzustellen ... kp wie das gehen sollte, ich hab da nich so tolle ideen deswegen hab ich ja hier gefragt.

edit: Habe den Code im ersten Post nicht gestest aber man kann das hier in Shaman's Keylogger beobachten

edit2: ich habe auch das hier gelesen verstehe es leider nicht ganz ...:

Zitat:

The parameters supplied to the ToAscii function might not be sufficient to translate the virtual-key code, because a previous dead key is stored in the keyboard layout.

aus msdn

edit3: Habe was (meiner meinung nach) interessantes gefunden:

Code:

George,

The problem probably lies with ToAsciiEx.
It takes keystrokes and converts it to (ascii) character codes.

When using ToAsciiEx in a global hook proc, this messes up the handling of dead key characters in the application that is being hooked ..
The reason is that ToAsciiEx stores (remembers) the dead key when pressed and does not return a character.
When a 2nd key is pressed, ToAsciiEx takes the stored dead key, combines that with the new key and returns the combined character.
If a hook proc calls ToAsciiEx, the hooked application will also call ToAsciiEx (Actually TranslateMessage does this in the applications main message loop). 
The fact that ToAsciiEx is called twice to process the same keystrokes messes up the dead key character combination, because the first ToAsciiEx that is called will eat the dead key that was stored and the 2nd ToAsciiEx will no longer find a dead key character stored and will therefore produce an incorrect ascii character ... 
We basically confuse ToAsciiEx by calling it twice to process the same keystrokes: once in the global hook and once in the hooked application .
Ofcourse, in English, these special characters like "à" do not exist and this problem does not occur there. But in most European languages it does.
I have found a number of attempts on the internet to work around this problem, but none of them works as it should.

A method that works is to simply trap the WM_CHAR message in a global hook.
A WM_CHAR message carries complete characters like é, ñ, etc.
A WM_CHAR message is generated by the API function TranslateMessage that takes the keystrokes (WM_KEYDOWN etc.)
and translates the virtual key codes into an ascii character (most likely by calling ToAsciiEx internally).
TranslateMessage is called in an applications main message loop like this:
Code:
    DO WHILE GetMessage(Msg, %NULL, 0, 0)
        TranslateMessage Msg
        DispatchMessage Msg
    LOOP
Strangely enough, I have read that there are applications that do NOT call TranslateMessage, and use a message loop like:
Code:
    DO WHILE GetMessage(Msg, %NULL, 0, 0)
        DispatchMessage Msg
    LOOP
Like this, no WM_CHAR messages are generated and a global hook can not trap the characters ...
However, keystroke messages like WM_KEYDOWN are still generated ..
I read that Borland Delphi shows (or showed) this behaviour, though I myself have never encountered a program behaving like this.
Apart from one I wrote myself to test.

Hope this helps (a bit)...

Kind regards

(Hab das male in [ Code ] gepackt weils soviel is)

Kommt von hier

[smallsmoker]

Sry für den Doppelpost aber sonst geht es noch unter ...

Benutz jetzt ein (sehr) dreckiges workarround

Wenn ein toter Key kommt benutze ich ToAscii nicht und setze ein boolean (bool1) auf true

Wenn der nächste Buchstabe kommt speichere ich diesen sowie den Keyboard Zustand und setze die bool1 auf false und bool2 auf true

Wenn der nächste buchstabe kommt und bool2 true ist gebe ich den gepspeicherten Buchstaben aus.

Naja so wird der User wenigstens nicht genervt (sowie bei Shaman), leider habe ich dann auch keine âsd oder ásd in den logs sondern nur Oem5asd

vieleicht kann jemand was damit anfangen, auch wenn ich das bezweifele xD

mfg smallsmoker

[p80286]

Warum nicht? Der Keylogger produziert ja nur die "Zutatenliste", gekocht wird in toascii. Dem entstandenen Gericht sieht man dann manchmal gar nicht mehr an woraus es zusammen gekocht wurde.

Aber wie wäre es mit DK_OEM5 oder etwas ähnlichem, damit man's gleich erkennt?
Ausserdem würde ich den Keycode und das Zeichen mit übergeben, es soll Anwendungen geben, die nur auf Keycodes reagieren, da sind die produzierten Zeichen ganz egal.

Gruß
K-H

[smallsmoker]

habe ne neue idee ...

ich glaub ich pack wenn ein deadkey kommt den in ne queue wenn noch einer kommt den auch etc.

wenn dann ein nicht-deadkey kommt wird er auch noch in die queue gepackt (das wäre dann zb ^^â oder ähnlich) immer zusammen mit den keyboard states etc.

wenn dann noch ein nicht-deadkey kommt (man kann nun ToAscii ohne Gefahr benutzen) wird die queue abgearbeitet so das im Log stände: "^^^aa" statt original: "^^âa" woraus man aber das original aber gut ablesen könnte.

kann mich grad nur nich aufraffen

[smallsmoker]

schlagt mich tot ich mach nochmal nen doppelpost, aber irgendwie glaub ich das edits untergehen xD -.-

also ich habe das aus meinem vorherigen post realisiert und was echt komisches festellen können

nachdem ich nun die vkcodes und die keyboard states etc. in die liste gepackt habe und durchging, fiel mit auf das wenn man ToAscii mit einem deadkey aufrief dieser in den Buffer des Keyboards geladen wurde ...

kp ob jemand was damit anfangen kann xD

edit:

achso um das oben genannte workarround zu realisieren musste ich nun beim durchgehen der queue wenn es sich um einen deadkey handelte ToAscii ein 2. mal aufrufen um den Keyboard Buffer wieder zu leeren Code (in c#)

Code:

                foreach (object obj in DeadKeys)
                {
                    object[] objArray = (object[])obj;

                    OnKeyActionWeiterverarbeitung2((uint)objArray[0], (uint)objArray[1], (bool)objArray[2], (byte[])objArray[3]);

                    if (IsDeadKey((uint)objArray[0]))
                        ToAscii(vkcode, nScanCode, (byte[])objArray[3], new StringBuilder(2), 0);
                }
                }