Skip to content
This repository has been archived by the owner on Mar 17, 2024. It is now read-only.

New Keylogger #122

Closed
wants to merge 19 commits into from
Closed

New Keylogger #122

wants to merge 19 commits into from

Conversation

yankejustin
Copy link
Contributor

Hi!
Here is the re-written keylogger!

@MaxXor Please make a separate branch for this because there are a few more things that should be either fixed, added, or modified with this keylogger before it should be added to the main branch. Please see Upcoming and To-Do.

Features

  • Flexible and dynamic behavior
  • Easy to modify
  • Encapsulation
  • Supports many more keys (again, extremely easy to add more)
  • Documentation!
  • Uses Virtual Keys then calls ToUnicodeEx for better localization.

Upcoming (before merging)

To-Do

  • Improve code and optimize (much later... probably after upcoming is done and after adding to the master branch)
  • More testing on the output... A few known unreliable things, such as: pressing 'alt' key or 'ctrl' key will print the correct key (such as '[CTRL]' for the correct key, but will then also print '[L_CTRL]' because it was the control key from the left...)
  • Improvements to the interface, including things like being able to easily access or modify log files, colorizing, etc. Open Containing Folder Addition to Transfers + Colorizing Window Title and adding time to keylogger #90
  • Add the ability to dynamically re-assign the output, as specified in Email keylogger logs. #111
  • Add a maximum size cap. for log files and add folders for each day instead of files because they get long. Also handle multiple or repetitive keys in a more elegant way, as specified in multible (repeated) key in keylog and very long line #119
  • Eventually encode the formatted output of the keylogger so it is not vulnerable to Cross-Site Scripting (XSS)

yankejustin and others added 19 commits May 7, 2015 08:09
Merge with most recent branch
Big changes to the Keylogger. Still needs lots of changes but my intent
should be visible by these changes. This is now very flexible, easy to
change and add keys, etc.
Added documentation for the two properties of the Keylogger.
AttributeTarget can now correctly apply to Keylogger Keys.
Added the second and likely last of the big changes and additions to the
Keylogger. The core design of it is much more clear than the initial
changes commit. Though not yet functional (last of it has to be
implemented, as seen by the small commented-out portions), it is nearing
completion. With this new design, it is significantly more scalable.
With these changes also comes another huge factor: modifications. This
new system allows easy feature additions and modifications, such as
filtering out specific keys to log dynamically in a natural manner.
Made a small attribute to support the power and beauty of extension
methods in .NET 2.0! :)
Fixed null check for the stored key loop in the key buffer and renamed a
method so it is more clear.
Very nice work.  This looks very nice.
added special key attributes
Implemented the new way of adding a key to log when the timerLogKeys
elapses.
If the timerEmptyKeyBuffer elapsed at a bad time or state, or if it was
unable to 1) Append data to _logFileBuffer or 2) Was unable to
successfully remove the entry from _keyBuffer
Now we can see this thing in action!
Needs one more commit to handle the special keys again and to detect
when a toggle key is toggled. I can't remember how to represent 0x80 as
a byte! :(
Forgot to add changes to this file!
Many more changes.
Still has things to work out but there is much more to work with and
many more possibilities.
@DragonzMaster
Copy link
Contributor

I see that you have a lot of work to do
good luck bro :D

@yankejustin
Copy link
Contributor Author

Hehe... Yeah, it is quite a lot of work, but might as implement a new and big feature correctly to make it easier for future changes and modifications! :)
A big reason for asking for a separate branch from my last commit is because it is in a functional state. Not the desired state, but it works. Making a branch from my current progress means that many others will be able to take some of the work and contribute to this new major change to a big part of what makes up a wholesome Remote Administration Tool. 💯

@MaxXor
Copy link
Contributor

MaxXor commented May 12, 2015

Created the new branch dev for this.

@ghost
Copy link

ghost commented May 12, 2015

Good work @yankejustin, I'm making some changes to this to get the toggle/down keys to work correctly. One thing I've noticed is that keys are sometimes logged multiple times just pressing the key once, maybe you could have some insight on why this is happening. Also, currently, every key is being treated like a special key (being highlighted)

@yankejustin
Copy link
Contributor Author

@d3agle Thank you! :)
Yeah I will have to toy with the output tonight. The big priority is making sure that the special keys are being captured, and that the toggle state of the keys is being correctly detected.
The reason that the keys are logged multiple times is because the value of the keys that have multiple values (ctrl = l_ctrl | r_ctrl) so I think I am just neglecting to pull only a single flag out of the input we are given...

@yankejustin
Copy link
Contributor Author

Another priority is the interface, but we (of course) need the output to be accurate and correctly formatted. :)

@yankejustin
Copy link
Contributor Author

@MaxXor Can my fork be deleted without affecting your branch? I should have used a different branch instead of my fork's master branch to work on the keylogger... :P

@MaxXor
Copy link
Contributor

MaxXor commented May 13, 2015

@yankejustin yes. :) it's safe to delete.

@yankejustin
Copy link
Contributor Author

Okay, good. Thank you!

@ghost
Copy link

ghost commented May 14, 2015

I hate to say this, but I don't think that this key logger is going to work, as far as accuracy and efficiency. I've done a lot of research on GetAsyncKeystate and it doesn't appear that this method contains enough information to have accurate control on what we are trying to accomplish. Initially, I wanted to avoid global keyboard hooks when I was looking into this method, but considering there would be a lot more control over the accuracy and efficiency of recording keystrokes (filtering system messages), I think that using a keyboard hook might be a more viable option.

@yankejustin
Copy link
Contributor Author

Yeah, I agree. Throughout my extensive research on all hookless methods to do this, I have consistently seen horribly poor documentation by Microsoft, inconsistent behavior with the methods provided, and just simply incorrect behavior that seems to be experienced by others as well. It feels that, even if done correctly, this is going to end up being one hacky fix after another in order to implement a functioning and accurate keylogger.

@yankejustin
Copy link
Contributor Author

@MaxXor We need your input on this. I have been doing more research in my free-time (about to work on some open issues soon), and I have also come to the conclusion that using a keyboard hook would be far better of a solution due to the unpredictable and poorly-understood GetAsyncKeystate

@MaxXor
Copy link
Contributor

MaxXor commented May 15, 2015

I think we should try out using a keyboard hook. :) Let's see how this is working.

@yankejustin
Copy link
Contributor Author

I am going to close this pull request because most of it is already in the "dev" branch. I will be committing new changes so we are using a keyboard hook instead of GetAsyncKeystate and I will create another pull request once the new way is up. :)

@MaxXor
Copy link
Contributor

MaxXor commented May 15, 2015

Alright!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants