Satori Updates

 I've continued to update Satori little by little out there on github.  Both updating the underlying code and fingerprints.   Always happy to have new ideas or feedback on the program.

Youtube channel

I've continued to make updates to the python version of satori and have put a lot of time in the past few weeks to updating fingerprints and fixing some minor bugs that have cropped up.  But.... I thought I'd take this opportunity to do a quick intro to the youtube channel I started.

It is called, you guessed it, Chatter on the Wire, or CotW for short.  It won't just be about OS Fingerprinting, but I'm sure I'll put some demo's of Satori and other programs I've written out there.  It will be videos about a number of different things, small electronics, coding projects, melting metals and whatever else I find myself periodically doing that I decided I'd document.  Mostly I believe it will be reviews of products I've been using myself or testing out for certain specific applications for home, work, or other areas of my life.

It will bounce around a bit and I hope to put stuff out every so often.  Not sure if that will be every few days, weeks, or months, but will all depend on time and the amount of effort it takes to put the videos together.

posted to github

https://github.com/xnih/satori

3 modules so far:

• dhcp
• tcp
• useragent

Speed increase of anywhere from 7.5 to 20.4 times faster than my old windows version.

I have not run all my old pcaps through it at this point, but did run a few from my last sans course through it to find a few bugs I had.

Fingerprint files for each of those 3 have been updated, with a number more hopefully coming with the next week.

I also hope to get smb done before long, as I do see there is an smb one in pypacker (missed it before).

Satori rewrite update

Real life/work always gets in the way.....

Lost 2 weeks to work related fun, but finally had a chance to revisit the rewrite this weekend and parse some of the tcp pcaps I've gathered in the past month or so to feed it.

tcp.xml has been updated with a number of newer OS's.  Since it had been 4+ years or so since I'd last updated it, there were a lot of Windows OS's to add to it.  I did find it interesting that I can tell the difference between windows 10 - build 14393 (and potentially earlier) to 15063 and greater!  Something changed in the tcp stack between those builds.  Also added some 2012 and 2016 server fingerprints and a few others such as some newer OS X ones.  By no means complete with what I have, but when you're that far behind on things, takes awhile to start adding things again!

As for the rewrite itself, got some command line options so you can choose which modules you want to use (tcp is done, dhcp is next to be worked on).  Not sure what all ones I'll port, but moving along.  Also got code in place to choose the file you want to read in, instead of just having it hard coded.  Neither huge accomplishments, but something I had to get fixed to make it even partially usable.

I also got things broken out into different files, initially was all one big jumble, but hey, i'm not really a programmer, I hack stuff together to make it work! 

Hope to have something out on github for testing in the near future, but all depends on free time.

TCP module done???

First the good news, the tcp module, including reading in the tcp.xml from years ago seems to be done.

I ran nmap -O 192.168.x.0/24 against my local home network and saved a tcpdump file to disk while it was running.  Of course I forgot about it and it was listening while any traffic it could see was going out to the internet as well.  Currently satori.py is hard coded to read one specific .pcap file, which I then read in:

python3 satori.py | awk -F';' '$7 != "" { print $3, $6, $7 }' | sort -u

Output:

192.168.1.108 8192:128:1:52:M1460,N,W8,N,N,S:A Windows 7:5|Windows Server 2008:5

192.168.1.109 29200:64:1:60:M1460,S,T,N,W7:. Ubuntu 18.x:5

192.168.1.131 8760:64:0:52:M1460,N,W0,N,N,S:A Hewlett-Packard JetDirect:5

192.168.25.128 29200:64:1:60:M1460,S,T,N,W7:. Ubuntu 18.x:5

198.8.71.207 65535:128:1:52:M1460,N,W1,N,N,S:A Windows 7:5

207.198.x.38 8192:128:1:52:M1460,N,W8,N,N,S:A Windows 7:5|Windows Server 2008:5

207.198.x.39 8192:128:1:52:M1460,N,W8,N,N,S:A Windows 7:5|Windows Server 2008:5

207.198.x.40 8192:128:1:52:M1460,N,W8,N,N,S:A Windows 7:5|Windows Server 2008:5

