逆コンパイラCodeReverseを作る

CodeReverseは、片山博文MZが開発している、Windows用の逆アセンブラ兼ダンプツールです。
最終的には「リバーシブルな」逆コンパイラを目指しています。

CodeReverse公式サイト
http://katahiromz.web.fc2.com/codereverse/

GitHubレポジトリはこちら
https://github.com/katahiromz/CodeReverse

【実行可能ファイル（PE形式）関連】
The Portable Executable File Format
http://www.csn.ul.ie/~caolan/publink/winresdump/winresdump/doc/pefile2.html
Windows EXEファイル形式
http://home.a00.itscom.net/hatada/mcc/doc/win32exe.html
インポート情報
http://hp.vector.co.jp/authors/VA050396/tech_07.html
A Tour of the Win32 Portable Executable File Format
http://msdn.microsoft.com/en-us/library/ms809762.aspx

【アセンブラ関連】
X86アセンブラ (WikiBooks)
http://ja.wikibooks.org/wiki/X86%E3%82%A2%E3%82%BB%E3%83%B3%E3%83%96%E3%83%A9/16%E3%80%8132%E3%80%8164%E3%83%93%E3%83%83%E3%83%88
x64 アセンブリ言語プログラミング
http://homepage1.nifty.com/herumi/prog/x64.html
x64 アセンブリーの概要
http://www.isus.jp/article/introduction-to-x64-assembly/
x64 の入門書
http://msdn.microsoft.com/ja-jp/magazine/ee230241.aspx
インテル日本語技術資料のダウンロード
http://www.intel.co.jp/content/www/jp/ja/developer/download.html

【遅延読み込み関連】
DLLの遅延読み込み（delay loading）
http://www.glamenv-septzen.net/view/671
UNDER THE HOOD (delayload)
http://www.microsoft.com/msj/1298/hood/hood1298.aspx
DLL遅延ロード情報をPythonで
http://www.glamenv-septzen.net/view/677

【スタックフレームなど】
スタックフレーム
http://www.c-tipsref.com/words/stackframe.html
Unprototyped Functions
http://msdn.microsoft.com/en-us/library/6yy8aw4d.aspx
Varargs
http://msdn.microsoft.com/en-us/library/dd2wa36c.aspx
呼出規約
http://ja.wikipedia.org/wiki/%E5%91%BC%E5%87%BA%E8%A6%8F%E7%B4%84
Caller/Callee Saved Registers
http://msdn.microsoft.com/en-us/library/6t169e9c.aspx
Return Values (C++)
http://msdn.microsoft.com/en-us/library/7572ztz4.aspx
Prolog and Epilog
http://msdn.microsoft.com/en-us/library/tawsa7cb.aspx
Parameter Passing
http://msdn.microsoft.com/en-us/library/zthk2dkh.aspx
Overview of x64 Calling Conventions
http://msdn.microsoft.com/en-us/library/ms235286.aspx

【逆アセンブル・逆コンパイル技術に関して】

Ｃの逆コンパイラはどこまで実現可能か
http://www5d.biglobe.ne.jp/~noocyte/Programming/Decompile.html
逆コンパイラ - Wikipedia
http://ja.wikipedia.org/wiki/%E9%80%86%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%A9
逆アセンブラ - Wikipedia
http://ja.wikipedia.org/wiki/%E9%80%86%E3%82%A2%E3%82%BB%E3%83%B3%E3%83%96%E3%83%A9
エイリアス解析 - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%A8%E3%82%A4%E3%83%AA%E3%82%A2%E3%82%B9%E8%A7%A3%E6%9E%90
エスケープ解析 - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%A8%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%97%E8%A7%A3%E6%9E%90
コールグラフ - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%AB%E3%82%B0%E3%83%A9%E3%83%95
シェープ解析 - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%A7%E3%83%BC%E3%83%97%E8%A7%A3%E6%9E%90
データフロー解析 - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%95%E3%83%AD%E3%83%BC%E8%A7%A3%E6%9E%90
ポインタ解析 - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%9D%E3%82%A4%E3%83%B3%E3%82%BF%E8%A7%A3%E6%9E%90
制御フローグラフ - Wikipedia
http://ja.wikipedia.org/wiki/%E5%88%B6%E5%BE%A1%E3%83%95%E3%83%AD%E3%83%BC%E3%82%B0%E3%83%A9%E3%83%95
制御構造 - Wikipedia
http://ja.wikipedia.org/wiki/%E5%88%B6%E5%BE%A1%E6%A7%8B%E9%80%A0
静的単一代入 - Wikipedia
http://ja.wikipedia.org/wiki/%E9%9D%99%E7%9A%84%E5%8D%98%E4%B8%80%E4%BB%A3%E5%85%A5

パッと思いつくのは
・アドレスにラベルを割り付ける
・関数を切り分ける
・スタックフレームから関数引数・ローカル変数・戻り値を切り出す
・if/for/switchを抽出して構文化する
・DLLからロードされるシンボルを置き換える

