xenepicbinary

[xenepicbinary]

zlibとして解凍してみる

前回は区切り文字の推測と，含まれているデータが78 01で始まっていることから，zlibで圧縮されているのではないかと疑った．

そこで，次の区切り文字までのzlib headerからチェックサムまでで別のファイルを作って，解凍を試みることにした．

いまはPerlよりもPythonがリバースエンジニアリングでは使われているっぽいので，WindowsにPythonを入れてみる．そして， zlib.decompress()　を実行．

解凍前のデータ長と解凍後のデータ長を表示してみると，どこかで見た数字が出てきた． C:\py>python test.py 5172 19144

改めてヘッダを見てみる． D7 17 32 01 C8 4A 00 00 34 14 00 00 01

先頭の４バイトは日付． 次の２バイトが，解凍後のデータ長だとわかった． 次の２バイトがＮＵＬＬ，たぶん区切り文字． 次の２バイトが圧縮時のデータ長． 次の２バイトがたぶん区切り文字． 次の１バイトは不明．

では解凍したやつをファイルに保存，バイナリを見てみる．

ビットイメージを見ると画像っぽいような雰囲気がある．

[xenepicbinary]

GMBMPの解析

datファイルの中で，まず手をつけたのが明らかにBitmapが格納されていそうなファイル名になっているファイルたち．この名前が付くファイルはいくつかあって，データサイズもdatファイルの中では一番多いことから画像であることが推測される．

まずStirlingを導入して，バイナリを覗いてみる． 読み取れる文字列は全然無い．１６進数を見てみよう． GMBMP.001とGMBMP.DDRは共通の４バイトから始まっているし，何度も出てくる．

D7 17 32 01

これが区切り文字ではないか？と予想． バイナリの世界では，だいたいリトルエンディアンなので0x13217d7を１０進数にすると 20060119.　日付っぽいぞ．

区切り文字の次にくるのが，ヘッダ情報． 区切り文字の次の４バイトは今のところよくわからない． 次の区切り文字まで何バイトあるかというデータサイズがほしい．

次にくる２バイトがまさにそれだった． 区切り文字の先頭～次の区切り文字の１つ前から１２バイト少ない数値だ． ということは，ヘッダサイズは１２バイトということになり，データ本体のサイズが判明．

次の２バイトは00 00で，よくわからない．

次の２バイトが78 01で，これをぐぐるとzlibという圧縮を使ったときのヘッダで出てくるものらしい．商用ソフトによく採用されている圧縮形式で，画像を主に圧縮するときに使われているそうだから，データ本体はzlibで圧縮されていることを疑ってみる．

+---+---+ |CMF|FLG| (2 bytes - Defines the compression mode - More details below) +---+---+ +---+---+---+---+ |     DICTID    | (4 bytes. Present only when FLG.FDICT is set.) - Mostly not set +---+---+---+---+ +=====================+ |...compressed data...| (variable size of data) +=====================+ +---+---+---+---+ |     ADLER32   |  (4 bytes of checksum) +---+---+---+---+

zlibのフォーマットはこんな感じになっているみたいで，区切り文字４バイト＋不明４バイト＋データサイズ２バイト＋不明３バイト（バージョン？）までが１２バイト．次にＣＭＦとＦＬＧらしき78 01が来る． どうやって解凍するのか？

こういうのは目grepともいうみたいです． https://www.slideshare.net/murachue/grep-8057239