脳log[2014-10-18～]

最終更新: 2014-10-17T00:06+0900

♪ gdipp_loader_32.exe

以前書いた不満を解消するべく慣れないことをした。

gdipp_loader_32.exeが、引数として与えられたプロセスが終了するまで終了しなくなってる。WaitForSingleObject(pi.hProcess, INFINITE);してるんだから必要なことなんだろうけど残念。

gdipp_loader_32.exeは第一引数(任意の exeファイル名)のディレクトリをカレントにして exeを起動するけど、そのせいで exeに渡される二番目以降の引数が相対パスだったときにファイルを見つけられない。例えば

検索しもってちなみにたどり着いた手順。

1. >SetEnv.Cmd
   >dumpbin /all /disasm gidpp_loader_32.exe

2. 出力を読む。CreateProcessW関数は KERNEL32.DLLからインポートする関数として３番目に列挙されていて、KERNEL32.DLLの Import Address Tableの位置は 408000となっているので、408000,408004,408008,...の３番目(408008)を覚えておく。

3. 出力を読む。コードは .textセクションに含まれている。/disasmオプションを付けたのでニーモニックで読める。さっき覚えておいた 408008で検索すると次の行(だけ)がヒットした。

   004010B3: FF 15 08 80 40 00  call        dword ptr ds:[00408008h]

   呼び出し規約の違いは知らないが、callにそなえて末尾の引数から順番に pushしてるぽいところから推測する。

   CreateProcessW(argv[0], lpCmdLine, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, working_dir, &si, &pi);

   004010B2: 52                 push        edx
   00401094: 8D 8D F4 FD FF FF  lea         ecx,[ebp+FFFFFDF4h]
   0040109A: 51                 push        ecx (これがきっと working_dirに違いない)
   0040109B: 6A 00              push        0  (NULL)
   0040109D: 6A 04              push        4  (たぶん CREATE_SUSPENDED)
   0040109F: 6A 00              push        0  (FALSE)
   004010A1: 6A 00              push        0  (NULL)
   004010A3: 6A 00              push        0  (NULL)

   51(push ecx)を 6A 00(push 0)に書き替えることはサイズが違ってできないので、その前の準備段階を含めた 8D 8D F4 FD FF FF 51(lea ecx,[ebp+FFFFFDF4h]; push ecx)を 90 90 90 90 90 6A 00(NOP;NOP;NOP;NOP;NOP; push 0)に書き替えることにする。

4. 書き替える範囲は 00401094からの７バイトだが Stirlingで開いた gdipp_loader_32.exeにそんなアドレスはない。dumpbinが出力した .textセクションの情報を見る。

   68EA virtual size
   1000 virtual address (00401000 to 004078E9)
   6A00 size of raw data
    400 file pointer to raw data (00000400 to 00006DFF)

   virtual sizeと size of raw dataの微妙な違いが気になるが、00401094-00401000+00000400 = 494のアドレスを Stirlingで表示すると目当てのバイト列があったので書き替えた。

5. 同じ要領で WaitForSingleObjectの呼び出しも 90(NOP)で塗り潰した。

すごく時間がかかった。『解析魔法少女美咲ちゃん』を参考にしようとしたが、丁度いいところで OllyDbg便利そうということしかわからなかった。済んでしまえばこの程度のことなのでバイナリエディタだけでなんとかしたいが、PEヘッダとインポート情報を読んでアドレスを変換するのが果てしなく面倒で、また、間違えやすい。アドレスもそこから読み取る値も同じバイト列だからか、すぐに区別がつかなくなる。

最終更新: 2015-01-12T01:26+0900

♪ Go言語をインストールした。

ifが値を返さないとか条件演算子がないとか*、エラーを nilと比較することはできるけど || や && のオペランドにはならないとか⁑、配列の最後の要素の後ろにカンマを置かずに改行するとカンマがないって理由でコンパイルエラーになるとか⁂、ああ、この独善的融通の利かなさ、Rubyではないな googleだから Pythonがこうなのか？という感想。

 beni/lexer/javascript.go (2014-09-24, 4.9KiB)