解説しているサイトとかあるかは調べてないので知らん

どうせ defineされた定数をマクロ名に戻せないとか
構造体復元が難しいとかあるから大したことはできん

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

ネタスレはマ板でやれよ。

> Ｃの逆コンパイラはどこまで実現可能か
アフィサイト晒してんじゃねーよ。 内容もちょい微妙だし。

まず、アセンブリから C/C++ へのトランスレータは簡単だろ？
そっからどの程度 C/C++ らしい表現にするかが問題なんだろ？
何から手を付けてどういう順番でやるつもりなの。

まずは関数の切り分け(手元では入り口を解析する形でほぼ完了)。次は関数情報とスタックフレームの解析。
そして中間表現の定義と中間表現への変換。さらに構文解析と型情報の処理。
トランスレータって言ってもそんなに簡単じゃない。

リソースのダンプでいいのないか(オープンなの)？

関数には__cdecl、__stdcall、__pascal、__fastcall、単純ジャンプ関数の五種類あるんだけど、これをどうやって判別するかという問題がある。

遅延ロード情報の取り込みもしたい。ソース希望。

OllyDbgじゃダメなんか
分かってる人には充分だろ

ネタスレではありません。私は本気です。明日、OllyDbgのソースをDLしてみます。
CodeReverseは、NASMのコードを一部拝借しています。
多分、構文解析用のインクルードファイルが必要になると思います。
MinGWから頂くかも知れません。ライセンスはどうするか？ アイコンのデザイン、洒落てるでしょ？

できたらよんで。

>>11
> MinGWから頂くかも知れません。ライセンスはどうするか？ アイコンのデザイン、洒落てるでしょ？
MinGWのソース使ったら、配布するときのライセンスはGPLになると思う。
一部パブリックドメインらしいけれど。

アムロの親父みたいに俺の親父もボケてしまった。
たしかに昔はある分野で日本一の技能をもってた。俺の目標は親父だった。
今は硬い世界の殻に閉じこもってしまって、もはや日常会話しか通じない。

うーむ、今のところこの世にまともなC/C++の逆コンパイラが
存在しない事を考えても片山程度の技術力で作れるとは思えんが・・・

ま、なんかできたらまた呼んでくれ

ヘッダファイルもプリプロセッサも要るから、単純にMinGWに寄生する形にします。
バージョンアップの度にいちいちでっかいファイルをダウンロードさせるのも不憫だから。
ライセンスはGPLになる予定です。

つーか、片山GUIはどうした？予想通り挫折したのか？

そんなんじゃ逆コンパイラなんてもっと無理だろ

自動車の命はエンジンでしょ。GUIは後で自由に作れるから。

自動車の命は乗り心地だと思う

>>19
そういう問題じゃねーだろｗ

お前にはモノを最後まで作り上げる能力が無いって事だ
あれだけWin32APIやMFCに代わるGUIを作るって豪語してたろ
多分お前はこの逆コンパイラも作れないし、後になってもGUIも作れんよ

まあ一人で色々作ってたら未完成になることは多い。
そういう未完星人の同類なら、GUI作りくらい協力してやってもいい。
だが残念だがそれは無理だ。なぜなら彼が作っている物は俺よりしょぼい。
もはや彼が俺に「あなたのプロジェクトに協力させて下さい」と頼まなければいけないレベルなのだ。
残念である。世の中は不条理に満ちている。

まあ誰もが出来ないと思ってるよ

グラフィックライブラリもこれを最後に音沙汰なしだしな

975 名前：片山博文MZパンク ◆0lBZNi.Q7evd [sage] 投稿日：2013/03/21(木) 03:21:59.90
ＭＺＣ２順調に開発中。。。

順調に開発中クソワロタｗｗｗ

どこが順調なんだよｗｗｗ

CUIの有り難みがわからない人とは話しが合わないっす。
CUIにパイプラインをつなげてGUIを作るなんてお茶の子さいさいっす。
俺はサイドビジネスで忙しいから、空いた時間で作ってるっす。
CUIの使い方も知らない人はうざいから消えてね。

出来ない人間の言い訳きたｗｗｗ

ふーむ、CUIのありがたみがわかってる人間がなんでわざわざ
二番煎じのGUIを作ろうと思ったのか。しかもオリジナルより劣化してる。

更には、お茶の子さいさいと言いながら、いまだに何の成果物も出せないのはこれいかに。
>>23のレスからもう半年も経過しているが。

俺は貴様らよりも自由じゃないから。夜遊びはできないし、インターネットに
つなげてもらえないし。パソコンの使用時間は制限されてるし。
この書き込みも見張りに見つからないように携帯から書き込んでいるところ。

典型的な口だけダメ人間の末路だなｗ

こりゃアカンで。ちょっと期待してたらどうやら>>1の人格・人間性に
相当の問題アリやな。

クロスワードギバーというパズル作成ソフトで結構反響あった。MZ KeyLoggerもわりと人気あるし。

