30日OS自作入門-3日目（C言語導入）-

ちょっと気分を変えてブログの名前を変えてみました。

最近インフラ勉強会に参加しているのですが、セキュリティ以外の部分も色々やっていきたいなぁ、というところが芽生えまして。というところで、今後ともお付き合いいただければと思います。

さて、では始めていきます。
今回は、前回のつづきとしてC言語を導入し32ビットで動作するコードを書いていきます。とはいいつつ、まだまだアセンブリ多め。

今回のまとめ

3日目の後ろの方で、C言語を導入するところからになります。

で、本書とは違うツールを使用する場合には、作成するファイルであったり追加で必要となったりするファイルがあります。

そこらへんは以下のサイトを参考にして流れの確認やコマンドのオプション確認を行いました。

・流れの確認で参考にしたサイト

OS自作入門 3日目-1 【Linux】| 64bit環境での苦悩 | サラリーマンがハッカーを真剣に目指す

・コマンドの確認で使用したサイト

『30日でできる！OS自作入門』のメモ

んで、上のサイトはこの本を読み終えるまで非常に参考となります。私も逐一ここは確認しながらやっていこうと思います。

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さん本当にありがたや）。

参考にした記事は以下の通りです。

tk-secu.hateblo.jp

色々ありましたが、はじめていきます。

全体の結果

私のところのハニーポットには、ずっとvncさんが定期的にきているという状況ですね。しかも、相変わらずロシアからです。ただ、ここまで時間が固定的だと自動化している可能性もありそう？

また、前回の記事で書いた内容に関連することですが、警察庁からRedisを標的とした探索行為の増加がみられる報告がありました。

www.npa.go.jp

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日目部分

• アセンブリ命令をじゃんじゃん使って、1日目にhexで書いた部分をアセンブリコードで書き直す
• CPU内に存在する記憶領域であるレジスタや、CPUからみると外部記憶装置であるメモリに関するお話

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
  • Cylinder, Head, Sectorの頭文字
  • シリンダ番号、ヘッド、セクタを特定のレジスタに格納しディスク上のデータの読み込み開始位置を指定*2
• 読み込む対象のドライブ番号を指定（FDDが1つしかない場合には0x00でおk）
• int 0x13で実行（戻り値はCF（キャリーフラグ）にセットされる。CF＝１の場合、エラーが発生しており、AHにエラーコードが格納）

詳細については、以下のサイトを参照。
http://oswiki.osask.jp/?%28AT%29BIOS

もし、ディスクアクセスに関連したエラー処理をする場合には、

int  0x13

命令のあとに以下のような処理を追加すればいいのでしょう。

1. CFにフラグが立っているかどうかを判断する
2. フラグが立っている場合には、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

この例だと、

1. セグメントレジスタESに0x0820を格納
2. BXに0x0012を格納
3. AXに0x4141を格納
4. ES×16+BXで格納先メモリアドレスの計算を行う。メモリアドレスは0x0820 × 16 + 0x0012 = 0x8212
5. メモリアドレス0x8212にAXのデータを格納

セグメントレジスタを使ってメモリアドレスの指定を行う際は、「セグメントレジスタで大雑把に場所を決める」「レジスタを使って細かな場所を決める」と覚えておけば問題はないかと。

今のところの疑問点など

・割り込み命令の時にはなぜ特定のレジスタに引数を入れておくのか？
・今回、読み込みのリトライの部分とエラー表示の部分を書いたので、わざとエラー処理に飛ばす方法はあるのかな？

時間はかかりましたが、かなり濃い勉強ができました。
次は、3日目の残り部分をやっていきます。時間があれば4日目部分もまとめてやろうかと。

*1:昔のディスクアクセス方式、今だとLBAが用いられる

*2:FDD１枚だと、シリンダは80、ヘッドは2つ、セクタは18あり、記録できるデータの合計は、80×2×18×512(byte per sector)=1,440KB

T-Pot観測記録：2018/4/27〜5/3

最近、ハニーポットの観測日記をよく見かけるのと、ハニーポットの人気が高まっている（？）ので、それに便乗して私も自分で飼っているT-Potの観測記録をつけていこうと思います。

観測記録の投稿周期

毎日やっている方もいますが、基本的には１週間に１度結果をまとめて記事にする、という形でいこうと思います。
また、世間的に気になる攻撃があった場合には、少し周期を短くして投稿しようかと。

T-Pot観測記録：2018/4/27〜5/3

全体の結果

他のかたのブログを見るとCowrieに対する攻撃が多い感じがしますが、私のハニーポットではvnclowpotが多い状況です。

また、vnclowpotのグラフをみて見ると、アクセスが周期的に行われていることがなんとなくつかめます。確認したところ

• 毎日15:00(JST)で5900ポートへのアクセスが多くなっている
• vncへの攻撃（アクセス）のほとんどがロシアから

ということが判明しました。vnc関連であれば、昔このような記事がありました。
blog.trendmicro.co.jp

POS端末を狙っているのか、はたまた別の端末を狙っているのか。。。

また、ハニーポットの観測記事で有名なブログをみた際、「Webカメラ」の初期パスワードを狙った攻撃が観測された、という記述がありました（「サイバーセキュリティはじめました」というブログです）

私のところでも同じような攻撃があるかどうか確認してみたところ、Webカメラの初期設定ユーザー名と思われるものを使った攻撃を観測できました。

• username : vstarcam2015
• password : ipcam_rt5350

（※この組みでアクセスされた、というわけではありません）

あまり、ログ解析はやったことがないので、これをいい機会に勉強しようと思います。
また、私の一番の興味はマルウェア解析になるので、dionaeaの改造なども挑戦していきたいですね。

30日OS自作入門-環境構築編-

先ほどの記事に続いて、環境構築に関して書いていきます。
環境については前回の記事に書いた通りですが、再掲します。

環境

macOS Sierra ver 10.12.6(ホストOS)
VMWare Fusion(仮想環境)
Lubuntu16.04 x64(ゲストOS)

Lubuntuにしているのは好みの関係ですw
画面としてはこんな感じ。デスクトップにターミナルのシンボリックリンクを置いています。

さて、ではここからはゲストOS上で作業を行なっていきます。
まずは、ゲストOS上で自作したOSを動かしたいので、そのためのエミュレータをインストールします。
エミュレータはqemuを使います。アセンブラについてはnasmを使っていこうと思います。

qemuインストール

sudo apt-get install qemu

nasmインストール

sudo apt-get install nasm

ここまで終わった時点で、試しにこの本の1日目で使用するhelloos.imgファイルを起動してみたいと思います。

起動コマンド

qemu-system-i386 helloos.img

そうすると、こんな感じで画面が出てきます。

ひとまず起動は完了と。
あとは、本を読んでいきながら少しずつ進めていきたいと思います。