From bsjohnso at midway.uchicago.edu Wed Nov 13 22:53:23 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:34 2006 Subject: [Cs22800] BSDsebek Update Message-ID: <3DD32C43.7040102@midway.uchicago.edu> Below is output in /var/log/messages for BSDsebek. As you can see, it clearly indicates that the hacker (myself) typed: kldunload module which is in fact what I did to unload BSDsebek. I am unsure of how to get the tty_id so currently I just use TEST1234. sshd was running as 130 and I was root (uid 0) in the terminal where I was capturing keystrokes. So it looks like everything is working pretty well. Also, I can write to and read from /dev/sebek so tomorrow I will combine the logging with sending the data to the driver rather than printing out as a kernel message. If I have additional time, I will work on gettting the log reader to work. Then I would simply have to get the sniffing / parsing to work, which actually isn't a huge deal because if it seems hard to port right now, a quick fix would be to have a linux machine on the net and to run sebeksniff on there. I sitll have to add the adorebsd rootkit-like features to it but that's just code cutting and pasting. Finally, I will have to setup a configuration / installation system and then we can test it! If all goes well, that will all be done by next monday, and if not then probably just a few days later than that. Let me know if you guys have any questions, suggestions, etc. BTW, in a previous message I stated that I always got incorrect return values...that was partially true as I did not get what the user was got, but I guess I got what a system call should return in the kernel. I figured out part of the proc structure that had the return value (ie the # of bytes read) that I was looking for. Its amazing how after I sat down for a while reading all the header files from /usr/include/sys, stuff made much more sense. See ya, Ben -------------------------------------------------------------------------------------- Nov 13 20:42:48 bsd /kernel: |BEGIN1|->1037241768:130:0:sshd:7:TEST1234:c:2:k Nov 13 20:42:48 bsd /kernel: |BEGIN1|->1037241768:130:0:sshd:7:TEST1234:c:2:l Nov 13 20:42:48 bsd /kernel: |BEGIN1|->1037241768:130:0:sshd:7:TEST1234:c:2:d Nov 13 20:42:49 bsd /kernel: |BEGIN1|->1037241769:130:0:sshd:7:TEST1234:c:2:u Nov 13 20:42:49 bsd /kernel: |BEGIN1|->1037241769:130:0:sshd:7:TEST1234:c:2:n Nov 13 20:42:49 bsd /kernel: |BEGIN1|->1037241769:130:0:sshd:7:TEST1234:c:2:l Nov 13 20:42:49 bsd /kernel: |BEGIN1|->1037241769:130:0:sshd:7:TEST1234:c:2:o Nov 13 20:42:49 bsd /kernel: |BEGIN1|->1037241769:130:0:sshd:7:TEST1234:c:2:a Nov 13 20:42:49 bsd /kernel: |BEGIN1|->1037241769:130:0:sshd:7:TEST1234:c:2:d Nov 13 20:42:49 bsd /kernel: |BEGIN1|->1037241769:130:0:sshd:7:TEST1234:c:2: Nov 13 20:42:50 bsd /kernel: |BEGIN1|->1037241770:130:0:sshd:7:TEST1234:c:2:m Nov 13 20:42:50 bsd /kernel: |BEGIN1|->1037241770:130:0:sshd:7:TEST1234:c:2:o Nov 13 20:42:50 bsd /kernel: |BEGIN1|->1037241770:130:0:sshd:7:TEST1234:c:2:d Nov 13 20:42:50 bsd /kernel: |BEGIN1|->1037241770:130:0:sshd:7:TEST1234:c:2:u Nov 13 20:42:50 bsd /kernel: |BEGIN1|->1037241770:130:0:sshd:7:TEST1234:c:2:l Nov 13 20:42:50 bsd /kernel: |BEGIN1|->1037241770:130:0:sshd:7:TEST1234:c:2:e Nov 13 20:42:50 bsd /kernel: |BEGIN|->1037241770:130:0:sshd:7:TEST1234:b:3: -------------------------------------------------------------------------------------------------------- -- Benjamin Johnson "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." -- Albert Einstein From odonnell at cs.uchicago.edu Fri Nov 15 14:34:23 2002 From: odonnell at cs.uchicago.edu (Mike O'Donnell) Date: Thu May 18 12:41:34 2006 Subject: [Cs22800] Salon article on AbiWord Message-ID: <20021115203428.BF4A48080A1@surya.cs.uchicago.edu> http://www.salon.com/tech/col/leon/2002/11/15/abiword/index.html From odonnell at cs.uchicago.edu Fri Nov 15 14:44:58 2002 From: odonnell at cs.uchicago.edu (Mike O'Donnell) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] Please post work details, schedule Message-ID: <20021115204503.30BFD8080A1@surya.cs.uchicago.edu> I'd like to see some real presentation of work on the Web pages before the meeting on Monday 18 November. I like Ben's presentation, and particularly the "development diary." But there are no entries since 2 November. The list of milestones is also very important. Does the expected release of version 0.1 on 18 November mean that you've beat the milestone of "Working copy ... for FreeBSD 4.62/4.7 by December 2002," or does version 0.1 lack something for that purpose? Get the diary up to date, clarify the progress toward goals, and mention somewhere when you intend to take credit, and this will be a nice informative presentation. For the rest of you, I can't find anything beyond the original statement of general goals. It's past time to refine those into another layer of detail, with at least 3 interesting milestones to pass in the near future. The plan and milestones can be revised, but without any provisional specifics its very hard to gauge progress and the consequences of various decisions. And, for everybody, I'd like a clear written indication of when you intend to take credit. That can also be revised if necessary, but I need to know the best estimate. Ben could collect that information and put it into the main table on the front page. Mike O'D. From odonnell at cs.uchicago.edu Fri Nov 15 14:49:02 2002 From: odonnell at cs.uchicago.edu (Mike O'Donnell) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] Meeting activities Message-ID: <20021115204907.549698080A1@surya.cs.uchicago.edu> I'd like to see the meetings get a bit more productive. Please identify at least one and preferably two or three presentations for each week. Demos are good, even if the stuff you demo is crappy. Code reviews are good. The idea is to present what you're doing, as a mechanism for organizing your own thinking about it, to share the experience around so we all learn from all of the projects, and to get extra eyeballs and help in working out issues. I think we are a couple of weeks late in getting serious about this, so please choose some definite topics for Monday the 18th. Just presenting bugs and showing the structure of the code is cool. As soon as we looked at the Enlightenment prototype code last week, we chased down one little bug, and generated some thinking about good structure for one aspect of the code. I think we can do a lot more of that. Mike O'D. From bsjohnso at midway.uchicago.edu Fri Nov 15 16:28:05 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] Please post work details, schedule References: <20021115204503.30BFD8080A1@surya.cs.uchicago.edu> Message-ID: <3DD574F5.6010403@midway.uchicago.edu> Mike O'Donnell wrote: >I'd like to see some real presentation of work on the Web pages before >the meeting on Monday 18 November. I like Ben's presentation, and >particularly the "development diary." But there are no entries since 2 >November. The list of milestones is also very important. Does the >expected release of version 0.1 on 18 November mean that you've beat >the milestone of "Working copy ... for FreeBSD 4.62/4.7 by December >2002," or does version 0.1 lack something for that purpose? Get the >diary up to date, clarify the progress toward goals, and mention >somewhere when you intend to take credit, and this will be a nice >informative presentation. > > I was planning on updating this stuff tonight or tomorrow night. I've recently done some good things that I have not documented yet, so I'll put info on those up on the site. I also plan on writing up a summary of the whole process. > > >And, for everybody, I'd like a clear written indication of when you >intend to take credit. That can also be revised if necessary, but I >need to know the best estimate. Ben could collect that information and >put it into the main table on the front page. > > > I can formalize this part more on my site. Also, any of you can send me stuff whenever and I'll get it up on the site as quick as possible. See ya, Ben -- Benjamin Johnson "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." -- Albert Einstein From bsjohnso at midway.uchicago.edu Fri Nov 15 17:54:36 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] Sebek: Problem + spurring online discussion Message-ID: <3DD5893C.60804@midway.uchicago.edu> Ok, I think we should have more discussion online of any problems, solutions, etc... I have to store captured SSH traffic in a buffer so that when a helper application opens and then periodically reads from the device driver, it gets part of the array (whatever it requests). So far, I have it work like char sebek_buf[500000] (used 500000 because sebek did). The problem is that if I have captured a lot of traffic before it has been read, I am not sure what to do with it. Sebek does some sort of circular method yet its real messy, the variables aren't labeled very well and I'm not sure if its the best way. It has int d_start and int d_end that point to the starting and ending points, and the starting point can be larger than the ending point, thus signifying to wrap around. So far mine has been simplified to not try the wrap around. If that's confusing, let me know. Basically I was wondering if any of you have ideas on how I should approach the data storage, and if I should do something circular how should I do it (or if you have any ideas for topics to google for, that would be great). On a secondary note, if anyone has experience with semaphores or basically locking down something in the kernel (while the array is being manipulated by /dev/sebek), that would be really helpful. I just ordered Richard Stevens' book on IPC but that won't get here for at least a couple of days. Thanks, Ben -- Benjamin Johnson "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." -- Albert Einstein From zrscott at uchicago.edu Sat Nov 16 07:42:29 2002 From: zrscott at uchicago.edu (Ziba Scott) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] enlightenment style question Message-ID: <3DD64B45.8040600@uchicago.edu> Here's a question Stephen and I have been working on: What format should we present taskbar information to the client programmer in? (this is in C) The bulk of the information we are passing from our functions to the hypothetical taskbar writer consists of a list of names, each with a number and a pointer. So, should we give the user: a struct with several arrays/lists, a struct list, an array of structs, or something else? Which would be easiest to work with? Which would be most efficient? (we are dealing with relativly small lists) -Ziba From trow at ximian.com Sat Nov 16 18:31:39 2002 From: trow at ximian.com (Jon Trowbridge) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] enlightenment style question In-Reply-To: <3DD64B45.8040600@uchicago.edu> References: <3DD64B45.8040600@uchicago.edu> Message-ID: <1037493099.2025.1.camel@unagi.ximian.com> Here are my 2 cents, along with some random observations about C API aesthetics. First and most important: if there is a convention used by the rest of the Enlightenment APIs, follow it. Sometimes being consistent is a greater virtue than being perfectly engineered. OK, now that I've gotten that disclaimer out of the way, here are a few thoughts on how to be perfectly engineered. In my experience, the first thing to think about when returning complex data objects[1] are life-cycle issues. Since C is one step above flint knives and bearskins, the poor user has to correctly manage any chunks of memory that you hand back to him. You want to make this task as easy as possible for the user --- hence the benefit of consistency. > hypothetical taskbar writer consists of a list of names, each with a > number and a pointer. You almost certainly want to assemble some kind of struct that contains the window information, and then hand the user a sequence of them. Don't hand back N lists (a name list, a number list, a pointer list, etc.), since that is a giant pain in the ass to iterate over. So you'd have something like: /* Typing 'struct' all of the time is very passe./ typedef struct _TaskbarInfo { char *name; int *a_number; void *a_pointer; /* or whatever... */ } TaskbarInfo; Hmm... but there is a string inside of the struct -- so whoever frees the structure has to make sure to also free the name. Please don't expect the user to do something like free (my_taskbar_info->name) free (my_taskbar); because that would lead to pain and memory leaks when someone adds another allocated field to the struct six months from now. So be polite and provide some sort of explicit destructor. IMO a destructor should always be provided in this kind of situation, even if it just ends up being a wrapper around a call to free: it is best to be defensive. This makes things pretty simple for the user; they just have to remember to call taskbar_info_free on any TaskbarInfo items they need to dispose of. Of course, there is another layer to the problem that I've ignored so far: you aren't returning just one of these guys, but you have a bunch of structs to deal with. I'd be surprised if E didn't have some library full of typical data structures like lists and hashes already coded up in C. I'd advise you not to use them, except maybe if: * They are smart and let you attach destructors for the data objects, so that freeing the list doesn't leak all of the objects in the list. * The Enlightenment convention is to return these kinds of objects. * There is absolutely no other way to do what you want to do in a clean way. In the GNOME, there is a library full of data structures called glib, but some people[2] considered it bad form to return them from any user-visible API --- the argument generally boil down to life-cycle questions or the lack of type safety, but in the end it is primarily a aesthetic/religious question[3]. A simple alternative is to return a NULL-pointer-terminated array of pointers. These are easy to iterate over, though it is still good manners to provide a whole-array destructor. Though it is probably beyond the scope of what you'd want to do here, sometimes it is nice to abstract away all of the memory management issues, particularly if the semantics are complicated[4] or you think they may change. I really like using a functional programming-type idiom --- which works just fine in C. Your API would look something like this: typedef void (*TaskbarInfoFn) (const char *name, int a_number, void *a_pointer, void *closure); void get_taskbar_info (TaskbarInfoFn fn, void *closure); All memory-management questions are now gone: the get_taskbar_info function can manage all of the memory and clean up after itself as necessary. In case you are confused, here is an example of using this kind of API to write the window info to a file: static void write_info_callback (const char *name, int a_number, void *a_pointer, void *closure) { FILE *out = closure; fprintf (out, "%s (id=%d)\n", name, a_number); } void write_taskbar_info_to_stream (FILE *out) { get_taskbar_info (write_info_callback, out); } Warning: C programmers tend to freak out when you do this sort of thing. They are usually the same misguided people who don't like Lisp. But if you are stuck working in C, this idiom can be a life-saver. -JT [1] i.e., something other than an int, double, etc. [2] Here when I say "some people", I really mean "I", but I'm not the only person who feels this way. Honest. [3] However, that doesn't mean it isn't important. If your code is aesthetically pleasing, it is more likely to be well-thought-out and correct. And it will also be more readable, which vastly simplifies future maintenance. [4] Classic example: when you are caching data and you don't want to let the user decide when to free it. And you also don't feel like adding full-blown reference counting to your objects, which would be overkill in many cases. From bsjohnso at midway.uchicago.edu Sat Nov 16 19:06:22 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] enlightenment style question References: <3DD64B45.8040600@uchicago.edu> <1037493099.2025.1.camel@unagi.ximian.com> Message-ID: <3DD6EB8E.2080908@midway.uchicago.edu> I would agree with what Jon says. I think he's got some good stuff in his message. As I stated in my message last night, I myself have to come up with some solutions with various audiences in mind, so I guess we're in similar boats. See ya, Ben Jon Trowbridge wrote: >Here are my 2 cents, along with some random observations about C API >aesthetics. > >First and most important: if there is a convention used by the rest of >the Enlightenment APIs, follow it. Sometimes being consistent is a >greater virtue than being perfectly engineered. > >OK, now that I've gotten that disclaimer out of the way, here are a >few thoughts on how to be perfectly engineered. > >In my experience, the first thing to think about when returning >complex data objects[1] are life-cycle issues. Since C is one step >above flint knives and bearskins, the poor user has to correctly >manage any chunks of memory that you hand back to him. You want to >make this task as easy as possible for the user --- hence the benefit >of consistency. > > > >>hypothetical taskbar writer consists of a list of names, each with a >>number and a pointer. >> >> > >You almost certainly want to assemble some kind of struct that >contains the window information, and then hand the user a sequence of >them. Don't hand back N lists (a name list, a number list, a pointer >list, etc.), since that is a giant pain in the ass to iterate over. > >So you'd have something like: > >/* Typing 'struct' all of the time is very passe./ >typedef struct _TaskbarInfo { > char *name; > int *a_number; > void *a_pointer; /* or whatever... */ >} TaskbarInfo; > >Hmm... but there is a string inside of the struct -- so whoever frees >the structure has to make sure to also free the name. Please don't >expect the user to do something like > > free (my_taskbar_info->name) > free (my_taskbar); > >because that would lead to pain and memory leaks when someone adds >another allocated field to the struct six months from now. So be >polite and provide some sort of explicit destructor. IMO a destructor >should always be provided in this kind of situation, even if it just >ends up being a wrapper around a call to free: it is best to be >defensive. This makes things pretty simple for the user; they just >have to remember to call taskbar_info_free on any TaskbarInfo items >they need to dispose of. > >Of course, there is another layer to the problem that I've ignored so >far: you aren't returning just one of these guys, but you have a bunch >of structs to deal with. > >I'd be surprised if E didn't have some library full of typical data >structures like lists and hashes already coded up in C. I'd advise >you not to use them, except maybe if: > * They are smart and let you attach destructors for the data > objects, so that freeing the list doesn't leak all of the objects > in the list. > * The Enlightenment convention is to return these kinds of objects. > * There is absolutely no other way to do what you want to do in a > clean way. > >In the GNOME, there is a library full of data structures called glib, >but some people[2] considered it bad form to return them from any >user-visible API --- the argument generally boil down to life-cycle >questions or the lack of type safety, but in the end it is primarily a >aesthetic/religious question[3]. > >A simple alternative is to return a NULL-pointer-terminated array of >pointers. These are easy to iterate over, though it is still good >manners to provide a whole-array destructor. > >Though it is probably beyond the scope of what you'd want to do here, >sometimes it is nice to abstract away all of the memory management >issues, particularly if the semantics are complicated[4] or you think >they may change. I really like using a functional programming-type >idiom --- which works just fine in C. Your API would look something >like this: > >typedef void (*TaskbarInfoFn) (const char *name, > int a_number, > void *a_pointer, > void *closure); > >void get_taskbar_info (TaskbarInfoFn fn, void *closure); > >All memory-management questions are now gone: the get_taskbar_info >function can manage all of the memory and clean up after itself as >necessary. > >In case you are confused, here is an example of using this kind of >API to write the window info to a file: > >static void >write_info_callback (const char *name, > int a_number, > void *a_pointer, > void *closure) >{ > FILE *out = closure; > fprintf (out, "%s (id=%d)\n", name, a_number); >} > >void >write_taskbar_info_to_stream (FILE *out) >{ > get_taskbar_info (write_info_callback, out); >} > >Warning: C programmers tend to freak out when you do this sort of >thing. They are usually the same misguided people who don't like >Lisp. But if you are stuck working in C, this idiom can be a >life-saver. > >-JT > > >[1] i.e., something other than an int, double, etc. > >[2] Here when I say "some people", I really mean "I", but I'm not > the only person who feels this way. Honest. > >[3] However, that doesn't mean it isn't important. If your code is > aesthetically pleasing, it is more likely to be well-thought-out > and correct. And it will also be more readable, which vastly > simplifies future maintenance. > >[4] Classic example: when you are caching data and you don't want to > let the user decide when to free it. And you also don't feel like > adding full-blown reference counting to your objects, which would > be overkill in many cases. > > > >_______________________________________________ >CS22800 mailing list >CS22800@cs.uchicago.edu >http://mailman.cs.uchicago.edu/mailman/listinfo/cs22800 > > > > -- Benjamin Johnson "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." -- Albert Einstein From bsjohnso at midway.uchicago.edu Sun Nov 17 00:40:18 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] BSDsebek update Message-ID: <3DD739D2.6090701@midway.uchicago.edu> Well, I have run into a few bugs but i'm going to simplify my code more tomorrow to try to single them out. Its just frustrating when I have to wait for a machine to reboot everytime... I updated some stuff on my site: http://people.cs.uchicago.edu/~bsjohnso/cs228/ Also, I plan on putting up administrative details tomorrow. See ya, Ben -- Benjamin Johnson "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." -- Albert Einstein From bsjohnso at midway.uchicago.edu Sun Nov 17 19:21:29 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] Update Message-ID: <3DD84099.4030709@midway.uchicago.edu> I should be able to update you all more tomorrow, but for now I am writing to tell Professor O'Donnell that on my site ( http://people.cs.uchicago.edu/~bsjohnso/cs228/ ) I have put up some administrative details (such as getting credit this quarter). See ya, Ben -- Benjamin Johnson "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." -- Albert Einstein From bsjohnso at midway.uchicago.edu Sun Nov 17 23:28:28 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] Robustness of BSD Sebek port, methods for covert transmission References: <20021020192607.8B4BD8080A1@surya.cs.uchicago.edu> Message-ID: <3DD87A7C.8060607@midway.uchicago.edu> Hey, Mike O'Donnell wrote: >Regarding the port, I hope we can get into one more layer of detail >soon. In particular, I wonder how robust the port can be >w.r.t. further changes to Sebek. Will Ben, or his successor, need to >do additional configuration work for each such change? Or, can we >provide patches to the core Sebek group so that they can produce a >distribution that compiles automatically to BSD as well as Linux. > > So far, it looks like we might need a maintainer for the BSD version. I want to stay with the honeynet group for a while so I figure I'll be able to. I plan on trying to port this to the other BSD's as well as maybe OS X and Solaris, so BSDsebek will give me a good start. The helper applications should be "compilable" in both linux and bsd, as Ed already began doing that earlier and i will finish it / touch it up. The real problem is with the kernel modules. I suppose you could do a lot of #IFDEF FBSD { } and stuff in the module.c, but that seems a little too ugly for the whole kernel module to be like that. >The answer depends to some degree on how the core Sebek project is >organized. Have they used the autoconf/automake/libtool types of >tools, and if so, how well? I've done a bit of this, and it seems like >a horrible black art. The individual pieces of documentation for make, >autoconf, automake, libtool are hard to integrate into an >understanding of the whole task. Somewhere in the Gnome project's Web >space I found a pretty good how-to for the whole thing, at least in >one reasonably workable style. > > We use makefiles for the helper applications and for the kernel modules, although kernel modules (especially the BSD ones) seem to have a slightly different style. Since the configuration also involves deciding where to have the driver, what to call everything, what you want the deceitful packets to look like, etc, I believe we will end up writing a bash or csh script to prompt the user for answers to all these questions. I actually wrote some scripts this summer that did this, but they now have to be redone to accompany newer features and changes that have been made in sebek since. Also I am hoping that if sebek becomes useful that we can code up a gui installer, or at least a "gui-text type of installer (i guess maybe using ncurses? I'm not a gui person at all). >Covert transmission >------------------- > >This isn't Ben's chosen topic, but we might as well think about the >whole Sebek project a bit. In the note from Ed that Ben posted on 28 >September, there's a lot of influence on the problem of dumping >Sebek's data to another host across a LAN without arousing the >intruder's suspicions. That sounds inherently difficult to me. Is it >feasible, instead, to use a separate network connection for dumping >Sebek data? > Yes, feasable. Ed told me that some of the people who setup honeynets want the traffic dumped onto the wire. On a side note, and this isn't public knowledge (so please keep it to our class although I don't think the feds will come banging down any doors), Ed has written some code that will cause packet sniffers to not capture the traffic we dump onto the wire. I haven't had time to see this yet but Ed is a good coder so I assume it works pretty well. Therefore, unless the hacker gets into other systems on the network (which usually the way a honeynet is setup he won't), they will not see any unusual traffic. >This could be a separate ethernet, or just a parallel port >or a serial port, or maybe a USB. It looks to me like the big question >is how well can you hide such a port and its activity from the >intruder. In principle, it sounds very feasible. Take the device >driver code, and hide it in a file somewhere, and invoke it directly >instead of using the usual /dev interface. If this works, in principle >you might even write to a covert disk, or better a write-once >device. But there might be snags in the details. And the attempt to >have a covert peripheral device might run afoul of attempts to make >device detection and configuration automatic---maybe a modern BIOS >will even interfere. > > Yah, these are all good ideas. I'm hoping to explore some of them possibly over winter break and into winter quarter. Unfortunately, I believe that the porting along with testing and documentation, might end up taking the rest of the quarter. I keep running into bugs...it works pretty well right now, but everytime it crashes I have to try to decipher some crazy kernel panic message. I recompiled my kernel so that it has all the debugging possible, but even when I get an error I can somewhat understand, there is hardly anything out there in mailing lists that is relevant to my needs. I made some good progress this weekend but in trying to make nicer and more efficient code, somehow I managed to cause a lot more kernel crashes...so I ended up going back to what I had a couple days ago (I still made a few modifications tonight). What I have left to do: -fix really baffling bug (will describe in class) -get reading from the device (/dev/sebek) to work flawlessly -be able to determine the tty id of the process that is calling the read that BSDsebek hijacks -add in some error checking -combine with adorebsd for file/process/module hiding (should be basically cut & paste) -port helper application (already started by Ed and since its user-space, should be real quick) -TEST / DOCUMENT (yay and oh no!) On a side note concerning the covert stuff, I know in linux that inode 0 is reserved for bad blocks, so data can be "hidden" there. Perhaps FreeBSD has something similar. Also, I have used programs that hide data in the slack space of file blocks and then later extract it. This is all feasable. Unfortunately, in order to perform quality logging, not only does all the ssh traffic have to be captured, it also has to be timestamped and contain the user id, process name, pid, etc. Anyways, I guess that's about it for tonight. See you guys in class. Ben -- Benjamin Johnson "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." -- Albert Einstein