22日目

[4]〜[5]
へー。実行ファイルの先頭にはこんな情報が！？。
でも考えてみれば当然かもね。昔みたいにとにかくアセンブラが走ればいいみたいなものじゃないもんね。今のOSは。
（しかし、内部のデータの位置をちゃんと分けなくちゃいけないのかぁ。VBとはあの手のヤツはコード内にまったく意識なくデータを置いているけど、ああいうのも内部で自動に割り振っているのかな？）

[6]
えぇぇ？　スタックにPUSHした値を直接書き換える？　いいの？そんなことして？（・・・いやいいんだろうなぁ）
（うーん。OS<->アプリのデータの受け渡しがどんどん複雑でややこしくなっていくなぁ。以前は単にある番地を決めておけばよかったんだけど。これは保護の弊害？というか、副作用なんだろうなぁ）

[7]
うわー。細かいところがまだあやしいけど、どんどんAPIが追加されていく。そしてとりあえず、「パターン」が解ってきたなぁ。

（きっと後で解決されると思うけどこの時点での疑問。「じゃ、パラメータや渡す値が10個とか必要なAPIの場合、どうするんだろう？）

22日目 [1]

へぇ〜！おもしろ〜！！。なるほどなぁ。これらはいずれの成功しないクラックだけど、こういう発想の仕方があるのかぁ。

（ここでシロウトながら思ったこと。INやOUTが使えないってことは、周辺機器の制御ができないということだよね？。じゃ、たとえばWindowsなんかはどうやって新しいハードウェアを制御しているんだろう？。　・・・あ〜。そうか。アプリのようでアプリじゃない。OSのようでOSじゃない。それが「ドライバ」というプログラムなのかぁ。逆に言えば、ドライバに悪意あるコードを忍ばせておけばきっと、OSはお手上げ状態になるってことなんだろうか？？？）

[2]
おー！やっぱし！。いや、これ、前から気になってたけどたぶん後で出てくるんだろうなと思ってた。
そうだよね？16bitの時のセグメントと違って32bitのセグメントは開始番地だけじゃなくて大きさも自由に指定できるんだもんね。「じゃ、そこからはみ出したらどうなる？」ってのは当然の疑問だった。やっぱちゃんとあるんだね？

[3]
ほんとだ！ EIPレジスタ（今動いているプログラムの行番号？を管理しているレジスタ。これを強制的に別のアドレスに書き換えちゃっているわけか。（いうなれば命令の真ん中に無理やりjmp命令をはさみこんだような結果になると）

21日目

[3]
ふむふむ。OSの保護とな？
なるほど。このクラックプログラムは、OSがずっと維持orメンテナンスしている部分に強制的にデータを上書きして、書き換えor破壊してしまうわけか。

[4]
やっていることはなんとなく解るな。アプリ用のセグメントを設け、アプリを全部その中に閉じ込めてしまう。でもそうなるとOSのデータやAPIが使えなくなっちゃうので、OSの関数（呼ばれるほう）のほうで帳尻を合わせるためにレジスタを盛んに退避and復帰させているのか。
・・・って、「なくなっちゃうので軽く流しとけ！」って？　うえ〜ん！(TT)

あー。そうか。悪いプログラムはこの段階ですでにOS内部ではじいてくれているけど、「はじいたぞ！」「止めたぞ！」って解るようにしてないってことか。
（改めて思うけど、OSがないコンピュータって、ほんとになにからなにまでやってあげないといけないのね・・・）

[5]
ん？ちょっとまって？
「一般保護例外」？。これは、このcrack1みたいにOSが管理していて（セグメントの設定で）書いちゃいけない部分を書こうとすると自動的に起こる割り込みなの？
「保護さえしておけば発生してくれる割り込み」かぁ。こりゃ便利！。
ってことは、最初にアプリが動く段階でのメモリ割り当て（これはOS側が行う）の時に保護の設定さえしておけば必ず捉えることができるじゃない。すごい。