そうそう幅広くニッチなところ狙ってけ。おまえはわけのわからんものを大量に発明して東京都知事選に変態枠で出馬するようなタイプなんだ。

× 大量に発明して
○ 大量に「発明するぞ」というだけ言って

>>32
当選は枠があるけど出馬は出たきゃ出れるんじゃなかったっけ？

エクスポート名の@の右の数字は引数全体のサイズだよね？

で、__stdcallの引数全部のサイズが命令retの第一オペランドの値だよね？
そして、スタックフレームはebpとespの値の増減を調べないとわからないんだよね？

キャバクラでかわいいホステスと夜遊びしたいな

>>9は間違いね。__pascalなんてないし、64ビットに言及がないし、単純ジャンプ関数って何じゃそれ

以下、sage進行でよろしくお願いします。

片山死ねよ

>>35-36
Win32 べったりの話？ 何にも知らないんだね。

DEF ファイルを使った DLL からのエクスポート
で検索してご覧、MSDN 内のページが引っかかるから。
悪いけど、主要な（少なくともターゲットとする）コンパイラやアセンブラやリンカのマニュアルを読んでから質問してくれる？
ていうかブログでやってくんない？

ブッブー、defファイルではなく__stdcall,__fastcall関数のmanglingの話でした。

manglingされたシンボル名から元の名前を求めるのは大変みたいですね。

片山にすら馬鹿にされる>>41w

>>43
まぁだがコンパイラ毎ではあるもののマングリングは明確な規則で行われてるわけで…
それを難しいとか言ってるようではC/C++コードへの復元とか夢のまた夢だわな。
呼び出し規約と関数内のレジスタ利用方法の規約ゴッチャにしてる辺りも残念すぎる。

v0.0.1にバージョンアップしました。
関数の切り分けができるようになりました。

課題１：DisAsmメソッドの中で各関数の種類（FUNCTIONTYPE）を確定させる。
また、各関数の引数全部のサイズを求める。関数内関数の対処。

名前修飾（Name mangling） - Wikipedia
http://ja.wikipedia.org/wiki/%E5%90%8D%E5%89%8D%E4%BF%AE%E9%A3%BE

EXEからコンパイラの種類を判定する方法ってありますか？

全パターンぶんデマングルしてみてうまくデマングルできたやつを採用すればいいんじゃない

PEiDでも調べれば？

g++の場合は、プログラムc++filtで解読できるようです。
gccの場合はわからない。
VCの場合はdbghelp.dllのUnDecorateSymbolName関数で。

UnDecorateSymbolName function
http://msdn.microsoft.com/en-us/library/ms681400(v=VS.85).aspx

正直ね、片山さんのその技術力で
逆コンパイラじゃなくて
C#とD言語を上手く改良したような実用できる言語作ってほしい
逆コンパイラの都合のいい言語みたいな感じでもいいから。
そしたら実装も楽になるかもよ。
これ作るついでにやってみてくれないかな？

ネイティブC#みたいな位置づけのさ。
D言語だと正直不安定すぎて使えなさすぎなのよ

マングル返し

Microsoft C は、シリアル番号をオブジェクトファイルに
埋め込んでるってうわさ話があったな...

>>53
そんな速攻で検証できそうなことをわざわざするかなぁ……？

課題２：アドレスからスタック状態集合への写像
課題３：コンパイラの種類を判定するコード
課題４：アセンブリ命令が何を参照し、何を変更するかの情報
課題５：データ型の管理方法

これらに関して知ってることがあれば俺に教えて下さい。

次のリリースは、pimplで読みやすいコードになる予定。
今までの人工知能研究の全てを注ぎ込んで、頑張りますのでご声援を。

いや、そのレベルでいったいなにをつくるきなんだ…

コントロールパスというのがよくわからん。単純にプロファイルするとループで無限長になってしまうよな。
掛け算と割り算のキャリーとオーバーフロー条件の違いもよくわからん。

前途は多難ですね

思った以上にレベル低過ぎてワロタｗ

ファンクタって関数ポインタより使いやすいな

v0.0.2にバージョンアップ。

コードの整理。insn*.datファイル、mzc2mini.{h,cpp}ファイルの追加。
関数内関数の対処。

insnはinstructionの略でアセンブリの命令のこと。

次は、コントロールパスとスタック状態の取得に挑戦します。

サイドビジネスで疲れてMPがない
妙なバグがまだ取れてない
頑張るしかないか

コントロールパスの組み合わせが無限になるバグが修正できない。
ループは排除したのに。

無限大じゃなかったけど、コントロールパスが768通りって多すぎないか？

スタックについて必死に勉強中です。

一進一退というか一進二退くらいになってるような

三値論理サイコー！！！

コントロールパスよりもCFGの方が重要だとわかった。目標が間違ってた。

v0.0.4 CFGの取得が可能になりました。

型情報がない状態で、レジスタとスタックの使用状況がわからないと、
関数の呼び出し規約や引数は分析できませんね。

