Satori Rewrite?

Ok, it has been 3 years since the last time I posted on rewriting Satori.....

I sat down Friday after work with pypacker.  I put an hour or two into getting it to read packets with some example code and parse through tcp packets to at least get my TCP fingerprinting under way.  I bounced a question off of the developer (one earlier in the week when I was hoping to start and then again once I finally did).  He was helpful in both cases and by the end of Saturday I had code in place that properly dissects TCP packets.  I have 2 pieces to fix, one which has always been my nemesis, bit shifting, never really got it in my head how that works 15 years ago when I wrote Satori in Delphi and now that I rarely program this type of stuff anymore, no better off with python.   The difference in 2018 though is I'm not writing the protocol dissectors anymore!

Pypacker isn't really decided per se for what I'm using it for, it is really more for making your own packets, but it has the ability to decode them as well!  He already has the protocol stack built out for almost everything I need, just missing SMB.  Once I get through TCP, DHCP and a few others I'll start looking at that one, but it will be a bit down the road.

The one difference with this rewrite vs the one I claimed in 2015, 2014, 2013.....  I'm actually really interested it doing this this time.  Code will also all be open sourced this time around and project will be hosted out on something like github.

Time permitting today, I should have TCP, p0f v2 style and ettercap done.   I hope to have something in place as well to actually parse through the fingerprint files and spit out a guess at the OS.  While I'd prefer to do DHCP as my first one, as that was where I really enjoyed this the most, TCP seems like the most useful.  Once I get this done I'll look at p0fv3 that came out in the 2014 time frame as I was really winding down my work in this field.

Anyway, if you are doing any type of python and network type stuff, I highly recommend you check out pypacker.   I had tried doing this before with scapy, dpkt and a few others, but they were all a bit slow on convoluted for me and didn't have enough of the protocols already built out.  Or maybe they really did and I just wasn't motivated enough, can't really say. 

Its fun to be working on this project again after this long break.  Once I get it moving along, fingerprint files will be updated again as well.

Initial output:
192.168.25.128:36526 -> 216.58.217.34:443
 Flags: S ,Fingerprint: 29200:64:4096:60:M1460,S,T,N,W7:.
216.58.217.34:443 -> 192.168.25.128:36526
 Flags: SA ,Fingerprint: 64240:128:0:44:M1460:A

The 4096 part is due to bad bit shifting on my part to read the don't fragment bit (reading 1 bit out of 16 is so much fun).  I did a kludge elsewhere in the code, but now that i remember about bitshifting, may have to go back and rewrite that.  But 95% of the way there on TCP at this point!

Satori - update 0.7.3 and most dll's recompiled

I'm busy taking the SANS 503 IDS course, one of the things we do in that course is look at BPF style filters. Low and behold, I use these in Satori to do some prefiltering of packets before Satori hashes through them. While I have complete confidence in my coding skills (brief pause as I control the hysterical laughing fit I've found myself in), it never hurts to preprocess the packets before I get them.

History on the filters, we'll look at the TCP fingerprinting one:
Original:
'tcp'

Noticed vlan tagged traffic wasn't being picked up so, up until yesterday:
'tcp or vlan'

Yesterday first change:
'tcp or (vlan and tcp)' - decent update, meant only vlan traffic that was also tcp got sent to me, but wait, we only want TCP traffic with options, so...

'tcp[12] > 50 or (vlan and tcp[12] > 50)'

So now, instead of having to process all tcp traffic with Satori, winpcap only sends this dll tcp traffic that has tcp options!

Other protocols still read the whole tcp packet, or the whole packet for that matter, but now tcp processing should be a little quicker as I don't have to dig through the packet to see if it is tcp with options, I let winpcap do it. I still check to see if there are options on it and don't assume all is good, but I limit the initial packets that I have to process!

Ok, other updates besides BPF stuff....

Satori 0.7.3 released. Wanted a new .zip file as the last one was 0.7.1 and that was from quite awhile ago. 0.7.2 .exe was released 1.5 years ago! One thing I recently noticed with the update of the oui.txt file is that Satori reads it, but doesn't pick up any new changes in it unless I recompile the .exe. No idea why, on my list to fix some day.

Also released the SIP dll and profile. I wrote these back in 2010 and evidently never released them to the public. Which reminds me, I should probably upload the .xml file that goes with that also which means updating the .zip file that will be missing it also. Oh well, 5 more mins of my life.

Enjoy the updates, let me know if I broke anything as I haven't had a ton of testing time with the new changes as I'm supposed to be studying for SANS 503 stuff right now!

Oh last note, figured out some interesting "glitches" with the vlan tag and BPF, will try to do a different post once I verify it all and get some feed back.

p0f v3

And I though MZ gave up on p0f after no updates to v2 in years. I guess I'm proven wrong....

== What's new ==

Version 3 is a complete rewrite, bringing you much improved SYN and SYN+ACK fingerprinting capabilities, auto-calibrated uptime measurements, completely redone databases and signatures, new API design, IPv6 support (who knows, maybe it even works?), stateful traffic inspection with thorough cross-correlation of collected data, application-level fingerprinting modules (for HTTP now, more to come),
and a lot more.

----

On my list to test in the near future and provide some new fingerprints. Assuming time permits and how well it works (I have no doubts well, but...), I will look at what it is doing and see if I can incorporate new stuff/ideas into a newer tcp plugin for Satori.

Forensics contest #4 Answer

Ok, 3/18/10 has come and gone so I figure it is ok to post my answer at this point in time. Not sure if I got it correct or not, but here goes. I actually made some changes to Satori and wrote a new .exe specifically for parsing the data you can find more in the writeup:

Answer 1: 10.42.42.253
Answer 2: TCP CONNECT
Answer 3a: 10.42.42.50
Answer 3b: 10.42.42.56
Answer 3c: 10.42.42.25
Answer 4: 00:16:CB:92:6E:DC
Answer 5: 10.42.42.50
Answer 6: 135
Answer 6: 139


Xtra-Credit:
NMAP, we can tell this by some of the unique things it does on Syn Scans, also some of the MSS sizes it sends in its OS fingerprinting tests and its ICMP code of 9 in that test.

While not exactly like NMAP puts out and without the OS guesses:

---------------------------------------
Summary
---------------------------------------
List of Possible NMAP Scanning machines (and number of ports scanned):
10.42.42.25=12
10.42.42.253=7420

List of Possible Machines Scanned by NMAP System (and number of ports scanned):
10.42.42.25=3401
10.42.42.50=2025
10.42.42.56=2005

Systems with Open Ports:
10.42.42.50 - 135/tcp
10.42.42.50 - 139/tcp

Systems with Unfiltered Ports:
10.42.42.25 - 1/tcp
10.42.42.253 - 36020/tcp
10.42.42.253 - 36119/tcp
10.42.42.253 - 36120/tcp
10.42.42.253 - 36121/tcp
10.42.42.253 - 36122/tcp
10.42.42.253 - 36123/tcp
10.42.42.253 - 36124/tcp
10.42.42.253 - 36131/tcp
10.42.42.253 - 36134/tcp
10.42.42.50 - 1/tcp
10.42.42.50 - 135/tcp
10.42.42.56 - 1/tcp

Systems with Closed Ports:
10.42.42.25=2003 Port(s) not Shown
10.42.42.253=2 Port(s) not Shown
10.42.42.50=2000 Port(s) not Shown
10.42.42.56=2005 Port(s) not Shown

