第９回 COFFオブジェクトファイルの解析（３）
アセンブラの概形もできたので
こちらの解析を行いましたー。
えーと、こちらには２つの構造体がありましてー
typedef struct _IMAGE_SYMBOL {
union {
BYTE ShortName[8];
struct {
DWORD Short; // if 0, use LongName
DWORD Long; // offset into string table
} Name;
DWORD LongName[2]; // PBYTE [2]
} N;
DWORD Value;
SHORT SectionNumber;
WORD Type;
BYTE StorageClass;
BYTE NumberOfAuxSymbols;
} IMAGE_SYMBOL;
typedef struct IMAGE_AUX_SYMBOL_TOKEN_DEF {
BYTE bAuxType; // IMAGE_AUX_SYMBOL_TYPE
BYTE bReserved; // Must be 0
DWORD SymbolTableIndex;
BYTE rgbReserved[12]; // Must be 0
} IMAGE_AUX_SYMBOL_TOKEN_DEF;
それっぽいのをwinnt.hから探すだけの簡単なお仕事です（泣）
ちなみにセクションでない場合はIMAGE_SYMBOL１つだけでいいみたい。
というかIMAGE_AUX_SYMBOL_TOKEN_DEF構造体は、IMAGE_SYMBOLのNumberOfAuxSymbolsで数を指定できるみたい。
なんとなくで分かってくれ（切実）
ち～～～ん（笑）
名前が８文字より長いシンボルは
シンボルテーブルの後ろに文字を書くスペースがあって
そこへのポインタを書くのかしら
っていう
あと、textセクション本体の最後に書いてあるシンボルテーブルっていうのは
リロケーション＝再定義なんとか？で
この構造体を使ってるみたい。
typedef struct _IMAGE_RELOCATION {
union {
DWORD VirtualAddress;
DWORD RelocCount; // Set to the real count when IMAGE_SCN_LNK_NRELOC_OVFL is set
} DUMMYUNIONNAME;
DWORD SymbolTableIndex;
WORD Type;
} IMAGE_RELOCATION;
わかったよーなわかんないよーな(´・ω・｀)
この構造体の数はセクションヘッダのnumber of relocationsで指定するのか‥‥めんどい
けど機械語には区切りっていうものがないから、こういう長さのデータも書かなきゃいけないという。
ところで
ところで
ところで
わ・か・ら・ん☆
これ、ネットで調べたら
なーんかCodeViewみたいなのを使ってるらしい。
なので
その線でいろいろ調べたけどわかんない(´・ω・｀)
.debug$Sセクションであることは分かったけど
資料見ても項目はあったのに何も書いてないよヽ(｀Д´#)ﾉ
textセクション本体の後にあるdataセクションで
文字列なんとかいろいろ定義した後に
debug$Sセクションがきてるわけなんですが
04 00 00 00 F1 00 00 00 6E 00 00 00 33 00 01 11 00 00 00 00
こちらーがー問題の機械語となってるわけですが
それっぽいのを見つけてきた（dbgHelp.h）
typedef struct _MODLOAD_DATA {
DWORD ssize; // size of this struct
DWORD ssig; // signature identifying the passed data
PVOID data; // pointer to passed data
DWORD size; // size of passed data
DWORD flags; // options
} MODLOAD_DATA, *PMODLOAD_DATA;
けど
これ、サイズ的には合ってるけど
なんか違和感がするんですーするんですー
そもそも構造体の名前からしてアレ。
困ったなぁー
とりあえず機械語を適当に分解すると
04 00 00 00
F1 00 00 00
6E 00 00 00
33 00 01 11
00 00 00 00
になるのかしら。
これ、test64.objの話ですが
いろいろあってたまたま「test64_2.obj」を作ったら
その中にはこう書かれてました。
04 00 00 00
F1 00 00 00
70 00 00 00
35 00 01 11
00 00 00 00
となっておりますが
もしも先ほどの構造体でおｋだとしたら
この構造体の直後にオブジェクト名の絶対パス名が書いてあったので
test64.objとtest64_2.objとじゃサイズが２つ変わっちゃうわけですよ。
なのでdataとsizeメンバの説明ができ‥‥るかなぁ。
気になるのが
35 00 01 11のあたりかなぁ。
上位（なのか？リトルエンディアンでこう呼んでいいのか？）の01 11
これが何を意味するのか
これを読んだあなた、どうか真相を暴いて下さい。
それだけが私の望みｒｙ
実はここ、dumpbinでも解析されないorz
どうすりゃいいってんだよこれ(´・ω・｀)
もう１つ気になるのがですね
このdebug$Sセクションの終端が
6E 00 00 00の次のアドレスに6Eを足したものと一致するんですね。
構造体の終端でも先頭でもなく、6E 00 00 00という一変数の終端のアドレスが
基準になっているって
なんかおかしくありません？
そもそもこれは構造体ではないとか
２つの構造体で成っているとか
考えられるわけですが
もう１つ過程を。
33 00 01 11はDWORDではなく
33 00のWORD？かな？という。
少なくとも33 00っていうのは
この後にあるobjファイル名の文字列の長さを表していると思うんですが
その後の01 11から計算を始めると
アドレスを33進めたらオブジェクトファイル名終端のNULL文字と一致するんです。
01 11を入れずにその後の37 00を含むべきかも難しいところですし
オブジェクトファイル名の前の01 11 00 00 00 00が
何を表すかも不明ですし。
全然わかんないですし(´・ω・｀)
誰か‥‥誰か資料を僕にくれるんだ‥‥！
※つ・い・き☆
04 00 00 00 → ４バイト後の6E 00 00 00、間接的に次のセクションの先端を指している？
F1 00 00 00 → 終端のアドレス+F1が、シンボルテーブルにおける.dataセクションのアドレスと一致
01 11 00 00 00 00 → 知らんがな
