After a day of supporting First Lego League as a judge (lotta fun!), I was delighted to see an early release of next week’s WiCys cyber challenge. The title is ‘Wireshark doo dooo do doo’ and it’s only a 50 point challenge, so I was expecting a not too difficult exercise in finding things in a network traffic file.

Not too difficult is right. After checking the file properties (and importantly, looking at the comments, as well as doing a quick search in the text of the file for the flag format of picoCTF – hey, easy finds are still points!), I looked through what the file’s protocol hierarchy said it held. Mostly HTTP, with a little bit of line-based text data. Let’s start there.

Results: two packets that returned text/html or text/plain data. The line-based text data one has a syntax that looks a lot like a flag: foo{morecraziness}.

I tried using CyberChef’s Magic decryptor, without success. I even tried telling it what I expected the first bits of the text to be (“The flag is picoCTF”) – stil no dice. I then tried an online substitution cypher breaker I’ve used before: https://www.dcode.fr/rot-cipher. In this case, the first thing it returned in its long list of possibles was ROT13, with text that said THEFLAGISPICOCTF. OK, that’s my likely winner. I went back to CyberChef and used its ROT13 recipe, figuring it’d better handle upper/lower, numbers, etc. Bingo. Flag in hand, all w/in ~15 minutes.

Going to have find some more interesting puzzles for the rest of the week…

Notes from this week’s CTF – geek notes for Tina. Should have collected notes on more challenges, but, eh…

Received a PCAP file that said it had secret coordinates in it. PCAP was completely USB traffic, specific URB_INTERRUPT

  • https://wiki.osdev.org/USB_Human_Interface_Devices#USB_keyboard
  • Isolated traffic for appropriate device, after examining device descriptor response to find keyboard
  • Started mapping out the HID keys by hand, until a teammate suggested https://github.com/TeamRocketIst/ctf-usb-keyboard-parser
  • Ultimately used tshark to extract the data, via tshark -r ~/Downloads/file.pcap -Y 'usb.device_address == 2 and usb.data_len > 0 and !(usbhid.data == 00:00:00:00:00:00:00:00)' -T fields -e usbhid.data | sed 's/../:&/g' | sed 's/^://g' > keys.txt
  • (Note: the second se is because the recommended one ended up prefixing all the lines with : – second sed strips it off)

My masters class had us writing Yara rules for our project lab. Given that I recently gave a talk at DataWorks MD that took a brief foray into describing the use of Yara rules for static malware analysis – well – I was prepared for and looking forward to this particular lab.

The challenging part of the lab: to help us understand how analysts decide which byte(s) to check for hex strings, the lab had use the Linux utility, hexeditor. As instructed, we were to

  • sudo hexeditor
  • use the keyboard’s arrows to navigate into a particular file
  • press Ctl-W to invoke ‘search’
  • use the arrows to navigate to the hex search option, as opposed to text search
  • type in the appropriate hex string. Note: the hex string could be longer than the editor would show us in its entry window. With a long enough string, we were then working blind with typos
  • if the hex string was found, jot down at what byte position so that we could later use that in our Yara rules

Bleah… Too many opportunities for typos. Too slow, as we needed to iterate across five files. _Really_ too slow when you consider we were doing this in a VM hosted on university infrastructure, using its GUI via NoMachine.

Improvement 1: sudo hexeditor filename at least got me into a particular file, and importantly, let my file history show me what files I had already interacted with.

I then looked for command-line options to target hexeditor with a search string. That would at least let me repeat previous commands and edit the filename or the hexstring. Unfortunately, hexeditor doesn’t support anything of that sort. grep would apparently have gotten me to whether the pattern existed in the file, but not given me the byte location.

Long-ish story short, although the lab itself had no reason to cause me to do this, and it certainly took me longer to work this out than to just hand jam it, I now have scripts to iterate over a set of files and a set of hex strings to determine if the hex string is represented in the files, and if so, where. My geek demon is satisfied this evening, and I’m holding onto the files here to help in CTFs or other future geekish fun. Credit to here for the general approach for finding hex data locations in files, and here for helping work out the problem of iterating over lines that contain spaces.

#!/bin/bash

# test_hex_find.sh
# Examine file for hex value
# Argument 1: file name to check
# Argument 2: hex string to look for

position=$(od -v -t x1 $1 | sed 's/[^ ]* * //' | tr '\012' ' ' | grep -b -i -o "$2" | sed 's/:.*//')

if [ ! -z "$position" ]
then	
  position=$(( position/3 ))

  echo "filename: $1, hex value: $2"
  printf '%06X\n' $position
fi
#!/bin/bash

# find_hex.sh
IFS=$'\n' hex_strings=( $(xargs -n1 <hex_strings.txt) )


for hex_string in ${hex_strings[@]}; do
	echo $hex_string
done

for file in *.exe; do
  for hex_string in ${hex_strings[@]}; do 
    ./test_hex_find.sh $file "$hex_string"
  done
done
"C6 45 F4 74 C6 45 F5 6C C6 45 F6 76 C6 45 F7 63 C6 45 F8 2E C6 45 F9 6E C6 45 FA 6C C6 45 FB 73"
"8A 04 17 8B FB 34 A7 46 88 02 83 C9 FF"
"5C EC AB AE 81 3C C9 BC D5 A5 42 F4 54 91 04 28 34 34 79 80 6F 71 D5 52 1E 2A 0D"