Description:
Running the packet capture through nfc (http://myweb.cableone.net/xnih/download/nfc.zip), we find out there 2 possible systems doing some type of scan:

10.42.42.25 and 10.42.42.253, looking at the sheer number of scan packets, we can tell that 10.42.42.253 is the main system doing any type of scan. We can also look at SYN, Connect, XMAS and NULL scan types and see that 10.42.42.253 shows up in all 4, where 10.42.42.25 only shows up in the Connect Scan.

While 10.42.42.253 does do SYN, Connect, XMAS, NULL, and at least 1 port on UDP (probably during the OS fingerprinting part when looking for a closed UDP port). The first scan he does though is a TCP Connect Scan. We can see this by the flags and more importantly by the tcpoptions that are used. The general way we can break down the scan types is as follows (chunk of the delphi code used, due to having to have to port all the c code over to pascal on my own, source is not available, but general info on what was done is provided in the nfc downloaded zip file):

if tcpflags = 'SA' then
OpenPorts.Add(sl.Strings[x])
else if tcpflags = 'RA' then
ClosedPorts.Add(sl.Strings[x])
else if tcpflags = 'R' then
UnfilteredPorts.Add(sl.Strings[x])
else if (tcpflags = 'A') and (tcpoptions = '') then
ACKScan.Add(sl.Strings[x])
else if tcpflags = '' then
NullScan.Add(sl.Strings[x])
else if tcpflags = 'FPU' then
XMASScan.Add(sl.Strings[x])
else if tcpflags = 'S' then
begin
if tcpoptions = 'M1460:.' then
SynScan.Add(sl.Strings[x])
else //tcpoptions are going to be OS specific, so doing catch all for now
ConnectScan.Add(sl.Strings[x]);
end;

The tcpoptions are the same data I use in Satori for passively identifying OS's. This is close to what p0f is doing and the general fingerprints are the same, though mine have been updated over the past few years.

Looking through the summary info of NFC we can see that 3 machines were scanned:
10.42.42.25
10.42.42.50
10.42.42.56

Each saw a different number of ports scanned, this could be due to how NMAP's scripting engine works when it tries to OS fingerprint the remote system, though some of it could also be because of some of the interaction between these 3 hosts between each other when they started up their own conversations.

For OS identification we now look at Satori (http://myweb.cableone.net/xnih/download/satori.zip).

For this exercise some tweaks were made to a few of the fingerprinting dlls. While Satori wasn't designed to specifically parse nmap traffic, it can, though it is a bit slow due to the number of packets with tcpoptions.

One of the dlls that was changed was the icmp one. Found under the pull down for "icmp". NMAP sends ICMP Type 8 packets with an ICMP Code of 9 (Languard sends with a 13, others may send with their own too, trying to elicit a different response with a valid and invalid code). For the TCP dll I modified it to identify more than just S and SA packets (where the original dll just drop all the others), we now process them and tag them, even ones that may be of no use with flags such as FA and PA. The main new useful ones were NULL and XMAS. I also updated the mtu text file under fingerprinting to add in the common MTU sizes that NMAP uses (305, 680, 1440). All of this can be found in the pull down for "tcp".

Note: The downloadable version of Satori is quite old, but the updater program should be run after initial download, selecting ALL files, not just ones it marks as new since it looks at the last modified date, which typically is when you unextracted the file.

Anyway, to determine each OS here we can look at the data that Satori provided:
10.42.42.253 - Linux 2.6 (p0f) or Solaris (ettercap) nothing in my DB to identify it
10.42.42.50 - Windows XP SP3 most likely, XP or 2000 (Satori), Windows 2000 (p0f), BSD or 2000 Server (ettercap)
10.42.42.56 - unknown across all passive fingerprinting
10.42.42.25 - unknown across all passive fingerprinting, but based on MAC and that alone Apple (could always be spoofed) if it is an OS X box, there is a Syn fingerprint that can be added to my DB.

Based on the MAC, the Apple machine's MAC is: 00:16:CB:92:6E:DC

Windows machines IP can be seen above.

Using either NFC or Satori we can see that TCP ports 135 and 139 were open on it.


NFC output:
---------------------------------------
Types of Scans and General Info
---------------------------------------
SYN Scan info:
Start Time: 2010-02-02 17:43:10 Packet #: 6728
End Time: 2010-02-02 17:44:03 Packet #: 13525
System(s) appearing to do SYN Scans:
10.42.42.253=3745
System(s) appearing to be SYN Scanned:
10.42.42.25=1745
10.42.42.56=1000
10.42.42.50=1000

Connect Scan info:
Start Time: 2010-02-02 17:34:06 Packet #: 1
End Time: 2010-02-02 17:44:12 Packet #: 13620
System(s) appearing to do Connect Scans:
10.42.42.253=3670
10.42.42.25=12
System(s) appearing to be Connect Scanned:
10.42.42.50=1024
10.42.42.56=1003
10.42.42.25=1655

XMAS Scan info:
Start Time: 2010-02-02 17:44:10 Packet #: 13599
End Time: 2010-02-02 17:44:13 Packet #: 13624
System(s) appearing to do XMAS Scans:
10.42.42.253=4
System(s) appearing to be XMAS Scanned:
10.42.42.56=2
10.42.42.25=1
10.42.42.50=1

NULL Scan info:
Start Time: 2010-02-02 17:44:10 Packet #: 13597
End Time: 2010-02-02 17:44:10 Packet #: 13597
System(s) appearing to do NULL Scans:
10.42.42.253=1
System(s) appearing to be NULL Scanned:
10.42.42.50=1

---------------------------------------
Summary
---------------------------------------
List of Possible NMAP Scanning machines (and number of ports scanned):
10.42.42.25=12
10.42.42.253=7420

List of Possible Machines Scanned by NMAP System (and number of ports scanned):
10.42.42.25=3401
10.42.42.50=2025
10.42.42.56=2005

Systems with Open Ports:
10.42.42.50 - 135/tcp
10.42.42.50 - 139/tcp

Systems with Unfiltered Ports:
10.42.42.25 - 1/tcp
10.42.42.253 - 36020/tcp
10.42.42.253 - 36119/tcp
10.42.42.253 - 36120/tcp
10.42.42.253 - 36121/tcp
10.42.42.253 - 36122/tcp
10.42.42.253 - 36123/tcp
10.42.42.253 - 36124/tcp
10.42.42.253 - 36131/tcp
10.42.42.253 - 36134/tcp
10.42.42.50 - 1/tcp
10.42.42.50 - 135/tcp
10.42.42.56 - 1/tcp

Systems with Closed Ports:
10.42.42.25=2003 Port(s) not Shown
10.42.42.253=2 Port(s) not Shown
10.42.42.50=2000 Port(s) not Shown
10.42.42.56=2005 Port(s) not Shown



No Results are perfect here since we are not taking into account where in the scan certain things

happen.

This is just a quick and dirty best guess based on what we are seeing.

---

Satori being a GUI program will have to be downloaded and run.

Network Forensics Contest Results

A month or two ago philosecurity.org started a nice little Network Forensic contest. It wasn't too hard and wasn't too easy. It gave me a chance to parse through some traffic and see what was going on. Then to carve a file out of a packet capture, using some of the SANS 508 stuff I learned awhile back before I picked up my GCFA cert.

The original puzzle can be found here and then again here when SANS decided to sponsor it and give an On-Demand course away for the winner.

Well happy to say I at least got everything right, though I didn't win, nor was I one of the finalists. All of the finalists scripted out a way to answer the questions, or had one program that did it all (or most of it). The results can be found here.

Erik Hjelmvik, author of NetworkMiner, who is using some of the tcp and dhcp fingerprinting stuff from Satori was one of the finalists and implemented some new stuff in 0.89 to become a finalist, though not a semifinalist since it wasn't all scripted out either. (When I used NetworkMiner to parse it out, it was only version 0.88, Erik hadn't released 0.89 until after I put my submission in).

From a straight Network Forensics standpoint I understand why they wanted it scripted out, but from understanding how to actually do it I'm glad I didn't depend on an automated program to do it (granted each of the finalists I believe had to write their own programs to do this). If you understand how to carve the data out then you can do this with pretty much any data, if you depend on a utility to do it, you may have to wait for updates to it if/when things change.

Ultimately I just wanted to make sure I could do it and am happy that I got it done and answered correctly. I was more interested in it from fingerprinting stand point anyway and spent more of my time on seeing what else was on the network!

If anyone wants to do it, the puzzle and pcap files are still out there!

Here was my submission and all my notes (again I was interested in the rest of the network):

Answers:

1. Sec558user1
2. Here's the secret recipe... I just downloaded it from the file server. Just copy to a thumb drive and you're good to go >:-)
3. recipe.docx
4. 50 4B 03 04
5. 8350582774E1D4DBE1D61D64C89E0EA1
6. Recipe for Disaster:

