Registry Decoder v1.0 ~ Digital Forensics Tool

Registry Decoder v1.0 ~ Digital Forensics Tool:

What is Registry Decoder?
Registry Decoder provides a single tool in which to perform browsing, searching, analysis, and reporting of registry hive contents. All functionality is exposed through an intuitive GUI interface and accommodates even novice investigators. Registry Decoder is a free and open source tool

Registry Decoder was initially funded by the National Institute of Justice in late 2009 in the form of a research and development grant. Since the expiration of that grant, it has continued to be developed by Digital Forensics Solutions in order to add new features and perform more complex analysis. The main developers of Registry Decoder are Lodovico Marziale and Andrew Case.

Read more >>>

How to block or Disable Autorun.inf file in windows xp,Windows 7-Registry Edit

How to block or Disable Autorun.inf file in windows xp,Windows 7-Registry Edit:

Depending on the version of Windows that you are using, there are different updates that you must have installed to correctly disable the Autorun functionality:
To disable the Autorun functionality in Windows XP, in Windows Server 2003, or in Windows 2000, you must have security update 950582, update 967715, or update 953252 installed.



Simple way to disable autorun.inf :
Follow this link and download the msi file:

http://go.microsoft.com/?linkid=9741395

Read more >>>

How to disable writing to USB?

How to disable writing to USB?:

If you are the administrator of public cafe or school,this trick will be helpful for giving protection to your system.  You can disable writing to USB.  This will prevent from file stealing.  You have to login to administrator so that you can access regedit.

Go to start .  Select run.

Type as regedit and hit enter
Now navigate to

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies

 In right panel you can find writeprotect
Change the value to 00000001


That's all now no  one can transfer data to USB.  Now your system is protected.

How to show SuperHidden files in xp and vista?

How to show SuperHidden files in xp and vista?:

Some files will be hidden from Users. If you want to see those files,you have to edit the registry. This hack will fit for both windows xp and Vista.

Go to Start-<run
Enter as Regedit
Navigate to

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced

In the right panel ,you can see the superhidden registry
Right click on the SuperHidden
Change the Data value to 1.
Click ok
Exit the registry and restart the windows.

How to Fix the Login speed problem ?

How to Fix the Login speed problem ?:

Is your login speed very slow? then this may work to speed up your login speed.

Go to star->run
Type as regedit and hit enter
Navigate to this folder

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\Guardian

Right click over "Guardian" in the left pane.
Left click on "Permissions"
Left click "SYSTEM" once to highlight it.
Check "deny" in all boxes that you can at the bottom (Probably only 2)
Left click Apply
Left Click OK

Read more >>>

Building a Better Keylogger

Building a Better Keylogger: As some of you may or may not have known, in the past I wrote a keylogger in Perl for Linux systems. The purpose was to see what my significant other was doing to my computer while I was away from it, and certainly not to log passwords and things that malicious people use keyloggers for. I posted the source code to it here with the express disclaimer that it should be used only for educational purposes. [image]

