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なの？？
（あれクソ！どっか見落としてるかな？？）