Logger

ファイル logger.pcap が与えられた。

Wiresharkで開いてみると、Leftover Capture Data と表示された意味ありげなデータの前に同じデータ列があるようだった。
そこで、この同じデータ列をキーとして、以下のプログラムでデータを抽出した。

A file logger.pcap was given.

Opening with Wireshark, there were some data marked as "Leftover Capture Data", which looked meaningfull, and some fixed sequence of data before that.
I extracted the data via this program using the fixed sequence:

get_data.pl

これはUSBキーボードが送ってくるデータであると予想した。
USBキーボードは、キー情報を格納する場所が固定長のプロトコルの関係でNキーロールオーバーができなかったはずである。
このことを踏まえて抽出したデータを見ると、8バイトずつのデータのうち、最初の2バイトが状態、残りの6バイトがキーの情報であると推測できた。

MikanOSがUSBキーボードからの入力に対応していたことを思い出したので、 MikanOSのコードからUSBキーボードのデータを文字に変換するためのテーブルを拾ってくることにした。
キーの情報のテーブルはkernel/keyboard.cppに、 状態のテーブルはkernel/keyboard.hppにあった。
これらの情報を利用し、以下のプログラムでデータを文字列に変換した。

I guessed that this is data from an USB keyboard.
I heard that USB keyboards cannot support pressing all lkeys at once because the protocol uses fixed-length buffer to transfer information of keys pressed.
Looking the extracted data with this assumption, in the chunk of 8 bytes, the first 2 bytes looked like the status and the left 6 bytes looked like the pressed keys.

I remembered that MikanOS supported reading input from USB keyboards, and decided to get some tables to convert data from USB keyboards to characters from the source code of MikanOS.
The table to convert the keys was in kernel/keyboard.cpp, and the table to convert the status was in kernel/keyboard.hpp.
Using the tables, I used this program to convert the data into a string.

convert.pl

結果は以下のようになり、flagが含まれていた。

This is the result. The flag was in this result.

One popular but unverified explanatinon for the QWERTY arrangement is that it was designed to reduce the likelihood of flag{QWE_keyb0ard_RTY} internal clashing of typebards by placing commonly used combinations of letters farther from each oher inside the machine.
flag{QWE_keyb0ard_RTY}

setodaNote CTF