insn16.dat/insn32.dat/insn64.datファイルに書かれているような
中間表現によって、アセンブリとC言語ソースをつなげようと
考えています。

定数畳み込み
http://ja.wikipedia.org/wiki/%E5%AE%9A%E6%95%B0%E7%95%B3%E3%81%BF%E8%BE%BC%E3%81%BF

疎な条件分岐を考慮した定数伝播
http://ja.wikipedia.org/wiki/%E7%96%8E%E3%81%AA%E6%9D%A1%E4%BB%B6%E5%88%86%E5%B2%90%E3%82%92%E8%80%83%E6%85%AE%E3%81%97%E3%81%9F%E5%AE%9A%E6%95%B0%E4%BC%9D%E6%92%AD

抽象解釈
http://ja.wikipedia.org/wiki/%E6%8A%BD%E8%B1%A1%E8%A7%A3%E9%87%88

大域値番号付け
http://ja.wikipedia.org/wiki/%E5%A4%A7%E5%9F%9F%E5%80%A4%E7%95%AA%E5%8F%B7%E4%BB%98%E3%81%91

共通部分式除去
http://ja.wikipedia.org/wiki/%E5%85%B1%E9%80%9A%E9%83%A8%E5%88%86%E5%BC%8F%E9%99%A4%E5%8E%BB

Partial redundancy elimination
http://en.wikipedia.org/wiki/Partial_redundancy_elimination

演算子強度低減
http://ja.wikipedia.org/wiki/%E6%BC%94%E7%AE%97%E5%AD%90%E5%BC%B7%E5%BA%A6%E4%BD%8E%E6%B8%9B

C言語の構文解析
http://www.syuhitu.org/other/cparse/cparse.html

逆コンパイラに興味ある人は少ないみたいだな

そりゃそうだ。リバースエンジニアリングってのはどちらかといえば破壊行為だし。
この板の連中はおまえの想像以上に生産的（破壊的の反対）なんだよ。

それ以前に「どうせ無理だろ……」と多勢が思っていることもあるだろうね

コンパイラが多すぎて全部はソースに変換できないって分ってからなぁ・・・
そしてコテ的に>>76

次は中間表現の生成をやります。

実用レベルに足るものは不可能とわかっているから

彼でも１〜２年で限定用途なら可能だろうし
５〜１０年も頑張れば実用レベルのが出来るんじゃないかな？ただそれだけ頑張った見返りがあるか疑問だが。

MFCの劣化ライブラリも腐っているしな

>>80
何一つ完成させたことが無いのに？

>>74
興味ありますよ頑張ってください応援してます

え、まずはコンパイラ作ってみたら？

しばらくスクリーンセーバーの開発に時間を割くことにします。GUIはwxを採用します。

MZC使えよバカ、作った人にも使われないなんてよっぽどだな(笑)

馬鹿がまた飽きたのかｗｗｗ

こいつ本当に何一つ最後まで作れないなｗ

最後まで作らないうえに86とかどうしようもねぇな

仕事の合間にLinuxのスクリーンセーバーをWindowsに移植したら、海外から何件か要望が来た。
要望の多い方を優先する方針。すまない。何ならGitHubで開発に参加してくれると助かるのだが…。

まあ簡単な方から片付けていくのが効率的人生の鉄則ではある。

また偽装請負か・・・

解散

クッソワロス、やっぱり最初に言った通り途中で挫折したｗ

ちなみに、こいつが途中で他のを優先すると言って
また開発に戻った例は無いぞw

まだだ、まだ俺のスタック領域は溢れちゃいねェ

保守

catcher

>>50-51
Salamander

スクリーンセーバーの移植が終わったので、CodeReverseの開発を再開します。

また仕事が入った

catcher

Windows 系の .exe .dll を逆コンパイルするので分りやすいコードを吐いてくれるのは
今って何が高性能？
Ｃ＃ぐらいの言語っぽいのだと分りやすいんだけど

機械語からの逆コンパイルは大抵ろくなコードが出てこない。
マトモなコードになるのは中間言語からの逆コンパイルくらいだな。
.NETやJavaやActionScriptやHSPの中間言語は結構普通の逆コンパイル結果が得られる。

逆コンパイルで出てきたコードを書き換えてコンパイルしようという訳じゃないんだ。
機器のログを表示するソフトのデータ読み込みにバグがあるみたいで
自分で表示用データを出せるプログラム作ろうとしたら一部計算式が分らない
三角関数だろうけど

>>103
だから中間言語使った実行ファイルなら逆コンパイルも実用になるけど、
機械語使った実行ファイルの逆コンパイラはなかなか実用にならんよ。
たぶん逆アセンブラがなんだかんだ一番実用的だと思うぞ。

その.exeや.dllが中間言語使ってる実行ファイルかどうかは知らん。
.NETあたりだと逆コンパイルも楽だから.NETだといいね。

>>103
その機器のメーカーに直してもらえよ