207.198.x.41 8192:128:1:52:M1460,N,W8,N,N,S:A Windows 7:5|Windows Server 2008:5

207.198.x.42 8192:128:1:52:M1460,N,W8,N,N,S:A Windows 7:5|Windows Server 2008:5

209.15.x.11 8192:128:1:52:M1460,N,W8,N,N,S:A Windows 7:5|Windows Server 2008:5

209.15.x.8 8192:128:1:52:M1460,N,W8,N,N,S:A Windows 7:5|Windows Server 2008:5

Format above is just src IP, tcp fingerprint, OS guess.   In true satori fashion, the OS guess has a value associated with it, so that I can tie the different ones together and give a guess based on different protocol fingerprints.  Format is OS Guess:Weight  |  next OS Guess:Its weight    etc....

Full output from Satori looks like:

2018-10-14T01:50:57.063663;00:0C:29:5F:9F:42;192.168.25.128;TCP;S;29200:64:1:60:M1460,S,T,N,W7:.;Ubuntu 18.x:5

Date/Time in UTC, ISO Format; SRC MAC; SRC IP; What protocol it came from; In the case of TCP, if it was a S or SA; TCP Fingerprint; OS Guess w/ Weight

In the case of TCP, the SRC MAC is normally worthless as it will be the router, but for DHCP and others it is the Unique Identifier I need.

Now the minor bad news....

pypacker doesn't have any built in ability to read live packets, it only has its ppcap piece that has read in it for captured files.  I'm going to dink around with pcapy later and verify if I can use it to read live packets and just feed the packets in similar to the pypacket buffer.  I have high hopes, but be a few days until I get some time to verify.

So what is next...

1. Add feature to read specific capture files from disk instead of a single hard coded one that I keep manually renaming to test.pcap!
2. Investigate pcapy for live capture input into the script instead of just saved files
3. Update tcp.xml as it is WAY out of date!
4. Get setup on github or something similar (think I already have account) and publish this as I go
5. Add a ton of error checking into this, currently only one try: except: clause in it and was only added due to last round of testing when things were blowing up on my nmap pcap file.

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!

Fingerbank Collector

Ok, it has been eon's since my last post and this has more to do with other projects taking up my time in electronics than in fingerprinting, but I still like to dabble in this world as time permits.

Going back to 2007 and a lot of what Satori does/did, it looks like fingerbank has taken on, which is very cool to see!

https://fingerbank.org/collector.html?utm_source=pf-announce-en&utm_medium=email&utm_campaign=gartner_collector

ARP, DHCP v4 and v6, DNS and mDNS, HTTP and HTTPS, Radius (one I never tried to utilize) and TCP

They are doing it cloud based and it is closed source, but still cool to see what I was doing 7 years ago is making it main stream these days in yet another project.

Satori rewrite

Ok, for years I've been planning on rewriting Satori in python (or something else) and never have gotten around to it.  Well 2 weeks ago I started playing with pyshark while working with SMB packets for FOR572 class.  More on that project in the future, but it got me thinking, why go to all of the headache of writing new code to parse all those packets, instead use the power of tshark, via pyshark.

So with that said, I really do plan on Satori 2.0 (or would it be 1.0 since I never made it out of the 0.7x arena).  The future releases of Satori will be pyshark/python based with tshark on the backend to do the heavy lifting.  I plan on just coding enough to pull the needed info and query the underlying .xml files for fingerprint data.  This will get it off the ground again, though may not make it as fast as it could be, but trade offs, it is that or I probably never get back to it :)

I'm not sure I can do everything I was doing with Satori before, but I can easily do dhcp, http agent string, and some of the smb stuff I was doing.

I'm thinking about adding some SSL fingerprinting to it also.

All of this to say, evidently Satori isn't dead from my end!  Just taken a bit of a break.

OS's - patching and support

In the past few weeks Microsoft has appeared a bit peeved with Google's disclosure policy.  They had a patched planned for Patch Tuesday (today) and the information about it hit the 90 day mark back at the end of December and was released by Google. 

There have been a number of threads going on the different lists I'm on, some supporting this saying Microsoft knew their policy and knew the dead line, while others upset at google who knew a patch was in the plans and released the data anyway.

