 |
| A lof of work has went into these... and protecting our countries from harm |
This looks a lot nicer at https://www.linkedin.com/pulse/exploring-text2pcap-hidden-message-my-sec503-challenge-jb-/ please follow me as well on LinkedIn if you're involved in the industry & read this post from there..
Recently I've read some really nice research surrounding pcaps, the first two that come to mind are on adding comments to the pcap-ng file format from Xavier Martens (@xme), and from Erik Hjelmvik's NetReSec blog (@netresec), most recently on Anti-virus scanning of pcap files.
Along these same lines I'd like to look into the various small programs that come with the Wireshark bundle, experiment with it on OSX, instead of linux, just for kicks, and then focus-in on one component, text2pcap [spoiler alert I wonder what it does] which for an example I've recently used it to decode the numbers surrounding my SANS 503 coin.
One reason this all came about is because as I was studying for the GCIA exam I had the coin out as kind of an encouraging factor, and realized I'd never looked into this code around the edges. There is only one prominent post on google (just a twitter comment about this, from the coin's invention), which I've linked to at the bottom of the post, which without going down a CTF-rabit-hole, I assumed this was an IP packet header and payload, in hex, starting with "045..," in other words ip version 4, and 5x[16-bit/4 legacy word length] = 20 byles IP-header length, in the first two nibbles. If you're wanting to get a head start on that part of the write-up here, the hex is "45 00 00 28 00 01 80 00 40 06 14 02 53 45 43 20 20 35 30 33 20 4A 55 44 59 44 41 56 45 41 4E 44 59 50 02 20 00 FA 38 00 00." I did make sure this was publically available online, before writing this and giving away the secret ip address of the online coin-holders secret skull-club lair (likely not hidden in, at least this,coin... maybe that's in the 760 coin as pictured in the header of this blog post.)
Secret Messages in coins
You really should read the following blog post from Ed Skoudis of Sans, which he credits all of those whom I mentioned in the title for writing, passionately, "over a year's work," about the history of using the military-reward-style "challenge coins" for the various Sans challenges and end-of-the-week activities during courses; so if you've never read that post from the penetration testing blog of Sans, from a few year's back, here it is.
The concept of secret messages in coins, is not new, for a quick review see for example Codebreaking and Numismatics (cointalk blog) in regards to the The Imitation Game about Alan Turing and the cryptanalysts at Bletchley Park, and as well this post re the secret code embedded on the Queen's face on new £1 coin. The Sans coins may be the first to include potentional packet hexidecimal messages.
Naturally, since I was neck-deep in packets, and really enjoying studying up on the structure of various packet types, I wanted to decode this message by hand, here was the start of my notes before it got wild...tcp/ip packet, linux ttl-style (0x40), with a 20 byte reported payload. ..looking at the 10th offset (*checksum, which i had previously often forgotten) and forward, (hexa. 1402 ....) = header, checksum must equal 5122: not going to check that :-) offsets 12-15 source, 16-18 dest. ipv4 addressing is what might be interesting for further decoding ..below.. *interesting also is the ”8” in the fragment (reserved bit) w/o 000 correctlyry cute* at offset 52, “8” 0x38 creating the ascii number 8 (ascii code 56, in decimal)
This quickly would have led me to scan a computer in Russia for more clues, as the source IP starting at offset 13 decoded to (see my notes below)--you can also see the first clue, that if you add the text2pcap -a option (filter out ascii text), it mangles the 2nd address, which was not mapping via whois to a direct target, anyway. You can see I was already headed a bit too deep in to the mystery:
“source” 0x5345 4320 = binary address 83.69.67.32
“dest. 0x2035 3033 = binary address 32.53.48.51 (32.53.0.0 if you use the -a option to filter ascii text out of the packet ):)
interesting concept as well, “destination”. // who is the secret message for >-)
if it is not our destination . is that a code within a code perhaps...
...
whois output of source of this packet, with a destination of AT&T in the USA:inetnum: 83.69.64.0 - 83.69.95.255 netname: RU-TRANSTELECOM-20040526 country: RU abuse-mailbox: abuse[at]ttk.ru person: Evgeny A. Zhdanov address: 2a Vitebskaya st. address: Nizhny Novgorod lol
In fact, at one point investigating the tcp segment tcp[2:2], the destination port, I even had looked up the port on the Storm Center and somehow noticed this even some hidden messages there! So let's "do not hack"... stay on track!:
Confirmation with Wireshark
This and the spoiler from the twitter post, led me to understand the "code," was probably simpler than it seemed. I turned to google and learned then that text2pcap was part of Wireshark. I was really impressed by the package created by the Wireshark communityfor installation on OSX. Even though I had used Wireshark and TCPdump a lot in the past, I had used them on various Linux hosts, and wanted to get it also on a Mac which I use quite a bit. There was very extensive documentation of exactly how to remove every single file that was installed to your host during the install, and this is very rare in OSX installer packages! So nice! The program also works mostly nicely; I did remove their Launch Daemon so that it would not run on my system start; which is needed to expedite captures (I only wanted to use it for analysis, sometimes). This may have caused a few crashes. It also did not correctly integrate the man pages, so that would be a downside of OSX v. Linux Wireshark. Maybe you just have to access them manually, or the paths will work after a reboot.
I didn't see a list of all the components, but here is a nice list which I got from the Windows installation website of Wireshark--all of the following gets installed when you install Wireshark--you will notice text2cap, which we will briefly dive into, next:
Wireshark - The network protocol analyzer that we all know and mostly love.
TShark - A command-line network protocol analyzer. If you haven’t tried it you should.
Wireshark 1 Legacy - The old (GTK+) user interface in case you need it.
Plugins & Extensions - Extras for the Wireshark and TShark dissection engines
Dissector Plugins - Plugins with some extended dissections.
Tree Statistics Plugins - Extended statistics.
Mate - Meta Analysis and Tracing Engine - User configurable extension(s) of the display filter engine, see https://wiki.wireshark.org/Mate for details.
SNMP MIBs - SNMP MIBs for a more detailed SNMP dissection.
Tools - Additional command line tools to work with capture files
Editcap - Reads a capture file and writes some or all of the packets into another capture file.
Text2Pcap - Reads in an ASCII hex dump and writes the data into a pcap capture file.
Reordercap - Reorders a capture file by timestamp.
Mergecap - Combines multiple saved capture files into a single output file.
Capinfos - Provides information on capture files.
Rawshark - Raw packet filter.
User’s Guide - Local installation of the User’s Guide. The Help buttons on most dialog windows will require an internet connection to show help pages if the User’s Guide is not installed locally.
I had previously used also mergecap as a lifesaving tool!
Text2pcap usage
Next using a man page I found online on a Linux website for text2pcap, I learned that you can create file for input with the following format. The last byte must either be followed by the expected next offset value e.g. here would be 00003A or a space or a line-end character(s). Here I've used 00002A since there are 9 values in the last row, the next expected offset would be the 10th [not counting from 0, but 1], which is 0xA in hex, and 0x2A in context of where it lies in my text file. It does not matter to text2pcap where you cut off the lines of bytes as long as there are preceeded with hex row numbers with the correct values (mine are in 16's):000000 45 00 00 28 00 01 80 00 40 06 14 02 53 45 43 20 000010 20 35 30 33 20 4A 55 44 59 44 41 56 45 41 4E 44 000020 59 50 02 20 00 FA 38 00 00 00002A
Using the bash-style comment, you can include comments in your ,pcap's, but then they are not saved such as below, when you output to a .pcap-ng using text2pcap using the -n option (a comment from a pcap-ng file, like Xavier discussed in the blog I referenced at the top of this post:packet comments comment jb3 [Expert Info (Comment/Comment): comment jb3] [comment jb3] [Severity level: Comment] [Group: Comment] Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface
Similarly I'd like to point out that the packets are not identical, each time you make them even using the same file. I did several sha256 hashes of packets generated by text2pcap, so something in the binary conversion is causing this I assume.
Text2pcap understands a hex dump of the form generated by od -Ax -tx1 -v. In other words, each byte is individually displayed, with spaces separating the bytes from each other. Each line begins with an offset describing the position in the packet, each new packet starts with an offset of 0 and there is a space separating the offset from the following bytes. The offset is a hex number (can also be octal or decimal - see -o), of more than two hex digits.
There are a couple of other special features to note. Any line where the first non-white space character is '#' will be ignored as a comment. Any line beginning with #TEXT2PCAP is a directive and options can be inserted after this command to be processed by text2pcap. Currently there are no directives implemented; in the future, these may be used to give more fine grained control on the dump and the way it should be processed e.g. timestamps, encapsulation type etc.
Here are a few highlights of the options for texts2pcap:
-n saves using .pcap-ng instead of .pcap, as mentioned just above
-a (as noted earlier) zero out all probable ascii text from the input hex
-o specifies offset format (default is hex)
-e [ethertype/l3pid in hex] for example -e -e 0x806 to specify an ARP packet. 0x800 is ipv4
Last, but not least, after a short period of trial and error, I realized that since text2pcap was outputting complete datagrams and not just ip bytes (like the data from my coin was assumed to be) I had to include the network access layer ether type so text2pcap could simulate that part of the complete "packet." Luckily I had a complete printout of all layer 2 ethertypes, right at my side, in preparation for the GCIA exam :-) I also had a printout of the tshark man pages as well. My final command was:
text2pcap -n -e 0x800 [input text file of hex bytes] [output pcap]
Then I got the packet which could then be verified with the protocol analyzers to confirm the data I had begun analyzing by hand in the beginning.
(The total size including payload, of 0x0028, 40 bytes), including the 20 byte link layer that is the 60 output by text2pcap, is now correct:
Conclusion
You can see the results of breaking the code, below; and I'd like to also point out that a huge clue came when I noticed in the initial review that the tcp urgent flag was was not set, but the 8 value, was there in the pointer field (18:2). I'm not sure why that 8 was wanted, especially without the urgent flag; but when consulting an ascii table you can see that the hex value which creates the 8 is confirmed as well. Judy, Dave, and Andy - hey!
So after looking at this in wireshark, I realized that I should probably ignore the addresses, and really any other information, especially since I really just wanted to get back to studying by then :)
Here is a link to the twitter post I mentioned earlier, from when judy first introduced the coin. So a shout-out goes out to Annah Waggoner (@tootsierollpop8), who had previously quickly decoded the coin from the images Judy Novak posted on Twitter; I'll have to ping them all later and see how she converted this to ascii, and if she had also used text2pcap, or scanned any Russian isp's in the process!
Here is a final paste of the actual packet decode in tshark -nVr [pcap file], (I've used the output here instead from Wireshark because the formatting keeps getting dsestroyed when I paste it into blogger) ...by the way, on OSX also even though the -n (no dns lookup), and -e show link/network access-layer, -xx hex including link-layer, and -V verbose, basicially seems to just get ignored. It just dumps the same verbose output, similar to what you'd see in Wireshark; no matter what options you add in. :
You can see the final message , probably just ASCII forced into the packet... albeit with love... the SANS instructor names who were giving the course at the time, Judy, Dave, and Andy.
A special dedication goes out on this blog to anyone who's served in the armed forces; all our coins belong to you~
The 503 coin motto "Caveat Oppugnator" means basically 'Let the Oppressor Beware,' and this is the motto of at least the following groups of service men and women:
174 AIR DEFENSE ARTILLERY (174 ADA)
174 ARTILLERY
180 ANTI AIRCRAFT ARTILLERY
--
