goldfish

Actually it's occurred to me you don't need to even do that. You can simply tell your compiler not to compile in the open new window directive - in Dev-C++ you can uncheck a box for MingW.

Now that is the challenge which we havn't got to just yet ;) But I'm working on it.

That's what I was trying to avoid :) I wanted to keep it as bloat free as possible. Also, you can hide the console window from the way it's spawned - for example the auto run VBS file. Removes the need for any windows api at all. I'm sorry, I just hate windows api :p EDIT: Having said that there is quite a minimal ammount of bloat just for hiding the window. That works for me! :) Now... about this API for the locking...

Sounds like you need to calibrate your parabolic dish a bit better, For a start you should have a directional feed which goes directly towards the center of the dish - a cantenna would do this perfectly. The distance between the dish and the feeder is very important and to get optimal performance you need to do some equations to get the distance just right. You'll also need to do some equations on the feeder too so that signals from the entire dish are being recieved optimally. An omnidirectional (such as the ones built into USB cards) are not really suitable for use with a parabolic dish due to their omnidirectional nature. Most of the signal reception will not be from the dish at all, rather from areas in front of the dish and to the sides of it. Check out this link: http://www.qsl.net/ki7cx/wgfeed.htm

USB AUTO LOCKER Something which I put together out of my own interest. When I walk away from a machine - I'll lock the machine and take my USB drive with me. This simply streamlines the process and locks the workstation when I remove the drive. For some nice, nice reason, the forums won't let me post the code here. So for your reference, it's here: http://pastebin.ca/275123 Pretty simplistic. A couple of notes on it. 1) Program still runs after you remove the device This is why this works. If your program is loaded into memory it will stay there until it's finished, even if the drive it's "working" from doesn't exist any more. The only difference is you cannot read from or write to the device any more - this is how we detect it has been removed. 2) The System Call Hmph. I'm not happy with this. The easiest and cleanest way that I could see to lock the workstation is by calling rundll32 and invoking the LockWorkStation function in user32.dll. This is far from perfect - Ideally you would use runtime library loading to load user32 and use it's functions directly - but this adds a lot of extra crap that I didn't want to deal with. Also, you'll notice the start command. If you try to invoke an executable from a "working directory" which doesn't exist, you'll get an error ("The Current Directory is Invalid") ... EVEN if you specify the full path. START is a part of the system libraries, and as such doesn't require file access so the CWD isn't checked. Boom, it works. INSTALLATION Easiest method: Compile, copy to your USB device. When you insert the device, run this program. As soon as you remove the device your workstation will be locked. To make things a bit quicker, you could set your drive up to launch this on Autorun. This works with the ever popular U3 autorun hack - in fact I developed this using that as a testbed. TODO As much as I hate Windows API, it would probably be better to use it for this task. But since it's such a simple task what's the point in worrying about it? It probably needs a method of exiting the program BEFORE you remove the drive. As it stands if you're going to log out, you need to pull the drive, screen locks, you log back in again then log out. Not ideal. I'm thinking a simple keyboard hook that listens for a specific key combo, when it will exit. Since this will require WinAPI I might as well do the locking with WinAPI too.

Irssi baby! The client of the future! :D I run it in screen sessions on my boxes so I never have to ever leave channels ... ever :D And I can ssh into it from my phone if I need to.

Now THAT needs to be done :D How the hell would you mount it, though? You'd need a pretty large amplifier to drive it too....

A route which might be interesting to take is injecting code into winlogon. Winlogon runs as SYSTEM, so you could use it to spawn a new process to do some dirty work for you. You would need to find a way to write to the memory which winlogon resides to (tricky...) and alter the instructions to jmp to a place in memory you have loaded in code, and then jmp back to the end of winlogon, after you have replaced the original instructions. And once you have done this - as far as winlogon is concerned - everything is fine. The beauty of this approach is that winlogon will be running all the time, no matter what the privs of the account you are using. And even if there is NOBODY logged on. . Equally, if someone has locked the machine, injecting code into winlogon to switch you back to one of the unlocked Desktops would defeat the password protection. For more permenant access you could make a screensave which does this when a certain key combo is pressed (before the system kills it to wake up the system). Unfortunately I believe that autorun does not work without a non-system user logged in - but if it did...

In this particular scenario it might help to understand what Cain is actually doing. To be honest you don't need to use ARP poisoning to read unencrypted traffic. Really, it's just a matter of firing up Ethereal and having a look at what you get. If you're not associated with the network then you can pop the card into passive mode (easier in Linux than Windows, but it's possible), if you are associated then you're good to go. All Cain really does is log packets recieved on the interface and look through them for passwords. If you look at Ethereal and log into an unencrypted HTTP Authenticated page you can quite easily spot the packets which contain the password. Cain just makes this easier by putting it into a nice Windows API listbox for you. In a wired-switched environment, you would need ARP poisoning to make each host send their packets to you before the send them to the gateway. Otherwise the switched network would not forward any packets which are not destined for your host, and you would only see the traffic between you and the gateway. This is the primary use for ARP poisoning.

But is it a backup with the same vunerability in it that previously caused the "outage"? Let's hope not...

I'm sorry but this is just ridiculous. Hoo freaking ray you can ARP poison a network. Wow look at all these SMB packets. Wow you can read an admins password over their shoulder. Hey, you can open a text file with a bunch of passwords in it. It's not worth discussing at all! It's the hacker equivilant to saying "Hey, you know, if you go to the post office and put a letter in the box it gets taken away to the place you wrote on the envelope! Isn't that amazing!?" What might be worth discussing is if you found a vunerability in a piece of software or practice. Or there is a hole in some security measure. Hell, even just saying that people save passwords in plaintext might be worth some discussion. If you don't understand why the hole exists then you've completely missed the point. It's not about breaking into things. That isn't what hacking is about! It's about understanding the technology you're using and making it work the way YOU want it to - rather than the way it was designed to. But the most ridulous part of this topic is how people are boasting on a public forum about doing stuff to their school networks - which I might add are mostly owned in some part by the GOVERNMENT. Think about that for a minute .... With people using the term hacking like this I'm not surprised we've got such a bad image. Not aimed at anyone in particular, but at this topic generally.

You could a) anonymously tell an admin or b) fix it yourself or c) wait till someone else does something stupid with it. It sounds from here like you just shoulder surfed the password. That's not really hacking - that's just lame. It might be a means but it's not really an end. If you don't have a really good reason to have that access then what the hell are you doing?? In this case informing admins would be a dumb idea - all it does is proves that you were trying to access their password. If it was using a vunerability that you found - then that might possibly be interesting. In which case you might be more inclined to noitfy them about it - without giving away your identity of course!