ベースは /shjs/lang/sh_javascript.js。

ミクロな感想

• gitコマンドがなくて >go get "github.com/..." に失敗した。手コピインストール……
• golangの regexpパッケージが re2そのままらしくて一番単純な先読みすらサポートされていないので一部のパターンを簡略化した
• マッチング処理が行ごとではなく全文一括なので改行をまたぐケースをひとつのパターンの中に押し込んでシンプルにした
• \wとか \sの差異を気にせずそのまま使ってる
• インポートは lexerディレクトリ丸ごとされてるんだけど、lexer/all.goにファクトリを登録しておかないと有効にはならない
• JavaScriptの正規表現リテラルが鬼門
• regexp.MatchStringは文字列の全体をテストするメソッドではない
• htmlフォーマッタに(未実装だけど)いろいろフラグがある。メソッド内で分岐するのでなく単目的一本道の処理を組み合わせてインターフェイスとフラグを満足するオブジェクトを構成したいと思った。フラグの組み合わせは膨大になる可能性があるので事前に定義したクラスとファクトリ関数は現実的でない。どういう方法があるだろうか。vptrと vtblをカスタムする？ 実行時コード生成？ たまらんね、他には？ Scalaには何か、型付きのダックタイピングをサポートするやり方がなかった？ あったとしてそれが解決策かは知らないけど、とにかく、間接レイヤーを挿入して自分でディスパッチしたりするのでなく、たとえそれがソースコード上のことに過ぎなかったとしても、入力と出力を直結して答えを出してる感じが欲しい。
• 色分け対象となるトークンに、LiteralStringDouble、LiteralStringSingle、LiteralStringHeredocなどが、また、総称的に扱われるのであろう LiteralStringや Literalがある。lexerの方では識別できる限り詳細なトークンを指定したいであろう。では、テーマの方で本質的な差異のないトークンをまとめて同じ色に塗ることにしようか。それを判断するには言語に関する情報が必要だ。
• 実質的にパターン最初に ^ が必須で、ポインタを１文字ずつ進めながらマッチするパターンを探していくのは
  • regexp.FindStringSubmatchメソッド呼び出しコストがかさむ
  • ^ では、与えられる部分文字列の最初を検出することができても、単語の切れ目(始まり)でない部分を除外することができない。
  • regexpパッケージのメソッド群には検索開始位置/検索終了位置を指定する引数が見当たらない。BMatch関数と同じ不備か？(20090808p03.02)。それがないと結果が変わってきたりする。re2には \K参考 も戻り読みもないけど \b(単語の切れ目)だけは影響しそう。
  • それと「FIXME: need to emit 'ch'?」と書かれている部分とが合わさって、ハイライト対象のどの部分もとりこぼしなく識別してマッチしないと、意図しないマッチが生まれたり対象の一部が(標準)出力から消えたりということが起こる。
  • マッチした位置/未試行/マッチ無しを記憶しておくのが効果的だと思う。(検索開始位置を指定できないと \b のマッチの仕方が不定だけど)

ただのデータファイルなので言語の勉強にはならないよね……。フレイバーの違いライブラリの違いに足を取られるのがわずらわしいしもどかしい。CLRと MSIL？

最終更新: 2014-09-20T17:08+0900

♪ にゃんころりん

最近撮ったのでもない画像を今日アップロードする理由。

俺が座椅子に横になって本*を読み始めると、ベッドの上で丸くなったり伸びたりしていてもすぐに起き上がっていそいそと近づいてきて脇(座椅子の上だから狭い！夏は暑い！)に居場所を要求してきた。一昨日(おととい)にはもう階段もベッドにものぼれなくなっていたけど、座椅子にはやはり乗っかってきた。まんまと、まんまと誘いこまれてやんの。それでこそ二階から下ろしてきて待ち構えていたかいがあるってもんだ。もっとも、しつこく手招きしていると膝の上でしばらくお愛想したあとでタッと何の未練も感じさせずに去っていく付き合いのいいにゃんこのことなので、まんまとのせられているのがどちらかわかったものではないが。