1 serving
Ingredients:
4 cups sugar
2 cups water
In a medium saucepan, bring the water to a boil. Add sugar. Stir gently over low heat until sugar is fully dissolved. Remove the saucepan from heat. Allow to cool completely. Pour into gas tank. Repeat as necessary.

How I got there:

Tools Used:
Satori - http://myweb.cableone.net/xnih - Passive OS Fingerprinting
NetworkMiner - http://sourceforge.net/projects/networkminer/ - Network Forensic Analysis Tool, used for cookie stuff and a few other sanity checks
FrHed - http://frhed.sourceforge.net/ - used to Hex Edit the file to remove the initial stuff prior to the magic number
Wireshark - http://www.wireshark.org - view and export pcap file
HashGenerator - http://pagesperso-orange.fr/cycocrew/delphi/applications.html - computer hashes
Google of course to find some of the other info
----

Writeup:
I started with 2 programs, one I wrote geared completely towards passive OS fingerprinting, Satori, and the other program NetworkMiner which I've worked with the developer on a little in the past. Using Satori I mapped out the machines identified in the packet capture and got an initial layout of the network. Determing which systems did what on the network. Then feeding the capture through NetworkMiner I was able to get some of the initial Clear Text information that was going on between clients. Once I had a better idea of what type of data was in the capture I started picking away at it with Wireshark.