Well, that keylogger had its problems. Although it had a couple of pros in there too compared to my new keylogger. The problem it had was that it required you to have root privileges on the Linux system you run it on, because it needed to read from /dev/input/* devices directly, which only the root user has permission to do. It also needed you to figure out which device node to read from ahead of time. And finally, it didn't work on some types of keyboards (I only tested it with a USB keyboard but I've heard reports from others that it just doesn't work for them).

The only pro it had was that it would log keys at the hardware level, including on text mode terminals.

Enter the New Keylogger

After reading this blog post about GUI isolation in *nix, I found out the trick to reading keys in the X Window System without root privileges. So, I wrote a new keylogger to take advantage of this new information I learned.

And so, the new keylogger does not require root privileges! The new keylogger relies on the X Window System, though, but this is the de facto windowing system on just about every Linux/Unix system out there today. This also means it will only log keys entered into graphical applications (for desktop *nix users though, this would log keys for just about everybody) so users in a text-mode terminal won't be logged.

One issue I ran into though is that the xinput test command seems to expect you to have a terminal (or TTY), i.e. that you run the command from a graphical terminal. So trying to read the output of this command in Perl caused some weird buffering issue, where the command wouldn't give any output until about 100 characters were typed. So, the script requires the IO::Pty::Easy module which creates a virtual TTY so that xinput believes you're running it from a real shell.

The new keylogger's source code can be found here. Have fun! [image]

More Ideas

They say that the Qubes system isn't vulnerable to this. In Qubes you basically set up different "security zones" for your various apps, to prevent the apps from messing with each other. On the back end it seems that it just uses multiple X servers to partition off the various zones. I have an idea how my keylogger could defeat even this...

When run from a graphical terminal, the $DISPLAY environment variable is already set to your current X display, e.g. ":0.0". But when launched from a non-graphical environment, the script would need to set the value of $DISPLAY itself, in order for xinput to know which X server to connect to.

Well, maybe if the keylogger changes up the value of $DISPLAY to log from different X servers it may be able to cross the partitions set up by Qubes. I'll have to investigate this further. [image]

SSH Port Forwarding

SSH Port Forwarding: *bump* (added a new section about getting to other machines on the remote network via port forwarding) - Originally posted on Jan 11, 2010 @ 7:08:50 PM.

This blog post is primarily for my own reference, to avoid having to dig through the manual to look up the occasional edge case.

How to use SSH to do port forwarding. These assume you're on a Unix-like system (Linux or OS X) and not using some lame Windows client like PuTTy.

Forwarding Remote Ports to You

Example: you're behind a firewall at the office, and your home computer is listening on the SSH port. You can connect out of the office to your home computer, opening a port so that, once you're home, you can SSH back to the office again (bypassing the firewall).

ssh -R 9022:localhost:22 remotehost.com

This will open port 9022 on remotehost.com (loopback only; you can only connect to 9022 from the local remotehost.com, not from elsewhere on the internet), and forward it to "localhost:22", where "localhost" refers to your computer at the office, and 22 is of course the SSH port.

By default the remote host only would make port 9022 available on the loopback address, so from your home PC you can do ssh -p 9022 localhost and connect to it, but you can't do e.g. ssh -p 9022 remotehost.com and connect to it from somewhere else on the Internet.

To open the port on all interfaces (thus making it available on the internet too):

ssh -R *:9022:localhost:22 remotehost.com

Replace the * with any other bind address if you want.

Forwarding Local Ports to Remote

If your home computer is running a web server on port 80, and for some reason you can't get to it from the Internet (firewall blocking it, maybe), you can forward a local port on your office computer that gets you to port 80 on your home computer.

ssh -L 8080:localhost:80 remotehost.com

Here, 8080 is opened on your office computer, for the loopback interface only, and localhost:80 refers to port 80 on the remote (home) computer. It's the reverse of ssh -R.

Then you open Firefox and go to http://localhost:8080/ and yer in.

Another example: you have a VNC (remote desktop) server running on remotehost.com, but the VNC protocol itself is insecure, and you don't want your password being sent across the network in clear text to log in. So, you need your VNC traffic to be encrypted via SSH.

Here, remotehost.com is listening on port 5900 (the VNC port). You want to open a port on your local computer to the same number, so that you connect a VNC client to "localhost:5900" and it really connects you to "remotehost.com:5900" over a secure SSH tunnel:

ssh -L 5900:localhost:5900 remotehost.com

Then with your VNC client, just connect it to "localhost".

"Penetrating" the Remote Network

Use case scenario: I'm at the office, and at home only my main PC can be reached from the Internet (the router forwards all ports to it); but, I also left my laptop at home turned on and it has a VNC server and I wanna get remote desktop access to it from work. So I'll use my home PC to set up a bridge so I can connect to the VNC server on the laptop, which has a private LAN IP address of say, 10.10.1.101.

ssh -L 5900:10.10.1.101:5900 remotehost.com

Here "remotehost.com" goes to the main PC which I can access.

This opens up a listening port 5900 on my local (office PC) -- the first 5900 in the command -- and if I connect to it, it will use remotehost.com as a jumping off point to connect onward to 10.10.1.101:5900 (the laptop with a private LAN IP address on the remote network).

Then I point my VNC client at "localhost" and I end up with remote desktop on the laptop.

Using SSH as a Secure SOCKS 5 Proxy

As a bonus, here's how to open up a secure SOCKS 5 proxy over SSH:

ssh -D 8080 remotehost.com

Now you can configure your programs (e.g. Pidgin, Firefox) to use a SOCKS 5 proxy and have them connect to localhost:8080. All their internet traffic will be routed through the SSH tunnel to remotehost.com, secured, and then enter the cloud from there.

Additionally, this can be used to reach other devices on the remote server's LAN that you otherwise couldn't get to. For example, turn on your proxy settings in Firefox and you can navigate to http://192.168.1.1/ to log into the router from the remote LAN (as opposed to a router on your local LAN). The SOCKS 5 proxy would cause Firefox (or any other app configured to use it) to use "remotehost.com" as a jumping off point into the internet, so it can connect to other local network devices on its end just the same.