Wizard Bible 増刊号 No.2
2007 年 10 月 24 日

1 章：ぬるま湯 Java 2 章：XHR のリバースエンジニアリング 3 章：Wizard Bible の紹介
1 章：ぬるま湯 Java
金床 著

その後まったく意味を理解しないまま（いわゆるコピペプログラミングで）何故かアプリケーションを作り続けることができ、1.1. はじめにおそらく数万行ほどは「意味はわからないが目的の動作をしていややあいまいな記憶だが、おそらく 2001 年ごろ、筆者はメイる」ソースコードを書き続けた。今考えると、この段階では BCBン言語を Java へと切り替えた。
それまでは 3 年ほど C++（Borlandが用意してくれる VCL というクラスライブラリをただ使っていC++ Builder 以下 BCB）を使っていた。気が付いてみれば 2006る状態だった。

年ももう後半であり、5 年近くの間殆ど Java だけで過ごしてきたことになる。この 5 年間仕事でも趣味でもコードを書き続けて転機が訪れたのは書店で「C++ FAQ」という本を購入したとききたが、そのほとんどすべての成果物が Java 製である。

だ。この時点ではもうかなりのボリュームのソースコードを書い

最近になって（筆者の本業である）ウェブアプリ周辺では、Rubyた経験があり、また VCL についてはかなり使いこなせていた（とが注目されている。耳にしている人も多いかと思うが、Ruby on思っていた）ので、「オレは C++は結構できるぜ」とすさまじい

Rails というフレームワークが起爆剤となり、世界中で爆発的に勘違いをしていたのである。しかしこの本を読んでも一体何が書Ruby の使用人口が増えているようだ。また、Python や PHP などいてあるのかさっぱり理解できなかった。答えではなく、質問のもこの 5 年でずいぶんメジャーになってきたようで、活気がどこ意味もわからなかったのである。「デストラクタって何だ？」とからともなく伝わってくる。

いうようなレベルであった。つまりその時点では C++という言語は殆ど何も理解できておらず、ただ使いやすく設計されていたプログラマには、どのプログラミング言語を使うのかという問VCL を使ってちょこちょこ作業ができる程度のレベルだったのだ。

題が常につきまとう。かつてサラリーマン時代に COBOL で仕事をしたことがあるが、その後 Perl を覚えたときに「これは生産性「C++ FAQ」を読み進めるうちに自分が作ったプログラムが（主が 20 倍は違うぞ」と驚愕したものだ（といっても実際には COBOLにメモリリーク系の）欠陥だらけ、問題だらけであることがわかと Perl では守備範囲が違うので、単純に比べるべきではないのってしまい、「今まで作っていたのは何だったんだ」という強いだが）。どのプログラミング言語を選択するかでその後の効率は脱力感にさいなまされた。しかし何とか頑張ってその時点ではじ大きく変わってくる。

めて「言語としての」C++を勉強しはじめ、他の書籍も片っ端から読み漁り、徐々にまともな C++プログラマへと進歩していった。

かつては「どの言語がいいのか？」という話題を見るたびに「より多くの言語を自分で使える状態にしておき、何か作るべきもの

1.3. Java との出会いを前にしたときに最適の言語を選ぶ姿こそが正しい」と思っていC++は間違いなく「最強の」そして「最狂の」プログラミングたのだが、いつのまにか「これも Java、あれも Java、それも Java」言語である。オブジェクト指向的に使うことで規模の大きいアプになってしまっていた。Java のぬるま湯に頭までつかっているリケーションも作れるのに、インラインアセンブラで CPU レベルのだ。最近になってだんだん他の言語も覚えてみたいなという欲でのプログラミングも可能であり、またテンプレートを使いこな求が出てきたのだが、その前になぜこんなにも Java だけで過ごせば想像を絶する高度なプログラミングが可能となる（ちなみにすようになってしまったのか、少し考えてみることにした。

筆者はテンプレートについては STL を使う程度のレベルまでしか理解できなかった）。そして実行速度も速く、多くのプラット

1.2. C++との出会いフォームでサポートされている。

1998 年頃はとにかく Windows 上でネイティブで動作するアプ

しかし欠点も多い。まず何と言っても「落とし穴」が多すぎる。

リケーションを作りたかったので、BCB を選択した。というか実

