Password sniffers....

[godaigo]

OK, first of all this isn't a question regarding where to find them, or what they are, but rather the correct
approach to take when writing one. The way I've been thinking about it, to write a sniffer, are you simply trying
to capture everything typed in, which would be simple enough, or does one need to write a specific algorithm that
would allow for some sort of logical sorting. (i.e. to decide what was a password, and what wasn't) Alternatively
shouldn't it be possible to key the program to the actual login process? And for my final question of the minute
does anyone have an opinion on whether or not it's better to have the results transfered over the internet, say under
the guise of a routine connection, or should the information be stored in a hiddent directory on the compromised machine?
Anyway thanks for any opinions or help with the subject! Cheers, and Guinness to all!

[godaigo]

I almost forgot, any opinions on whether it would be best to implement the storage in a class of it's own, or
would simply writing a function to dump the information to a preset place be best. The only concern that I can
see with the latter is the possibility of memory problems, buffer overruns, etc. Of course that would depend
on exactly how you implemented it. Cheers...

[Metgod]

Personally, I did C and Assembler, not C++. In fact I hated C++. Regardless,
hidden directories aren't really hidden in one essence: you just aren't looking at it.
A simple 'ls -a' reveals all. EOF.
Hell, if your admin does a ...
alias ls 'ls -alF' in your profile then even if you type 'ls' it will show as if you typed
'ls -alF'
However, depending upon your skill you may have to store it on the drive.
Depending upon the system setup, you may be able to set it up somewhere else.
There are so many factors it is unbelievable....


Erm..

A sniffer generally captures the headers of packets, for that is where the crucial
data is. Remember that. But to give you an example, try this:

From Linux:

tcpdump (I can't help you here cause I hate Linux)

From Solaris (a form of UNIX):

snoop

NOTE: You have to be root.
They are sniffers built into the OS. I'm sure F/O/NBSD and other UNIXes have sniffers
too but those are two of them. Take a look at the code and find out how they work.

I forget your questions (like I said, my memory is shot to hell), so ...
if you have any further questions, go ahead. :)

[CBK]

I would think there is a better way of doing this type of thing other than writing a program.  
A well written storage class  would only allow for a set amount of data before writing to disk.  Like a stack,  After the stack is at it's max amount of data, copy stack to disk, and restart with a new stack.  So you would need two classes: 1 like a buffer ( the stack) and 2 the class for the file you will write too.  That way you could have the file class check if the file is too big and start a new file.  I have had an X server error log get as big as 14GB!!!  It was  easy to find    I did a tail listing of that file and found the same error over and over again.  all i did was restart my Xserver. then deleted the file.
ok ok back to the task at hand...
1  Buffer class, used to set the amount of data to read into mem, set the file handle of the device you will be reading from, and some kind of member functions that write data to the buffer and send that data to file obj.
2  File class, used to preform error checking on the file to be made/appended to.  If you try and write to a dir that you don't have right to wirte in you may crash your progrie  u might want to have some kind of "This file is too big now lets make a new one" type of error checking also. One member function to append buffer data to current file. (.dumpfile01 or whatever makes you happy)  Also sence you are writing data to an obj (file class) when you close that obj that data will only be able to be read back using the same class (or a hex editor)

I'm shure theirs other things to worry about also.  And I don't see any way this type of program could be used without breaking any laws.  (other then deploying the program on your system and you were the only user of that system)  That is why I think there is a better way of  doing what you are trying to do. But it still would be fun to make.  Remember, KISS  Keep It Simple Stupid.  In everyday life and in software your write. The less amount  of moving parts the less chance for it to break (crash, bufferoverflows...)
Hope my ramblings have helped.

-CBK

[Metgod]

But why OOB ?
If this is UNIX (don't remember from topic), plain old C will suffice
for sockets.
Oh well, whatever you want..

[CBK]

Yes i too think c++ is a bit much for this type of program.  And programming network sockets is not that much more work ether.  I think c or pascal would work just fine if not better.  I just know more in c++ then i do in c.  I'm also thinking with Object Oriented  programming you could do some really cool STL's/storage classes for the buffer so it could handle the speed of the data input.  Mybe even have like 2 or 3 more containers to pharse that data to look for repeats and possable  passwords so a flag/marker can be written to the output files.. then we could reuse the c++ class to take over the world.
ok ok i'm going to bed now.
-CBK

[godaigo]

Hi guys, thanks for all the replies. I think one of my key conceptual problems is that this program is really
a keystroke logger rather than a password sniffer. I may not have been at my most sober when I posted
. Still the main reason that I approached it with C++ rather than C is just that I'm more familiar with it. I think
that some of the container classes implemented in the STL might work, but with a file sitting around on the hard
drive then it's liable to discovery. As far as why to write it, basically something to do, something to keep programming
since my job really doesn't involve computers on any level, other than that of a standard user. Point and click (bleh).
As for programming sockets I really don't know what's involved with that, any suggestions for reading material?
Again thanks for the reply's, it's nice to see the activity! P.S. I remember the excite boards as well, although I
almost never posted! Cheers....

[wilnix]

building your own password sniffer? Sounds like you have an abundance of time. I know how to write and compile "hello world" in C...

Maybe I'll learn that tomorrow...

Wilnix

[godaigo]

Well since I cut down on the beer (sob!) I figured I should try and do something interesting with my time. Programming came up, but actually I've mostly been playing with hardware lately. I've been debating on whether or not to put a serious cooling system in my computer, I don't really need one (at least not until I get the RAID up and running) but it sounds fun....

[wilnix]

Have fun  

Wilnix

[catfish]

i've actually, just for the hell of it, been trying to work out a circuit to do this, (because i have nothing better to do in electronics). it reads the keyboard input, and whenever the username shows up, it stores the next 24 charactors into a PROM chip, hopefully the password will be somewhere in the 24 chars. i bet it wouldn't be too hard to make a file that does the same. and that would take up MUCH less space than a key logger. anyways, bye. (but with a key logger, you can read people's email! yay!) *cough* *yawn* anyways, i'm going back to my cave, to sleep some more.

[wilnix]

Both of you have more time then I do.

Wilnix

[godaigo]

Actually about the time that I made that last post my time almost completely evaporated! I decided to finish a minor in Japanese studies and ended up having a pretty hefty 35 page research paper due for the summer. Shite there goes most of my programming time....(has a beer or three to compensate)  

[wilnix]

beer IS food.

Wilnix

[godaigo]

Especially Guinness! But on to something that lies within the topic of this folder!   Does anyone know of any texts, electronic or otherwise relating specifically to socket programming in Unix/Linux/*BSD; just an introductory type of thing. Of course this would be more as a preparatory thing until I get that paper done! All hail the Guinness!