30日OS自作入門-4日目-
長くかかった3日目が終了し、これでやっとC言語を使った作業が行えます。
ということで早速はじめていきます。
今日のまとめ
4日目は画面表示がメインの項目になります。
画面表示をさせたい場合にはVRAMの領域に表示させたいものを記述させることで、OS起動時にVRAMを読み取って画面出力を行う、と言う流れです。
なので、今回やる内容としては
- OS起動時に画面表示を行う関数を作成
- 関数内で、「どういったものを画面表示させるか」を設定
ということになります。特にここではメモリのアドレスを意識してやっていく必要があります。
harib01a
3日目の最後に作成したharib00jのファイルに追記していく形になります。
まずは、nasmfunc.nasに画面表示用の関数と処理を定義します。nasmfunc.nasの中身は以下の通り
; File name : nasmfunc.nas ; TAB=4 [BITS 32] ; 32 bit mode machine code ; information for object file GLOBAL io_hlt ; function name that contains this program GLOBAL write_mem8 [SECTION .text] ; write this description at first io_hlt: ; void io_hlt(void) HLT RET write_mem8: ; void write_mem8(int addr, int data) MOV ECX,[ESP+4] MOV AL,[ESP+8] MOV [ECX],AL RET
write_mem8という関数を追加しています。
これ自体は、呼び出し元で設定された変数を読み出して各レジスタに格納している処理になります。
続いて、nasmfunc.nasで定義した関数を呼び出す側の方をみていきます。write_mem8を呼び出しているのはbookpack.cになります。
/* File name : bootpack.c*/ /* proto type declaration */ extern void io_hlt(void); extern void write_mem8(int addr, int data); void HariMain(void) { int i; /* 32bit integer */ for(i = 0xa0000; i <= 0xaffff; i++){ write_mem8(i,15); /* MOV BYTE [i],15*/ } for(;;){ io_hlt(); } }
write_mem8で設定されている引数はarg1=i, arg2=15となります。
arg1で設定されているiは、繰り返しによって値が0xa0000から0xaffffまで変化します。
arg2では固定値として15が指定されています。
結論から言うと、動作させた結果は以下の通り真っ白な画面が出てきます。
arg1の0xa0000から0xaffffの範囲は「画面表示させるものが記録されているメモリアドレス」でarg2の15が「実際に表示させるもの」になります。
で、15が画面の色で白を意味するので画面全体が真っ白になる、ということです。
ベースはわかったので、あとはちょいちょい値を変更していって画面の変化を観察していきます。
harib01b
今度はしましま模様を出します。変更する部分はbootpack.cのwrite_mem8に渡す引数部分です。
arg2で今度はiと0x0fのANDを取っています。
/* File name : bootpack.c /* proto type declaration */ extern void io_hlt(void); extern void write_mem8(int addr, int data); void HariMain(void) { int i; /* 32bit integer */ for(i = 0xa0000; i <= 0xaffff; i++){ write_mem8(i,i & 0x0f); /* MOV BYTE [i],15*/ } for(;;){ io_hlt(); } }
実行結果はこちら。
んで、このあとのharib01cからharib01eまではポインタの話がつらつら書いているだけなので飛ばします。
harib01f
harib01bとはちょっと色違いのしましまを出します。その際、harib01bとは異なり色番号を自分で設定します。
harib01bでコードを追加したbootpack.cに、さらに結構コードを追加します。
追加するコードは、自分で設定する色番号とそれに関連する関数になります。
/* File name : bootpack.c */ /* proto type declaration */ extern void io_hlt(void); extern void io_cli(void); extern void io_out8(int port, int data); extern int io_load_eflags(void); extern void io_store_eflags(int eflags); void init_palette(void); void set_palette(int start, int end, unsigned char *rgb); void HariMain(void) { int i; /* 32bit integer */ char *p; /* pointer */ init_palette(); /* setting palette */ p = (char *)0xa0000; /* set address of VRAM area */ for(i = 0; i <= 0xffff; i++){ p[i] = i & 0x0f; /* MOV BYTE [i],15*/ } for(;;){ io_hlt(); } } void init_palette(void) { static unsigned char table_rgb[16*3] = { 0x00, 0x00, 0x00, /* 0:black */ 0xff, 0x00, 0x00, /* 1:light red */ 0x00, 0xff, 0x00, /* 2:light green */ 0xff, 0xff, 0x00, /* 3:light yellow */ 0x00, 0x00, 0xff, /* 4:light blue */ 0xff, 0x00, 0xff, /* 5:light purple */ 0x00, 0xff, 0xff, /* 6:light water blue */ 0xff, 0xff, 0xff, /* 7:white */ 0xc6, 0xc6, 0xc6, /* 8:light gray */ 0x84, 0x00, 0x00, /* 9:dark red */ 0x00, 0x84, 0x00, /*10:dark green */ 0x84, 0x84, 0x00, /*11:dark yellow */ 0x00, 0x00, 0x84, /*12:dark blue */ 0x84, 0x00, 0x84, /*13:dark purple */ 0x00, 0x84, 0x84, /*14:dark water blue */ 0x84, 0x84, 0x84 /*15:dark gray */ }; set_palette(0, 15, table_rgb); return; /* static char operation is equals to DB operation */ } void set_palette(int start, int end, unsigned char *rgb) /*パレットのアクセスの手順にしたがって処理を行う*/ { int i, eflags; eflags = io_load_eflags(); /* record the allowing interrupt flags value */ io_cli(); /* set allowing flag 0 for prohibitting interrupt */ io_out8(0x03c8, start); for(i = start; i <= end; i++){ io_out8(0x03c9, rgb[0]/4); io_out8(0x03c9, rgb[1]/4); io_out8(0x03c9, rgb[2]/4); rgb += 3; /* gain rgb pointer index 3 */ } io_store_eflags(eflags); /* restore interrupt allowing flags */ return; }
色番号の設定は、以下の2つの関数で行なっています。
init_palette set_palette
２つの関数の処理の流れとしては、
- init_palette関数を呼び出し、関数内部で色番号の配列を定義しset_palette関数を呼び出す
- set_palette関数内で、eflagの値を退避させたり割込み禁止にしたりしたあと、for文のなかで自分が設定しようとしている色番号を登録し、割込み禁止解除とeflagsの値を復元
というものになります。
特に、「set_palette関数って何やってるの？」というところについては、以下のサイトに詳しく書いてあります。
http://oswiki.osask.jp/?VGA
上記のリンクの「ビデオDAコンバータ」の項目の「パレットのアクセスの手順」を確認しておくといいかもです。
あとは、HariMainのルーチンに戻ったあと、登録した色番号を使用してVRAMのアドレスに色を書き込んでいきます。
これが今回書いたbootpack.cの処理フローです。
続いて。上記で追加した関数の処理についてはnasmfunc.nasにて定義します。なのでnasmfunc.nasもコードを追加します。
; nasmfunc ; TAB=4 ; [FORMAT "WCOFF"] ; the mode creating object file [BITS 32] ; 32 bit mode machine code ; information for object file ; [FILE "nasmfunc.nas"] ; source file information GLOBAL io_hlt ; function name that contains this program GLOBAL io_cli GLOBAL io_sti GLOBAL io_stihlt GLOBAL io_in8 GLOBAL io_in16 GLOBAL io_in32 GLOBAL io_out8 GLOBAL io_out16 GLOBAL io_out32 GLOBAL io_load_eflags GLOBAL io_store_eflags section .text ; write this description at first io_hlt: ; void io_hlt(void) HLT RET io_cli: ; void io_cli(void) CLI RET io_sti: ; void io_sti(void) STI RET io_stihlt: ; void io_stihlt(void) STI HLT RET io_in8: ; int io_in8(int port) MOV EDX,[ESP+4] ; [ESP+4] is arg1 MOV EAX,0 IN AL,DX RET io_in16: ; int io_in16(int port) MOV EDX,[ESP+4] MOV EAX,0 IN AX,DX RET io_in32: ; int io_in32(int port) MOV EDX,[ESP+4] IN EAX,DX RET io_out8: ; void io_out8(int port, int data) MOV EDX,[ESP+4] MOV AL,[ESP+8] OUT DX,AL RET io_out16: ; void io_out16(int port, int data) MOV EDX,[ESP+4] MOV EAX,[ESP+8] OUT DX,AX RET io_out32: ; void io_out32(int port, int data) MOV EDX,[ESP+4] MOV EAX,[ESP+8] OUT DX,EAX RET io_load_eflags: ; int io_load_eflags(void); PUSHFD ; it is equals to PUSH EFLAGS POP EAX RET io_store_eflags: ; void io_store_eflags(int eflags); MOV EAX,[ESP+4] PUSH EAX POPFD ; it is equals to POP EFLAGS RET
一応、いくつか出てくるアセンブリ命令についてまとめておきます。
IN EAX,DX ; 装置から電気信号を受け取る命令 OUT DX,EAX ; 装置へ電気信号を送る命令 ※扱うサイズによってEAXの部分はALやAXになる
それぞれ、DXには「装置番号」、EAXには「受け取るor送る値」が設定されます
で、２つの命令では指定するレジスタはDXとEAXで、INとOUTでsourceとdestinationが入れ替わります。
わりと覚えやすいかも。
CLI ; 割り込みフラグを0にする命令（CLear Interrupt flag）-> つまり割り込み禁止にする STI ; 割り込みフラグを1にする命令（SeT Interrupt flag）-> つまり割り込みを有効にする
何か重要な処理をしたいので「割り込みは勘弁！」といった際にはCLIを使い、その処理が終了後にSTIで元に戻せばいいんでしょうか。
割り込みに関しては後々やるとのことなので、こんな推測に留めておきます。
PUSHFD ; eflags（フラグレジスタの値）をDWORDサイズでスタックに積む POPFD ; eflags（フラグレジスタの値）をDWORDサイズでスタックから取り出す
フラグレジスタの操作に関連したpushとpop命令です。
んで、最終的に実行結果はこちら。harib01bとはちょっと色が違うことが確認できるかと思います。
harib01g
ここでは3つほど色の違う四角形を表示させます。
先ほど作成したbootpack.cの内容を色々変更しますが、変更点については以下の通り
- 先ほど配列で定義していた色番号をdefineで定義しなおす
- 四角形を描画する関数boxfill8を定義して、指定した色で塗りつぶして表示する処理を記述
というわけで変更後のbootpack.cのコードは以下の通りです。
/* proto type declaration */ extern void io_hlt(void); extern void io_cli(void); extern void io_out8(int port, int data); extern int io_load_eflags(void); extern void io_store_eflags(int eflags); void init_palette(void); void set_palette(int start, int end, unsigned char *rgb); void boxfill8(unsigned char *vram, int xsize, unsigned char c, int x0, int y0, int x1, int y1); #define COL8_000000 0 #define COL8_FF0000 1 #define COL8_00FF00 2 #define COL8_FFFF00 3 #define COL8_0000FF 4 #define COL8_FF00FF 5 #define COL8_00FFFF 6 #define COL8_FFFFFF 7 #define COL8_C6C6C6 8 #define COL8_840000 9 #define COL8_008400 10 #define COL8_848400 11 #define COL8_000084 12 #define COL8_840084 13 #define COL8_008484 14 #define COL8_848484 15 void HariMain(void) { int i; /* 32bit integer */ char *p; /* pointer */ init_palette(); /* setting palette */ p = (char *)0xa0000; /* set address of VRAM area */ /* 3つの四角形を、描画位置と色を指定して描画 */ boxfill8(p, 320, COL8_FF0000, 20, 20, 120, 120); boxfill8(p, 320, COL8_00FF00, 70, 50, 170, 150); boxfill8(p, 320, COL8_0000FF, 120, 80, 220, 180); for(;;){ io_hlt(); } } void init_palette(void) { static unsigned char table_rgb[16*3] = { 0x00, 0x00, 0x00, /* 0:black */ 0xff, 0x00, 0x00, /* 1:light red */ 0x00, 0xff, 0x00, /* 2:light green */ 0xff, 0xff, 0x00, /* 3:light yellow */ 0x00, 0x00, 0xff, /* 4:light blue */ 0xff, 0x00, 0xff, /* 5:light purple */ 0x00, 0xff, 0xff, /* 6:light water blue */ 0xff, 0xff, 0xff, /* 7:white */ 0xc6, 0xc6, 0xc6, /* 8:light gray */ 0x84, 0x00, 0x00, /* 9:dark red */ 0x00, 0x84, 0x00, /*10:dark green */ 0x84, 0x84, 0x00, /*11:dark yellow */ 0x00, 0x00, 0x84, /*12:dark blue */ 0x84, 0x00, 0x84, /*13:dark purple */ 0x00, 0x84, 0x84, /*14:dark water blue */ 0x84, 0x84, 0x84 /*15:dark gray */ }; set_palette(0, 15, table_rgb); return; /* static char operation is equals to DB operation */ } void set_palette(int start, int end, unsigned char *rgb) { int i, eflags; eflags = io_load_eflags(); /* record the allowing interrupt flags value */ io_cli(); /* set allowing flag 0 for prohibitting interrupt */ io_out8(0x03c8, start); for(i = start; i <= end; i++){ io_out8(0x03c9, rgb[0]/4); io_out8(0x03c9, rgb[1]/4); io_out8(0x03c9, rgb[2]/4); rgb += 3; /* gain rgb pointer index 3 */ } io_store_eflags(eflags); /* restore interrupt allowing flags */ return; } void boxfill8(unsigned char *vram, int xsize, unsigned char c, int x0, int y0, int x1, int y1) { int x,y; for(y = y0; y <=y1; y++){ for(x = x0; x <= x1; x++){ vram[y * xsize + x] = c; } } return; }
表示される画面はこんな感じです。
boxfill8で特定の座標に四角形を描画していますが、座標軸は通常数学でやるときの中心を原点とするものではないです。
PCの場合、画面左上を原点として座標の計算を行います（一般的な話かどうかは知りませんが）。
今回四角形の描画で使用しているboxfill8の引数と関連させてみると、以下の図のようになるかと。
あとは、実際に描画させる際にはVRAMのアドレスを対応させればいいです。
なので、「画面上の」原点の位置は、「メモリ上では」0xa0000に対応するので、特定の座標の色に対応するメモリの位置は以下の計算式で求められます。
0xa0000 + x + y * 320
で、「なぜyに320をかけるのか？」と言う疑問がありますが、これについては以下のサイトにあるsksatさんの解説が非常にわかりやすいです（ページ上で「320」と検索をかければ見つかります」
http://hrb.osask.jp/wiki/?q_and_a
加えて、こちらのサイトの内容も確認しておくとこの疑問については解消されるのではないかと思います。
OS自作入門 4日目 【Linux】| VRAMとカラーパレット | サラリーマンがハッカーを真剣に目指す
具体的に、0xa0000から開始されるvramにおいて、(X座標, Y座標）がどのアドレスに該当するのかをわかりやすく示してくれています。
ここまでくると「おぉ〜」とちょっと感動しますね。
harib01h
4日目の最後です。ここでは、昔のウィンドウズっぽい画面を描画します。
ただ、とくに新しいことはなく、boxfill8関数を使ってそれっぽいものをじゃんじゃん描画していくのみになります。
なので、変更するのはbootpack.cのみ。
/* proto type declaration */ extern void io_hlt(void); extern void io_cli(void); extern void io_out8(int port, int data); extern int io_load_eflags(void); extern void io_store_eflags(int eflags); void init_palette(void); void set_palette(int start, int end, unsigned char *rgb); void boxfill8(unsigned char *vram, int xsize, unsigned char c, int x0, int y0, int x1, int y1); #define COL8_000000 0 #define COL8_FF0000 1 #define COL8_00FF00 2 #define COL8_FFFF00 3 #define COL8_0000FF 4 #define COL8_FF00FF 5 #define COL8_00FFFF 6 #define COL8_FFFFFF 7 #define COL8_C6C6C6 8 #define COL8_840000 9 #define COL8_008400 10 #define COL8_848400 11 #define COL8_000084 12 #define COL8_840084 13 #define COL8_008484 14 #define COL8_848484 15 void HariMain(void) { char *vram; int xsize, ysize; init_palette(); /* setting palette */ vram = (char *)0xa0000; /* set address of VRAM area */ xsize = 320; ysize = 200; boxfill8(vram, xsize, COL8_008484, 0, 0, xsize - 1, ysize - 29); boxfill8(vram, xsize, COL8_C6C6C6, 0, ysize - 28, xsize - 1, ysize - 28); boxfill8(vram, xsize, COL8_FFFFFF, 0, ysize - 27, xsize - 1, ysize - 27); boxfill8(vram, xsize, COL8_C6C6C6, 0, ysize - 26, xsize - 1, ysize - 1); boxfill8(vram, xsize, COL8_FFFFFF, 3, ysize - 24, 59, ysize - 24); boxfill8(vram, xsize, COL8_FFFFFF, 2, ysize - 24, 2, ysize - 4); boxfill8(vram, xsize, COL8_848484, 3, ysize - 4, 59, ysize - 4); boxfill8(vram, xsize, COL8_848484, 59, ysize - 4, 59, ysize - 5); boxfill8(vram, xsize, COL8_000000, 2, ysize - 3, 59, ysize - 3); boxfill8(vram, xsize, COL8_000000, 60, ysize - 24, 60, ysize - 3); boxfill8(vram, xsize, COL8_848484, xsize - 47, ysize - 24, xsize - 4, ysize - 24); boxfill8(vram, xsize, COL8_848484, xsize - 47, ysize - 23, xsize - 47, ysize - 4); boxfill8(vram, xsize, COL8_FFFFFF, xsize - 47, ysize - 3, xsize - 4, ysize - 3); boxfill8(vram, xsize, COL8_FFFFFF, xsize - 3, ysize - 24, xsize - 3, ysize - 3); for(;;){ io_hlt(); } } void init_palette(void) { static unsigned char table_rgb[16*3] = { 0x00, 0x00, 0x00, /* 0:black */ 0xff, 0x00, 0x00, /* 1:light red */ 0x00, 0xff, 0x00, /* 2:light green */ 0xff, 0xff, 0x00, /* 3:light yellow */ 0x00, 0x00, 0xff, /* 4:light blue */ 0xff, 0x00, 0xff, /* 5:light purple */ 0x00, 0xff, 0xff, /* 6:light water blue */ 0xff, 0xff, 0xff, /* 7:white */ 0xc6, 0xc6, 0xc6, /* 8:light gray */ 0x84, 0x00, 0x00, /* 9:dark red */ 0x00, 0x84, 0x00, /*10:dark green */ 0x84, 0x84, 0x00, /*11:dark yellow */ 0x00, 0x00, 0x84, /*12:dark blue */ 0x84, 0x00, 0x84, /*13:dark purple */ 0x00, 0x84, 0x84, /*14:dark water blue */ 0x84, 0x84, 0x84 /*15:dark gray */ }; set_palette(0, 15, table_rgb); return; /* static char operation is equals to DB operation */ } void set_palette(int start, int end, unsigned char *rgb) { int i, eflags; eflags = io_load_eflags(); /* record the allowing interrupt flags value */ io_cli(); /* set allowing flag 0 for prohibitting interrupt */ io_out8(0x03c8, start); for(i = start; i <= end; i++){ io_out8(0x03c9, rgb[0]/4); io_out8(0x03c9, rgb[1]/4); io_out8(0x03c9, rgb[2]/4); rgb += 3; /* gain rgb pointer index 3 */ } io_store_eflags(eflags); /* restore interrupt allowing flags */ return; } void boxfill8(unsigned char *vram, int xsize, unsigned char c, int x0, int y0, int x1, int y1) { int x,y; for(y = y0; y <=y1; y++){ for(x = x0; x <= x1; x++){ vram[y * xsize + x] = c; } } return; }
表示される画面はこんな感じ。
なんかOSぽくなってきました！ちょっと今後が楽しみ
という感じで、今回は特に大きな失敗はありませんでした（逆に不安
30日OS自作入門-番外編その１ FTK Imagerを使ったイメージファイルの読み込み-
本編とは関係ないのですが、ちょっと自分が使っているツールの紹介をば。
まだ3日目ですが、作成したイメージファイルの中身の構造がどうなっているのかを知りたい際には、FTK Imagerというツールがおすすめです。
Windows上でのみ動くツールですが、イメージファイルの簡易的な解析には非常に使えます。まぁ、このツール自体がフォレンジック用途なので、ファイルシステムの解析などに強いと言うのもあるのですが。
私自身、フォレンジックをやっている身なので、よくイメージファイルの中身を簡易的に見るという作業をやっているのですが、その際に使用しています。
FTK Imger自体は、ダウンロードフォームに記入後、メールにてダウンロードリンクが飛んできますので、そこに記載されているダウンロードリンクから落とせます。
このツールを使って作成したイメージファイルをマウントさせると、こんな感じで中身が見れます。
ちょっとだけ、使い方を紹介いたします。
FTK Imagerの使い方
使うときのフローとしては以下の通り。
- 作成したイメージファイルor接続されているHDDを選択
- ツールに読み込まれたイメージファイルorHDDの中身をみる
です。非常に簡単です。
1. 作成したイメージファイルの選択
まずは、作成したイメージファイルの選択をします。以下の図のようにやっていただければいいです。
流れとしては
- Evidenceの追加
- Evidenceの種類を選択（今回はイメージファイルなので、Image Fileを選択）
- イメージファイルを指定
最後のFinishをクリックすると、下のような画面に切り替わります。
それぞれの画面で、イメージファイルないのディレクトリツリー、ファイルのリスト、プロパティ情報、hexを確認することができます。
で、30日自作OSの3日目のharib00jで作成したイメージファイルであれば、イメージファイルの先頭から0x4200にbootpackのコードがあるはずです。
なので、Evidence Treeの部分でimgファイルを選択し、hexの画面上でCtrl+Gをすると任意のアドレス（オフセット？）に飛ぶことができます。実際に0x4200を指定してそのデータを見て見ると確かにそのコード部分が存在するのが確認できるかと思います。
hexを見るだけであればxxdコマンドなどを使えばいいのですが、こちらのツールを使うとファイルシステムを読み取って中の構成をちゃんと確認できるので、「作成したharibote.sysがファイルとして格納されているはずなんだけど、本当にあるのか？」など確認できます。
その他にも、イメージファイル内に存在するファイルを取ってきたりメモリダンプを取りことも可能です。フリーツールとは思えない完成度だとおもいます。。
興味があればぜひ使ってみてください。
30日OS自作入門-3日目（C言語導入）-
ちょっと気分を変えてブログの名前を変えてみました。
最近インフラ勉強会に参加しているのですが、セキュリティ以外の部分も色々やっていきたいなぁ、というところが芽生えまして。というところで、今後ともお付き合いいただければと思います。
さて、では始めていきます。
今回は、前回のつづきとしてC言語を導入し32ビットで動作するコードを書いていきます。とはいいつつ、まだまだアセンブリ多め。
今回のまとめ
3日目の後ろの方で、C言語を導入するところからになります。
で、本書とは違うツールを使用する場合には、作成するファイルであったり追加で必要となったりするファイルがあります。
そこらへんは以下のサイトを参考にして流れの確認やコマンドのオプション確認を行いました。
・流れの確認で参考にしたサイト
OS自作入門 3日目-1 【Linux】| 64bit環境での苦悩 | サラリーマンがハッカーを真剣に目指す
・コマンドの確認で使用したサイト
んで、上のサイトはこの本を読み終えるまで非常に参考となります。私も逐一ここは確認しながらやっていこうと思います。
Haribote.img作成までの流れ
上で紹介したサイトにも流れは書いていますが、自分なりに図を起こしてみました。
どのコードがイメージファイルのどの部分に入ってくるのかイメージしやすいようにしてみました。特に、harib00iとharib00jの部分が本書で使用するツールを使わない場合になかなか難しいと思いますので、そこを中心に。
（作成する際のファイル名は、本書のものとはちょっと異なる（だいたい何のファイルかは想像がつくかと思います）ので、読み替えていただければ。
harib00i
まずは、harib00iで作成するイメージファイルの作成フローです
作成したMakefileは以下の通り。上の図と比較しながら見ていただければ。
# Makefile for harib00i bootpack.hrb: bootpack.c os.lds gcc -march=i486 -m32 -nostdlib -T os.lds bootpack.c -o bootpack.hrb nasmhead.bin: nasmhead.nas nasm nasmhead.nas -o nasmhead.bin -l nasmhead.lst ipl.bin: ipl.nas nasm ipl.nas -o ipl.bin haribote.sys: nasmhead.bin bootpack.hrb cat nasmhead.bin bootpack.hrb > haribote.sys .PHONY: run run: qemu-system-i386 -fda hariboteos.img .PHONY: remove remove: rm *.bin *.lst *.sys *.hrb .PHONY: debug debug: qemu-system-i386 -m 32 -localtime -vga std -fda hariboteos.img -gdb tcp::10000 -S & hariboteos.img: ipl.bin haribote.sys mformat -f 1440 -C -B ipl.bin -i hariboteos.img :: mcopy -i hariboteos.img haribote.sys ::
最後のhariboteos.imgを作成する際には、mformatとmcopyというコマンドを使っています（上記の参考サイトをみてやって見ました）。
一応、このコマンドが何をやっているのかをまとめておきます。
mformat -f 1440 -C -B ipl.bin -i hariboteos.img ::
-f 1440 : サイズを指定、今回は1440byte
-C : ディスクイメージを作成し、MS-DOSファイルシステムを構成する
-B ipl.bin : ブートセクタを指定する。今回はipl.binがブートセクタ
-i : よくわからない（image fileのiとか？と推測）
ここでのmformatコマンドでは、1440byteのイメージファイルhariboteos.imgを作成し、ファイルシステムをFAT12として、ブートセクタをipl.binに書かれている内容とする、ということをやっています。
（FAT12の12の部分って「何ビットのクラスタ識別子を利用するか」という話だったんですね。。んでクラスタ識別子は「ファイルを何個まで格納できるようにするか」という話なので、2^12=4096個までファイルを格納できるファイルシステムがFAT12ということでしょうね）
mcopy -i hariboteos.img haribote.sys ::
-i : こちらもわからない（おそらくimage fileを指定したものだと思われる）
mcopyコマンドでは、先ほどmformatで作成したイメージファイルhariboteos.imgのファイルシステム内にファイルを追加するということを行なっています。
追加するファイルはharibote.sysで、前回の記事で書いたFATの構成のRoot Directory部分にharibote.sysのファイル名を追加し、File Storage Spaceにharibote.sysのファイルの中身を記録しています。
ということで、xxdコマンドを使ってhariboteos.imgのファイル内をみてみます。
まずは、0x2600の部分にharibote.sysファイル名が書かれています。
続いて、0x4200にharibote.sysの中身が書かれていることを確認します。
個別に作成したharibote.sysの中身がこちら。
多分同じになっているはずです。このような動きをmformatとmcopyのコマンドではやっています。
harib00j
次に、nasmfuncを加えたharib00jのイメージファイル作成フローです。
作成したMakefileは以下の通り。こちらも同様に上の図を見ながら確認していただければ。
# Makefile for harib00j bootpack.hrb: bootpack.c nasmfunc.o os.lds gcc -march=i486 -m32 -nostdlib -T os.lds nasmfunc.o bootpack.c -o bootpack.hrb nasmhead.bin: nasmhead.nas nasm nasmhead.nas -o nasmhead.bin -l nasmhead.lst nasmfunc.o: nasmfunc.nas nasm -f elf nasmfunc.nas -o nasmfunc.o -l nasmfunc.lst ipl.bin: ipl.nas nasm ipl.nas -o ipl.bin haribote.sys: nasmhead.bin bootpack.hrb cat nasmhead.bin bootpack.hrb > haribote.sys .PHONY: run run: qemu-system-i386 -fda hariboteos.img .PHONY: remove remove: rm *.bin *.lst *.sys *.hrb *.o .PHONY: debug debug: qemu-system-i386 -m 32 -localtime -vga std -fda hariboteos.img -gdb tcp::10000 -S & hariboteos.img: ipl.bin haribote.sys mformat -f 1440 -C -B ipl.bin -i hariboteos.img :: mcopy -i hariboteos.img haribote.sys ::
harib00iとharib00jの動作結果として、真っ黒の画面が出ていれば成功です（おそらく
bootpack.hrbを作成する際、gccを使用してbootpack.oとnasmfunc.oをos.ldsというリンカスクリプトを利用して生成しています。リンカスクリプトについては以下のサイトをみなさん参考にやっていたので、私も便乗しました。
https://vanya.jp.net/os/haribote.html#gcchrb
ただ、このリンカスクリプトの書き方も後でちゃんと確認しておこうと思います。
本当はここをldを使ってリンクをしたかったのですが、うまくいかなかったのでgccコマンドでまとめてやってしまっています。
これもちゃんとあとでldを使う場合にはどうしたらちゃんとうまくいくか確認してみようと思います。
ドツボにハマったところ
色々なサイトを見ていきながらコードを書いて、「いざ実行！」して見たのですが、なぜか画面が真っ黒にならず、一番最初の「Booting from floppy...」までの文字列が繰り返し表示される。。。
ひとまず、デバッグをして見たところ、なぜか0x7c00（ipl.binが置かれるメモリアドレス）と0xc200（nasmhead.binが置かれるメモリアドレス）を行ったり来たりしていました。
一応コードの間違いとかを確認しましたが、それを見つけられなかったので再び１からコードを書き直しました。書き直した方ではちゃんと動きました。
んで、何が間違っていたかというと、nasmheadの最後の部分がなんかおかしかったようです（hexみたらなんか違う。。。）。
なぜ繰り返したかはちょっとこの後デバッグしてみて確認しようと思います。
失敗したことと参考情報
特にharib00jの部分で色々とありましたので、そこをまとめておきます。
まず、nasmを使用している場合、nasmfunc.nasでは
- [FORMAT "WCOFF"]と[FILE "nasmfunc.nas"]の部分は必要ない
実際にこれを書いた状態でアセンブルした場合、以下のようなエラーが出ます。
nasmfunc.nas:4: error: unrecognised directive [FORMAT] nasmfunc.nas:9: error: unrecognised directive [FILE]
識別できないディレクティブがあるということですが、これらの行をコメントアウトすることで解決できます。
続いて、nasmfunc.nasのオブジェクトファイルを生成したのち、gccでbootpack.hrbを生成しようとしたところ、以下のようなエラーが吐かれました。
nasmfunc.o: file not recognized: File truncated
もともとMakefileに書いていたnasmのコマンドは以下の通りです。
nasm nasmfunc.nas -l nasmfunc.lst -o nasmfunc.o
ということで、nasmfunc.oってどんなファイルになってるのかをfileコマンドで調べたところ、
nasmfunc.o: ISO-8859 text, with no line terminators
となっていました。生成しなければいけないのはELF形式なので、こりゃだめだということでnasmfunc.nasをアセンブルする際にコマンドのオプションを追加して解決できました（上記Makefileのnasmfunc.oの部分を参照のこと）
その後もエラーがでます。次はgccでbootpack.hrbを生成する際に、bootpack.cの部分で以下のようなエラーが出ました。
/tmp/ccjdiCmn.o: In function `HariMain': bootpack.c:(.text+0x7): undefined reference to `io_hlt'
よくよく考えてみると、このエラーが出るのは当然かと。プロトタイプ宣言している関数が外部ファイルに定義されているものなのに、「外部ファイルから呼び出しますよー」という記述が一切ないですよね。
というわけで、bootpack.c内でプロトタイプ宣言されているio_hlt関数の先頭にexternを入れることで、「この関数は外部ファイルで定義されているますよー」という目印になります。これで無事解決。
んで、本書のダウンロードリンクから落としてきたソースにはexternがついていません。なので、これをそのまま写してgccでコンパイルしたとしても通らない可能性が高いです。ご注意を。
あと、harib00jで作成したイメージをgdbでリモートデバッグしてみたのですが、ちょっと嫌な予感がしています。。
まぁ、これについては詰まった時にまた考えることにします。
ちゃんと動くまでかなり時間を要しましたが、これでちゃんと先に進めそうです。
ただ、ここで３回ほどソースコードを全部書き直したりしたので、コードの流れがある程度把握できたと思います。
うまく動かない場合には一からコードを書き直すのもありだと思います。
T-Pot観測記録：2018/5/11〜5/17 vnc、またきたかおまいらw
最近、再びraspberry piとarduinoを触り始めてはまってしまったのでちょっと遅れてしまいましたが、先週の分の記録をつけていきたいと思います。
...といいたいところなのですが、tpotにアクセスしたところ以下のような画面ががが。。
「なんでじゃー」ということで、Status Breakdownの部分を見てみると、elasticsearchの部分で"Elasticsearch is still initializing the kibana index"となっており、これが問題と思われる。
とりあえずこれをググってみる。....よくわからんがcurlをつかってREST APIでクラスタヘルスをチェックできるらしい。が、みてもよくわからん！
ということで、私が参考にしているTKさんのブログに同じ現象の解決方法がありましたので、この手法を使ったところ無事復活しました（TKさん本当にありがたや）。
参考にした記事は以下の通りです。
色々ありましたが、はじめていきます。
全体の結果
私のところのハニーポットには、ずっとvncさんが定期的にきているという状況ですね。しかも、相変わらずロシアからです。ただ、ここまで時間が固定的だと自動化している可能性もありそう？
また、前回の記事で書いた内容に関連することですが、警察庁からRedisを標的とした探索行為の増加がみられる報告がありました。
4月ぐらいから急激に増えて、そのまま継続しているという状況でしょうか。
私のところでは先週はきていましたが、今週はきていないようでした。
ちょっと他も見てはみたものの面白いネタがないですw
ちょっと気になったこと
あと、私のところのSuricata CVEでは、今までCVE-20170143しか見たことないのですが、TKさんのところだと色々きていて羨ましい。
みなさんSuricataのチューニングとかやっているのでしょうか？
やってみたい！
これまたTKさんの記事にあるものですが、DionaeaとVTの連携は非常にやりたい！毎回コマンドうって確認するの疲れました。
なので、近々やろうと思います。
T-Pot観測記録：2018/5/4〜5/10
ちょっと遅れてしまいましたが、今週分の観測記録をつけようと思います。
全体の結果
先週まではvnclowpotに対するものが多かったのですが、この週は非常に変動がありました。継続してvnclowpotのイベントは多いのですが、それ以外のCowrie, Honeytrapのイベントが非常に多くなっています。なので、今回はこの３つを中心にイベントをみていきます。
vnclowpotのイベント
vnclowpotに対するものは依然としてある程間隔的にイベントが発生しています。ただ、その時間が少し変わっています。
・先週：毎日15:00近辺でスパイクしていた
・今回の週：6:00, 9:00などでスパイクしていることが多くなっている
攻撃元のIPは前回と変わらずロシアが大半を占めています。また、発信元はロシアのモスクワが圧倒的です。
ロシア（モスクワ）との時差は6時間（モスクワより日本の方が進んでいる）となるため、今回の週の時間をモスクワの時間で考えると
・今回の週（モスクワ時間）：0:00, 3:00
となります。夜中にかけて攻撃を実施しているということなのでしょうか？たしかに、夜中にかけて攻撃した方が、日本の企業の人にとっては気づきにくい+対処しにくいでしょうね。
Honeytrapのイベント
こちらもロシアがほとんどです。すごいですね、ロシア。。
送信先ポートは以下の通り
dest port : 6379, 2222, 2323, 5902, 3307
5902はvncらしいですね。というのも、vncではポート番号が基本的に「5900+ディスプレイ番号」になるとのこと。つまり、5902では2番のディスプレイ番号を使用していることを表します。
また、6379はRedisと呼ばれるインメモリ型のNoSQLデータベース（キー・バリュー型）らしいです。この、「インメモリ型のDB」という話ですが、最近話題になったmemcachedも同じようなものらしいです。分類としてもRedisと同じような分類（インメモリ型NoSQL(キー・バリュー型））らしいです。ここら辺の詳しい話はちょっとわかりませんが。。
Cowrieのイベント
こちらについては、この週において非常に多く発生するようになりました。
・攻撃元：メキシコ、ベトナム、アメリカ、ブラジルの順で多い（中国やロシアは少なかったです。
・ポート：2222(ssh), 2223(telnet)がほとんど。443と80はかなり少ない。
また、メキシコからの攻撃ではtelnetに対するものが多く、ベトナムからはsshという感じです。アメリカに関しては半々という結果でした。
では、Cowrieで使用されたアカウントとパスワードをみていきます。
アカウント名
パスワード
アカウント名は、前回の記事でも出たものがちらほらと見えます。新しいものであれば、以下のものでしょうか。
e8ehome, telecomadmin,
両方とも、Miraiに似たネットワークスキャンで使用されるものっぽいですね。以下参考記事。
blog.trendmicro.co.jp
パスワードについても、上記の記事に書いているものが多いですね。
強いていうなら以下のものがちょっと特徴的でしょうか。
nE7jA%5m
ただ、これも調べてみたら中国製のルータのデフォルトパスワードっぽいですね。
このようにみて見ると、デフォルトパスワードがいかに危険か実感できますね。なので、デフォルトパスワードは使用しないように気をつけなければ。
今はこんな感じで記録をつけていますが、他のハニーポッターの方はどんな風に（使っているツールとか）ログ解析しているのかは非常に気になりますね。
30日OS自作入門-１〜２日目-
前回までで環境構築を終わらせましたので、早速作業に入りたいと思います。
今回やっていく内容
- 1日目の部分
- 2日目の部分
1日目部分
やったことは以下の通り
- おもむろにバイナリエディタを起動し、hexを写経（鬼w
- テキストエディタを起動し、DB命令を使ってhexを記述（18万4314行の¥x00を打ち込む必要がある。これも鬼w）
- アセンブリ命令を少しづつ加えながら、hex自体で書く量を減らしていく
主にhexを写経していくような作業。結構しんどいけど、「0x〜」を打鍵するスピードが上がった気がします
命令
DB(data byte)
- ファイルに1byteのデータを直接書く命令
- DB命令のオペランドはカンマで区切ると複数指定可能？（本では８バイト分）
- ファイルに書くデータの大きさによって以下のような命令がある
- DW(data word) : 2byteのデータを書き込む
- DD(data double-word) : 4byteのデータを書き込む
- DB命令については、オペランドに文字列を指定可能
RESB(reserve byte)
- 指定したバイト数だけ0x00を書き込む
んで、RESBに関連する部分で$マークを使い余り部分を0書きするという部分がありました。
RESB 0x1fe - $
ここでの＄は「先頭行から何バイト目か」を教えてくれる変数として機能します。なので、例として$マークの部分が先頭から0x1f0行目だったとしましょう。そうすると、
0x1fe - 0x1f0 = 0x00e
となるため、RESB命令部分は
RESB 0x00e
となり、ファイル内のアドレス0x1f0から14byte分0を書き込みます。
。。。という感じなのですが、私の環境（linux+nasm）では$のままだとアセンブルできないので（エラーが出る）、linux+nasmでやっている方であればこの部分のコードを以下のように変更します。
RESB 0x1fe - ($-$$)
これについては、以下の記事を参考にしました。
tsurugidake.hatenablog.jp
この２つの命令を使ってnasファイルにコードを打ち込みアセンブルしてimgファイルを作成し、それをqemuで実行します。
nasm helloos1.nas -o helloos1.img
qemuでの実行
qemu-system-i386 helloos1.img
そうすると、こんな感じで画面が出てきます。
実際に起動して、ちゃんとhello worldの文字が見えるとやはり感動しますね。
まぁ、1日目については主に今後の作業の流れを掴むような作業でしょうか。
2日目部分
2日目から少しずつアセンブリ命令とレジスタなどを使って処理を書いていきます。
命令
ORG(origin)
- 記述した機械語をメモリ上のどのアドレスに読み込ませるか指定する命令
- ORG命令を使ってメモリ上のアドレスを指定した場合、$マークの意味も「読み込まれるメモリ上のアドレス」になる（nasmを使う場合は注意）
- コードの先頭部分でまずは以下のように指定を行う
ORG 0x7c00
INT(interrupt)
- ソフトウェア割り込み命令（詳細は後日）
HLT(halt)
- CPUを待機状態にする命令
- 外部で変化があればCPUがプログラムの続きを実行
（節電したいのであれば、使うべき？）
レジスタ関連
レジスタについては、今の所16bitのものが出てきますが、そのうちAX, BX, CX, DXについてはそれぞれ8bitレジスタとしても使える（AXはAHとALとして指定することも可能）というところは覚えておく必要あり（あとで出てくるので）。
バイトオーダー
MOVなどの転送命令でメモリ上にデータを格納する場合には、データの下位バイトからメモリに格納される点に注意。このような、メモリ上にデータを格納する方式のことをバイトオーダーと言い、こん秋のようにデータの下位バイト（桁のくらいが小さい方）からメモリ上に格納していく方式をリトルエンディアン。
（ビッグエンディアンはデータの上位バイトから格納していく方式。直感的にはこっちの方がわかりやすいかも）
エラー、警告関連
記述したアセンブリコード（nasファイル）をnasmでアセンブルするたびに以下の警告が吐かれていました。
warning : uninitialized space declared in .text section: zeroing
ひとまず警告は出ていたとしてもimgは起動できたので置いておいたのですが、気になったので解決法を調べてみたところ、同じような環境でやっている方がブログに書いておりました。有難や。
d.hatena.ne.jp
tsurugidake.hatenablog.jp
基本的にはRESB命令をTIMES命令に書き換えて、格納する値を定義してやるという感じですね
TIMES <繰り返す回数> DB(データの大きさ) 値
書き換えることによって、上記の警告は出なくなりました。
30日OS自作入門-3日目（C言語導入前まで）-
最大の鬼門と言われる3日目に突入しました。ただ、今回はC言語導入前までのまとめをしたいとおもいます。
今回のまとめ
主に３日目の内容についてまとめていきます。3日目は主に割り込み命令を使って以下の処理を実現する内容です。
・ディスクからの読み込み
・ビデオモード設定（画面モードの切り替え）
アセンブリコードとimgファイルの中身
3日目のはじめのソースコードを、実際にアセンブリ命令を書いてimgファイルを作りqemuで起動しました。
書いたアセンブリ命令とマシンコードの対応関係については、以下のコマンドで生成されるlstファイルを見ると確認できます。
nasm ipl.nas -l ipl.lst -o ipl.img
上記のコマンドでは、lstファイルの生成とimgファイルの生成を同時にやります。
lstファイルは以下のようになっています。
1 ; haribote-ipl 2 ; TAB=4 3 4 ORG 0x7c00 5 6 00000000 EB4E JMP entry 7 00000002 90 DB 0x90 8 00000003 48415249424F5445 DB "HARIBOTE" 9 0000000B 0002 DW 512 10 0000000D 01 DB 1 11 0000000E 0100 DW 1 12 00000010 02 DB 2 13 00000011 E000 DW 224 14 00000013 400B DW 2880 15 00000015 F0 DB 0xf0 16 00000016 0900 DW 9 17 00000018 1200 DW 18 18 0000001A 0200 DW 2 19 0000001C 00000000 DD 0 20 00000020 400B0000 DD 2880 21 00000024 000029 DB 0,0,0x29 22 00000027 FFFFFFFF DD 0xffffffff 23 0000002B 48415249424F54454F- DB "HARIBOTEOS " 24 00000034 5320 25 00000036 4641543132202020 DB "FAT12 " 26 0000003E 00<rept> TIMES 18 DB 0x00 27 28 ; main program 29 30 entry: 31 00000050 B80000 MOV AX,0 32 00000053 8ED0 MOV SS,AX 33 00000055 BC007C MOV SP,0x7c00 34 00000058 8ED8 MOV DS,AX 35 36 ; reading disk 37 0000005A B82008 MOV AX,0x0820 38 0000005D 8EC0 MOV ES,AX 以下省略
一番左から順に「nasファイル内での行番号」「ファイル上でのアドレス」「マシンコード」「アセンブリ命令」という順になっています。
そして、先ほどのnasmコマンドで生成したimgファイルの中身をhexで表示してみます。imgファイルの中身をhexで表示する際は、以下のコマンドを使用。
xxd ipl.img | more
表示されたファイルの中身はこちら
00000000: eb4e 9048 4152 4942 4f54 4500 0201 0100 .N.HARIBOTE..... 00000010: 02e0 0040 0bf0 0900 1200 0200 0000 0000 ...@............ 00000020: 400b 0000 0000 29ff ffff ff48 4152 4942 @.....)....HARIB 00000030: 4f54 454f 5320 4641 5431 3220 2020 0000 OTEOS FAT12 .. 00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000050: b800 008e d0bc 007c 8ed8 b820 088e c0b5 .......|... .... 00000060: 00b6 00b1 02b4 02b0 01bb 0000 b200 cd13 ................ 00000070: 7203 f4eb fdbe 8a7c 8a04 83c6 013c 0074 r......|.....<.t 00000080: f1b4 0ebb 0f00 cd10 ebee 0a0a 6e6f 2064 ............no d 00000090: 7269 6e6b 2c20 6e6f 206c 6966 6521 0a00 rink, no life!.. 以下省略
先ほど示したlstファイルの「マシンコード」とimgファイルのhexを先頭から比較すると、対応していることがわかるかと思います。
毎回ではありませんが、たまにこういった確認をすると、自分で書いたコードがどのようイメージファイルになっているのかが確認できるのでいいかもしれません。
割り込み命令
今回出てくる割り込み命令では、「指定したディスクの場所を読み込む処理」と「ビデオモード設定」について。
ディスクの読み込み
- ディスクアクセスの方式はCHS*1
- 読み込む対象のドライブ番号を指定（FDDが1つしかない場合には0x00でおk）
- int 0x13で実行（戻り値はCF（キャリーフラグ）にセットされる。CF＝１の場合、エラーが発生しており、AHにエラーコードが格納）
詳細については、以下のサイトを参照。
http://oswiki.osask.jp/?%28AT%29BIOS
もし、ディスクアクセスに関連したエラー処理をする場合には、
int 0x13
命令のあとに以下のような処理を追加すればいいのでしょう。
- CFにフラグが立っているかどうかを判断する
- フラグが立っている場合には、AHに記載されているエラーコードをみて、エラーコードに応じた処理を行う（ラベルを作って、エラーコードに応じてジャンプさせればいいのかな？）
ビデオモード設定
本の通り、ビデオモードは以下の通りまずはやってみました。
MOV AH, 0x00 MOV AL, 0x13 ; 8bitカラー INT 0x10
そうすると、本に書いてある通り真っ黒の画面がでてきました。カーソルもきえました。
ちょっと他のモードもになったので、本に書いてある以下のモードを試してみました。
1. MOV AL, 0x12 ; 4bitカラー 2. MOV AL, 0x03 ; 16色テキスト
そうすると以下のような結果になりました
- 1. の場合、AL=0x13と同じ結果（画面真っ黒、カーソルも消える）
- 2. の場合、画面は真っ黒になるものの、カーソルは点滅
（自分だけ違っていたら嫌なので、やってみた方コメください; ）
イメージファイル内に記録されるファイル名とファイルの中身の位置
本の内容としては、haribote.sysのファイル名（haribote.nameと記載）とその中身については、イメージファイル上の以下の位置に記録されると書いてあります。
- ファイル名 ：0x002600
- ファイルの中身：0x004200
んで、これらの位置というのがどのように決まっているのかがちょっと気になったので、調べてみました。
FAT12におけるHDD上の構成を図で書いてみました。
Boot Sectorはいいとして、File Allocation Tableについてもとばします。
「Root Directory」は、FAT12のファイルシステム上で管理されているファイルの目次（ファイル名一覧）という感じです。Windowsで言えばMFT(Master File Table)に該当する部分。
その下の「File Storage Space」は、ファイルの中身を記録している部分です。Root DirectoryとFile Storage Spaceという2つの領域があるということは、ファイル名などのメタ情報とファイルの中身が別々に管理されている（格納場所が１まとめになっていない）ということがわかるかと思います。
でそれぞれの開始位置が0x2600と0x4200になっているので、haribote.nameというファイル名はRoot Directoryの先頭に記録され、haribote.sysファイルの中身はFile Storage Spaceの先頭に記録した、ということになります。
で、今までのOS作成で、自分がどのような部分を書いていたのかを上の画像と見比べて確認してみます。
こんな感じで確認しておけば、自分が今どんな部分を作成しているのかわりと把握しやすくなるかなと。
上記の図の作成においては、以下のサイトを参考にいたしました。
The FAT File System
補足としてですが、クラスタのサイズについては、ファイルシステムによって違うので要注意ですね（NTFSは1cluster=8sector=512*8=4096が一般的です）。
ただ、今回本書では1cluster=1sectorで扱っていくっぽいので、あまりセクタとクラスタの違いは意識しなくて済みそうです（ファイルの論理サイズと物理サイズ、そしてファイルスラックの話があるのですが、フォレンジックの記事を書く際に出そうかと）。
セグメントレジスタ
今までよくわかっていなかったセグメントレジスタの使い方など。
時代背景的には、
- 昔はレジスタの記憶可能なサイズが16bit(64KB)しかなかった
- 容量の大きいメモリを積んでいる場合であったとしても、実質64KBしか使えない
- レジスタの使い方とか工夫して、もっとメモリつかえるようにできんかねー？
という流れでセグメントレジスタができたという流れでしょうか。
このセグメントレジスタと既存のレジスタを使ってメモリの番地を指定することで1MBまでメモリの番地を指定できるようになったと。
セグメントレジスタをつかってメモリの番地を指定する際、アセンブリではこのように記述します。
MOV ES, 0x0820 MOV BX, 0x0012 MOV AX, 0x4141 MOV [ES:BX],AX
この例だと、
- セグメントレジスタESに0x0820を格納
- BXに0x0012を格納
- AXに0x4141を格納
- ES×16+BXで格納先メモリアドレスの計算を行う。メモリアドレスは0x0820 × 16 + 0x0012 = 0x8212
- メモリアドレス0x8212にAXのデータを格納
セグメントレジスタを使ってメモリアドレスの指定を行う際は、「セグメントレジスタで大雑把に場所を決める」「レジスタを使って細かな場所を決める」と覚えておけば問題はないかと。
今のところの疑問点など
・割り込み命令の時にはなぜ特定のレジスタに引数を入れておくのか？
・今回、読み込みのリトライの部分とエラー表示の部分を書いたので、わざとエラー処理に飛ばす方法はあるのかな？
時間はかかりましたが、かなり濃い勉強ができました。
次は、3日目の残り部分をやっていきます。時間があれば4日目部分もまとめてやろうかと。
