> You're given a spec resembling Chinese for a proprietary image
> protocol. Study the attached example images to discover the flag in
> the captured transmission.

Not all reverse engineering tasks are about booting IDA and staring at
disassembly.  This one can be solved by looking for patterns and
figuring out what they mean.

The textual spec is almost completely useless.  It looks like a
Markdown document with garbled text containing hexadecimal number
literals here and there.  Naturally the text doesn't translate to
anything meaningful, but at least there are longer blocks of hex
literals with some garbled text sprinkled in them, like this one:

    0x01 0xff
    0x02 0xff
    0x03 0x01
    0xff 0x00 ; 侸喽 军廎 十呿 侙壌 1

Looking at the other files there's a binary file accompanied by at
least one PNG file.  Perhaps these show snapshots of the image
transmission?  Let's look at the contents of `0x00.bin` using a hex
editor:

    00000000: 01ff 02ff 0300 ff00                      ........

Pretty boring.  Eight bytes for a blank image.  But wait, these bytes
have been mentioned in the spec, so perhaps it's explaining each
binary?  Let's check out `0x01.bin` next:

    00000000: 01ff 02ff 0300 ff00 0301 ff00 0302 ff00  ................
    00000010: 0303 ff00 0304 ff00 0305 ff00 0306 ff00  ................
    00000020: 0307 ff00                                ....

That's more interesting.  The first eight bytes are the same.  After
that we get a steadily increasing sequence of `030xff00`.  There's
eight of them in total which corresponds to eight PNG files.  Again
this matches a section in the spec which lists the bytes in a nicer
format:

    0x01 0xff
    0x02 0xff
    0x03 0x00
    0xff 0x00 ; 巫乸 墰扉 奓夗 嶛儗 0
    0x03 0x01
    0xff 0x00 ; 媑寤 串勸 嬂囎 嫒厏 1
    0x03 0x02
    0xff 0x00 ; 亙慞 乹扚 慨岊 徿彃 2
    0x03 0x03
    0xff 0x00 ; 劳啈 仜姈 抻人 婚处 3
    0x03 0x04
    0xff 0x00 ; 扒廊 傋打 徬壸 崍应 4
    0x03 0x05
    0xff 0x00 ; 届嬎 怺壙 徾屻 佡垫 5
    0x03 0x06
    0xff 0x00 ; 尗彟 嫣拮 嫡峒 偢嫚 6
    0x03 0x07
    0xff 0x00 ; 奥嫄 剁峓 垔佴 嘔偬 7

Each text snippet refers to a PNG file, that's for certain.  It's a
bit unclear what the `ff00` sequence does though, is it performing a
snapshot?  The text snippets reference the steadily increasing
number.  Since the only difference between the PNGs is the color, it's
a safe bet that the numbers refer to a color in a palette.  `030x` is
therefore the sequence for setting the color.  Let's check out the
next example in the spec (since the binary is going to look the same):

    0x01 0x80
    0x02 0x80
    0x03 0x00
    0xff 0x00 ; 侴当 屳亪 0|0 俸徙 佳姅 仁拴 0
    0x04 0x80
    0x05 0x80
    0xff 0x00 ; 嬻庇 句崁 1|1 互嚒 廉廙 嵌壻 唝哠
    0x03 0x01
    0x04 0x00
    0x05 0x80
    0xff 0x00 ; 嗉决 塟弸 0|1 忆噑 峭宴 廗习 1
    0x04 0x80
    0x05 0x00
    0xff 0x00 ; 巸俴 偄廳 1|0 岰凥 唔妨 崏坾 惰兰

Another interesting pattern is that each sequence is two bytes, with
the first byte denoting the type of the action and the second byte
being an argument of sorts.  This example shows that `01xx` and `02xx`
can be called with something else than `ff` as argument, for instance
`80` which happens to be half of `ff`.  Two new actions are
introduced, `04` and `05`.  Since this example shows images where half
of it is colored, my guess would be that they are about width, height
and coordinates of the rectangles.  Maybe the next example will clear
this up:

    0x01 0xff
    0x02 0xff
    0x03 0x00
    0xff 0x00 ; 圔剛 個愗 嘠伩 喷弟 0
    0x01 0x08
    0x02 0x10
    0x04 0x58
    0x05 0x58 ; 傻夌 匎偯 夡岹
    0x03 0x02
    0x07 0x40
    0xff 0x00 ; 完垐 崒侫 #1 世僸 僎嫧 台伝 2
    0x03 0x03
    0x09 0x40
    0xff 0x00 ; 吜冭 嚁壣 #2 儼尹 嘏囄 庝忷 3
    0x03 0x04
    0x06 0x40
    0xff 0x00 ; 婧尗 亶後 #3 庌倊 堝嗡 慲懶 4
    0x03 0x05
    0x08 0x40
    0xff 0x00 ; 唩左 伃帋 #4 壺伻 戴咼 囷哼 5

This one does indeed clear things up. `01` sets the width and `02` the
height of the rectangle.  This explains why it's the first thing to
happen, first of all the background of the image is painted.
Likewise, `04` and `05` are about the coordinates.  They aren't used
to paint the colored dots though, for this `06`, `07`, `08` and `09`
come into play.  They appear to do relative movement, each by 64
(`40`) pixels.  As that's the distance between the colored dots and
they appear counter-clockwise, it's safe to assume they correspond to
the four directions.  Finally, `ff` isn't about creating a snapshot,
but drawing a rectangle.  The protocol first specifies how the
rectangle looks like, then paints one.

Armed with that knowledge it's not too hard to recreate the PNGs from
the binaries.  Your script should look roughly as follows:

    while not bytes.eof():
        action, argument = bytes.read(2)
        case action:
            0x01: width = argument
            0x02: height = argument
            0x03: color = argument
            0x04: row = argument
            0x05: column = argument
            0x06: row -= argument
            0x07: row += argument
            0x08: column -= argument
            0x09: column += argument
            0xff: draw(width, height, row, column, color); prtscr()

Test it with the example binaries first, then use it on the challenge
binary.  It will print lots of screenshots which look like an
animation of morse symbols.  Decoding these gives you numbers in the
ASCII range, decode them again and you get the flag.