アセンブラは機械語と一対一に対応しているとよく言われるけど、
実際は対応していない。
同じアセンブリでも配置によって複数の機械語から特定のコードを選択
しなければならないプロセッサはよくありがち。
いろいろ面倒だよ。

>>103
ログ読み取りに不透明要素を持ちこむな　本末転倒にもほどがある

catcher

>575 名前：片山博文MZコスモ ◆T6xkBnTXz7B0 ：2013/12/31(火) 22:44:07.54
>2013年の実績：
>クロスワードギバーを完成。
>XScreenSaverの200個以上のスクリーンセーバーをWindowsに移植。
>逆アセンブラを途中まで作成。

いつのまにか逆アセンブラにグレードダウン（笑）
なんというか、「〜をダウンロードした」とか「〜を勉強中」など
どうでもいいことは大声で宣伝するが、重要なことは何も言わないとか・・・

ネタギレです…しばらく保守になります。

この停滞状態が我慢できなければGitHubでPull requestしてね

都合が悪くなると名無しで発言するんだな、発言の内容からして本人であることは明白なんだが

ドラゴンプック買えばいいんですかね？

無駄にはならんと思うが、つまみ食い気分で買うにはちとお高いよ

アマゾンギフト券2000円を買ったぞ
中古のドラゴンブック買うぞーー！

ドラゴンブック、1000円くらいの中古を買っちゃった！！！！！
さあ、ドラゴンと戦うぞ！！！

「コンパイラＩ原理・技法・ツール」が家に届いたぞー

戦闘開始！

コンパイラ「ロバｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ」

