!!! CROSSPOST !!!
Habe hier ein kompliziertes Problem:
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 selbst bin auf das hier gestoßen:
http://www.docdroppers.org/wiki/index.php?title=Writing_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/subversion/nodes/keylogger?rev=4
leider bin ich nicht so fitt in c++ und ehrlich gesagt hoffe ich das es einfacher geht ...
Mit freundlichen Grüßen
smallsmoker
weitere Infos:
#####################################################################
es ist ein bekanntes problem das ToAscii sowie ToUnicode den Tastatur-Buffer löschen.
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 interessantes gefunden:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
| 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
!!! CROSSPOST !!!
