制作日記

こういうの作った方が、逃げにくいじゃない

トップ

トップ
※申し訳ないですが、メールでの返信は出来ません。

DEP回避して任意コード実行
_reimu_ver191.ico

DTCリターンアドレス改竄テストキャラ(ver0.7xとは別物です)
_reimu_ver181.ico

MUGEN用プロセスメモリリーダ、memRead 最終更新 2013/11/17
memRead.ico
CUIアプリです、普通にアイコンをダブルクリックでも起動できます

リンクを右クリックして、「対象をファイルに保存」からダウンロード
ファイルの拡張子をrarに変えてから解凍してください

MUGENステコン入力支援マクロ
入力補完、短縮表記機能有り版(取説)
stateControl_2.js
入力補完、短縮表記機能なし版
stateControl_1.js
使い方とかはjsの先頭に書いてあるので、メモ帳で開くなりして読んでください

バグ報告等々コメントして頂けると助かります
公開物とそれらに関する情報の利用は、内容に依らず自由にして頂いて問題ないです

過去verは続きへ追いやられました

続きを読む

続F12

http://melon-eat-pierrot.seesaa.net/article/458683030.html

> drab氏の記事を補足すると、4B54E4にはmugen%i.pcxの部分の引数が入ってる
> だから数値を大きくしても落ちはしないんじゃないかな

細かく書かないと理解されんのかねえ

sprintf(EDX, "mugen%i.pcx", [4B54E4])って呼び出しになっていて
EDXの指すバッファは16byteしか用意してないんだから、4B54E4の値が7桁以上になったらオーバーフローするでしょ

文字列長くすると落ちるという事実を観察していて、4B54E4が %i の値ってことも理解しているのに
なぜ、落ちない(=オーバーフローしない)という結論に至るのか

あー、もしかしてリターンアドレス書き換えの理屈自体を理解できていない?
なぜ16byteなのか、とか諸々の話がわかってないとかなのかな

F12

http://melon-eat-pierrot.seesaa.net/article/458606895.html

文字列保存用の一時変数が16byteだから
それ超えてリターンアドレス書き換えてるだけでしょ?
というか、fopenのフラグ"rb"も巻き添えで書き換えるから
ファイルの存在確認用のfopenが必ず失敗するようになってしまう

このあたりだけど、これは0x4B54E4にデカい値を書いてF12押すだけで落とせそうですねぇ
00417700  /$ 8B0D E4544B00  MOV ECX,DWORD PTR DS:[4B54E4]
00417706 |. A1 4C5B4B00 MOV EAX,DWORD PTR DS:[4B5B4C]
0041770B |. 83EC 10 SUB ESP,10
0041770E |. 8D5424 00 LEA EDX,DWORD PTR SS:[ESP]
00417712 |. 56 PUSH ESI
00417713 |. 8BB0 C45C0000 MOV ESI,DWORD PTR DS:[EAX+5CC4]
00417719 |. 51 PUSH ECX
0041771A |. 68 F0414A00 PUSH winmugen.004A41F0 ; ASCII "mugen%i.pcx"
0041771F |. 52 PUSH EDX
00417720 |. E8 32AB0700 CALL winmugen.00492257


elemフリーズ

http://oki6761.blog23.fc2.com/blog-entry-2524.html

むかーし、似たネタがあって記事書いたわ
http://drabs.blog40.fc2.com/blog-entry-1108.html

重要なのは以下2点で
1.指定elemをどうやって探索しているのか
2.その探索を継続する条件は何なのか

で、どうなってるのかって-と
1.xフレーム目に何枚目のelemが表示されるかで線形探索
2.探索中のフレームがデバッグ表示の総time未満
 もしくはデバッグ表示の総timeが-1のとき探索継続

つまり、0フレームelemは決して見つけれず
末尾elemのtimeが-1のaminは探索継続条件を常に満たすので、探索が終了せず無限ループする
ただし、最初と最後のelemへのchangeanimは例外ね、そもそも上記の探索が動かない

というのを理解すると、いろんなパターンで無限ループを起こせる
elem=2にchangeanimするとして、

何個か固まるanimを例示
[Begin Action 9999]
8901,0,0,0,0
8901,0,0,0,0
8901,0,0,0,-1

[Begin Action 9999]
8901,0,0,0,-1
8901,0,0,0,0
8901,0,0,0,0

[Begin Action 9999]
8901,0,0,0,-5
8901,0,0,0,2
8901,0,0,0,2

ライブラリのリンクとか

アセンブラ書くのって面倒なのよ

mugen起動するとかぐらいなら、文字列埋め込んで引数渡してexec叩くだけだから簡単(だと思う)
スレッド作るのは、それだけならなんとか
呼び出し規約とか気を付ける必要はあるけど、関数用意してスレッド作成の関数に渡すだけやろ?

子プロセス起動して云々やりだすと面倒?
というか、SAM氏のとこのコメントに子プロセス起動と書いたけど、windowsってforkないんだっけ?
CreateProcessとかexe起動だけやったっけ
なら、子プロセス起動って自作のexe起動しか選択肢ないのか
ここは自分が良くLinux向けの開発やってるせいで、間違えてたわ

となると、ライブラリのリンクいらないんじゃね?
アセンブラで自作モジュール起動するだけでええやん
アセンブラでファイル探索書くのめんどい?

ライブラリリンクする明確な利点は
メッセージも取ったり、スレッド立てたりとかか

ああ、でも子プロセス起動するにもwinmmugenからCreateProcessのsymbol参照してないしなぁ
GetProcAddress叩かないとか
CreateProcessの引数積むのも面倒だし
子プロセス作るためだけでもライブラリをリンクしてCから関数呼んだ方が楽か
プロフィール

Author:drab
霊夢改変キャラ
「12 3 ! {V} [_]」
公開中
L霊夢でもl_reimuでも好きなように読んでください

最新記事
最新コメント
月別アーカイブ
カテゴリ
検索フォーム
RSSリンクの表示
リンク