mirror of
https://github.com/quasar/Quasar.git
synced 2026-04-25 15:25:59 +03:00
[GH-ISSUE #149] New Keylogger Progress #70
Labels
No labels
bug
bug
cant-reproduce
discussion
duplicate
easy
enhancement
help wanted
improvement
invalid
need more info
pull-request
question
wont-add
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Quasar#70
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @MaxXor on GitHub (May 19, 2015).
Original GitHub issue: https://github.com/quasar/Quasar/issues/149
Hey,
as we don't have a general issue about the new Keylogger, I'll open this one.
What's the current status of the new Keylogger in the
dev-branch? And is the Keylogger in themaster-branchstable at the moment?This is mostly for @yankejustin and @d3agle, as they've worked on the new Keylogger.
Thanks!
@ghost commented on GitHub (May 19, 2015):
I've been working for a while on this and I've got a working solution. However, there is a lot of work that needs to be done. One of the problems is how the keys will be logged to ensure that the additional enhancements that were desired, are met. I've fell short of coming up with a viable solution to controlling the situations of displaying Modifier keys e.g. [ctrl + alt + shift + esc]. I feel like this is a problem @yankejustin could tackle with ease.
The current keylogger in the master-branch is stable, but it is not optimized nor is it viable.
Would you like me to commit a bare-bones version of the current work I've done, to the dev branch?
@MaxXor commented on GitHub (May 19, 2015):
Yes, that would be great if you make a pull request.
@MaxXor commented on GitHub (May 19, 2015):
Bugs:
Todo:
@yankejustin commented on GitHub (May 19, 2015):
@d3agle At whichever state your work is in, I would appreciate a pull request to be sent to the dev branch. I noticed you made many changes but I don't often send contributions to volatile branches so I was just waiting a little bit on you to add your changes to the new branch so I can help out. :)
@yankejustin commented on GitHub (May 19, 2015):
@MaxXor Is there a possibility that you could close the issues related to the keylogger on the main branch and open them on the dev branch for us please?
@yankejustin commented on GitHub (May 19, 2015):
To give a more definite answer to all those wandering, I have been experimenting with the hook with progress, but I am actually having my High School graduation banquets and such so I have been quite busy! x)
I have time tonight and I will finally switch this thing over to a hook. :)
@MaxXor commented on GitHub (May 19, 2015):
@yankejustin Closed them. Congrats for finishing High School! :) No need to rush the code now, take the time you need.
@yankejustin commented on GitHub (May 19, 2015):
@MaxXor Haha thanks.
I have a big favor... Would you please resolve some of the conflicts we have with the
masterbranch compared to thedevbranch? I am still rather new to doing that using Github so I might end up butchering it. x)@MaxXor commented on GitHub (May 19, 2015):
Done. :)
@yankejustin commented on GitHub (May 19, 2015):
Thank you very much!
@yankejustin commented on GitHub (May 19, 2015):
@MaxXor I was messing with ideas that have finally come together about this Keylogger. Before I set to work putting the puzzle together (features of handling mouse input, repeated strokes, accent character handling, (alt + key code) combining) I naturally set off to research if anybody has already added a feature like this. It is rather foolish to re-invent the wheel, right? ;)
Anyways, I have stumbled upon a project recently moved to Github and I think it is perfect for our needs.
Link to @gmamaladze's project
It will be very easy to adapt to this project, it is event-driven (no manual Timers), and I know exactly how to fix it up. What is in that project is a good representation of the building blocks for of a functional, efficient, and versatile Keylogger. I could implement this (awaiting gmamaladze's explicit permission) and chain a variant of a producer-consumer pattern to route the output however we wish, and I also expect to hook up my key filter (client can be explicity told which keys to log).
@ghost commented on GitHub (May 19, 2015):
Nice find @yankejustin! I took a look at some of the source and it is very well written. The key filtering will be very important to accomplishing what we need done. Looking forward to seeing what you can do with this.
@yankejustin commented on GitHub (May 19, 2015):
To extend on key filtering, gmamaladze's project also seems to have started on registering hotkeys. For those reading this that may not understand, hotkeys allow filtering of more complex combinations of keys. :)
@MaxXor commented on GitHub (May 20, 2015):
Indeed, a very nice find @yankejustin! Hope we can use it too.
@DragonzMaster commented on GitHub (May 20, 2015):
nice find, I hope gmamaladze does not mine using his project
I gave it a look and it seems to be good
EDIT : Correct me If i am wrong ... it uses global hook (Article Posted in 2004 'codeproject')
so can you remind me who said that global hook is impossible in .NET ? 😆 😆 @yankejustin
@yankejustin commented on GitHub (May 20, 2015):
@DragonzMaster It is not possible using .NET... It is possible by invoking native code.
@yankejustin commented on GitHub (May 20, 2015):
We need to:
1) Make sure the hook is being set.
2) Verify that keys are being handled correctly.
I suspect an issue in setting the windows hook (preventing output):
https://github.com/yankejustin/xRAT/blob/Keylogger/Client/Core/Keylogger/WinApi/HookHelper.cs#L57
Can someone please help me research how effective getting the current process' main module -> base address is when the process is running under the way the client is? (shell execute = true... etc.)
Also, @MaxXor handling more special keys is much easier with v3.5 💩
@ghost commented on GitHub (May 20, 2015):
@yankejustin, the reason the hook isn't working currently is because we don't have a message pump on the thread, so we can't intercept the messages from the OS
Calling Application.Run() should do the trick
@DragonzMaster commented on GitHub (May 20, 2015):
i don't know if you have seen this or not ... if not you can give a look at the Author's Article you might find it useful @yankejustin
GlobalHook [http://www.codeproject.com/Articles/7294/Processing-Global-Mouse-and-Keyboard-Hooks-in-C]
Sorry I'm really busy these days
@yankejustin commented on GitHub (May 21, 2015):
@DragonzMaster Yes, of course I have seen that. :)
The code I have implemented to the keylogger branch is the work of George "gmamaladze"Mamaladze. His updated work is now placed on Github. The link to his repository can be found on a post I made yesterday on this same issue. 🐐
@yankejustin commented on GitHub (May 21, 2015):
@d3agle Thank you for the information. It is very appreciated.
@yankejustin commented on GitHub (May 22, 2015):
Status
4/22/15
Functioning (needs a bit more work, but it works).Upcoming
To Finish By 5/24/15
1) Write unit tests for the Keylogger. 2) Perhaps extend supported keys for the Keylogger by attempting to use the (older)KeyloggerKeysenumeration instead of theKeysenumeration. 3) Final testingBy 5/25/15
masterEdit (5/23/15):
@MaxXor commented on GitHub (May 22, 2015):
I really like your status posts, thanks alot. :) I'll see if I can help with any of this.
@yankejustin commented on GitHub (May 23, 2015):
Status
Very good point; it works at a very good level.
To-Do
At this point, the code is clean and efficient enough to implement to
masternow. However, we should really fix that vulnerability caused by this before merging. Besides that, the features that are being conjured can come at some later time; for now, this Keylogger is so much better that, besides the vulnerability that has existed since the beginning, it would be a great addition to themasterbranch.@yankejustin commented on GitHub (May 23, 2015):
Thank you for the complement, MaxXor. :)
@ghost commented on GitHub (May 23, 2015):
I would just like to point out, that before this should be merged to the master branch, we should also take care of the problem with the message pump calling Application.Run(). I haven't found a solution to ending it's operations. Calling Application.ExitThread() within the thread does not work, and because the thread does not exit, the client won't respond well to disconnects or uninstalling. I'll try to dig a little bit further to see what else can be done, but I would appreciate any help implementing some sort of solution, whether its clean or not!
@MaxXor commented on GitHub (May 23, 2015):
I'll try to find a solution for this too.
@rabbitsmith commented on GitHub (May 23, 2015):
can i know what is the vulnerability
@MaxXor commented on GitHub (May 23, 2015):
https://github.com/MaxXor/xRAT/issues/167
It's already fixed.
@ghost commented on GitHub (May 23, 2015):
#178, fixed message loop termination
@ghost commented on GitHub (May 23, 2015):
Status
Functional and operational
To-Do
The keylogger has been refactored and optimized to the point I can hardly find any more ways to improve the functionality. We should now be able to merge to master and see if any issues pop up. (Hopefully not, but who knows)
@MaxXor commented on GitHub (May 23, 2015):
@d3agle the PageUp and VolumeUp are already highlighted with the latest commit.
@ghost commented on GitHub (May 23, 2015):
Oh ok! I wasn't sure I hadn't tested them I was just using them as examples for extra keys to add. We should really add as many as we can just so we can ensure it looks pretty on the user-end :D
@MaxXor commented on GitHub (May 23, 2015):
When we find the reason for issue #181 and fix it, we can merge
devintomaster.@MaxXor commented on GitHub (May 24, 2015):
Status
- Fully functional and operational - Ready to merge into `master`@ghost commented on GitHub (May 24, 2015):
Before merging this @MaxXor, I need to fix a bug with the dead-keys. Pressing the ^ key then Shift + character should produce an upper-case accented character
@ghost commented on GitHub (May 24, 2015):
dead-key fix #189
@ghost commented on GitHub (May 24, 2015):
Another bug surfaced, it has to do with how we handle our modifier keys.
(Pressing Alt Gr + character for example shown)
@yankejustin commented on GitHub (May 24, 2015):
@d3agle Out of curiosity, what is your keyboard layout?
@ghost commented on GitHub (May 24, 2015):
@yankejustin, I'm using German keyboard layout. (Language pack DEU) http://clasfaculty.ucdenver.edu/tphillips/GermanKeyboardLayout.html
@yankejustin commented on GitHub (May 24, 2015):
I am on a different machine that supports different characters.
Here is a short list of some good (common) specials to test for:
` ¡ ™ £ ¢ ∞ § ¶ • ª º – ≠
œ ∑ ´ ® † ¥ ¨ ˆ ø π “ ‘ «
å ß ∂ ƒ © ˙ ∆ ˚ ¬ … æ
Ω ≈ ç √ ∫ ˜ µ ≤ ≥ ÷
@ghost commented on GitHub (May 24, 2015):
Another problem is that some of the accented characters, for example 'Ê' (pressing '^' followed by shift + e), will provide the correct representations from the system, but in our logs it will state a 'E' without the accents. This doesn't happen with lowercase letters.
@yankejustin commented on GitHub (May 24, 2015):
https://github.com/d3agle/xRAT/blob/dev/Client/Core/Keylogger/WinApi/KeyboardNativeMethods.cs#L318
Does using
Charset.Autoaffect us? Shouldn't we specify to marshal the info. usingCharset.Unicode?Also, @d3agle , I would find where our flags are internally being reset somewhere along the lines...
I would also recommend actually looking at the actual logs and making sure it is not an issue with displaying it in the WebBrowser control.
@ghost commented on GitHub (May 24, 2015):
@yankejustin, I'm not sure. I will check it out and see if I can produce some results. Also, the ToUnicodeEx method in https://github.com/MaxXor/xRAT/blob/dev/Client/Core/Keylogger/WinApi/KeyboardNativeMethods.cs#L77 will report the correct unicode value. However, in the raw data in the KeyPress event, the e.KeyChar value will be of unaccented value (Given the state of holding 'shift + key'). The webbrowser control won't be the problem since I've added the metadata tags for displaying utf-8 charsets (I checked this by setting a flag in the KeyPress event checking for 'Ê' as a character)
@yankejustin, it is not the Charset.Unicode. I think it might be somewhere in here https://github.com/MaxXor/xRAT/blob/dev/Client/Core/Keylogger/KeyEventArgsExt.cs#L104
@yankejustin commented on GitHub (May 24, 2015):
https://github.com/MaxXor/xRAT/blob/dev/Client/Core/Keylogger/WinApi/KeyboardNativeMethods.cs#L141
Try
while (rc < 1);@yankejustin commented on GitHub (May 24, 2015):
https://github.com/MaxXor/xRAT/blob/dev/Client/Core/Keylogger/WinApi/KeyboardNativeMethods.cs#L118
Restrict how often that is set to 0. We should not lose that
lastVirtualKeyCodeso fast... :(I'm curious why there is a return type
boolon this function; it will always returntrue.@ghost commented on GitHub (May 24, 2015):
@yankejustin , I fixed this about an hour ago #189, the system posts the message to the active window with success an accurately, it's only when its translated back into a character we don't have the data
Also, you're right, the return type doesn't matter. I had to make some modifications to the code to get it to work and I didn't think about changing the method to void. The only thing we are interested in getting out of this method is the char[]
@yankejustin commented on GitHub (May 24, 2015):
Before I leave for a bit, I just wanted to clarify what I said earlier.
There is a location within that method (likely somewhere around where I suggested) that is obviously setting an internal state incorrectly, causing the reflected output to be something that is not what went in. Somewhere along the lines, it is either setting the incorrect internal state or is neglecting to handle it.
Last lead before I go:
https://github.com/MaxXor/xRAT/blob/dev/Client/Core/Keylogger/WinApi/KeyboardNativeMethods.cs#L110
Possibility
It is often very likely that it arrives at that case when there are two or more items found because of un unresolvable dead key combination.
It is likely arriving there because https://github.com/MaxXor/xRAT/blob/dev/Client/Core/Keylogger/WinApi/KeyboardNativeMethods.cs#L118 is losing our value of the lastVirtualKeyCode, and is telling the rest of the method that it is not to be handled as a dead key (even though it likely was).
@yankejustin commented on GitHub (May 24, 2015):
Oh, got it. I will see this again later if it is not fixed. Enjoy your day.
@ghost commented on GitHub (May 24, 2015):
Thanks. You too! When you're available, it would be awesome if you could brainstorm some alternate modifier key designs so we can use (AltGr modifier - which is (Ctrl + alt) but also provides a character)
Also, @yankejustin, you are closer to the source of the problem than I thought I was. What I don't understand is why the message that is posted to the active window is accurate, but the character returned isn't...
I set a MessageBox within this loop here:
https://github.com/MaxXor/xRAT/blob/dev/Client/Core/Keylogger/KeyPressEventArgsExt.cs#L112
Searched for 'ê' character and it found it. Searched for 'Ê' character and it did NOT find it.
@ghost commented on GitHub (May 24, 2015):
@yankejustin, thank you for pointing this out! I have fixed the accenting bug now!
(The line that is inaccurate with the ^^, I'm not sure why this happens. Press the '^' dead key once then again and it will display ^^ as it would normally, however in our logs it displays once (not applying the dead key as a character)
The only thing other than fixing the case of 2 characters in the buffer, that appears that is left to do is modify our ModifierKeys design to something that will allow us to use the AltGr modifier (Ctrl + alt + key) as a character representation!
@ghost commented on GitHub (May 24, 2015):
Reference to this problem: https://github.com/MaxXor/xRAT/pull/189#issuecomment-105033185
(The line that is inaccurate with the ^^, I'm not sure why this happens. Press the '^' dead key once then again and it will display ^^ as it would normally, however in our logs it displays once (not applying the dead key as a character)
The problem is the raw event handlers in this case our KeyPress event, the first '^' (caret) is sent to the handler, and added to our pressedKeyChars List, followed by another caret sent to the method after. Since its already added it wont be added again/added to the logs. It won't be removed from the list to be added again because the first keypress to '^' is a dead key and has no character representation (nothing is returned the first time). The second time it is pressed it fills the buffer with two '^' characters and then it will trigger the KeyPress event handler twice (including KeyDown/KeyUp of course)
@MaxXor commented on GitHub (May 24, 2015):
Fixed the bug with the ^^. :)
@MaxXor commented on GitHub (May 24, 2015):
Status
- Wrong detection of AltGr + key@ghost commented on GitHub (May 24, 2015):
Awesome :) Good job!
We can merge this into master if you are ready to, however we still need to work on modifier keys.
For example, try pressing AltGr and a key to display a symbol, then look at the logs (This won't be a huge issue, but it's annoying when it occurs)
@MaxXor, it is because AltGr translates to (Control key + Alt key press), so the KeyDown event fires with both Control and Alt keys
@MaxXor commented on GitHub (May 24, 2015):
Sorry, I've updated the status. I'll look into this.
@DragonzMaster commented on GitHub (May 24, 2015):
but one thing need to be added >> the time to windows title @d3agle @MaxXor
@ghost commented on GitHub (May 24, 2015):
@DragonzMaster , good call!
@m6m4m2 commented on GitHub (May 24, 2015):
Good job you guys ...
the purpose of a key-logger is to log every key that have bean pressed on
the keyboard nothing more ... but since the data will be huge some times
its harder to read the raw data ... so I think you should work on a filter
so that data can be easier to read like this picture below
here is the source
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
namespace xServer.Forms
{
public partial class FrmRePlay : Form
{
public FrmRePlay()
{
InitializeComponent();
}
private int i;
private string strMessage;
1), 1));
if ((i == strMessage.Length))
{
timer1.Enabled = false;
}
if (strMessage.Contains("[Enter]"))
{
strMessage = strMessage.Replace("[Enter]", "\r\n");
}
}
}
On Sun, May 24, 2015 at 9:10 PM, d3agle notifications@github.com wrote:
@ghost commented on GitHub (May 24, 2015):
@xmizrx , that is a nice idea. Maybe you can add an enhancement for this when we have completed it, kind of like an add-on for the Log viewer for the server!
@yankejustin commented on GitHub (May 25, 2015):
Personally, I think we should add this to
masternow. It is so significantly better than the original keylogger and the keylogger in thedevbranch has no more major issues. It is now mostly up to a polishing point. This should be implemented now and allow the long "polishing" phase to tie with themasterbranch.@ghost commented on GitHub (May 25, 2015):
@yankejustin , sorry I broke it XD. take a look at #190. After this I think it SHOULD be good to go, I'm currently testing other possibilities/scenarios with other languages/keyboard layouts that use dead-keys. If I can't break it after I spend a few more hours with it we should be good to go!
@MaxXor , do you have a keyboard with an Alt Gr key? If so, could you please test my latest pull request #190 here and let me know if it works combining (Alt Gr + 2) to produce the '²' character?
@yankejustin commented on GitHub (May 25, 2015):
@MaxXor Next branch created for
devshould be on the next priority: persistence.@DragonzMaster commented on GitHub (May 25, 2015):
Presistance OR Registry Editor 💭 ?? @yankejustin
@yankejustin commented on GitHub (May 25, 2015):
Registry Editor is a minor feature. By minor, I mean that the process of creation and implementation is rather straight forward. I do not think editing a registry hive by a programming language is difficult (please tell me if I am incorrect!). Not much different than a file editor. :)
I will look into it while MaxXor deliberates on the next priority.
@rabbitsmith commented on GitHub (May 25, 2015):
@yankejustin please describe the status of the keylogger so that useless and good-for-nothing people like me can understand
@ghost commented on GitHub (May 25, 2015):
@MaxXor, as @yankejustin said this is good to go