[6]
うほ！　はりぼてOS敗北！？？

[7]
んんん？なんだこれ？？　わからんぞ？？？

えーっと？つまりこういうことなのかな？

　・アプリ専用のメモリ(セグメント)を確保。
　・そのセグメントに「ここはアプリだよ！」と属性を付ける
　・アプリとして動いている場合、DSにOS用のセグメントを代入しようとすると例外割り込みが発生

と。DSってのはデータセグメントレジスタ。つまり、アプリから書き換えたり出来るセグメントを指している。
うーむ。そうすると、たとえばOS用のセグメントが0x0100だとする。で、現在のアプリのデータセグメントが0x0200だとする。
OSが使うメモリは、物理的には0x0100〜0x01FFだとすると、たとえば0x0111番地になにかデータを書き込むことができればOSを破壊できるわけか。しかし、アプリで物理的な番地を直接指定してデータを書き込むことはできない。たとえばアプリから、「0x0111番地に30を書け！」と命令しても、実際にはセグメント+オフセット値として処理されちゃうので、物理的には0x0200+0x0111=0x0333番地しか書き換えることができない。そこで、DSをなんとか書き換えることができればいいと。こういう理屈なのかな？？？

えーっと。「OSがアプリをコールしてはいけない」ってのは、OS保護のための仕組みではなく、「とにかくx86はそうなっている」という理解でいいのかなぁ・・・
（だってそうじゃないと、このRETFを使った裏技が動作するってのがちょっとおかしいような気がする）

んんん？　P439の_asm_hrb_api。「スタックやらレジスタやらに切り替えをCPUが自動でやってくれる」というのは、今回導入したセグメント属性をセットするとそうなるってことなのかな？

あー。そっかそっか！割り込みも禁止と許可があるのかぁ！


・・・うっわぁ・・・ダメだここ。理屈の理解だけで手一杯だ。
２巡目に期待〜。

21日目