普通にのんきにプログラミングしていると、かならず足をずっぽは最初に Visual C++を買ったのだが、意味がわからずアプリケり取られてしまうのだ。C++で罠を避けるためには常に頭の中でーションを作れなかったのである。いわゆる挫折である。プログ「この場合はアレに気をつけないといけない…」「こういうケーラミングのプの字もわからなかった頃だったので、いきなりスではコレはタブーで…」と最大限の注意を払わねばならないの

Visual C++は難しかった（…今さわっても理解できないような気だ。これは非常に疲れる。

もするが）。

また、クロスプラットフォームのコードを書くのことが実質不BCB はやさしかった。難易度だけでなく、プログラマに対して可能である。これは同時にインターネット上で参考になりそうな、やさしい開発環境だった。何もしなくても矢印のボタンをクリッあるいは利用できそうなソースコードを見つけても、手元の環境クするだけでウィンドウプログラムが起動するのだ。Visual C++

ではコンパイルできず動かない、というケースが多いことも意味で挫折した後だったのでこのやさしさは筆者の心をわしづかみする。BCB 時代にはさんざんこれで泣かされた。高いスキルがあにし、アンチマイクロソフトの旗印を鮮明にすることとなった。

れば移植できることもあるのだろうが、当時の筆者には難しい話

1

であった。

「言語と開発環境は一体だ」と再認識した。

さらにセキュリティの問題がある。バッファオーバーフローやフォーマットストリングバグなど、コンピュータを乗っ取ること筆者が考える Java の魅力は、Eclipse あってのものだ。エデのできる致命的なセキュリティホールを作る可能性が高い。

ィタで編集中にリアルタイムでコンパイルが走り、エラーとなる箇所に赤線が入る。保存を行えばほぼその瞬間にコンパイルは完

そんな C++との激しい戦いで消耗しつつあった筆者の前に、了しているので、すぐに実行し動作を確認することができる。つJava が姿を現した。

まりコンパイル型言語とインタプリタ型言語のおいしいところを両取りしているのだ。

1.4. 言語と開発環境
このころ（そして今もだが）、筆者にとってはプログラミングいわゆる「コンパイル型言語」では変更するたびにコンパイルはそれ自体が目的ではなく、ソフトウェアを完成させることが目する時間が必要となるので、その間にプログラマの思考が中断さ的となっていた。そのため言語仕様だけでなく、どのようなクラれてしまうと言われる。そのため「インタプリタ型言語」は保存スライブラリが使用できるのかという点が非常に重要になってして即実行できるから思考が中断されず、多くのプログラマに支いた。

持されているのだ。しかし「インタプリタ型言語」は実行するまJava に手を出して最初の印象は「クラスライブラリが信じらで文法エラーがあるかどうかわからないという欠点を持つ。特にれないほど充実している」というものだ。VCL も悪くないライブ

筆者のようにセンスがないプログラマは何度実行してもエラー、ラリだったのだが、筆者が特に作りたかったネットワーク関係エラー、エラーとなってしまい、そのたびに「何行目でエラー（ソケット関係）のライブラリはイマイチだった（そのためかなだ？」とエラーメッセージを読み解いてエディタに戻って…といり苦労して自作した）。

う作業を繰り返すはめになる。

しかし Java は違った。最初から完璧な形でソケット関連のライブラリが用意されていたのである。これには感動した。そして

しかし Eclipse ならば編集中に文法エラーを発見でき、思考をこのクラスライブラリが「標準」であり、多くのプラットフォー中断されずに即実行できる。これはあまり大きな声で語られていムで同じコードが稼働することに驚いた。

ないが、Java+Eclipse という組み合わせを決定的に魅力的なものにしている最大の要因ではないだろうか。

言語としての Java も筆者を魅了した。C++にあったようなたくさんの落とし穴は殆ど見あたらず、気軽なプログラミングが可能他にも関数の名前を変更したいときなどに使えるリファクタとなっていた。C++で感じていた「う〜ん、これはちょっと問題リングの機能やクラス間の継承関係を把握できる機能など、今やなんじゃないのか」という点がことごとく解決されていたのであ筆者にとっては「必須」となってしまった機能が Eclipse には満る。
「C++の反省をふまえて開発された」という点が筆者のニーズ載されている。筆者にとって「Java」とは同時に「Eclipse でのとぴたりと一致した。

開発」を意味するものとなっている。

しかし開発環境はいまいちだった。BCB でプログラミングを覚1.6. GUI