RE: Bison Windows m4 problems
bison: cannot open file `data/m4sugar/m4sugar.m4': No such file or directory
https://lists.gnu.org/archive/html/help-bison/2010-03/msg00015.html

空白を含むC:\Program Filesにインストールしちゃ駄目らしい。やり直し。

これも必要
set BISON_PKGDATADIR=C:\GnuWin32\share\bison

報告。ドラゴン本第三章まで読了。左再帰を右再帰に直す方法を学習した。
フロントエンド、フェーズなどの用語を習得した。
GNU Win32 Bison(Yacc)+Flex(Lex)のインストールに成功した。
引き続きBison+Flexの使い方を勉強する。

ここまでの学習成果をまとめました。
http://katahiromz.web.fc2.com/mathai/compiler-tech-ja.zip

次の目標は、Cパーサーの作成です。

あれ、逆コンパイラじゃなかったの？
フロントエンドよりバックエンドの方が重要だろう

俺が知らないうちに方針が変わったのかな

ロバ「方針が変わったのかな」

どうでもいい。アホは自由だけが取り柄、好きにすればいいじゃない。

C言語で連結リスト書いたよ。

連結リストライブラリ LinkedListInC
https://github.com/katahiromz/LinkedListInC

Cで書くべきかC++で書くべきか？

bison+flexで作ったパーサーを２つ以上取り込むことができないから、Cはダメだな、C++にしよう

ftp://sunsite.unc.edu/pub/Linux/devel/lang/c/cdecl-2.5.tar.gz

ここにcdeclというプログラムのソースがある。これを分析する。

最近はPEGを使うのが流行りなのか？ ちょっくら調べてみるか

パーサジェネレータの勉強を兼ねて電卓を作ってます。

bison/flexのパーサーが複数使えないって
片山はマニュアルが理解できないのか

Windowsではまだmodern Bison++(3+)は入手できない。
それにC++に関してはまだ実験的らしい。
すぐに使えなくなりそうなコードは書きたくない。
だからANTLR3を使うことにした。

ドラゴンブックに挫折したか

まだ挫折していません。
ANTLR3でここまですごい電卓ができました。

http://katahiromz.web.fc2.com/mathai/mzcalc3.zip

SS貼れよ

Type [q or Q] to quit
> 871263948761872364871623946182973164+8761928734912634183412379461874234
Result is: 880025877496784999055036325644847398
> s=92183019827349179203471
s := 92183019827349179203471
Result is: 92183019827349179203471
> sin(s)%100.3
Result is: 0.7484296692622107891527456053804399259219719456829430374497200718368
9079690554390091960884209113407122218168687650754654152155867
>

C11を勉強しなければ‥‥

電卓で終わる予感

Grammar Zoo
http://slps.github.io/zoo/

__extension__とか__builtin*とか処理が多いなあ。

ANTLRでFOLLOW_set_in_問題が発生した。これも使えないのか。。。

bison-3.0.2をビルドしようとしたが失敗。
CaperとPEGを試してみる。。。

スマポ？ なにそれおいしいの？

Caperは生成に時間がかかる(Core i5で10分)。しかもできるものが非常にでかい。

Cパーサのプロトタイプができたよ！！！！
http://katahiromz.web.fc2.com/mathai/cparser2.zip

storage class関連の文法の見直し、並びにT_TYPEDEF_NAME,
T_TYPEDEF_NAME_FIRST, T_TAGNAMEなどの特殊なトークンが必要だった。

それにしてもCaperは時間がかかりすぎ。。。やっぱりBisonが最強かなと思い始める。。。

>>145
あんた偽物だろ。
片山先生ならなぜ時間がかかるかまで調べて教えてくれるはず。

さあ、caparの高速化に挑戦するぞ。開発環境はMinGW+MSYS。
まずは、計測。
$ time ./caper.exe -c++ cparser.cpg cparser.hpp
　　　　real 7m50.856s
　　　　user 0m0.015s
　　　　sys 0m0.000s
7分50秒もかかっていることがわかる。

g++のコマンドラインに-pgをつけてビルドすると、
関数の処理時間などをプロファイルするCaperの出来上がり。
　　　　$ ./caper -c++ cparser.cpg cparser.hpp
を実行すると、ファイルgmon.outが作成される。さらに
　　　　$ gprof caper.exe gmon.out > gmon.log
と入力すると、人間にも読めるgmon.logができる。
...（中略）...
その結果、
　　　　real 0m31.862s
　　　　user 0m0.000s
　　　　sys 0m0.031s
となり、30秒程度で処理できるようになった。めでたしめでたし。
http://katahiromz.web.fc2.com/mathai/qcaper.zip

騙されてる

ここまでできたぞ！！！
http://katahiromz.web.fc2.com/mathai/cparser4.txz

これより、型システムを実装する。

型のデータ構造とASTを構築中。。。

@jonigataさんのCaperが劇的に高速化されたらしいぞ！！！
github.com/jonigata/caper

汗から関数を切り出すのはできた。汗コードから関数の引数の個数を判定する方法がわからない。
最近汗やってないな。。。

雑用とか色々有って忙しいんだよな。
C2EXEの作者でも降臨して手伝ってくれないかなあ〜。多分連絡取れないんだろうな。

exe2cの間違いだった。。。

AST構築中。。。

最適化なんてどうでもいいから、早くASTを構築しろって上司に怒鳴られた。
すなおに実装してみるか

AST構築完了。次はコンパイルだ。
http://katahiromz.web.fc2.com/mathai/cparser8.txz

まだやってたのか

こうして見返してみると馬鹿なコード書いてるのがわかるな。。。
書き直そう。

github.com/katahiromz/CodeReverse
更新しました。パースルーチンを追加。コードの近代化。
ライセンスをThe BSD 2-Clause Licenseに変更。
さあ、どんどん作るぞ！！！

技術レベルの高いことやってるね。

x86アセンブリから関数の引数のサイズを求める方法がわからない。知ってる人、教えてよ

calling convension調べろよ

そういうのはプロジェクト立ち上げる前に解決しとくと子だろ

catcher

途中何も読んでないから的外れ言ってたらすまんこまんこ
引数はPUSH最後からPUSHで行って、最後にリターンアドレスをPUSHして関数をcallする
arg3
arg2
arg1
retaddr
引数が４バイトで３つの場合、呼び出し直後のスタックはこうなる

関数呼び出し規約の違いは引数の分のスタック処理を誰が責任持つかの違い
__stdcallは呼び出された関数が最後にスタックを整理して返る
__cdeclは呼び出し側がpushした分だけスタックを整理する
__fastcallはcallする前にpushじゃなくて最大２つまでレジスタに値をぶっ込んでからcallする
__thiscallはcallの直前にecxにthisポインタを入れてから呼び出すが、スタック処理は_規定では_stdcallと同じ
関数内でecxにあれこれしてローカル変数っぽいのを弄ってたらなんかしらのクラス決定
__cdeclを指定されたり可変個引数だったりするメンバ関数は、thisポインタを最後にスタックに積んだ気がする

__fastcall調べたなら「スタック処理を誰が責任持つかの違い」じゃ無いことは自明だろがアホ
あとx64だとかなり様変わりする

ごめんニワカなんだすまんこまんこ
__fastcallは3つ以上引数取るときには３つめ以降の責任は__stdcallと同じだったはず
x64はほとんどレジスタで引数やりとりするんだっけ？全く詳しくないが

「引数の渡し方からしてそもそも違う」のに「誰が責任持つかの違い」に限定しなきゃいかん理由は何なんだ。

v0.1.0!
https://github.com/katahiromz/CodeReverse

パースした関数のプロトタイプを出力するようになりました。

型システムは70％くらいできた。
アセンブリから呼び出し規約と引数のサイズを推定するオートマトンを作らないといけない。
頑張るぜ。

Amazonでドラゴンブック二冊目買おうかな
データフローを勉強したいんで

買う買う光線ビーム！！！

こわい

買ったぞーーーー

>>176
つhttp://awabi.2ch.net/test/read.cgi/classical/1389828072/

0.1.1!
https://github.com/katahiromz/CodeReverse

型システムが85％できました。ビットフィールドが難しい。。。

ビットフィールド、サポート出来そう。
次はオートマトンに取り組むぞ！！！

【関数呼び出しコード分析における注意点】
☆呼び出しの際、スタックを解放せずに再利用されることがある。
☆呼び出し先のアドレスがレジスタに格納されて呼び出しに使われることがある。
☆また、条件によって場合分けされて呼び出し先の異なるアドレスがレジスタに格納されて呼び出しに使われることがある。

レベル０．機械語コード。
レベル１．アセンブリのみのコード。
レベル２．関数に切り分けられたアセンブリコード。
レベル３．レジスタとスタックの直接的操作を含む中間表現コード。
レベル４．レジスタとスタックの直接的操作を含まない中間表現コード。
レベル５．C言語のコード。

#こんな感じかな？

レベル３．レジスタとスタックの直接的操作を含む型なしの中間表現コード。
レベル４．レジスタとスタックの直接的操作を含まない型付きの中間表現コード。

命令セットの中間表現はテキストとして与えられる(insn*.dat)。
よって、中間表現の設計とパーサとASTが必要。
中間表現はC言語のサブセットの拡張とする。

gccは余分にスタックフレーム確保してる。。。何でだろ？

実現出来てもwatcom cの吐いたバイナリで面白いことになる予感

本が来た━━━━━━━━━！！！

コンパイラが関数だとすると、逆コンパイラは逆関数である。
逆なんだよ、逆。コンパイラのコード生成に対しては、逆コンパイラのコード分析が対応する。

__stdcallが一番簡単。__stdcallのときに限ってretの引数があって、それが関数の引数リストのサイズ。
__stdcallでないときはretに引数がなく、呼び出し側が引数スタックを解放する。
__cdeclか__fastcallか__thiscallの判断はレジスタの使用や関数呼び出しの状況を統計するしか方法はない。
スタックやレジスタやヒープの型情報とデータと式などを統合して扱う仕組みが必要。

統計しなくても理詰めで解けるケースを想定できんのか
//どっちみち可変長引数は詰むけどな

ある関数内で呼び出すターゲット関数のスタック引数サイズは、スタックフレームマイナススタックポインタ以下の値を取りうる。
関数内でターゲット関数の呼び出しが１回のみで他にスタック操作をしていないなら、そのときのスタック引数サイズは確定する。
ターゲット関数内のレジスタとスタックの使用状況から、スタック引数サイズの下限がわかる。
可変長引数の場合は、スタック引数サイズは下限以上の値になる。

ということは、スタックフレームイコールスタックポインタの場合はターゲット関数の
スタック引数サイズはゼロで確定で、ターゲット関数に対する統計は不要という訳か？

１．関数のスタック引数サイズとローカル領域を確定し、スタック操作を仮想化する。
２．コードを基本ブロックに分け、分岐を仮想化する。
３．オペランドに型を付けて型推論を行う。
４．データフロー解析を行い、中間表現へ変換。オペランドを式に抽象化する。
５．読みやすいように最適化しながら、コード生成を行う。
６．AStyleを使ってコードを整形する。

0.1.4!　コードを整理。
https://github.com/katahiromz/CodeReverse

x86のintrinsicのまとまった情報が欲しいけど見付からない

符号付きか符号なしか分からない型をxsignedで表す。
未知の型はunknown%d_tという型を付ける。未知の型について型の属性を解析していく。
例えば、即値xが非ゼロで上位ワードがゼロならポインタでなく整数である。
callの引数は間違いなく関数ポインタである。

ということは、intrinsicのアセンブリパターンをほとんど全部調べて、
パターンマッチングでパターンごとに中間表現に置き換えていく必要があるんやで。
パターンデータを用意するのが大変やで、しかし。

pattern {
(アセンブリのテンプレート)
} code {
(中間表現)
}

こんな感じのテキストデータを事前に読み込んで、それ(置き換え規則)を使って
パターンマッチを行い、中間表現への置き換えをする。
テンプレートには$1,$2,$3,...などの引数が書ける。

パターンが足りず変換し損なうか、パターンが意図しない場所にマッチして変換し損なうか、
マッチ候補の組み合わせ探索量が爆発して尋常じゃなく遅くなる、て未来が見えそうだね。

最適化されたバイナリとか全く考えて無さそうだな
変換できなかったらインラインアセンブリのソースに変換します！　ならかっこいいｗ

>>199
それ言い出すとインラインアセンブリだらけになっちゃうだろ！

ループ展開とか、再起がgoto文になってたりすると見にくそう

forもwhileもgotoになるだろう

>>197
コンパイラの癖が変わったら破たんするな。

>>203
コンパイラのバージョンとコンパイルオプションの組み合わせごとにパターンセット作るんじゃね？
手作業だと余裕で死ねる。

頻出形だけカバーできればいいだろ
どうせ大事なのはその先なんだし

最初から最後までインラインアセンブリ

>>206
なにその手の込んだ手抜き

はーひふーへほー！！！
片山被告のせいで俺まで職場で悪役扱いだずぇ！
まゆげが無くても父親が殺人者でも関係ねぇ！
俺はコンピュータテクノロジーの心臓部に弾丸を撃ち込んで歴史を塗り替えてみせる！
俺様は諦めない！がはははっひゃっ！ ばいばいきーん！

最終チェックが終わったら次は64bitのパターンだな。
7月15日までに結果を出さねば。

jmp を for にできるようになったら呼んでくれ

v0.1.5!
https://github.com/katahiromz/CodeReverse

パターンファイルasmpat32.dat, asmpat64.datを追加しました。
ソースが読みやすくなりましたので、興味がある方はじっくりご覧下さい。

>>210 それはまだ先のこと。

たいした成果がないとスポンサーからの今年の研究費がお預けになる予感。。。開発を急がないと。。。
GitHubにてPull Repuest歓迎。アドバイス・批評歓迎。功績・貢献にはアマゾンギフト券かWebMoneyでお応えします。

もう少し納得がいくまでひらがな電卓がんばります。

うひょー、ひらがな電卓のお陰で研究費ゲットだぜぇ！ もう少しひらがな電卓を頑張るずぇっ！

catcher

>>214
ニートですが研究費とかいうものはどうやったら貰えるのですか？

>>216
「クラウドファンディング」で検索

catcher

catcher

catcher

お花畑

catcher

catcher

バイナリをLLVMにするって可能なのか？ うーん

Fracture
https://github.com/draperlaboratory/fracture

これもあまり進んでいないなあ。参考になるかなあ。

しばらくCalc-Hの営業
時間ないな

catcher

GitHubで星が１つ付いた。頑張らないといけないのだが、時間がない。

catcher

時間ねーから

catcher

こんな嘘ばかりのスレ取り消せ。
クソボケが 、アホクソボケカスが。
根性無しのカスの集まりが。
どうせ何もできんのやろが？
カスはカスらしく黙っとらんかい！クソボケ！
何なんじゃアホが。この根性無しのクズが。
クソボケクズ。クズの集まりじゃねえか。
ポンコツのクソドアホが。ボンクラだろがてめえら。
はっきり言っといてやるよ。 てめえらなんか、何一つ怖くないわ、
このクズ以下のポンコツボンクラが。

catcher

catcher

catcher

データフローの表現の問題が未解決。アイデアが見つかるまで時間が掛かりそうです。

dag (directed acyclic graph): 閉路のない有向グラフ。「グラフ理論」を参照。
基本ブロック (basic block): 途中で停止したり、分岐したりしない、連続した文の並び。
流れグラフ: 基本ブロックを制御の流れに従って矢印で結んだもの。
「基本ブロックのdag表現」とは、次のようなdag:
１．葉のラベルは一意な識別子。
２．内部節点のラベルは演算子。
３．さらに節点に識別子の並びのラベルを付けることができる。

この「内部節点」は、「節点内部」の誤訳だろうな

内部節点で正しいと思う
http://imd.naist.jp/~miyazaki/doshisha/data-algo/ad-3.pdf
・内部節点(internal node)　子を持つ節
・外部節点(external node) 葉(leaf)　子を持たない節

>>239
なーるほど
そう言うことか。有難う。

『節点』に『内部』があると思っているのか？日本語からやり直せよチョソ

>>241
残念。節点なんだけど丸で描かれてその中にラベルがあるんだな、これが。
現在、インシデント解決待ち。

Cパーサーができた。
https://github.com/katahiromz/DoWonders
これをCodeReverseへ取り込もう！

さあ、やるんだ

おう、がむばってくれ

DLLのリンク情報はどうやって抽出すればいい？

完璧なCパーサーを作るのは大変だな。。。
https://github.com/katahiromz/DoWonders

早くバグ取らないと怒鳴られるぞ。。。

だいぶ進んだよ。
https://github.com/katahiromz/DoWonders

Win32 APIのほとんどの型情報が抽出できた！ K点越え！

https://github.com/katahiromz/DoWonders

おうがんばれや

へえ。結構やるじゃん。

今、リファクタリングとDBのサニタイズしてるとこ。いくつかサイズの間違いを見つけた。
構造体のサイズを正確に得るには、アライメントを考慮せねば。

Ａ「では、進捗報告を」
Ｂ「アライメントの扱いに案外手こずり、まだDBのサニタイズが終わっていません」
Ａ「時間が掛かりすぎだ！いつになったらできるんだ！(机を叩く)」
Ｂ「申し訳ございません。」
Ａ「アライメントの規則性を分析して早くサニタイズしなさい」
Ｂ「御意」

サニタイズ完了。
https://github.com/katahiromz/DoWonders

型情報のload/saveを可能にしなきゃ。
定数の"typed value"計算を可能にしなきゃ。

今、typed valueの実装をやってるけど、型によって場合分けが
必要だから、「場合分けの化け物」になっちゃうんだよな。
関数型ならもっとスマートに書けそうだが。。。