I've been back and forth on Full Disclosure vs Responsible Disclosure over the years.  I see both sides and understand the needs.  I do believe the security researchers that find these bugs and push the vendors to get patches out the door are important, but I also believe a lot of these researchers (not all, but a lot) haven't had to support large organizations and deal with the "headache" these things cause.

In the end, supporting or trying to secure a large organization is tough to start with, made tougher by the numerous pieces of software and hardware that may be out there and made even tougher when you don't have total control over what is on your network (at least in the .edu space).  Add to that screwed up patches that get pulled and 3rd parties disclosing things "days" before a patch is due out, its almost enough to make you pull your hair out some days.

Microsoft has the problem of trying to make sure that things are backwards compatible, supporting things from 10+ years ago.  Google on the other hand just drives forward with a new OS and dropping support for older ones.

Case in point:

https://community.rapid7.com/community/metasploit/blog/2015/01/11/google-no-longer-provides-patches-for-webview-jelly-bean-and-prior

As we see more and more devices built on the Android OS and their support just ending, due to carriers not doing upgrades, or whatever, it will be interesting to see how things plays out in the future.  Will Google actually be the one that takes the heat or will the carrier (from the public).  Or will the idea of just throwing the old equipment away and constantly upgrading continue to be the norm?

I'm still running an old 2.3.x "smart" phone.  I don't surf the net with it, it gives me phone access and it gives me my calendar stuff.  It works for what I need, but I know its limitations and security implications if I surf the web with it.  How many users do?  Should we really be forced to spend that much every 2 years to replace older tech?  Maybe things change constantly, it isn't like when I started and we used to get new AV definitions every 6 months anymore :)  But I hate to see us continue to throw away perfectly working tech that could be patched.

Oh well, I digress.  Another Patch Tuesday is upon us and another will come next month.  Changes will continue to happen and those that have to support systems will continue to adapt or short of that move on to other things!

Pi clones

The raspberry pi was a great little device a few years ago.  Great price point, allowed you to run linux on a very small device that if lost/stolen wouldn't be the end of the world, but it also had very little horse power to do much of anything.  Trying to run a GUI on it was painfully slow due to the limited ram and single core proc running at 700 or so.

There have been a few different clones, found 2 I liked last night in searching around for things.

The ODROID-C1- http://ameridroid.com/products/odroid-c1
At $37 bucks hard to beat a quad cpu, 1 GB ram device.  It should provide a bit more omf when needed!  It is on my wish list to order now since I found it, perhaps today I'll do it.

The BPi-R1 - http://www.bananapi.com/index.php/component/content/article?layout=edit&id=59
Newegg is carrying these at $75 (http://www.newegg.com/Product/Product.aspx?Item=9SIA6DB29F2479).  While not as powerful as the ODROID-C1, this one is the kitchen sink, designed specifically for a home router type setup, it has what I've wanted which is a built in switch.  I've wanted to build a box to route game traffic through and do some manipulation of the traffic.  Not sure if it will be powerful enough, but doing some tcpdumps off this may be an option.

For now I'll stick with the ODROID-C1 I think and just put a USB to ethernet jack on it so I have a 2nd wired port to route stuff through.

Anyway, raspberry pi has made some great things possible.  I hope we continue to see higher powered systems (more ram actually) at the sub $50 mark.

Maybe I'll just build a few of these with ARPWatch on them and drop them on some of my closed networks!

Filters and updates

This was one of those learning moments.  You've used a tool for years and it has always worked for you and then all of a sudden you're getting results you aren't expecting.  After 30 mins of looking at the code, verifying it works in your primary location but not in the one you've provided to the rest of the world, it finally dawns on you that you've added filters into the program to limit the garbage that you have to process.

This could have been wireshark or a plethora of programs out there, but this was in Satori.

Historically I didn't use the filters much, it was something added at the request of someone else, but more are more at home I've found myself using them.  Problem is, I sometimes forget they are turned on.  I wanted all of my local 192.168.x.x traffic and any of my local IPv6 traffic (FE80::), but when doing DHCP work, it makes a big difference if you've added that last one in there.  Without 0.0.0.0 I wasn't seeing any discover or request packets and for the life of me I couldn't figure out why!

It is always wise to go back to the basics when something all of a sudden stops working.  Get things back to a set starting point with no tweaks in place and make sure it is working there, before spending 30 mins digging through code and realizing there is nothing wrong with it and it works fine on that system!

Anyway, all that to lead up to the fact that I've updated web, tcp, webagents, sip and the main satori.exe file (that was one change to make sure Windows 8.1 was in the hard coded part of the program I've never got out to config files yet).