えた筆者にとって、統合開発環境（IDE）はあって当たり前のもしばらく CUI のプログラミングとウェブアプリケーションののだ。Java を勉強する際は javac などを使うコマンドラインで開発ばかりやっていたのだが、やはり GUI のソフトウェアも作りのプログラミングからはじめたものの、javac の起動はあまりにたい。しかし現状、Java での GUI 開発はまだまだ問題がある状も重く、「Java は重い」というイメージを増幅することとなった。

態である。
BCB で可能だった「マウスでボタンなどの部品を選び、同じく Borland から出ていた Borland JBuilder を使ってみたぺたぺた貼り付けて GUI を作る」というプログラミングはまだ実ものの、Swing で作られた IDE はあまりにも重く、またネイティ現できていないのだ。

ブ GUI とのルック&フィールの違いは違和感が大きすぎた。

Java が標準でサポートしている Swing のような GUI は、筆者にとっては受け入れられないものだ。あの違和感と動作のもったそこで出会ったのが Eclipse である。

り感は、とうてい使いたくなるものではない。苦労して作ったアプリケーションがあのような使い心地では、満足できないのであ1.5. Eclipse

る。

Eclipse で最初に驚いたのはコンパイルがあっという間に終わることだ。BCB ではコンパイルというのは数分、時には 10 分か

そこで最近は SWT というライブラリを使っている。これはかるものだったのだが、Eclipse ではエディタ上で変更点を保存

Eclipse も使っている、Java でネイティブな GUI を使うアプリケ

するとほぼその瞬間に終わるのである。
「Java は重い」という常ーションを作成できるものだ。これはなかなか悪くない。ただ現識が覆された。

状では開発環境が追いついていないため、どうしてもソースコーまた、ネイティブ GUI で動作するので使っていて気持ちがいい。

ド内でボタンのサイズなどの数値を直接入力するスタイルを取

エディタに vi を使えないという点は残念なのだが、それを補っらざるをえず、開発効率はとても悪い。Eclipse にプラグインがてあまりある魅力に溢れている。Eclipse を使い始めたことで、あるのだが、バグが多く使い物にならない状態だ。

2

2 章：XHR のリバースエンジニアリング
1.7. その他いろいろ

金床 著

そして筆者はウェブアプリケーション開発で食っている人間なので、やはりサーブレットエンジンのような効率的に開発され2.1. はじめにたサーバーサイドの仕組みは魅力的だ。C++などでももちろんウXHR とは XMLHttpRequest のことである。これを使うと、ウェェブアプリケーションを作ることはできるのだが、かなり効率がブページ中に埋め込まれた次のような JavaScript のコードによ悪いと言わざるを得ないだろう。また、RDBMS と連携する箇所もり、比較的自由度の高い HTTP 通信を行うことができる（このコ多いので、JDBC のように多くの RDBMS をサポートするライブラードは IE でのみ動作する）。

リが使えるのもありがたい。これらの要素は言語が広く使われてはじめて実現される側面もあるため、「シェアが広い」という点

var request1 = new ActiveXObject("Microsoft.XMLHTTP");が言語自体の魅力になるという考え方もできるだろう。

request1.open( 'GET', 'http://www.jumperz.net/index.php',false );request1.send( null );1.8. まとめalert( request1.responseText );以上により、筆者がプログラミング言語と開発環境に求めるのは次のような点である。

しかし XHR が存在することで、ウェブアプリケーションに XSSクラスライブラリが充実しており、また高いクオリティを脆弱性が存在する場合、XHR に TRACE メソッドを送信させること持つで XST（Cross Site Tracing）攻撃が可能となる。この場合、Basicネットワークプログラミングが可能である（できれば SSL認証の情報や HttpOnly で発行された Cookie が攻撃者に奪われるもネイティブでサポートする）可能性がある。そのため Firefox や Opera の最近のバージョンでエディタの保存と同時にコンパイルが（高速で）終わり、は XHR を使用する際にメソッドとして TRACE は指定できないようエラー箇所がすぐわかるになっている。IE でも同様に比較的新しいバージョンでは TRACE関数名の変更などのリファクタリングの機能があるが禁止されている。

オブジェクト指向をサポートしているネイティブ GUI のアプリケーションを開発可能である

また、メソッドと同様に、XHR の送信先となるポート番号もセクロスプラットフォームである（Windows と Linux がサポーキュリティ制限の対象とすべきだ。例えば 25 番ポートに接続でトされていればとりあえず満足）きてしまうと、XHR を悪用してスパムメールを送信されてしまう

