SHA2017 writeups: Forensics : Samsung S4 (300)

Last weekend I participated in the SHA2017 CTF https://ctf.sha2017.org/ with my team HackingForSoju. We ended up at third place. Here are the writeups for the levels I solved.

Forensics: Samsung S4 (300)

A forensic investigator was wondering how hacker boxes like RIFF and Z3X use JTAG on a Samsung S4 phone while the main cores have debugging disabled.

The attached file was an archive with the file CTF_SamsungS4.csv, the contents of that file looked like:

Time, tms, tck, tdi, tdo 
0.000000250, 1, 0, 1, 1
0.000000500, 1, 1, 1, 1
0.000000750, 1, 1, 1, 1
0.000001000, 1, 0, 1, 1
0.000001250, 1, 0, 1, 1
0.000001500, 1, 1, 1, 1
0.000001750, 1, 1, 1, 1
...

TMS, TCK, TDI and TDO are the four mandatory signals in the JTAG protocol, and the logfile gives their logical levels over time. There are many tools to analyze logical signals, but I used sigrok and the GUI PulseView. https://sigrok.org/wiki/PulseView

The CSV-file could not be imported to sigrok right away, I had to remove the headers and timestamps:

grep -o ' .*' CTF_SamsungS4.csv | tail -n+2  > stripped.csv

When imported into pulseview, the data looks like this after naming the signals:

The data line TDI shows data going into the device, and TDO holds data that comes out of the device. Note that there is data at TDO between the samples 2500 and 4000. This seems to be an intresting point to look at.

I added a JTAG-decoder to decode what was going on.

The magenta bits indicate that the JTAG state machine is doing SHIFT-DR, the text labels don't show at this zoom level. The data on TDO is the previous content of the data register, we probably want to have a look!

There might be a more elegant solution to get the data out, but as CTFs are under time pressure I just added an extra SPI decoder with TMS as chip select to get the bitstream. Note that there are 35 bits in the SHIFT-DR section, so this width must be changed in the SPI decoder.

This CTF has made me recognize 'FLAG' when written in hex, but the byte order had to be changed:

>>> s = '67616c66 3061397b 39633565 33636134 37383365 33313931 31626130 66633333 31656662 7d38'
>>> ''.join([e.decode('hex')[::-1] for e in s.split()])
'flag{9a0e5c94ac3e38719130ab133cfbfe18}'
>>> 

SHA2017 writeups: Crypto : Stack Overflow (100)

Last weekend I participated in the SHA2017 CTF https://ctf.sha2017.org/with my team HackingForSoju. We ended up at third place. Here are the writeups for the levels I solved.

Crypto : Stack Overflow (100)

I had some issues implementing strong encryption, luckily I was able to find a nice example on stackoverflow that showed me how to do it.

The attached archive contained two files, encrypt.py and flag.pdf.enc.

encrypt.py:

import os, sys
from Crypto.Cipher import AES

fn = sys.argv[1]
data = open(fn,'rb').read()

# Secure CTR mode encryption using random key and random IV, taken from
# http://stackoverflow.com/questions/3154998/pycrypto-problem-using-aesctr
secret = os.urandom(16)
crypto = AES.new(os.urandom(32), AES.MODE_CTR, counter=lambda: secret)

encrypted = crypto.encrypt(data)
open(fn+'.enc','wb').write(encrypted)


This is not a good implementation, as every 16-bit block will be XOR-ed with the same key. It is enough to just know 16 bytes of plaintext to extract the key. The name of the encrypted file suggests that it in a PDF, wich has a predictable file header.

Here is the script I wrote to solve break the key:

# Input data as integers
data = map(ord, open('flag.pdf.enc').read())

# Plaintext, as integers
plain = map(ord, '%PDF-1.3 \n1 0 ob')

# Key is plaintext XOR:ed with ciphertext
key = [a^b for a,b in zip(plain[:16],data)]

# Decrypt and save
msg = [chr(a^b) for a,b in zip(key*len(data), data)]
f = open('flag.pdf','w')
f.write(''.join(msg))
f.close()

The contents of the decrypted file is an image with the flag and an important message:

Narrow test clips

Although not really a project, I recently bought a few test clips on Ebay, called "Universal Chip IC Test Clip Socket Adpter Programmer SOP SOIC TSOP MSOP SSOP" http://www.ebay.com/itm/381608877505

This was how they were advertised:

Ships with case and cables


Can connect to IC pins on a circuit board:


I paid 16 dollars for a set of 10 clips, shipping included. They arrived in less than three weeks.
The clips looked as advertised, although the cables smelled strange and the case felt cheap.

The instructions says that the clips are possible to use with one hand,
but I needed two hands to use them.
The one-handed grip does not seem to be nice to the cables.



It works fine to connect the clips to adjacent pins with 50 mil (1.27mm) pin spacing, but I would not try to connect to anything smaller than that and expect it to work.
This is an improvement from the the clips I've had previously, they are unwieldy for anything under 100 mil (2.54mm).
However, I doubt I could connect to a QFP64 package as advertised without causing  a short-circuit to the adjacent pins.