Anti Keylogger and Clipboard monitor

[rcbblgy]

Thank tzuk for lots of help

SbieAKL is a dll used to block the keylogger and clipboard monitor which are sandboxed

Requires sandboxie versions: v3.46 or higher (both of 32bit and 64bit)



How to use it:
1、Put the dlls and ini file at same place, for example C:\SbieAKL
2、Edit the "sandboxie.ini" file, and add the following content for 32bit

InjectDll=C:\SbieAKL\SbieAKL.dll

or this for 64bit

InjectDll=C:\SbieAKL\SbieAKL.dll
InjectDll64=C:\SbieAKL\SbieAKL_64.dll

the content should be added under the sandbox which you want to use the dll



About the ini file:

you should put the ini file at the same folder with the two dlls

In the ini file , you could see the content like below

Code: Select all

[OPTION]
;when LearnMode=1, please allow the sandboxed programs access the current ini file directly or fully
LearnMode=0


[ALLOW]


[CONTROL]
GetKeyState=1
GetAsyncKeyState=1
GetKeyboardState=1
WH_KEYBOARD_LL=1
WH_KEYBOARD=1
WH_JOURNALRECORD=1
GetRawInputData=1
GetRawInputBuffer=1
RegisterHotKey=1
AttachThreadInput=1
RegisterRawInputDevices=1
SetClipboardViewer=1
GetClipboardData=1


[EXCEPTION]

1、About the "CONTROL" section -----Global rule
All of APIs are hooked in the dll are put under the "CONTROL" section, you could set value to "0" to turn off an API hook, if all of hooks are turned off, the sandboxed programs would not be injected by the dll
Notice:All the sandboxed programs use this control, so if you turn off an API hook, the API hook of all the sandboxed programs is turn off

2、About "EXCEPTION" section -----Exception rule
Here, you could turn off an(or some) API hook for a (or some) program, other sandboxed programs are not affected by these rules
for example:
C:\Program Files\Internet Explorer\iexplore.exe = GetKeyState,GetKeyboardState
GetKeyState and GetKeyboardState are not hooked if the injected program is iexplore.exe
Notice:if you want to add an exception rule, you should use the full path of the program



3、About "ALLOW" section -----White list
If a program is put here, it would not be injected by the dll, so there is no hook for it, Usually, you could put your trusted programs here
for example:
C:\Program Files\Internet Explorer\iexplore.exe = 1
Now IE is a trusted program
Notice:Require full path, and the value should be "1"




4、LearnMode -----Same with learn mode of HIPS
If you set it value to "1", the dll would record all of APIs used by a program, the dll will write a rule in the ini file when the program exits, when the program runs next time, the dll will not hook these APIs, So, "LearnMode" could help you make a trusted program works correctly
Notice:If you turn on the "LearnMode", please allow the sandboxed access the current ini file directly or fully


Download:
SbieAKL

[rcbblgy]

About priority
[ALLOW] > [EXCEPTION] > [CONTROL]


when the dll is injected into a process, it will get the full path of the process, then it will read the ini file

step 1
if the dll find the path under "ALLOW" section, it will make the process unload itself

step 2
if the dll can't find the path under "ALLOW" section, it will get the rules under "CONTROL" section and "OPTION"

step3
the dll will try to find the path under "EXCEPTION" section, if find, it gets the rule

step4
now the dll gets all the rules in the ini file, then it begin to judge whether there is any API is hooked, if there is , the process is injected, if there isn't, the process will not be injected

step5
if the process is injected and "LearnMode" is turn on, the dll will record which API has been used and add an exception rule when the process exits, if "LearnMode" is turn off, the dll will block the process call the APIs which are hooked.

[ssj100]

This sounds interesting. Does it block screen-shot logging too? Might be worth testing it out against Zemana's and SpyShelter's test programs etc. I might test it out myself if I find time.

[rcbblgy]

This sounds interesting. Does it block screen-shot logging too? Might be worth testing it out against Zemana's and SpyShelter's test programs etc. I might test it out myself if I find time.

It can't block screen-shot logger.

It could block SpyShelter's test tool and AKLT

About the Zemana's test tool, if you use sbie v3.5 and win7 64bit, the dll could block it, otherwise, can't

[ssj100]

When I try to put

Code: Select all

C:\SbieAKL\SbieAKL.dll

in the "Sandboxie.ini" file (for 32-bit), I get an error.

[ssj100]

It can't block screen-shot logger.

About the Zemana's test tool, if you use sbie v3.5 and win7 64bit, the dll could block it, otherwise, can't

Right, any reason why it can't block it on other Windows platforms? Or is that still in development?

[rcbblgy]

When I try to put

Code: Select all

C:\SbieAKL\SbieAKL.dll