Knowing Ann's IP it was easy to get started in wireshark with a simple filter of (ip.host == 192.168.1.158). With this in place and scanning through the packets for anything out of the ordinary in the hex window. Basically I knew there had to be some type of clear text conversation going on due to what NetworkMiner had seen. We see Ann's computer is talking to a 64.12.24.50 (bos-m013a-sdr3.blue.aol.com). Since it is an AOL server it is probably AIM being used, but I did not verify that. The information looks to be SSL based on the destination port, but ends up being in clear text. I assume this was an attempt to get past any egress filtering, but didn't dig into it since that wasn't requested at this time.

Identifying who she was talking to was fairly simple, and digging into whatever protocol the chat program she was using would have probably been a good idea. Based on other things I saw she appears to be comunicating with Sec558User1.

Eventually she transfers the file to the other user at computer 192.168.1.159, which appears to be a Windows XP box. Depending on your env this may be a dead give away that you are having issues. Looking at the other systems on this network they all appear to be Linux Boxes, so a new rogue XP box sticks out like a sore thumb. Something like packet fence which does DHCP fingerprinting may be useful to block computers like this off their network or at least make it a little harder for them to get a valid IP and use the network.

In packet 92 we see the beginning of the file transfer. Sending the file recipe.docx

The rest of the file transfer which starts in about packet 109 where we are able to right click on it and do "Follow TCP Stream". This shows both directions of traffic. Next we need to go to the bottom and filter by 192.168.1.158 --> 192.168.1.159, getting just the data that Ann's computer is sending to the XP box. Select Raw and do a Save As. This will save "extra" info in the file, which we will need to remove based on some file carving next.

We now know, or appear to know the type of file it is based on the file name above. We need to look up that magic number. A docx file really is a zipped file so it has the same magic number which is: 50 4B 03 04 14 00 06 00

We now open up the file we saved in a hex editor and do a search for the above magic number. Once we find it we delete anything prior to it and resave the file. There is always the chance that there will be extra junk at the end too that may need carved off.

After that, we can open up the file with OpenOffice or Microsoft Word and see what the data is. We could also unzip it instead and look at the .xml files generated if we need to find out more about the initial file.

Run the file through your choice of md5sum programs and you should be good to go.

-----

Below is the notes I took while I went through the system, typically wouldn't put them in a report, but there was a few interesting pieces of info in there I found.

Extra info and general notes on systems on the network and what they appear to do:

192.168.1.2 - Linux 2.6 possibly, limited info, did what may have been a scan of 192.168.1.157. Connected on port 80, but just did a handshake and said goodbye, no header info exchanged.
192.168.1.10 - default gateway I assume
192.168.1.30 - NTP Client Box, running SSH server (192.169.1.2 connected to it)
192.168.1.157 - running Samba 2.2.7 - 3.0.x client (actually 3.2.0, need to update Satori)
print queue
HTTP Server, or at least port 80 is open
Herbivore/SANS
192.168.1.158 - Linux 2.4 or 2.6 box, packet 92 starts sending recipe.docx, packet 112 using cool filexfer sends it also
NTP Client
Talking to 64.12.24.50, most likely sec558user1
FTPs file to 192.168.1.159, syn comes in in packet 109
192.168.1.159 - Windows XP, 2000 or 2003 box (XP based on Web)
talking to 64.12.25.91
downloads zip file of smiley faces from 205.188.13.12
goes off to at.atwola.com, requesting DNS info for them after download of resume.doc
pulled file (httpget) with: (removed since it was actually linking to the ad in this post!)
pulled file (httpget) with: (removed since it may have linked to ad also).
"username" on cookie: JEB2=4A839DDB6E65181C45921CB2F00016D8; ATTACID=a3Z0aWQ9MTU4NzdpYTAwYTh2Ymk=; ATTAC=a3ZzZWc9OTk5OTk6NTAyODA=; badsrfi=V0d710994e8ccb8db64a83a07939b2; atdemo=a3ZhZz1hbTM6dWEzOTtrdnVnPTE7; AxData=; atdses=0
atwola.com appears to be "spyware/adware" based on a quick search