バッファオーバーフローなどを起こすことができない（ユーザのブラウザにスパムメールを送信させる）可能性が考え関数の中身を実行時に書き換えることができるられる。つまり次のようなコードは失敗するべきと考えられる。

ウェブ用の効率的なエンジンが存在する
RDBMS との相性がいい

request1.open( 'GET', 'http://www.jumperz.net:25/index.php',false );このように情報を整理してみると、やはり Java が頭ひとつ抜さてこのようにき出て魅力的であることがわかる。しかしあまりにもぬるま湯でTRACE メソッドは禁止刺激がないことも確かだ。そこで、Ruby や Lisp などの勉強もしポート番号について、例えば 25 番などは禁止てみようかと思っている（Lisp の勉強は少しだが開始した）。
Rubyというセキュリティ制限がかけられている XHR だが、どうも IEについては Eclipse 並に充実した IDE が登場することを期待してについてはこの制限のかけ方がお粗末であるように思える。そこいる。

で今回はリバースエンジニアリング祭りをおこない、IE の XHR

5 年後には一体何を使っているだろうか。

実装がどこでどのように行われているのかを調べてみた。
2.2. メソッドの制限
TRACE メソッドを禁止するべき場所は open 関数の第 1 引数だ。
この引数はずばり HTTP リクエストのメソッドを指定するもので、普通は GET や POST が指定される。HTTP のメソッドというのはア
ルファベットの大文字と相場が決まっているので（よい子は相場じゃなくて RFC を見てくだちい）、とりあえずまともなプログラ
マなら[A‑Z]{1,20}のような感じで入力をチェックし、その上で「TRACE」ではないことを確認するだろう。
しかし、さすがマイクロソフト様。なんと次のようなおどろきのコードで TRACE が飛んでしまうのだ。
request1.open( '¥nTRACE', 'http://www.jumperz.net/index.php',false );3

76674226 68 58426776

PUSH WININET.76674258

この場合、送信される TCP のデータストリームの内容は最初に7667422B 53

PUSH EBX

余分な 1 バイト（0x0D）が付いた TRACE メソッドの HTTP リクエ

7667422C FFD6CALL ESIストとなる。しかし Apache や IIS はこれを受け付けてしまうた

7667422E 85C0TEST EAX,EAX

め、XST は成立してしまう。つまりこの IE の XHR における TRACE

76674230 0F84 DBC30100の禁止は、簡単に回避されてしまうのだ。

76674236 6A 05

PUSH 576674238 68 50426776

PUSH WININET.76674250

さらにひどいことに、次のようなコードさえ動いてしまう。

JE WININET.76690611

7667423D 53

PUSH EBX

7667423E FFD6CALL ESIvar method = "GET¥x09/index.php¥x09HTTP/1.0¥r¥nHost:hogehoge¥r¥nX‑Foo:";

76674240 85C0TEST EAX,EAX

request1.open( method, 'http://www.jumperz.net/index.php',true );76674242 ^0F85 09F5FFFF

JNZ WININET.76673751

request1.send( null );76674248 E9 C4C30100

JMP WININET.76690611

このテクニックを使うとクライアントサイドでの HRS をはじ; ASCII "TRACE"; ASCII "TRACK"

このように、StrCmpNIA という API を使って何か（おそらくユめ、様々な問題が引き起こされるだろう。

ーザが指定したメソッド）と「TRACE」という文字列を比べているのである。
「ビンゴ！」というやつだ。

2.3. ポートの制限
Firefox や Opera では XHR で接続可能なポートについても厳し

さて「これは何だ？」と思ったのは「TRACK」の部分である。

く制限しており、スクリプトを含むページと同じポートにのみ接TRACE と同様に、TRACK というメソッドも禁止しているのだ。そ続可能のようだ。しかし IE ではこの実装も奇妙であり、21 番ポ

こでウェブを検索してみると、どうやら IIS のオリジナル実装で、ートや 25 番ポートには接続できないのだが、22 番ポートや 23TRACE と同様の働きをする HTTP のメソッドということである。

番ポートには接続できてしまう。接続できたからといってそれほ

XST では TRACE と同様に TRACK も問題になる、と指摘している文

ど深刻な問題が発生するわけではないのだが、メソッドの禁止の章を見つけることができた。TRACK というメソッドの存在は知ら実装と同じく、どのように実装されているのかが気になるところなかったので、これは勉強になった。

である。
ここで StrCmpNIA の第 3 引数として「5」を指定している（PUSH
2.4. 祭り開始

