2017年05月17日

親捏造,参照先弄り,%n,コード実行等まとめ

自分用メモも兼ねてまとめ

・参照先(リダイレクト)弄り
メモリに保存されてるアドレスを弄って参照先を変更する手法。
オバステで可能なものもあれば別途アドレスを取得しなければ弄れないものもある。

1.parent
オバステで可能。一般的には親捏造と呼ばれている。parentvarset等で数値変更、parentリダイレクトで広範囲の数値参照が行えるが、若干不安定
2.root
オバステで可能。rootリダイレクトで広範囲の数値参照ができるが、不安定。
3.target
オバステで不可能。いくつかのアドレスを辿る必要がある。parentやrootと同様で広範囲の数値参照が行える。しかしフラグを適切に立てないとMUGENが落ちる危険性を孕んでいるとともに、target参照先変更による弊害があまり解析されていないため実用的ではない(かも)。
4.power
オバステで不可能。最近の主流(個人的感想)。後述するafterimagetimeの利用で更に使いやすくなった。参照範囲は8バイト(変数2つ分)、変更範囲は4バイトと範囲は狭いもののかなりの安定性を誇る。ヘルパー個別のpower参照が動かない点やタッグで狂う場合があるが、ある程度は対処可能。
5.afterimage&afterimagetime
オバステで可能。制限はあるが中範囲の代入が行えるafterimageと一部リセットされるが4バイトの任意値代入が可能なafterimagetimeが使える。応用すればオバステのみでデバッグキー操作が行えるほど便利ではあるが、肝心の演出用に使えなくなったり使い回しすぎるとフリーズするバグがある。ちなみにafterimagetimeとpower参照を併用すれば簡単に任意アドレスの参照が可能となる(自己アドレスは別途取得が必要)。
6.bindtoroot&bindtoparent
オバステで可能。あまり使い所がないが、オバステで行える上安定性も高いのでアドレス取得に使うことができる。仕様上1F遅れて取得することになるが数値取得で急ぐ必要がない場合は十分使える技術。加えて数値取得はFの最後に行われるため最終時の情報を取得できるという利点がある。
7.被弾時参照
オバステで可能。あまり調べていないが、以前drab氏がデバッグキー実行に使っていた記憶があるような…
正直情報不足です。
8.p2
9.enemy
両者ともオバステで可能。しかし弊害が調べられていない上、使い道は微妙。
正直情報不(ry

・%n系統
お馴染みのヤツ。アドレスを引数としてそれまでに出力した文字数を代入する。最近ではdrab氏によって巻き込み範囲が2バイトの%hnが発見された。
固定アドレスやpersistent弄りを利用しない場合はアドレス取得が必須。
最近ではアドレス取得は親捏造やコードで済ませ、代入処理を%nで行う場合も多い。

・コード実行
DEPなし環境では%nを超える存在。任意のアセンブリコードを実行する。少し前までは1バイトずつ%nで空白領域(0x4B4000周辺が多い)に代入していたが、現在ではスタック上でコードを実行することによってある程度長めのコードの代入,実行を1ステコンで行えるようになった。
コード実行の種類は以下の通り。

1.空白領域に%nで1バイトずつ代入+スタックバッファオーバーフローによるRETN先変更
以前の主流。上記で軽く説明したが、空白領域にコードを埋め込みDisplayToClipboard(以降DTCと略記)のtextパラメータのバグを利用する。使うにあたって不便な点は1バイトずつ代入のためステコン数が増える点。1ステコンコードの発見により使われる機会はかなり減った。
2.空白領域に残像でコードを代入+スタックバッファオーバーフローによるRETN先変更
あまり日の目を見なかった実行方法。残像の参照先を空白領域に指定し、パラメータにコードを埋め込む。1.で不便だった点である1バイトずつの代入を大幅に改善した。
3.スタック内にコード代入+スタックバッファオーバーフローによるRETN先変更
現在の主流その1。
正直解説面倒なので下の記事見てください。
4.スタック内にコード代入+残像領域にコード代入+スタックバッファオーバーフローによるRETN先変更
現在の主流その2。先程のリンクに出てきた『残像のパラメータでコード実行』というのを改良して、nameに依存しなくなったのがこの手法。基本原理は3.と同様なので解説は省略。利点は変数をそのまま指定できる点。注意点は演出で残像を使いにくくなる点。
亜種として変数領域でコードを実行する場合もある。

ここからは実行する機会が少ないと思われるコード実行方法。
5.Def Buffer Overflow Attack
通称DBOA(最後のAttackを省略しDBOFとする場合もある)。詳しくはdrab氏のブログを見て欲しいが、簡単にいうと『statedef xxxのx部分を異常に長くしてスタックバッファオーバーフローを起こしRETN先を変更する』というもの。メインスレッド(コード開始地点401000)ではなくサブスレッド上でバッファオーバーフローが発生する。
6.%fと%eの処理
DBOAにおいて補助的に使用される場合が多い。DTCのtextに%fや%eを指定した際に以下のコード
call [4B48E8]
が実行されるため、4B48E8にコード実行地点を代入すれば敵味方関係なくコードを実行できる。
7.キー入力時の処理
キーボードのキーを押した時に以下のコード
call [4B5960]
が実行されるため、4B5960にコード実行地点を代入すれば敵味方関係なくコードを実行できる。
また、動的な解析ではあるが毎フレーム実行されてそうな気配がある(要検証)ため実行タイミングさえわかれば有用かも。ちなみにDBOAで補助的に使用しているキャラもいる。


こんなところかなー
なんか思い出したら追記しよう、久々に長い記事書いたから疲れた
神キャラ製作したいけどなかなか時間が取れん…
ゲームする時間を抑えなきゃ
posted by メロンピエロ at 09:11| Comment(0) | MUGEN | このブログの読者になる | 更新情報をチェックする

2017年04月25日

5030で非凍結オバステができる理由

調べようと思って先延ばしにしてたのでこの際調べた
結論から言うとtimeだった

5030ステートに自動的に飛ぶ条件は
Lifeが0
aliveが0以外
nokoが使用されてない
です

プレイヤーの個別ステート処理終了後、上の条件を満たしているとaliveが0になって5030ステートに移動させられます
その際、timeは0になるのですが…

一般的にtimeは各プレイヤーの個別ステート処理が終わった後に1増加します

ここで注目したいのが処理の順番
5030移動&time=0となる処理が先か、timeの増加処理が先か

前者なら次Fをtime=1で迎えられるので非凍結オバステが可能
後者なら増加した後timeが初期化されるので不可能

もちろんMUGENの処理は前者です

これを使って!time貫通砲の撃破挑戦キャラでも作ろうかと思ったんだが案が浮かばなかったのでブログで報告することにした
posted by メロンピエロ at 14:06| Comment(0) | MUGEN | このブログの読者になる | 更新情報をチェックする

2017年04月23日

最近

最近やったこと

残像と併用したらステコン数増えちゃうのでコピペ可能な変数仕様型1ステコードを組んだ
それだけかなー

だんだんとMUGENのやる気がなくなりつつある…一通さん作りたいとは思ってるのに手が進まんなー

そういえばdrab氏が%hnを見つけたそうですね、あれは便利そう

私も%Zの処理解析をしてたんですが途中で詰まったから放置してる…
誰か解析して(他力本願)
posted by メロンピエロ at 10:03| Comment(0) | MUGEN | このブログの読者になる | 更新情報をチェックする