| 日記 | 攻略 | 攻略資料 | 倉庫 | 掲示板 | 管理人 | リンク |
| 管理人の生存と生態についての記録/[twitter@sabakunoame] |
↑フォロー返しはしません
（※予測を含むため間違ってる可能性アリ。間違いがあっても訂正しない）
| 2012/06/26 /攻略 |
青空と雲と彼女の恋
フリーの汎用スクリプトエンジンですね。 まず、インストール先のファイルを見てみましょう。  pacフォルダの中身は、  ファイルの拡張子がypfです。 ローカルフラグはこんな感じで。  このセグメントに繋げるポインタは、  この部分になります。 YU-RISだと、バージョンが変わってもポインタの構造は大体同じ。 しかし、この1個前の中継ポインタが問題だったり。  このポインタの密集地点のため、SSGにするときにどうしても汎用化できない部分がここです。 ポインタの数が異常に多い上、ローカルフラグやグローバルフラグのポインタが混じってるわけですから、 どうしても実際のフラグから辿っていくしか…という感じになってしまいます。 基点はわかりやすいんですけどね。  慣れると実行モジュール内のエリアを見ていくだけで、この部分の基点を探せます。 要は「数をこなせ」…ってことですよ。 かなり特徴的な配列になっています。 基点は、おそらくこの部分からかな…  そして逆アセンブル  ちなみにこれは個人的なメモなので、逆アセンブルすることが重要なわけではないでし。 作成したSSGは、  こういう感じで。 基点をサーチで特定することは可能なんですが、前述の中継ポインタの密集地点が問題で、完全な汎用化ができてないわけです。 ただ、個人的に思うところは、実行モジュールにどのポインタを使うかの指示はあるはずなので、その部分を読み取ることができれば、 汎用化は可能かな…とは思います。 |
| 2012/06/17 /攻略 |
この大空に、翼をひろげて
とりあえず最初にことわっておきます。 自分のための細かい部分での備忘録であって、 アプローチの手法を奨励するわけではありませんし、 これに関する質問にも答えません。 ここに書いてあることは、改造を推奨するものではありません。 あくまで備忘録。 そして、これを読んだからといって、ゲームのCGや音楽の抽出、プログラム改造ができるようになるわけでもありません。 プロセスメモリを見たときの攻略用フラグに関する部分のみについて書いてあります。 で、「この大空に、翼をひろげて」です。 主に使うツールは「うさみみハリケーン ver0.10 beta2」 プロセスメモリからフラグを読み取る最初のアプローチはスクリプトエンジンの性質を知ることになります。 使われているスクリプトエンジンからフラグの格納方法の予想が大体つきます。 ということですが、ブランドがPULLTOPなのでスクリプトエンジンはWill系列で使われてる汎用エンジンだと予想がつきます。 単純なテンプレートライブラリーだと思いますが、 実際のところ、Will系列で使われてる汎用エンジンはプロセスメモリでのフラグの格納の仕方が単純です。 しかし、今回はエンジンが以前と比べて変わったようですね。 基本のエンジンの骨格はおそらくは変わってないのかもしれませんが、 プロセスメモリでフラグを見る限りは別物のように見えます。 まず、インストール先のファイルをチェックしましょう。  「RIO」のフォルダはおそらく椎名里緒が関係してるのだろうと思いますが、 フォルダで管理されているところから予想して、スクリプトエンジンの本体とはあまり関係がないような感じです。 他に注目するべきところは「lua5.1.dll」ですね。 Luaは組込みスクリプトで、プロセスメモリでフラグの格納に大きく関わってきます。 こういう部分は先にチェックしましょう。 以前のWill系列で使われてる汎用エンジンにはなかったDLLです。 そこで、フラグを以前のWill系列で使われてる汎用エンジンと同じ方法でプロセスメモリ上のフラグを探してみますが、 ローカルフラグは全くヒットしません。 最初の選択肢は、 「あげはを待つ」 「小鳥と一緒に先にいく」 になります。 予想として、上の選択肢で あげは＋１。下の選択肢で 小鳥＋１ だと思われます。 ただ、ヒットしないということで考えられるのは、 ・＋１と予想しているのが間違っている。 ・実は最初の選択肢にはフラグがない。 ・固定アドレスではなくて格納アドレスが変動している。 ぐらいでしょうか。 こういう場合は、この時点での調査は諦めて次の選択肢で絞った方が良さそうです。 そして次の選択肢で、「あげは」に絞ってカウントフラグの調査をします。 ただ、やはり該当アドレスがヒット無し…ということで、 ・＋１と予想しているのが間違っている。 というのが濃厚になりました。 ここで１つ。 Luaの性質を知ってるとわかりやすいのですが、Luaはフラグをインデックスから参照することがあります。 また整数ではなくて倍精度の実数で格納される場合があります。 ただ、ADVのフラグに倍精度の実数を使うというのはあまり考えられないので、探す数値はおそらく整数でしょう。 で、ここからのアプローチを端折って・・ この辺が怪しいという結果に。  どこが怪しいかって？ 最初の選択肢で「あげはを待つ」を選択。 次の選択肢でどのような数値の変化になるか見てみましょう。 ①「小鳥」を選択  ②「あげは」を選択  ③「天音先輩」を選択  0xB2B2FCの数字に注目すると、 ①0x03000420 ②0x15000060 ③0x15000020 勘のいい人であれば上の数字配列を見ただけですぐに気付きます。 慣れてない人には全く何のことかわからないと思いますが…。 つまりどういうことかというと、ビット単位です。 ①0000 0011 0000 0000 0000 0100 0010 0000 ②0001 0101 0000 0000 0000 0000 0110 0000 ③0001 0101 0000 0000 0000 0000 0010 0000 ですね。 ビットで格納されているのはこの作品だけなのかもしれませんし、今後も同じようにビットで格納するかもしれません。 そもそも、Luaを使ってこの程度であればまだまだ楽だってことですね。 他のメーカーがやってるLuaを使ったフラグの格納方法だと、プロセスメモリで単純に追うのはひじょうに難しい場合があります。 今後、このエンジンが進化すると非常に怖い存在になりそうです。 ついでに、プロセスメモリは環境依存になるので、  基点がこの辺。 この基点のアドレスが何処から来るんだろう？ ということで、  自信は無いですが、この辺ですかね… とりあえず最後の自分用メモは、  何で逆アセしてるんだよって思うかもしれませんが、自分用で使うのに重要だったり。 こういう画像をキャプってもHDDの中のどの辺に保存してるのかわからなくなるんですよねぇ… つーことで、ここまで読んでくれた人はご苦労様です。 実際のアプローチ方法は書いてません。 結果だけは書きましたが、重要なのは結果ではなくて、どうやってフラグのアドレスを絞ったかという過程です。 この辺がフラグを調べて攻略する攻略人のノウハウってことですよ。 |
| 2011/06/23 /攻略 |
デュエリスト×エンゲージ
グローバルフラグもメモリで見るのが簡単。 未読スキップを非装備。 自動カーソル移動強制。 の最悪の仕様で、  こんな風に改造。 攻略の確認時は未読スキップが必要なんだな ちなみに用途不明のフラグがありますが……設定ミスでしょうか？ 穢翼のユースティア
 こんな感じで作成。 基点をサーチで特定して、そのサーチしたアドレスからフラグを導くように記述してます。 仮に修正ファイルとかで基点がズレても問題なし。 クリアフラグは、見極めるのがしんどいんですけど、 Ethornellのいつもの場所にあっていつものような状態で格納されていました。 キミとボクとエデンの林檎
