We’ve found an encoder board using double 74HC161s along with a binary file.
Please help us to decode it.
The problem can be downloaded at https://github.com/SECCON/SECCON2015_online_CTF/tree/master/Binary/500_Reverse-Engineering%20Hardware%202.
Given an APK file.
I first installed this app in my Android phone. It has three screens.
It’s time to decompile the app. Use apktool, dex2jar, jad as usual. My tool apkext came in handy.
From AndroidManifest.xml, we find that the entry point activity is kr.repo.h2spice.yekehtmai.MainActivity. The program is obfuscated via name substitution.
Given an ELF binary putskey and a text file log.txt. As the title suggests, log.txt is a remote GDB command log.
The binary is simple. It reads two inputs, flag and enc using getc() into buffers in .data section. Then it xors two string into enc, and prints the result. But we don’t know the data.
The location of first input buffer is flag: 0x80d7300 ~ 0x80d7340. Second input buffer is located at rnd: 0x80d7340 ~ 0x80d7380. Resulting data are stored at enc: 0x80d7380 ~ 0x80d73c0.
Remote GDB protocol is throughly documented at https://sourceware.org/gdb/onlinedocs/gdb/Overview.html and https://sourceware.org/gdb/onlinedocs/gdb/Packets.html.
First I focused on memory read command (m) because data are written in fixed locations. From this, content of rnd could be recovered:
65 6f 26 02 13 06 25 60 34 0b 27 3b 78 3a 26 00 39 4a 46 5d 3d 5e 58 36
Content of flag and enc did not appear in memory read commands. Instead, I found many repetitive breakpoint, continue and register (g) read command. I extracted eax of every register read command, hopefully contains the return value of getc(). Among bunch of numbers, I found the data that looks like flag.
36 2a 65 41 5c 48 5e 28 51 67 4b 54 3f 7e 64 50 4b 25 32 32 5e 31 34 4b
The answer is xor of two strings. SECCON{HelloGDBProtocol}.
Execute all ELF files
We are given 11 ELF binaries, for all different architectures.
$ file *
10.bin: ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped
11.bin: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
1.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, stripped
2.bin: ELF 32-bit MSB executable, MC68HC11, version 1 (SYSV), statically linked, stripped
3.bin: ELF 32-bit LSB executable, NEC v850, version 1 (SYSV), statically linked, stripped
4.bin: ELF 32-bit MSB executable, Renesas M32R, version 1 (SYSV), statically linked, stripped
5.bin: ELF 64-bit MSB executable, Renesas SH, version 1 (SYSV), statically linked, stripped
6.bin: ELF 32-bit MSB executable, SPARC version 1 (SYSV), statically linked, stripped
7.bin: ELF 32-bit LSB executable, Motorola RCE, version 1 (SYSV), statically linked, stripped
8.bin: ELF 32-bit LSB executable, Axis cris, version 1 (SYSV), statically linked, stripped
9.bin: ELF 32-bit LSB executable, Atmel AVR 8-bit, version 1 (SYSV), statically linked, stripped
There are number of ways to deal with this problem
The tutorial says we can record a webcam video with following code. (which doesn’t work)
#include <opencv2/imgproc/imgproc.hpp>
#include <opencv2/highgui/highgui.hpp>
int main()
{
VideoCapture capture(0);
int w = capture.get(CV_CAP_PROP_FRAME_WIDTH);
int h = capture.get(CV_CAP_PROP_FRAME_HEIGHT);
int fps = 30;
VideoWriter writer("out.mp4", CV_FOURCC('X','2','6','4'), fps, Size(w,h), true);
Mat frame;
while (true)
{
capture >> frame;
writer << frame;
imshow("frame", frame);
if (waitKey(20) == 27) break;
}
}
It doesn’t work on default OpenCV library for OSX. The program runs without error, but produces an empty file. I tried to change the fourcc values into 'M','J','P','G' and change the extension to .avi or even set fourcc to -1. But all these tries didn’t work.
According to a Stackoverflow Thread OSX version of OpenCV does not have a working video writer. Ouch! Instead, this thread suggests me another way.