DHCP Inform vuln?

I have not verified this, but since most of my work was around DHCP related fingerprinting I found it interesting.  I wonder how many other DHCP clients are vuln to this on my test systems.

Anyway, this is a direct repost off of FD from earlier today with only slight modifications for formatting issues:

Title:           Microsoft DHCP INFORM Configuration Overwrite

Version:         1.0
Issue type:      Protocol Security Flaw
Affected vendor: Microsoft
Release date:    28/05/2014
Discovered by:   Laurent Gaffié
Advisory by:     Laurent Gaffié
Issue status:    Patch not available
============================================================

Summary
-------

A vulnerability in Windows DHCP (http://www.ietf.org/rfc/rfc2131.txt) was
found on Windows OS versions ranging from Windows 2000 through to Windows server 2003.  This
vulnerability allows an attacker to remotely overwrite DNS, Gateway, IP Addresses, routing, WINS server, WPAD, and server configuration with no user interaction. Successful exploitation of this issue will result in a remote network configuration overwrite. Microsoft acknowledged the issue but has indicated no plans to
publish a patch to resolve it.


Technical details
-----------------

Windows 2003/XP machines are sending periodic DHCP INFORM requests and are not checking if the DHCP INFORM answer (DHCP ACK) is from the registered DHCP server/relay-server. Any local system may respond to these requests and overwrite a Windows 2003/XP network configuration by sending a properly formatted unicast reply.

Impact
------

Successful attempts will overwrite DNS, WPAD, WINS, gateway, and/or routing settings on the target system.

Affected products
-----------------

Windows:
- 2000
- XP
- 2003

Proof of concept
----------------
The DHCP.py utility found within the Responder toolkit can be used to exploit this vulnerability.

git clone https://github.com/Spiderlabs/Responder

Solution
--------
Set a DWORD registry key "UseInform" to "0" in each subfolder found in HKLM\SYSTEM\CCS\Services\TCP\Interfaces\

Response timeline
-----------------
* 18/04/2014 - Vendor notified.
* 18/04/2014 - Vendor acknowledges the advisory ( [MSRC]0050886 )
* 18/04/2014 - Suggested to vendor to run Responder on a A-D environment while looking at the DHCP issue for education purposes. Since multiple attempts were made to have them be aware that any A-D environment by default is vulnerable if Responder is running on the subnet. Also, MSRC was
asked what code change made this DHCP INFORM issue different on Windows
Vista than Windows Server 2003.
* 21/04/2014 - MSRC answers with an automated response.
* 08/05/2014 - Request for a reply.
* 14/05/2014 - MSRC reply and refuses to share their view on the code change, however they mention that 'The product team is investigating whether the RFC for a DHCPINFORM message is properly implemented'.
* 14/05/2014 - An email was sent to notify MSRC that no code change was requested, but the logic behind it. Also, MSRC was asked if they were successful with Responder.
* 16/05/2014 - MSRC closes [MSRC]0050886 and doesn't provide any info on if they were successful with Responder in their environment.


References
----------
* Responder: https://github.com/Spiderlabs/Responder
* http://g-laurent.blogspot.ca/
* https://twitter.com/PythonResponder
* http://blog.spiderlabs.com/2014/02/responder-20-owning-windows-networks-part-3.html

Accelerometer fingerprinting in mobile devices

Interesting research here.

http://www.scmagazineuk.com/phone-tilt-sensors-can-be-used-to-track-you/article/345712/

They say: “An accelerometer fingerprint can serve as an electronic cookie, empowering an adversary to consolidate data per user, and track them over space and time. Alarmingly, such a cookie is hard to erase, unless the accelerometer wears out to the degree that its fingerprint becomes inconsistent. We have not noticed any evidence of this in the nine months of experimentation with 107 accelerometers.”

Original writeup:
http://synrg.csl.illinois.edu/papers/AccelPrint_NDSS14.pdf

---

It would be interesting to know how accurate this really is once you start getting into 1000's and 100,000's of devices.  While I can see where you could determine general info about what device and accelerometer is it in, using it to track and individual user may be a bit more problematic.  With that said, I haven't read the 16 page right up yet, just the quick news article and with that I'll admit I scanned it.

Interesting approach and cool way to do it!

Satori and AV (SEP at least)

Funny thing today.  I went to download Satori and install it on my work computer and Symantec deleted it for reputation......

Looks like I need to put in a request to get them to whitelist it.  Guess I know what I get to do on my vacation.  Thanks a lot Symantec!  Nothing like not being able to install ones own software because the AV company decided it didn't like it (I know I'm not the first and won't be the last).

Update:  Look at that, Kaspersky has no issue with it on another system.

2/17/2014 - update.  If any of you using Satori are Symantec users, please submit false positive reports as this is what I got back!

We are writing in relation to your application through Symantec's on-line Software White-listing Request form for your software Satori.
Symantec has decided not to add this software to its white-list at this time.
Please note that this decision does not mean that Symantec products will necessarily detect your software in the future.
It simply means that Symantec could not conclude from its analysis at this time that your software should be included in its white-list.
Symantec does not disclose or discuss its decision or analysis; however, in the event Symantec products detect your software at any point and you believe the detection to be a false positive, you may notify us through Symantec's on-line Security Risk/False Positive Dispute Submission form available at: https://submit.symantec.com/false_positive/

SANS webinar - What Matters in Your Chatter?

I like to listen to a lot of SANS webinars and most I get a bit out of, but some I get a lot out of.

The presenter on this one pointed out that one of the big issues in our field is most of us aren't excited anymore about things, digging into them because we want to learn more, instead just spending time filtering through stuff we already know.  We need to be looking for new things and be excited doing it!

It reminded me of why I got into this field before and how excited I was when I found the ability to do DHCP fingerprinting.

It was by no means the best webinar I've ever listened to, but it was a good one to listen to.

More on Interesting Patents

Amazing what you find when you start searching even more.  I'm really surprised Google Alerts never picked some of these up before and alerted me on them!

Detecting Rouge Wireless Devices via DHCP Fingerprinting:
Microsoft - 2011

Appears to be a similar one, but not sure of differences right now.
Microsoft - 2007

System and Method for Resolving OS or Service Identity Conflicts (using SMB, DHCP, etc)
SourceFire - 2011

So it looks like a few other places have put some patents on DHCP fingerprinting in the past few years also.

Patents on OS Fingerprinting - DHCP specifically

I'll admit, I've never looked much into patents and how they work (what protection they give you, how much they are worth, etc), but I'm curious how one gets one for OS fingerprinting?  Specifically on a technology that many people were freely writing about prior to the patent being filed.

Infoblox was one of my last posts after they popped up on a google alert and a buddy just sent me a link to this:

http://www.freepatentsonline.com/8458308.html

On Aug 23, 2006 they  filed this patent.  It took until Jun 4, 2013 for it to be approved if I read this correctly.

General history on DHCP fingerprinting from what I've found in my research on it over the years and my personal involvement in it:

Dave Hull and George F Willard III publish a paper on it from their research at KU.
Feb 2005 - http://kuscholarworks.ku.edu/dspace/bitstream/1808/584/1/NGDHCP.pdf

Many small spinoff programs start up based on the POC code and info.

March 2005 - I'm sitting in Iraq and find out about it myself for the first time looking through packets with no idea of the paper published the month before.  I was stoked when I first found out about using this technique and was a bit crushed when I found I wasn't the first to have found it.

I publish a general paper on OS fingerprinting and start discussing DHCP fingerprinting in more detail
August 2005 - http://chatteronthewire.org/download/OS%20Fingerprint.pdf

Sometime over the next two years I start working with David LaPorte from the PacketFence project to see if we can get something together to talk about DHCP fingeprinting at Blackhat.  We eventually get accepted to present it at BH Japan in 2007:
July 2007 - http://chatteronthewire.org/download/chatter-dhcp.pdf
October 2007 - http://chatteronthewire.org/download/bh-japan-laporte-kollmann-v8.ppt

During the last of my research I found indications that everyone listed so far was at least 2 years behind on this idea when we started talking about it in 2005 since there was a group out of Japan in Feb 2003 that published something on it!  Though I never found a translated copy on it at the time, you may be able to order a copy in Japanese here:
"New scheme for passive OS fingerprinting using DHCP message" - Joho Shori Gakkai Kenkyu Hokoku, Feb 2003!

Since 2007 many large companies have finally gotten onto the band wagon of DHCP fingerprinting which I'm glad to see.  It has taken 10 years since the first papers I'm aware of and at going on 6 years after the BH 2007 event which seemed to generate a lot of interest.  I know this since I had calls and some emails from at least one very large company now doing it and many small companies over the years.

I'm hoping that this patent doesn't cause any issues in the world of using DHCP fingerprinting for OS identification, but only time will tell.

Infoblox, new player in the DHCP fingeprinting world

I got a new Google Alert yesterday on "DHCP Fingerprinting", hadn't had much traffic on it in quite awhile now. 

The notice I found was here.

I'll admit I know nothing about this company, though I did like their writeup on DHCP Fingerprinting.  It is only 2 pages long, so short and to the point, covering what most upper management needs.  What their writeup I assume they are only doing Option 55 fingerprinting.

With that said though I did find the original writeup a bit funny.

"With the new Infoblox DHCP Fingerprinting technology, network administrators can see device type information - such as iOS or Android devices, an Xbox, or a Linksys router -"

New?  Did they say new?  I presented on this in 2007 and a few people, myself included were discussing it as early as 2005.  So while it may be new for them, this is by no means new technology!

Ok, all of that aside, it is cool to see another company using it. 

File updates to go with site change

I've been quite happy with the quick turn around that those that are using or have links to Satori have been able to update blog posts, urls, and in this case a program to the new url.  I'm still waiting for some people to get back to me, but little by little it will get taken care of.
 
Jeff updated his two programs that point to my website to grab fingerprinting files.  They can be found/download here:

DHCP Fingerprint Manager

http://cycocrew.pagesperso-orange.fr/delphi/applications.html#DHCPFingerprintManager

http://cycocrew.pagesperso-orange.fr/delphi/DHCPFingerprintManager-1.00.09-Setup.exe

Fingerprint Editor

http://cycocrew.pagesperso-orange.fr/delphi/applications.html#FingerprintEditor

http://cycocrew.pagesperso-orange.fr/delphi/FingerprintEditor-1.00.11-Setup.exe

 

Update

So my ISP decided to stop offering web hosting.  It wasn't great to start with, but it was free and is where my programs and papers have been hosted for 10+ years so I was a little sad to see http://myweb.cableone.net/xnih go away.  It is out there in many news groups and many posts over at least the last 7-8 years of posts, but oh well.

I purchased the name chatteronthewire.org as it was a name I've used for a lot of other things, this blog included, so I figured it made sense.

In looking for locations on the net, that I had access to post info at least, I began searching for where I could and found http://myweb.cableone.net/xnih all over the place.

The nice thing about that, found 3 different articles where either I'm mentioned or Satori is that I didn't know about.

Starting with 2009, I believe a russian magazine.  They are actually talking about NetworkMiner, but there appears to be a link to Satori.  Page 39 here at xakep. (if there is anything bad about the site or anything else, my apologies!)

Late 2012, December time frame a Gold paper for SANS for his GCIA.  "What's running on your network?  Analyzing pcap data with tshark".  My only complaint, my name is misspelled as always :) But it can be found here.

And the 3rd one I found was an article in INternation Jounal of Computer Applications from Feb of this year.  "Investigation of DHCP Packets using Wireshark".  My last name got hosed again, but I'm quite used to it these days!  This paper can be found here and I was just a reference.

Can't say I've read either of the 2 papers there yet, but guess that will be this weekends project.