5 の部分）ので、文字列の比較は 5 文字目までしか行われない。

まずは IE における XHR の実装がどの DLL で行われているのか

そのため面白いことに、ユーザが「TRACEAAAA」や「TRACKBBBB」を調べてみることにした。system32 ディレクトリにおいて「grepのような文字列を指定した場合にも、これは禁止される。

‑i xmlhttprequest *.dll」としてみると、msxml3.dll などのいくつかの DLL ファイルがヒットする。

2.5. 一般の開発者を無視した実装

TRACE の禁止が明示的に行われているようであれば「grep ‑i

さて鋭い読者なら同様の疑問を持っているかと思うが、この実trace msxml3.dll」でヒットしそうに思えたが、これはヒットし装には大きな問題が存在している。TRACE と TRACK の禁止は明らない。また TRACE というのはよく使われる単語なので、「grep

かに XST 対策である。XST 対策は IE の XHR の実装に対して行わTRACE *.dll」などとしてしまうと大量の DLL ファイルがヒットれるべきだが、実際には wininet.dll の中で行われてしまっていしてしまい、結局どの DLL において TRACE の禁止が実装されている。

るのかはわからない。
wininet.dll というのは IE 以外のソフトウェアからも利用さ
そこで Dependency Walker というツールを使って msxml3.dllれるライブラリであり、一般のアプリケーション開発者が HTTPが依存している DLL をリストアップしてみることにした。リスト

クライアントを作る際にも利用する可能性が高い。これは例えばアップされた中で、まずは winhttp.dll というファイルが怪しい次のようなコード（本稿を書く際に使ったもの）で行われる。

ように思えた。しかしこのファイルの中身を TRACE で検索してみても「ERROR̲SYSTEM̲TRACE」という文字列がヒットするだけで、#include <windows.h>

TRACE メソッドの制限が行われているわけではないようだ。そこ#include <wininet.h>

で、次に怪しいと思われる wininet.dll を調べてみた。すると#include <stdio.h>

HttpOpenRequest という関数の中で、それらしい箇所を見つけることができた。

int main( int argc, char* argv[] ){7667421E 8B35 B4136676

MOV ESI,DWORD PTR DS:[<&SHLWAPI.StrCmpNIA>];HINTERNET hInternet;

SHLWAPI.StrCmpNIA
76674224 6A 05

HINTERNET hSession;
PUSH 5

HINTERNET hReq;

4

ることがわかった。これは以下の箇所である（ちなみにこちらは少し古いマシンで調査したので、2.4 で示したリストとは DLL のhInternet = InternetOpen(バージョンが異なる）。

"TEST",
INTERNET̲OPEN̲TYPE̲DIRECT,
NULL,

7020DDAA 0FB74424 04

NULL,

7020DDAF 83E8 00

SUB EAX,00 );7020DDB2 74 1E

JE SHORT WININET.7020DDD27020DDB4 83E8 15

SUB EAX,15hSession = InternetConnect(MOVZX EAX,WORD PTR SS:[ESP+4]

7020DDB7 74 19

JE SHORT WININET.7020DDD2hInternet,7020DDB9 83E8 04

SUB EAX,4"www.jumperz.net",

7020DDBC 74 14

JE SHORT WININET.7020DDD280,7020DDBE 83E8 55

SUB EAX,55

NULL,

7020DDC1 74 0F

JE SHORT WININET.7020DDD2NULL,

7020DDC3 83E8 09

SUB EAX,9INTERNET̲SERVICE̲HTTP,

7020DDC6 74 0A

JE SHORT WININET.7020DDD20,7020DDC8 83E8 18

SUB EAX,180 );7020DDCB 74 05

JE SHORT WININET.7020DDD27020DDCD 33C0

XOR EAX,EAX

7020DDCF C2 0400

RETN 4hReq = HttpOpenRequest(hSession,"TRACE",

7020DDB4 の 15 は 10 進数で 21 である。EAX にはユーザが指定"/index.php",

したポートが入っており、まず 21 を減算してそれが 0 であるかNULL,どうかを調べている。つまりユーザが FTP のポートである 21 をNULL,指定した場合にはここで引っかかる。つぎにさらに 4 を減算してNULL,それが 0 であるかどうかを調べている。つまり SMTP のポートで0,ある 25 を指定した場合にはここで引っかかる。以下同様に比較

NULL );

が行われており、結果として禁止されているポートは21/25/110/119/143（FTP/SMTP/POP3/NNTP/IMAP）であることがわ

if( hReq == NULL )かった。

{
printf( "null" );ちなみにこの箇所については、0x05 で示したソースコードの}80 の部分（ポート番号）を接続可能なポート（22 番など）と接続が禁止されているポート（21 番など）に変更した exe をそれInternetCloseHandle( hInternet );ぞれ OllyDbg でトレースしてログを取り、ログの内容を比較する

InternetCloseHandle( hSession );こ と で特 定 する こと が でき た。 メ ソッ ドの 制 限は ただ単 にInternetCloseHandle( hReq );「TRACE」という文字列を検索するだけで見つけることができたが、こちらは少々手間がかかった。

return 0;}

