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!
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...
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. :)
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
But why OOB ?
If this is UNIX (don't remember from topic), plain old C will suffice
for sockets.
Oh well, whatever you want..
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
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....
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...
8) Wilnix
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....
Have fun ;D
Wilnix
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.
Both of you have more time then I do.
>:( Wilnix
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) 8)
beer IS food.
Wilnix
Especially Guinness! But on to something that lies within the topic of this folder! ;D 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!
http://www.ibrado.com/sock-faq/
Try google for some more...
Wilnix
http://www.ecst.csuchico.edu/~beej/guide/net/
Also, there are books on socket programming...
Uh.. can't think of the name off hand but.. UNIX Network Programming
might be the name.. look it up on Amazon and like Will said, a search engine...
Metty probably knows better then I do, and it seems there is a lot online if you search.
Wilnix
Thanks alot! It seems like this is something of a required subject if I'm gonna be doing anything in Unix. Of course my college classes really didn't address anything outside of "this is a program, here's how it's written" of course they don't tell you how it apply's to anything, or how to connect it to anything outside of your own projects structure! Thank god(or whatever ;)) that I like to work out stuff on my own! Thanks again these two sites look like they'll get me started. Once the ball starts rolling....
no problem..
next. ;)
Wilnix
http://www.manualy.sk/sock-faq/unix-socket-faq.html
http://www.scit.wlv.ac.uk/~jphb/comms/sockets.html
http://pont.net/socket/
http://www.cs.rpi.edu/courses/sysprog/sockets/sock.html
http://www.uwo.ca/its/doc/courses/notes/socket/
http://www.cs.cf.ac.uk/Dave/C/CE.html
i am trying to do the same thing. well here are some of my bookmarks. keep me posted okie ;)
I've seen some of these, and they do have some good stuff. will probably check the others out as it's always neat to have more stuff to refer to. So thanks.
As an aside, and some caution....
(and MS is probably the biggest cuplrit here since they love breaking standards ... and I"m probably stating the well known but ah well ...)
main() must be int in the ANSI C standard (and I see in one of those links they don't specify at all and rely on compilers -- which is a bad bad practice). It's true that most compilers default it to int (especially K&R compilers), but... it's best to specify int (and not void or anything else). And prototypes are your friend indeed! But MS's C code is inherently broken (since they specify void) and won't work everywhere.
One thing I'd recommend is usually specifying -Wall in gcc.
Oh, and valgrind and dmalloc are quite useful. Never tried electric fence or the others, but valgrind is my favourite (saved me on several occasions I might add), plus doesn't really i nvolve modification of code -- just specifying debug symbols to be inserted into the executable.
Hope I didn't horribly bore you all, haha
Also check this thread...
http://forum.hfactorx.org/index.php?board=34;action=display;threadid=1598
And a favourite of mine ....
http://www.gnu.org/prep/standards/standards.html
and can't forget the C FAQ!
http://c-faq.com/
Also check
http://cslibrary.stanford.edu (although I don't like some of this one's style and probably other things, but probably useful anyway).