Ghostpress - Free AntiKeylogger

That pic shows it binding to the loopback interface (127.0.0.1). Which some applications use for local communication between local components.

 

This is starting to look and sound really nice, great job!

I am also loving that you made Ghostpress portable, which makes it really nice when using a computer that isn't yours.

So far, I am liking everything that I see.

As for the widget color, sure why not.

Anyway's, keep up the excellent work!

 

Yes...you are right...if that action is blocked there is no connection between launched executable and needed .NET components so in effect Ghostpress woun't work.

 

Ghostpress never connects with the internet, except you enabled the auto update. The update check is not enabled by default.

The idea with the smaller widget and icon only will be included in the next version, while we work on new main features.

I personally never had any detections like that.

@ichito The problem with the polish keyboard only affects the user if the keyboard is abnormal to the standard. If you need to hold a different key to press Number1 button for getting the "1" then please contact us over the site and we can work on a solution anytime soon, otherwise we could need your help to find the problem as well.

 

Why Not...

 

Appears to me it is using a local host proxy.

You can verify this by opening up TCPView and look for connections to/from 127.0.0.1. Why anti-keylogging software would need to use a local host proxy is beyond me. Note that by using a local host proxy, the software is performing a MITM on your Internet traffic.

 

@itman: What did YOU see? Did you observe a browser establishing connections with the port Ghostpress is listening on? Socket activity that would indicate browser traffic is passing through Ghostpress rather than (or in addition to) flowing in the way it normally would given your setup? Any other specific thing that you think shows Ghostpress achieves the ability to inspect browser traffic (HTTP and/or HTTPS) or "connects with the net" for purposes other than a safe/simple update check (that is disabled until opted-in to)?

 

I never installed and tested it. What I previously posted was a suggestion to anyone that has Ghostpress installed to check if it indeed is using a local host proxy server.

 

Sounded like more to me. In any case, there is that indication that Ghostpress listens on 127.0.0.1:49676. Ephemeral port range, so port might vary. It appears the developer is here, so in addition to users investigating for themselves we can also...

@hsdev: What is the purpose/use of this socket?

 

But how does it do this? Does it install a global or API hook in order to redirect pressed keys?

 

Firefox also does this, but I always block it and FF continues to work correctly. Although I do sometimes have problems with playing Flash videos, but I'm not sure if this is caused by this.

 

Any decent anti-keylogger installs a kernel mode driver and hooks the browser. This is the only way API's associated with keylogging can be detected at the local level. Ditto for AV software that has keylogging protection.

It appears what Ghostpress is checking for is javascript based keyloggers from a web site. I assume this is what it is using its local host proxy for. No thanks on this software. The last thing I personally want is some new and obscure software monitoring my incoming web traffic.

 

No, it's not necessary to block message and hook based keyloggers with drivers and you don't have to hook the browser. Back in the day there was some tool that installed a global hook with the purpose of interfering with other hook based loggers, but I can't remember its name. I suppose Ghostpress is using a similar method.

 

There is only for all practical purposes two ways to install a global hook:

1. Calling the global hook API
2. Force injection at boot time using the AppInit_DLLs registry key.

However what needs to be do by anyone running this software is to determine if any hooking is being done. Use Process Explorer and for your browser, look for a .dll associated with Ghostpress. Next see if that .dll is injected into other processes; I doubt that it is. If injected into other processes, check your AppInit_DLLs registry key to see if the .dll is loaded there.

 

Ghostpress does not connect to the network until it is checking for an update, which is disabled by default.
The tool we use for basic sniffing "SocketSniff" does not show any running socket connection ready to be sniffed on even "TCP View" shows one listening port. "Process Hacker" says there are two sockets listening while the local address is "live.rads.msn.com" which is known as advertising address, but that does not make sense until this would be the remote address.

Debugging result: When putting a break point on the first action which happens due the program code it already has created the socket listener. That means Ghostpress does not control this connection, but the application compilation with our compiler always results in this socket creation.

Furthermore Ghostpress is of course NOT only checking for is javascript based keyloggers due a local proxy, it has a global protection which includes javascript keyloggers as well. It does not require any .dll injection or other process manipulation for that.

 

looks interesting , will give it a try on a few machines . Thanks , sent 5 pound donation , not much I know , hope it helps a bit .

 

Could it be created by a debugging feature you have enabled or failed to disable... or a third-party library/component you are explicitly or implicitly using? I think you want to know what it could be used for, in case it could be used against you (try to get rid of it).

 

We still need fix one minor bug and get the translation done by our supporters. After it the next update is ready which fixes some annoying bugs and comes with three new features:
-3 widget styles as wanted by @mood : big widget(current), small widget and icon only (frameless)
-warning for critical detections which might disturb the protection
-new unique delay protection (an user sent us this idea): this protection will have three modes: disabled, basic and enhanced
The delay protection will protect the users against algorithms which try to identify persons by their typing behavior. It delays the keypress for a small (hardly or nearly not noticeable) randomized moment. The delay is either calculated by a basic random number generator or by a safe (cryptographic) number generator.

Thanks your help and contribution to make Ghostpress even better!

@Jerry666
Every single donation helps us, especially on the whole server and domain costs.
I hope you got my personal "thanks e-mail".

 

@TheWindBringeth
This socket connection occurs with all disabled debugging features as well(like version 0.8 ).

We are not using any third party component as well, but anyway we will try to figure out the reason for this socket listener and keep you up-to-date.

 

Perhaps SocketSniff?

 

We finally found the reason for this socket listener. Ghostpress is a single-instance application and multiple do not make sense that is why we enabled the compiler option to prevent multiple instances. The listener is telling all newly started Ghostpress applications that it is already running and they will exit directly and the running window gets focused.
Now we are using an alternative way of preventing multiple instances without any socket connection.

 

Thank you for the info @hsdev.

I'm liking all the changes, keep up the good work.

 

Very interesting development.

 

Looks that it's true...screenshot from my XP
befor updating


after enabling update

 

In reference to the above screen shot, here's an interesting read on port 1568 usage: http://www.speedguide.net/port.php?port=1568