このように、ポートについてもメソッドの場合と同じようにwininet.dll 内に直接制限が設けられている。しかし HTTP クラ
wininet.dll の中で TRACE と TRACK が禁止されてしまったため、イアントが 21 番ポートなどに接続したい場合というのはあまり一般の開発者が作成する IE とは関係のない HTTP クライアントア考えられないので、メソッドとは異なり、こちらの副作用はほとプリケーションも影響を受けてしまう。つまりこれらのアプリケんどないと考えられる。

ーションからも TRACE や TRACK の送出が禁止されてしまうのだ。
これは開発者を無視した暴挙であるように感じる。TRACE を送出

2.7. 祭りの後のまとめするような専用のクライアントアプリケーションがそれほど多

今回は IE の XHR の挙動について、実装を行っている箇所をひく存在しているとは思わないが、本来ならば msxml3.dll 内などとりリバースエンジニアリング祭りによって特定し、実際に読んで実装すべき処理である。

でみることで、どのようにセキュリティ制限が行われているのか、またその影響などを把握することができた。開発者を無視して強2.6. ポートの制限

引に（しかも不完全に）TRACE を禁止するというマイクロソフトポートの制限についても同様に wininet.dll 内で行われていの手法は衝撃的ですらある。筆者は元々WININET のような MS 依

5

3 章：Wizard Bible の紹介

存のライブラリの利用は避けているが、これはやはり正解であったと思うことになった。

IPUSIRON 著

ところで KG 先生主催のリバースエンジニアリング祭りが秋に3.1. Wizard Bible とはも開催されるとのことなので、国内最高レベルのリバースエンジ

1 章、2 章で取り上げた記事は、それぞれ Wizard Bible vol.29

ニアリング関連情報を提供する Wizard Bible の読者・著者の皆（2006 年 11 月リリース）、Wizard Bible vol.34 (2007 年 6 月

様 に はふ る って 参加 し てい ただ き たい 。筆 者 は今 回つい にリリース)から抜粋したものです。

OllyDbg でのトレースログの取り方を覚え、また本稿のネタを調

Wizard Bible（http://wizardbible.org/）とはインターネッ

べるのに丸一晩かかったほどのハイスキルなので、参加しても学トで毎月公開されているオンライン雑誌です。内容は幅広い意味ぶべきことがあるか疑問だが、いちおう参加しようと思っている。

でのセキュリティを扱っております。また、誰でも無料で読むことができます。
3.2. Wizard Bible vol.36 の紹介
著者・読者の方々のおかげで、2007 年 9 月に Vol.36 を公開することができました。増刊号を手にとっている皆様にも雰囲気がわかるように、Vol.36 の目次を紹介します。ただし、この場では著者名は伏せておきました。
マニアック Java プログラミング第 7 回: 〜Java クラッキン
グ〜Windows システムプログラミング 番外編 〜Java〜
Windows システムプログラミング Part2 〜デバッグ〜
リバースエンジニアリング実践 khallenge へのチャレンジ
その 1
リバースエンジニアリング実践 khallenge へのチャレンジ
その 2
はじめてのハッキング 〜バッファオーバフローの利用〜
基礎暗号学講座・第 11 回 〜原始元判定アルゴリズム〜
これはあくまで一例であり、過去にも多くの記事を公開しております。興味がある方は是非 Web サイトにアクセスしてみてください。
3.3. Wizard Bible vol.37 の原稿募集
Wizard Bible vol.37 の原稿を現在募集してします。締め切り
は 10 月 29 日（月曜日）です。技術的な記事だけに限らず、セキュリティのイベントのレポートなどでも構いません。もちろん、Black Hat Japan 2007 のレポート記事も募集しています。どうか宜しくお願い致します。
なお、
募集やりリース時の告知などは http://akademeia.info/で行っています。

6