External Hosts
64.12.24.50 - bos-m013a-sdr3.blue.aol.com
64.12.25.91 - bos-m007c-sdr4.blue.aol.com
64.236.68.245 (dns requested info by 192.168.1.159)
64.236.68.246 (dns requested info by 192.168.1.159)
205.188.13.12 - no DNS entry, only talking to 192.168.1.159 via SSL), downloaded a zipped file of smile faces and their manifest.
10.1.1.20 - DNS server, NTP Server

Clear text data, (192.168.1.158 to 64.12.24.50) (owned by AOL, so possibly AIM traffic)
E4628778....Sec558user1
Here's the secret recipe... I just downloaded it from the file server. Just copy to a thumb drive and you're good to go >:-)
E4628778....Sec558user1*..c.z.........
G7174647....Sec558user1.......R..7174647..F.CL...."DEST.......................F.........'...........recipe.docx.*.V......
G7174647....Sec558user1*.V..{.......*..
7174647....Sec558user1..............J.H.........+..1n....+...O............J.........7174647..F.CL...."DEST.......*.V..".......*.1...........
Sec558user1..*.V..........*.y..N....w...
Sec558user1..............J.H.........+..1n....+...O............J......a........X....< HTML >< BODY >< FONT FACE="Arial" SIZE=2 COLOR=#000000>thanks dude< /FONT>< /BODY>< /HTML >.
......+..1n....+...O.........*.V..".......*.............Sec558user1..*.V..........+.Q.....L.....Sec558user1..............J.H.........+..1n....+...O............J......s........j....< HTML >< BODY>< FONT FACE="Arial" SIZE=2 COLOR=#000000>can't wait to sell it on ebay< /FONT>< /BODY>< /HTML >
............Sec558user1..*.V..".......+.............Sec558user1..*..d.".........H...........Sec558user1..*..e.J.........
I5088496....Sec558user1..."................see you in hawaii!....*..f.".........J...........Sec558user1..*.V......

DOCX (zip) Magic Number:
50 4B 03 04 PK..
ZIP PKZIP archive file (Ref. 1 | Ref. 2)
Trailer: filename 50 4B 17 characters 00 00 00
Trailer: (filename PK 17 characters ...)
DOCX, PPTX, XLSX Microsoft Office Open XML Format Document
JAR Java archive; compressed file package for classes and data
SXC, SXD, SXI, SXW OpenOffice spreadsheet, drawing, presentation, and text files
WMZ Windows Media compressed skin file
XPI Mozilla Browser Archive
XPT eXact Packager Models

50 4B 03 04 14 00 06 00 PK......
DOCX, PPTX, XLSX Office 2007 documents

Use Follow TCP Stream, just get one side of converation. Save as Raw. Lookup "magic number"
Search for it in Saved file. Delete everything prior to that and resave, get:

Recipe for Disaster:
1 serving
Ingredients:
4 cups sugar
2 cups water
In a medium saucepan, bring the water to a boil. Add sugar. Stir gently over low heat until sugar is fully dissolved. Remove the saucepan from heat. Allow to cool completely. Pour into gas tank. Repeat as necessary.

Hash on the File is:
8350582774E1D4DBE1D61D64C89E0EA1

Satori, Linux version

Ok, been busy working on a command line version of Satori for Linux. There are certain functionality in the cmd line version that I will not try to replicate that are in the windows version. Since I'm just doing output to screen an overall score and some of the other things, such as ICMP sequence differences will not be there.

So far I've ported the DHCP, TCP, p0f and ettercap stuff over.

It is written in free pascal (fpc) with the lazarus IDE. Ultimately my goal is to get as much of it over to Linux as possible and most likely to rewrite the whole thing in fpc so that I can have a GUI version on both windows and linux.

Main reason I'm writing it for Linux is so I can play with it on the wall-warts I wrote about a few weeks ago. Assuming I have some extra cash I'll probably be ordering one in the near future. This will require me to compile it for ARM also, hopefully all goes well!

If anyone wants a copy, let me know.

Updated Software

Satori updated to version 0.62. Lots of new fingprints added and others updated. Took like Linux distro's and combined them where it made sense instead of having 5 fingerprints that were all the same because they were based on the same distro. Also added the packetfence fingerprint info back into my dhcp.xml file. We'll see if the packetfence project starts using the .xml file or not, it has been discussed in the past and may be being looked at again. We'll see.

With the addition of these fingerprints back into dhcp.xml I decided to give the user a few more options in parsing dhcp fingerprints. You'll find it under options. I also added a new feature for arp parsing also since it was in an 'addon' dll instead before. Now it is just an option.

Last major change was an update program. It is a stand alone program that will update the .exe, .dll, and .xml files. It is nothing fancy, but it gets the job done. It will let you keep up to date on the latest fingerprint files, dll's, etc without me having to do a full new .zip file!

Updated Software

NetworkMiner -
Ok, been spending a lot of time trying to crash NetworkMiner for the author. Found a nice little bug he had going and a quite a few crashes. All of those are fixed in 0.87 which was recently released. If you are using NetworkMiner I highly recommend updating to the latest version to fix the nasty little bug earlier versions had on saving files.

Satori -
also been spending a lot of time with Erik, author of NetworkMiner, and Jeff (from a private company) on updating the dhcp.xml file schema. Jeff had a lot of good recommendations and has provided a few new fingerprints. Between the 3 of us we updated the schema to a very good 1.0 version I think. I may do an overhaul of it a year or two down the road to add some other functionality into it, but we'll see. Anyway, the new version allows us to group Devices much nicer than before. For Satori it will give me the ability to group Devices across fingerprinting files (dhcp, icmp, tcp) since all 3 have been updated to the new format. Not sure when I'll add the functionality to utilize it, but it is updated along with the removal of a lot of old information in the dhcp.xml file that came from the packetfence.org project. It was nice to have at one point, but since they do not track if it is a dhcp inform/discover/request packet, it doesn't do me any good anymore, so it was removed, along with some other fingerprints I got from files around the same time and did not get everything I needed!

Always looking for new fingerprints. And on that note, I setup an account dhcpfingerprints [AT] gmail.com specifically for fingerprints, originally for dhcp ones (since that is how most people keep finding out about Satori), but will probably use it for all fingerprints.

Network Miner

One program that is currently using parts of Satori is NetworkMiner, which is actually where most of the other news about Satori has been coming out from lately.

NetworkMiner uses the dhcp fingerprinting DB in the currently released version at:
http://sourceforge.net/projects/networkminer/

I believe the next version that is released should also have the tcp fingerprinting piece from Satori based on emails with the author in the past.

Some good articles on NetworkMiner and what all it can do can be found here:
http://holisticinfosec.org/toolsmith/docs/august2008.pdf
http://www.net-security.org/dl/insecure/INSECURE-Mag-18.pdf

The 2nd one you'll need to jump to page 18.

NetworkMiner is a very nice program to pull information off the network and rebuild the files that are being downloaded. Driftnet for windows along with a lot of other nice features. Its OS identification is not nearly as polished as Satori, in my opinion at least, but that is not what it is geared towards.

Check it out

Satori in the news "out there"

The following sites/blogs have information on OS identification that mention Satori:
One of the first references to it that I recall was by Thierry Zoller in a post on full disclosure, then later on his blog

http://snoopsec.blogspot.com/2008/10/obfuscating-your-os-tcp-stack-or-way-to.html
http://www.binrev.com/forums/index.php?showtopic=39194&st=0&gopid=319785&#entry319785
http://www.irongeek.com/i.php?page=security/osfuscate-change-your-windows-os-tcp-ip-fingerprint-to-confuse-p0f-networkminer-ettercap-nmap-and-other-os-detection-tools
http://hackaday.com/2008/10/04/avoiding-os-fingerprinting-in-windows/

The hackaday post came out on Oct 4, 2008, the hits to my website jumped from roughly 100 hits a month, to about 350 in a 4-5 day period after that spot came out!