資料

Microsoft PE形式ファイルおよびCOFF形式ファイルの仕様がわかるもの

• DJGPP COFF Spec

• Microsoft Portable Executable and Common Object File Format Specification

• Locreate: An Anagram for Relocate

• アレ用の何か - スタティックライブラリ関数の検出とフック

• Introduction to PE/COFF

osask(nask)でのWCOFF

nask内部処理

このあたりに実際の処理の記述がある

ヘッダ部分は140byte固定のようだ

• https://github.com/hangingman/osask/blob/29d1f0d8cdcd62a0700b4c362705bac025da9a0c/28GO/28GO_K/nask/Nasuka_sub.c#L2547-L2593

ボディ部分の出力

• https://github.com/hangingman/osask/blob/29d1f0d8cdcd62a0700b4c362705bac025da9a0c/28GO/28GO_K/nask/Nasuka_sub.c#L2661-L2836

WCOFFの中身

• 0 ~ 20byte: COFFのヘッダー
• 21 ~ 可変長: section table
  • .text
    • rawData: アセンブラの機械語を含む https://www.delorie.com/djgpp/doc/coff/
    • relocations: Relocation Directives https://www.delorie.com/djgpp/doc/coff/reloc.html
  • .data
  • .bss
• 36byte: PE auxiliary format 4: ファイル名を含む PE auxiliary format 4
• 36byte: 普通のシンボルテーブル: .text
• 36byte: 普通のシンボルテーブル: .data
• 36byte: 普通のシンボルテーブル: .bss
• 36byte: シンボルテーブル: COFF: Symbol Table
• 可変長: ストリングテーブル: COFF: String Table

naskのEXTERNシンボルの挙動

https://github.com/HobbyOSs/opennask/wiki/Opecode-CALL

• 下記のようなアセンブラを書くと、coffのrelocationに_inthandler27のエントリーが設定される

EXTERN  _inthandler21

xxx:
    CALL    _inthandler27

xxx:
    JMP    _inthandler27

• raw dataの開始をindex=0とすると、_inthandler21というシンボルの開始位置がrelocationのr_vaddr(virtual address)となる
• 下記の例の場合_inthandler27のvirtual addressは3となる(NOP, NOP, CALLのオペコードE8で3byte先にあって0-indexedなので3)

    14 00000000                                 _asm_inthandler27:
    15 00000000 90                                              NOP
    16 00000001 90                                              NOP
    17 00000002 E8 [00000000]                                   CALL    _inthandler27

• EXTERNで宣言されていないシンボルをCALLで使うと構文エラーになる

		GLOBAL	_asm_inthandler27
		;EXTERN	_inthandler27 コメントアウト

[SECTION .text]

_asm_inthandler27:
                NOP
                NOP
		CALL	_inthandler27

$ nask test.nas test.img test.lis
NASK : 1 errors.