Para-solとはポインタの数が違うような気がするんですが、 同じバージョンのエンジンなんでしょうか？ 単に表示が5.0.0.0のような気がしてます。 このエンジン、基点をサーチで特定できそうで中々特定できるような形態に持っていけないんですよね。  グローバル関係のフラグもすぐにわかりました。 勇者と彼女に花束を
基点はサーチで特定可能ですが、 オフセットが作品によってバラバラなので結局末端のフラグから逆探知していくような工程になります。 YU-RISの場合、フラグの配置が4Byte間隔じゃないので、その辺さえわかってれば容易にフラグが見つけられます。 他作品では簡単にクリアフラグも見つけられますが、この作品ではクリアフラグを見つけることができませんでした。 クリアフラグが無いのでしょうか……？  |
| 2011/06/21 /攻略 |
美衣菜△です!
ASTは１年半ぐらい前に制覇したと一度は思ったけど、 色々と作品の攻略をやってると制覇しているという状態でなく、 かなり厄介なエンジンであることがわかってきました。 「オトプリ」のときに、メモリでフラグが捕捉できたと思ったんですけど、 その後、「ボクラはピアチューレ」でフラグの順序が入れ替わることに気付き、 「令嬢の秘蜜」のときにはもはや何が何だか…… 「美衣菜△です!」で、取りあえずは出来るところまで解析です。 まずは基点からのポインタ先をずっと眺めていると、ある法則性に気付きました。 ちなみに基点の先にあるポインタってのは、ポインタの数が多くてどのポインタを使用するか…の判断が難しくなっています。 ついでに書いておくと、数が多いなら末端のフラグからポインタを特定できると思うかもしれませんが、 セグメントのヘッダ部分以外に飛ぶポインタってのがダミーの如く配置されていているので、 慣れていないと難しいです。  上図のポインタの配列を見ると、配列に規則性があります。 そのポインタ先を見るとそれも独特です。 例えば、0x3D6930と0x3D6934のポインタの関係を見ると下記の図になります。  この図を見たときに、使えるポインタが0x3D6930なのか0x3D6934なのか……の判断でしょう。 片方はセグメントのヘッダにありますが、もう片方はセグメントのヘッダじゃないです。 以前は、この判断でミスを導いたと、よーーーやく理解できました。 で、この関係から最初の図の配列を見たときに、使えるポインタってのはある数字の配列と関係しています。 つーことで、ここまでが１個目のポインタ部分の終了です。 次に……なんですが、 ASTの過去の解析でもわかってることとして、ポインタの数が特定できない…ってことです。 フラグの場所によって、ポインタの数が違っていたりします。 今回は１個目のポインタの関係からセグメントのヘッダ部分の構造が理解できたので、 セグメント内のポインタの配置の関係を探っていると、やはりここでも規則性がありました。 その関係をSSGにするとこんな感じ  とりあえずはゲームを起動ーーーー SSGをチェック。ちなみにフラグ名も取得しとるだによ  起動時は上の図のような感じなんですが……  ゲームを進めるとこんな感じに……orz ある捕捉しているフラグは、同じポインタでフラグが別のフラグに入れ替わっとるんだが……AST、恐ろしス…… ま、これが「令嬢の秘蜜」のときに発覚した、シナリオのある地点を通過すると、 あるフラグが別のフラグに置き換わってしまう現象の原因なのでした。 これはASTがフラグの数の絶対数を増やすときに、ポインタを増やしてフラグの数を増やします。 ゲーム起動時だとフラグの確保に割り当てられているポインタは1重のポインタですが、 ゲームが進行していくと2重、3重というようにポインタの数が増えていくわけです。 そして一度拡張されたフラグのポインタはゲームを再起動しない限り減ることはないので、 ゲームをロードとかするとプロセスメモリ上のフラグ配置はカオス状態になるよ。 ゲームのフラグの判定自体は、おそらく各フラグのハッシュを読み取ってるので、 プロセスメモリで配置がゴチャゴチャになったとしても、判定としては関係ないんだろうね。 どの道、SSGじゃ難しいシステムです。 フラグ名を取得してるSSGなので何とか使えますが、 ロードしたときのカオスな状態で、どうやってメモリを見ながら攻略が出来るって言うんだ？？ ってレベル。 特にこのエンジンはフラグの数が増えれば増えるほど、メモリでフラグが見え難い……という結果なのでした。 |
| 2011/05/29 /攻略 |
獄淫の尖塔
いつものSYSTEM NNNですね。  Windows7 x64だと、アドレスの開始位置が安定しなかった前々作なんですが、 WinXP x86だと不動の位置だったり…… 0x400000ですけど、SSGではgokuin.exeの開始位置から計算して記述しました。 SYSTEM NNNをSSGにするのは非常に簡単で、フラグから基点を探すなんて野暮な方法は使いません。 基点を先に探します。  特定の数字の配列で検索をかけると、上記のような候補が出てきます。 ８件だとかなり楽です。 これは、基点自体を検索しているのではなく、 ブラックサイクの仕様で基点の近くに必ず特定の数字の配列が来ることがわかっているので、 このように大雑把な方法でいけます。  特定の数字の配列からざっと、アドレスを下に辿っていると、かな～～り怪しい地点に到達します。 この辺が基点臭いと判断できます。 このポインタを辿ってみましょう。  ビンゴのようです。 勘で、怪しい地点と思われたポインタが基点で正解だったとわかります。 この辺のセグメントを探っていればフラグにぶち当たるでしょう。  まさしく、の箇所です。  この辺もそれっぽいですね。  結果をSSGにするとこんな感じで完成です。 |
| 2011/03/10 /攻略 |
姫様限定
体験版と仕様はほぼ同じでした。 体験版で作成したSSGを利用したのですが……  何故か、明らかにフラグが足りない。 メモリで見ると色々とフラグがあるのは見えてるんですが、SSGで記述すると半分以上のフラグを捕捉していません。 SSGの記述は、何度見返しても間違ってる感じはないし、一人ではどうにもならなかったです。 4169さんに教えてもらっった方法で  全部のフラグを捕捉できました。 これはSSGのバグのようです。 攻略ページの方で、私はよくわからないコメントを書いていますが、 これは私自身もよくわかっていません。 フラグを色々と弄ってしまったのでその関係かもしれません。 症状は、Hシーンで選択肢が出てこなくなる… というものなんですけど、もしかするとH_MODE_FLAGとか間違って弄ってしまったかも…… ひなたテラス
以前のバージョンからアップしている戯画のエンジン。 昔のエンジンはフラグが読み易かったのでナメてかかってましたが、 これがフラグすら中々特定できなかったです。 以前のエンジンの仕様からするとかなり難しくなりました。 とりあえずは、フラグの部分を某神攻略人の人から挙動を教えてもらって何とか特定できました。 そこからSSGにしようとチャレンジしても中々上手くいきません。 最初は単純なアドレス変動だと思ってましたが、   ま、こういうことです。 ハッシュ/インデックス型なので、SSGで捕捉しきれません。 この挙動は、末端のフラグだけではなく、実は中継するポインタ自体も動いています。 基点から中継するポインタまでを特定のハッシュを読み取っていて、 中継するポインタから末端のフラグへもフラグのハッシュを読み取っているような感じです。 ただ、救いなのは中継するポインタの候補となる箇所が少ないので、  このように強引にSSGにしてしまいました。 しかし、末端のフラグの範囲が広いですね…。 しかもよく動きます。好感度のフラグも当然よく動きます。 |
| 2011/02/23 /体験版 |
With Ribbon体験版
ver2.32の最初の安定版  コンソールを起動できても、あんま必要な情報が得られない。 これって、コンソールに出る情報って変えられるのでしょうか…？ コンソールからの情報でシナリオのファイル番号はわかるので、 xp3をバラしてスクリプト見れば選択肢は全て抜き出せるけど、 スクリプトを見てもフラグの判定が見つからなかったです。 単に設定してないのか、製品版でも無いのか、別のファイルに書かれているのかわからなかったけどね。 このバージョンだと、吉里吉里本体が公開されているので、xp3をバラして、内容を書き換えて、xp3に戻す…ってことが結構簡単に出来ます。 そうなるとデバッグツールとかも簡単に起動できるんですけど、デバッグツールの設定が悪いのか、上手く使えなかったです。 フラグ関係を簡単にモニタリングできるデバッグツールとかあると思うんですが、どうやって設定すれば動いてくれるのでしょうか…。 デバッグツールをONにするだけではダメだったです。 |
| 2011/02/20 /体験版 |
アルテミスブルー体験版
吉里吉里の場合、体験版と製品版でバージョンが違うことが多いのでほとんど参考にならないです。 ver2.30.2.416は3年ぐらい前のバージョンかな。 体験版範疇だと予測しにくい状態ですが、このまま最後までこの調子だと攻略的にはあまり価値が無いような気もします。 体験版では4回目のクリッカブルマップで「岸壁」を3回選択するくらいがフラグだったです。 少女のきもち体験版
メーカーの独自エンジンっぽいです。 アーカイブのヘッダが「MAI」というのが目安になる…？ 体験版はセーブが出来ない仕様だったのでフラグ探すのも面倒でやらなかったです。 ファイルは暗号化されてない仕様なので、セーブデータもおそらく暗号化されてないんじゃないかな。 セーブデータから解析するほうが早いかも。 ひなたテラス体験版
フラグがありそうで無さそうな…… 体験版仕様でしょうか？ フラグはおそらくモジュール内だと思うんですが、見つけることは出来ませんでした。 体験版の共通パートのスクリプトのファイルナンバーが12までありますが、 設定では共通パートのファイルナンバーは20まであるようです。 そこからヒロインルートへ分岐するようですね。 まかぱらっ！体験版
基点をサーチする方法でSSGを記述したいのですが、 前回adjustmentを使うとどうしてもreplaceの記述が正しく表現されないことがわかったので、 adustmentの部分とreplaceの部分をなるべく切り離すように調整することにしました。 慣れないWin7 Prox64で解析を慣行。 まあ、でもYu-RISは過去にWinXPでやってるのでさほど苦労はしません。 ただ…YU-RISの場合、基点がわかったからといってどうにもなりません。 実際には、末端のフラグからポインタを辿っていく方法じゃないと中継するポインタを予測できないです。 慣れればこんなもんです。  グローバルフラグのアドレスは完全な予測地点のアドレスです。 YU-RISの過去作品の傾向から、中継するポインタの配列が結構似通っているので、 こういったグローバルフラグで使用するポインタを予め推測することが可能となります。 しかし、難しいのはオフセットですね。 使用するポインタは同じでも末端部分でオフセットが違うことが多いので、 実際のアドレスを特定するのはかなり難しかったりします。 しかし、何処のセグメントにフラグが格納されるかわかるだけでも、かなりの参考にはなるんですけどね。 グリザイアの果実体験版
フロントウィングは、ここ数作だとCoreSystem2が続いてます。 一時期はQLIEだったんですけど、QLIEに比べればCoreSystem2のフラグは見易いです。 しかし、SSGにはまだ出来てないんですけどね… QLIEはアドレス変動タイプで、また結構よく動くのでプロセスメモリで生のフラグを追うのがかなり面倒なんですよ。 CoreSystem2だと起動時に依存する変動タイプなので逆にプロセスメモリで生のフラグを見るのは楽。 QLIEのメリットだと、スクリプトが読み易い…ってのはあるけどね。 分岐条件とかはスクリプトから読めることが多いし、その辺の検証をQLIEではする必要が無かったりします。 体験版では……ゲームのシステムがよく理解できませんでした。 シナリオを選択していくだけなんでしょうか？ かなりの謎です…… スイートロビンガール体験版
吉里吉里２安定動作版の最新のヤツのようですね ゲームはシステムがいまいち理解できないんですが…… ここ数年のチュアブルの作品を買ってないので、傾向が掴めなかったり。 まあ、今回も買わないかな……  体験版は共通パートの３から開始するんですけど、 シナリオ進行の仕組みがよくわからないです。 シナリオを読むときの「Go」と「Next」って何なん？ あまふたサンドイッチ！！！体験版
ミンクの新作です。 ミンクはどうも幾つかエンジンの種類があるようなのですが、 夜勤シリーズに使われているエンジンは見易かったような気がします。 しかし、このタイプのエンジンでフラグを見たことが無かったので、 丁度いい機会だと思ったのですけど、 この体験版……フラグ……ある？？ 変動タイプなんでしょうか？ よくわからなかったです。 普通のインクリメントのされ方をしてないのかなぁ… 単にフラグが設定されてないだけなのか…どうなんでしょう。 選択肢をパッと見たときに、どちらの選択にもフラグが無さそうなどうでもいいような選択が多いですね。 選択肢の数は多そうですけどね。 姫様限定！ -Princess Limited-体験版
過去にも攻略したことのあるエンジンでプロセスメモリのフラグの配置には独特の法則性があります。 丁度いい機会なのでSSGへ。  モジュールのアドレスが通常の位置とは異なります。 これって……OSの影響なのでしょうか？ SYSTEM NNNにも同様の挙動があるのですが、 単にエンジンがバージョアップしたのではなくてWin7 x64の影響の気がしてきました。 あとでWinXPで確認してみましょう。 どの道、モージュールの位置が固定されていようが、固定されていまいが、 モジュールの位置が固定されていない状態でSSGにしないといけません。 この辺の対応は簡単に出来るので問題は無いんですけどね。 モジュール内をざっと見ていくと  この辺に基点がありそうだと私の勘が告げました。 勘と言っても、実際は状況証拠的な部分があるんですけど、 それは上の画像よりも前の方のアドレスにあります。 こういったことは、数をこなせば大体わかってくると思うんですけどね。 で、適当にこの周辺のポインタを無作為に辿っていきます。  ビンゴです。 ここまで来ればフラグを割り出すのは簡単です。 フラグの名前があるので、 このタイプはあるポインタが特定のフラグを格納しないという疑いがあります。 要はハッシュ/インデックス型の可能性があります。 この辺の対応もついでにやっておきましょう…… ということで以下のSSGを作成しました。  YU-RIS Script EngineのSSGでやったように基点特定用のサーチ部分も追加してみました。 ただ、モジュールの位置が固定されないので、サーチ範囲が異常に広くなってしまいますけどね… SSGの書き方も、基点をすぐに書き換えられるような書き方にしてるので、 SFAのフラグの把握はかなり簡単に出来るようになりました。 _[!R($Val),[:!][:[:(MName::[!@MAIN->MODULE,0!])+[!@MAIN->OFFSET_A,0!]:][!R($Val),+[ !@MAIN->OFFSET_B,0! ]:]!]+[!@MAIN->OFFSET_B,1!]:] こんな感じです。 式だけ見ても多分わからないと思いますが… |
| 2011/02/19 /攻略 |
令嬢の秘蜜
アーベルとかも採用してる汎用エンジンです。 このエンジン、以前SSGにしていて、 そのときはASTを制覇したと思ったんですが、 実際には全く制覇出来ていませんでした。 単純なアドレス変動型かと思っていたのですが…難しいです…… 去年の「ボクラはピアチューレ」でASTが思い通りに行かないと気付きました。 当時は攻略を優先してしまって、詳しい検証を避けていました。 「ボクラはピアチューレ」で気付いた点は、フラグのアドレスは捕捉していても、 アドレスに格納されているフラグが、違うフラグを参照しているということでした。 要は、フラグの順番にズレが生じるのです。 ただ、この症状はEntisGLSも同様の挙動があるので、 EntisGLSと同様にフラグ名を参照していくSSGを作成します。  あるセグメント内にあるフラグの配列を表示。 上の画像はゲーム開始時です。 scというフラグはヒロインを選択した履歴のフラグで、 このフラグが立つとヒロイン選択時にその選択肢から除外されます。  同じフラグセグメント内のフラグを捕捉。 上の画像は二巡目に入ったときのフラグです。 新たにフラグ名が定義されている箇所が出てきます。 ちなみに、新たに追加されたフラグはこれ以外にもあります。 捕捉しているセグメントでは全然足りていませんね……  上の画像は、同様の箇所を三巡目に入ったときのフラグです。 ここでもフラグが新たに定義されていますが、 それよりも以前格納されたフラグが別のフラグに置き換わっているのがわかると思います。 詳しいことは画像中の「ポインタ検証用」のところにあるアドレスを見ればわかると思います。 ポインタ３のアドレスが前の2つの画像に示してあるアドレスとは異なっています。 以前のフラグは無くなったわけではありません。 この現象は、フラグが再定義されたときに中継するポインタが別のフラグのポインタに置き換わるようです。  最初の状態のメモリをキャプチャするのを忘れていたので、この画像だけではわからないですが、 最初0x00000000の箇所だったところにポインタが次々と格納されています……  後半に入ったときのフラグです。 やはり、ポインタが動いているようですね。 結局のところ、全てのフラグを把握するのは難しいシステムです。 何しろ、中継するある地点のセグメントは、 膨大な数のポインタが配列されていて、その中から目的とするポインタを最初から予測するのは難しいです。 ただ救いなのは、他作品とも比べていくとフラグを格納するのに使われるポインタはおそらく特定のポインタに限定されている傾向があるようです。 そもそも、フラグを格納するポインタがわかったからといって、それが特定のフラグを格納するアドレスを示していると限りません。 フラグとそのフラグのハッシュが必要となります。 フラグが再定義されない場合は、同一アドレスを監視しているだけで済みますが、 今回のようにゲームの途中で再定義されていくとアドレスがわかっても意味が無いですね… こういうハッシュ/インデックス型のスクリプトエンジンで何とか簡単に特定のフラグを捕捉し続けることは出来ないのでしょうか…… SSGでは……ムリ？？ |
| 2011/02/08 /攻略 |
妹ぱらだいす！
retouchのSSGを以前汎用化したんですが、 このバージョンのretouchには適用できませんでした SSGの書き方も変えてるので、この際だから作り直そう… ということで、最初から作り直しです。 retouchの傾向として、同じバージョンであればオフセットは同じだということ。 つまりは基点を特定さえすれば、フラグの格納されているアドレスを導き出すのは簡単です。 retouchは、特定の数字の配列からサーチをして基点を特定できます。 基点サーチしてSSGに反映させると、  こういう感じで作成出来ます。 しかしここで問題になるのはreplaceの記述です。 上記の図はフラグをちゃんと捕捉しているように見えますが、  うさみみハリケーンでプロセスメモリを見たときに、 0x8184FC8の数字が「8」であるのに対し、 実際のSSGになると、  電卓では「0」の数字になっています。 アドレスをSSG作者モードで確認すると、  0x8197360なので、全然違うアドレスを参照しているようです。 しかし、よくよく見てみると、 0x8197360-0x8184FC8=0x12398 です。 この数字、[adjustment]でサーチしたときの補正値なんですよね  SSGは、 [replace]_[:[:[:[_0x4C0000_]:]+[!@retouch->OFFSET_A,1!]:]+[!@retouch->OFFSET_B,1!]:]+[!L$Val!]*0x10+0x4*0,retouch->retouch_B で記述していて、[adjustment]で補正した部分は、 [_0x4C0000_] でカバーしているはずなんですが、結果として[replace]全体の式にも[adjustment]の補正値が勝手にかかっているとわかります。 おそらくSSGのバグなんでしょうが、 そういった部分を考慮して作成すると、  こういう感じで作成することは出来ます。 アドレスは  一応ちゃんとしたアドレスを参照しています。 動作は正常になったけど、記述が正常じゃないからなぁ……う～ん…… |
| 2011/02/06 /攻略 |
黙って私のムコになれ！
フラグを見るのは難しいエンジンじゃないし、SSGにするのは簡単。  こんな感じ。 AQUA
フラグはおそらく無い。 グローバルフラグぐらいなんじゃないかな。 フラグが仮に立っても、選択肢が1個だけじゃあ判断が難しいね 攻略的に面白くない作品 Leafの「星の王子くん」といい…攻略価値がなかった アネカノ
選択肢分岐です 案の定、攻略価値はありません。 SSGもグローバル関係のやつだと以下のぐらいでしょうか  Will系列のやつはグローバルフラグが見易いので簡単です。 |
| 2011/02/05 /攻略 |
星の王子くん
フラグというか直分岐？ らしき箇所はあるけど、書き換えても意味が無い  グローバルフラグの箇所もわからなかったです。 「寝床カラオケ」の出現とかフラグの場所を知りたかったんですけど……。 ただ…怪しい箇所はあります。  この周辺だと思うんですけど、時間を掛けて調べたのですが徒労に終わりました… 難しいです 固定アドレスだと思うんですが、違うのでしょうか？ 固定アドレスだと仮定すると 見つける方法としては、グローバルがONのときとOFFのときでメモリダンプしまくって比較すればいずれは見つけられると思います。 面倒なのでやってません。 |
| 2011/02/03 /攻略 |
極道の花嫁
フラグを見るのは簡単なエンジンなんですが、 Windows7 x64に移行してから結構しんどいです 同じフラグを比較してみると、 Windows7 x64の場合 0BD4FCE0-0BD4FD6F: 90h(144)Byte [Windows ANSI] Address : +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F 0123456789ABCDEF 0BD4FCE0 : 49 00 00 00 00 00 00 00 00 00 00 00 20 66 6C 6F I flo 0BD4FCF0 : 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I 0BD4FD00 : 97 F2 16 0B 00 00 00 88 00 00 00 00 00 00 00 00 劣 ・ 0BD4FD10 : 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0BD4FD20 : 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0BD4FD30 : 00 00 00 00 00 00 00 00 90 F2 16 0B 00 00 00 8C 泉 ・ 0BD4FD40 : 00 00 00 00 44 41 52 00 34 01 AC 1F 47 61 6D 65 DAR 4 ｬ Game 0BD4FD50 : 50 61 72 61 6D 65 74 65 72 00 DB 04 0D 00 00 00 Parameter ﾛ 0BD4FD60 : 0F 00 00 00 00 00 00 00 B0 FD D4 0B 06 00 00 00 ｰﾔ WindowsXP x86の場合 047770B0-0477713F: 90h(144)Byte [Windows ANSI] Address : +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F 0123456789ABCDEF 047770B0 : 03 00 03 00 9C 01 0C 03 00 00 00 00 32 00 00 00 ・ 2 047770C0 : 01 00 00 00 00 00 00 00 04 00 03 00 93 01 14 03 ・ 047770D0 : 00 00 00 00 33 00 00 00 01 00 00 00 FC FF FF FF 3 ・ 047770E0 : 01 00 00 00 0A 00 00 00 07 00 04 00 97 01 08 03 ・ 047770F0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04777100 : 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 04777110 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04777120 : 03 00 07 00 AE 01 0C 03 00 00 00 00 3C 00 00 00 ｮ < 04777130 : 01 00 00 00 00 00 00 00 04 00 03 00 AD 01 14 03 ｭ赤フォントの部分が同じフラグに当たります。 WinXP x86の方は、セグメントの範囲が露骨にわかりやすいですね。 一方でWin7 x64だと、数字を眺めていてもセグメントの範囲が掴めません。 単にwin7 x64での解析に慣れていないだけなのかもしれませんが、 他のゲームと比較してもWin7 x64だと傾向がよく掴めないんですよね。 これはx64とx86の違いの可能性が高いんですけど、 Win7 x86だとXP x86と同じように解析できるのでしょうか……？ Win7のライセンスは全てx64しか購入してないんですが、 x64へ移行するのは失敗だったような気がします。 結局、WinXP x86にインストールして解析し、SSGにしました。  |
| 2011/01/31 /攻略 |
BLOODY RONDO攻略
フラグを探すのは難しくは無く、 まあ、いつもの椎名里緒だな……と。  SSGはこんな感じですね 攻略は好感度累積型です。 規定好感度があって、過剰値は考慮されません。 規定好感度を満たしたヒロインの優先度も存在しますが、それは秘密にしておきましょう。 ちなみにルート判定箇所は1箇所ではなく複数個所で起こります。 効率化する場合はその辺が若干ネックになるかも。 小夜子攻略
実行モジュールの開始アドレスがこんな感じ。  起動するたびにモジュールの開始アドレスが変わるタイプ 以前のサイクだとこんなんじゃなかったハズなんですけど、 SystemNNNが以前のバージョンと違うのでしょうか？ フラグを探すのは難しくは無いと思います。 でも、先に基点のアドレスを確認します。 SystemNNNはすでに以前の傾向がわかっているので、 先に基点を見つけてからフラグの格納されているアドレスを特定することが可能です。  フラグを先に見るのではなく、 最初にプロセスメモリでモジュールをざっと見ていきます。 アドレスの位置からこの辺に基点が来ると予測できました。 この辺…ってのは経験的なものが必要かもしれませんが、 過去の傾向からある数字の配列を読み取って探しています。 そもそもプロセスメモリのエリア属性を考えれば捜索範囲は結構狭くなります。 そのためエンジンの傾向さえ掴めれば、基点は簡単に見つけられます。 勿論、ある数字の配列は画像中にはありませんよ ちなみにモジュールの位置が変わるので、画像中のアドレスはかなり意味を成していません。 この辺のポインタを辿ります。  ビンゴでした。 ポインタは1個というのが既にわかっているので、基点さえわかれば簡単です。 上記のフラグは最初のクリッカブルマップ時の状態を示しています。 勘のいい人であれば、フラグの状態がどういう仕組みなのかも理解できるでしょう。 サイク作品のフラグ配列は他のゲームに比べると難しいかも…ですが…… まあ、問題は起動するごとにモジュールの位置が変更されるということなんです。 この辺の対応をSSGにするのは難しくはありません。  こんな感じです。 |
>↑に戻る