[1]
うんうん。これはよくわかるぞ。API(OS）とアプリでは動いているセグメントが全然違う。
なので、なんていうんだろう。「絶対番地」のひとつを郵便ポストみたいにして、ここで番地番号をやりとりしようというわけだね？。
（うーん。でも、これでいいのかな？アプリやらから簡単に絶対番地を活用できちゃうのって・・・）

[2]
ん？　んんん？？　えー？なんで0x1bなの？？
（あれクソ！どっか見落としてるかな？？）

休憩〜。
例によって、ここまでやったharib17hの見た目だけを改造したの作りました〜。

（もうお解りのとおり、往年のマッキントッシュのモノトーンのデザインで・・・

20日目。やった！いよいよ大台！

[1]
これはいつもの整理ですね〜。

[2]〜[3]
なるほどぉ。アプリとかから使える関数をOS側で用意してあげるわけね。・・・しかしその理屈は単純ではあるけど、実際にはいろいろ煩雑だなぁ。（各プログラムがセグメントに分かれているんだからしょうがないよね。ん？じゃ、セグメントなんか使わないで全部OSと同じセグメント内で読み込み＆実行をしたらどうかって？。それは可能だけど、そうなるとアプリはすべて、自分が何番地に読み込まれるのかを設定しなくてはいけなくなるよね。それだと、アプリが一個しか使えないとかそういう話になっちゃう）

[4]
ん？あれ？　アプリの終了まではいいけど、アプリが終了した後の処理ってなんかしなくていいのかな？。確保してあるメモリを開放したりとか？？　（あれ？ソース見落としてるかな？）

[5]
割り込み？　あ〜。あったあった。んで、割り込み番号が余っているって？。へ〜。そうなんだ！。
なるほど。なんか、処理を割り込みにしたほうが簡単だよね？
（まあそれはいままでキーボードだマウスだの割り込みをがんばってきた財産なんだけどね）

・・・INT 0x??・・・。これ、BIOSコールとかもこのパターンだったよね？。たしかMS-DOSのファンクションコールも・・・
もしかして、BIOSやらDOSコールやらって、内部では今回と同じような処理and配置をしているの？（番号こそテンテンバラバラだけど）

[6]
お〜。これこれ。こうでなくっちゃ！　(^^

[7]
むむむ？。あ〜。そっか！ PUSHADって、汎用レジスタの値を一気にどーんとスタックに積んでくれる命令だっけ。
（どのレジスタが対象でどれが詰まれないかがちょっとあやしい。あとで復習しておこう・・・）

[8]
・・・復習いらなかった。書いてありますた。(^^;
へッへぇ〜。ここは実は、珍しく予測が付いていたのだ。（笑
昔、BIOSで文字表示したりしてたことあるんで、たぶんいずれこのパターンになるんだろうなぁなんてね。

で、改造したhello2.hrbと。
・・・え"〜？失敗オチ？
さすがのKタンも疲れて頭が回らないと？？　ざんねん〜！！

19日目 [5]　終了〜

・・・げげぇぇ！。アプリの読み込みと実行って、こんなんで出来るの？。こんなんでいいの？？？

うーむ。しかしたしかに
　・それ用のセグメントを作る
　・そのセグメント（メモリ）に読み込む
　・そこへfarjump
　・実行

・・・いや、たしかに過不足はないよね？
え〜。でも、とりあえずとは言っても、こんなんでいいの？
なんかすげー！！！
（いや、なんでそんなこと言うかっていうと、アプリの実行ってもっと仰々しい仕組みなんだろうと勝手に思っていたので・・・）

19日目 [1]〜[4] 終了〜

この辺は理屈もプログラムも解るし、結果が画面に出るんでたのしいね。

（それにしても、FATの圧縮。これは知らなかった。そんなことしてたのかぁ。いや、これも同じく、昔ちょっと勉強した時にFATを読み込んで見てみたことがある。その当時の解説書には、圧縮のことがちゃんと書いてなかったのか私が見逃してたのか、理屈がわかるのにバイナリデータがチンプンカンプンだった記憶がある。）

18日目 [7] 終了〜

・・・こりゃちょっと驚いた。dirコマンド。ディスクにアクセスしなくちゃいけない。
「え”〜！ そりゃおもしろいけど、そんな処理をここでできるのかなぁ？。32bitだからBIOSも使えないはずだし。はりぼて友の会のみんなもここいらへん苦戦してるみたいだし・・・」
と思ったのだが、こんな方法を使うとは！

もちろんこれは、「OSがディスクを読んでいる」わけじゃないんだから本当じゃない。しかしそれを言うのは野暮ってもんだよね？。
学習段階・未完成の段階で、とにもかくにもファイルの処理の例が出てるわけだから。

それともう一個。
私は昔、ちょこっとここいら辺りを勉強したことがある。あるセクタを読むと、そこには決まった長さでファイルの情報が書かれている。ずら〜・・・とね。
これを処理しようと考えた私は当時、for〜nextとかを使ってすんごい複雑な処理をして、変数にその情報を格納していったんだけど、今回も出てきた構造体定義＆ポインタ宣言型を使うことで、なんにも処理しないでちゃんと分割して読めるようになるんだなぁ。
ポインタはむずかしかったけど、これが解るようになるとこんな処理でかえって簡単確実にできるんだね。すご〜い！
（スマソ。きっとCを当たり前に使える人にはえらくレベル低い部分の感動なんでしょうねぇ。お恥ずかしい・・・）

18日目 [1]〜[6]

すごいぞ。コマンドがどんどん実装できる！。もちろんこういうのは将来的に分離するのが本当だろうけど、「まずは」で進めていけるね。
（冗談でおバカなコマンドを搭載したいと思う私はおバカですかそうですか）