in the "Sandboxie.ini" file (for 32-bit), I get an error.

Error ? Could you give me some more information ?

[ssj100]

Never mind, I think I worked it out - I think you meant this:

Code: Select all

InjectDll=C:\SbieAKL\SbieAKL.dll

Simply putting:

Code: Select all

C:\SbieAKL\SbieAKL.dll

won't do anything. In your instructions above, you make it sound like that's all you need to input for 32-bit.

By the way, just tested it with the Spyshelter tool and it works against keylogging and clipboard monitoring. Nice work.

EDIT: but come to think of it, simply denying execution of the program with Sandboxie's start/run restrictions is probably more effective?

[rcbblgy]

It can't block screen-shot logger.

About the Zemana's test tool, if you use sbie v3.5 and win7 64bit, the dll could block it, otherwise, can't

Right, any reason why it can't block it on other Windows platforms? Or is that still in development?

I don't know how it gets the key stroke

I use Defensewall to test it, and Defensewall shows me that the tool uses RegisterRawInputDevices to get the key stroke, but I have hooked this function in my dll, I don't know why it can't be blocked

[rcbblgy]

Never mind, I think I worked it out - I think you meant this:

Code: Select all

InjectDll=C:\SbieAKL\SbieAKL.dll

Simply putting:

Code: Select all

C:\SbieAKL\SbieAKL.dll

This is my mistake

EDIT: but come to think of it, simply denying execution of the program with Sandboxie's start/run restrictions is probably more effective?

so would you deny all unknown programs

[ssj100]

EDIT: but come to think of it, simply denying execution of the program with Sandboxie's start/run restrictions is probably more effective?

so would you deny all unknown programs

Yes, all my internet facing sandboxes only allow certain programs to start/run and access the internet. In fact, I have execution of everything unknown blocked by default system-wide with SRP too. If I want to play with a program or malware, I run it in a sandboxed VirtualBox.

But regardless, it looks like you have done some good work here. I'm sure if you kept developing it, it could prove to be a very valuable addition for many people.

[rcbblgy]

Yes, all my internet facing sandboxes only allow certain programs to start/run and access the internet. In fact, I have execution of everything unknown blocked by default system-wide with SRP too. If I want to play with a program or malware, I run it in a sandboxed VirtualBox.

I know , the dll is useless for most of people

but for me, I use sbie only, so it would be a little useful when I test an unknown program

And most of trusted programs will use these API which I hook in the dll, so it is also inconvenient

[Mark_]

The dll needs vc++ 2008 sp1 to work, and the version of sandboxie it requires is v3.46 or higher (both of 32bit and 64bit)

check this topic for a very nice explanation how to remove the visual studio runtime: http://www.uc-forum.com/forum/c-and-c/6 ... ntime.html

[rcbblgy]

check this topic for a very nice explanation how to remove the visual studio runtime: http://www.uc-forum.com/forum/c-and-c/6 ... ntime.html

thanks, I have updated it

[mikkie]

Does anyone have any further info regarding the method to capture data the Spyshelters test-tool uses? I am very curious but i suffer from a great lack of time to analyze it in depth at the moment. I have a small sense of feeling that the purpose of the tool is rather to market their product under abit of false or misleading info, but i could be wrong. This tool has been around for quite awhile and if i am not misstaken it has not gone through any greater changes since atleast 18+ months back.

The current FUD keyloggers around at current date uses rather sophisticated methods to remain so. All "logical" and oldschool documented methods are useless today. A wealthy host of security products have focused alot on defeating keylogging since the wildspree of (specifically Russian, Ukraine, Chinese, Vietnamese and Brazilian) RAT´s with logging capabilities that swept the globe like wildfire 2 years ago. Many of these products are now so touchy that they will generate false positives to such an extent that users may find them a pain in the ar*e to have installed.

Yet the spyshelter tool bypasses an ridiculous amount of these security products with ease, including some of the ones prone to generate an FP on keylogger detection as soon as u fire up notepad and type anything. Not even the behavioural based scanners or application control monitors found anything irregular about the test tool. Cant help but find this abit odd. The new breed of java based malware is extremely difficult to detect but i doubt theres any obfuscated java code being executed with their tool. It would be very interesting to test S-Shelters real effectiveness against any in the wild malware with logging. If i had time i would but im already hooked on too many similar projects. If anyone could pass me a shortcut i would be most thankful.

Zemana on the other hand im already familiar with, its a pretty good product too. Their test tool is also more believable and also easier to detect since it uses mostly known methods.

Sorry if i unintentionally hijacked the topic abit. This is a great tool for people like me who daily analyze unknown and/or suspicious activity and runtimes. Thanks for your effort and contribution. Much appreciated!