わら半紙

最大多数の最大幸福を願う愚か者の末路

http://pgr.blog.jp/

パンヤ

パンヤの裏話 2

例の解析記事でちらっと晒した5/16の定数。うろ覚えだが、コースデータの数値がそれ換算。
コースの高低差をその数値にあわせると、高低差が10mや1mのようなきれいな数値になる
メタセコで弄って、たしかそんなもんだった気がする
そういうデータだから、打球の傾斜もそれで換算できるかもと思ってたが、どうも違ったらしい

大半の升コードはS8でも通用する。メインのプログラムはほとんど変わってない。10年あればちょっとは対策してあるもんだが

解析記事のとおり、風向は256通りしかない。風速は65535以上も可
よってデータ取るなら風向と風速を固定すればいい。パッチ弄って好みのコースにすればいい
当時はカップの位置だけ凹ませて強制的にチップさせてたやつもいた
使った人らはもちろんBANされた

BL2Hの231yやSW7Hの231yと245yのカップ位置が、ほぼ風向0の位置にできる。あくまで(ほぼ)なので
すごく高く打ち上げると少しずつずれていく。風向が255通りしかなくとも、物理計算自体は小数点以下まで計算する
スピンいくつだったか忘れた。バックスピン250とかにすると浮きあがって戻ってこなくなる
トップスピンも同様。元のクラブの飛距離にもよるが、OBになるまで突っ込んでゆく

BL2の231yが風データとりに適していたとはいえ、OBゾーンというか海ぽちゃがあるので
基本的にはSW7や白wizのPar3で飛距離とズレのデータを取っていた。傾斜も含む
当時はそれで完成したと本気で思っていたが、実際はファミモバグのために完成とは程遠かった
今ではPar3(Par4,5を含むHIOマップ)に直行するので、データ取りというよりはひたすらにカップに打ち込む作業になってるように思う
昔とったデータは244, 258, 264, 276yであるが、SCやICの実装のため、後半のデータほど時間をかけずに取れるようになったが
結局すべて(一部のデータが不全なので)が不完全だった。これに気づくのはパンヤをやめて数年後であった


今だからいえるが、大昔のフレが大損使いまくって、BAN一歩手前だった。当時はクリムゾンリングが実装された頃
あのときに手を出さなかったのが、BANされず助かった理由だろうか
一方でデータゴルフを完璧にすることができなくなった要因であると思う
大損は当時を知る者なら間違いなく覚えていると思うが、ホントにすべての答えがあった
後にも先にも、あれ以上の完璧なものは存在しない。10年たってもだ。作ったやつはほんと天才だ


かりんごのあれは、特に証拠はないけど、最後の大会に参加したのだけ覚えてる
スコアで画像も晒したので画像持ってる人は多いと思う

パンヤの裏話 1

日本パンヤが終了したので、そろそろいいかな
まったく需要がないのもわかってる。ここのサイトはRMAだとか軸受け注油だけがマトモな永久ネタであるが・・・

パンヤのBGMを聞いてたら久々にいろいろと思い出したので、ちょっとした裏話を晒すことにする
もはやBANされることもないからね。一応最後までBANはされてないです。最終日にログインしてたわけではないけど
BANされたプレイヤーのフレのデータとかずっと残ってた


infinityは韓国パンヤでプレイ済み。日本に1Wトマチップと6IBIを持ち込んだ張本人
morがいちはやく日本語の解説ブログで有名になった

とまあここまでは一般的なお話

これは想像だが、かりんご=morcalcの作者。daison付属?の例のdll併用のオトパン計算機をばらまいて引退
かりんご=パーキッツという説は信じられない

もなか〜 とそのクラブの面々。特にツール作者らのような知識は無かったとされる
とあるルートから漏れたとされる、クラブメンツ用の(おんぷ)モカのWW-32動画をwinnyで流したという
TSURARA(ほし)のBL-35動画も同様。ただしWindHill動画は別のルートからniconicoやYoutubeに流出した

当時は♪モカのWizWiz動画のように、まだまだBS全盛期だったが、かりんご引退試合を境に、1WBIでどのホールも狙うという方法が広まったように思う
なお、パンヤを引退した♪モカはFEZにハマった。tara33もハマったっけな。その後は知らないが。

♪モカは大会で最初に?ゲージ定規を駆使して拡大縮小ずらしを行ったはず。当時、俺が後ろで見てたので間違いない。もちろん俺が晒した。当時のクラブメンツは皆知ってたと思うけどね。当時はヤード単位だったわけだし

今も言えるし誰も信じないが、tara33を育てたのは俺。といっても大半はMygoの影響を受けたともいえる
現状はMygoの理論がほぼ定着し完成したとされる
まあでもパワーゲージや画面すべてを使った風向測定の技術は俺がPeCaで晒した
もうちょっと詳細にいえば、4y/tan(1)=229y、4倍拡大or4yごとに風向が1度ずれる。ので228yの使えるパワーが最適だ、という理論。当時はいまだにヤードが主流だったが、実際はピクセルからの換算であることは疑いない

それを洗練させて、今ではパワーゲージのピクセル分で割ってHWI(垂直風影響値の略語)として確立
パワーゲージで風向もずらしも行う。いわゆるHWI理論はMygoが提唱したとされる
p.g.とHWIでほぼすべて決まるっていうあれ

個人的にはあれには賛成しない。上下10mだとか14mだとか20m高低差でデータとったけど、↑と↓では数値固定はできない
ただ、slopeっていう考え方はすごいと思った。風速換算も信じてなかったけどslope理論ならほぼ納得する
というか、その理論でクソ傾斜から1WBIしてたら納得するしかない

時代は戻って大損時代。S1の最後であるが、この頃に大損で暴れて永久BANされたプレイヤーからとある蜂ツールが流出し
オフラインで優秀な成績を残したと思うが、彩華miumiu@comが所属していたクラブ(この名前が思い出せない)に出回っていた。内容は非常に簡単で
風速表記をアルファ値にして透過させ風向を見やすくしたものと
0.25%刻みのパワーゲージをクライアントに直接表示させるもののセットのパッチである


このパッチは俺が作った。パッチに含まれる画像データの一番右下のドットの色が、マスクの周囲の色と違う
作者である俺以外気づきようがないので、当時のデータを持ってるプレイヤーは参照してみるといい。今では全国で100人もいないと思うが。というか俺でも当時のデータが残ってるか怪しい

同様のパッチは海外にも流出したか、そもそも同様の発想をするプレイヤーがいたのだろう
風向計を表記するようなパッチもあるみたいでYoutubeに残ってる
要はアルファチャネルだったり、白黒マスクなわけね。わかる人ならわかる

wecklが公開した動画、Erementar Mindsは今でもあったのでたまに見る。Youtubeに流用されていた動画は
明らかに第一部のBGMが違うので違和感
AfterEffect?っぽいエフェクト満載?第二部のタイトルはスターオーシャン2、第三部はサクラ大戦をモチーフにしたものだと思う
あれ参加してもよかったなって今は後悔してる。webでも募集かけてて門戸は広かったはず

とりあえず今日はここまで

プレイヤー名は敬称略

今更パンヤ、BL2H231y風表示


むかーし昔に作られた、風表示のアレ
流出した画像ではないハズなので、コレが公開されるのは初だと思う


wind_hayami

たしかBL2Hの231yのスクショをただひたすらに集めたものだったと思う
BL2-231yだけならほとんど正確な数値になっているらしいが
実際は状況に応じて数値を調整していかなければならないので、参考程度に

数値は16進値の内部値、sin、cosの順
作られたのは5年前らしい




パンヤはもはや別ゲーだった





http://www.youtube.com/user/tara33JPpangya?feature=watch

http://www.youtube.com/user/rechtwissenschaft?feature=watch


なんとか33さんはわしが育てた、なんて6年ぐらい前に配信でほざいてた人もいた記憶もあるが
あくまで素BI(死語かもしれないが、ティーやアプローチの通常ショットでノーバウンドカップインを狙う方法)によるチップを狙っていく概念を広めただけに過ぎず
現在のパンヤ上位層は、パンヤ(中央で止めること)率の高さ、コース攻略の密度、ショット1打1打の精度がすさまじい

なにこのゴルフゲーじゃない別のゲーム。廃人怖すぎ
って同じようなこと以前にも書いてた気がするわ

キモクナイ


https://www.pangya.jp/img/guide/info_caddie_img004.jpg

以前はパンヤをガチプレイしていたわけだが、今更ながらこのキモさである
誰かによく似ている気がするが、きっと気のせいだ



ノス活動、ネタともになし。激しく眠い。FCレイド逃したら仕方ないや



パンヤミドリムシ講座 ショット飛距離とコードインジェクション


CanUCrackIt?
最初のEBなのがいかにもJMPっぽい
とりあえず16バイト単位で並んでいるというだけでもヒントなのかね

英国公務員になるために知識が必要ってのも、すごい時代になったものですね
これを解いて公務員になれるのだったら楽かもしれません。ヤレヤレ


一方、愛知ではというと県政愛知採用情報で110人以上の採用を予定しているとのこと。詳細はこちら
非常勤嘱託、臨時、障害者向けの採用
長くて1,2年程度でも構わない方、大村閣下万歳できる人向け。中京都万歳できる人向け



本題のパンヤミドリムシ講座である。これ目当てに見てる人などいないと思う。完全なジコマンである
せっかくなので今回は実践的なことをしてみよう

コードインジェクションはパラサイトルーチンとも言われるが、元のアドレスの命令をJMP命令に書き換え
JMP先に本来の処理や置き換えたい処理をさせ、その後本来のアドレス(の次の命令に)JMPさせる
どうしても書き換えたいが、バイト置き換えだけでは不可能な命令をさせるために
メモリの余った部分にジャンプさせてしまうというものだ

実際に利用するケースは、「必要に迫られたとき」である




では実例を示すことにしよう
まずは適当にファミモでも行って適当にショットを打つ。すると飛距離表示が出る

png05

このスクショを撮った瞬間、メモリのどこかの値が210.10となっている(かもしれない)
アンチクラックの目的で、何かしらの演算を行って別の値をメモリから読み出していることもあるが
今回のパンヤでは、素の値がメモリに格納されている(と後でわかる)


何はともあれ、この飛距離表示がメモリのどこなのかをサーチしよう

flo

サーチ範囲は1000から。スタックも検索するということ。0x00401000以降をサーチするのが普通だが
現在はマシンパワーが余ってるぐらいなので、範囲を最大にしちゃっても構わない

DataType Search、Float、ExactValueでも全く問題ないが、念のためRangeで範囲を広げてみよう
パンヤが何FPSで稼動しているかはマシンごとに異なるが、マシンの性能次第で飛距離表示の描画頻度が変わる
なにしろ描画速度が速いため、瞬時の検索を行うためにはアプリケーションの処理を一旦停止させるしかない
SpeedHackなり、デバッガの一時停止なり、何かしらをする必要がある

何はともあれ、何度も範囲サーチをすることで値を一個に絞る

dst

今回は0x0A9F018Cであるようだ
0x0AD14858でも一定間隔で数値が更新されるが、瞬時の値を常に保持するのは前者である
きっと画面描画時に0x0AD14858の値が使われるのだろう(ホントかよ・・・)

dst2

指定メモリ書き込みに対するブレークポイントを張る。いわゆるFind out what Writes〜〜
デバッガでハードウェアブレークポイントしてもよい

dst3

どうやらこのアドレスの命令で書き込むらしい。ollydbgで周辺を見てみよう

dst4

ヒョッコリ出てきた定数0.3125(5/16)。自力でこの数値(の近似値)にたどりついている方がいれば
ランカー候補かもしれませんね。本当にスゴイと思うよ。
ここでは解説は省きますが、そのうちしてみたいですね


アセンブルコードいわく、EDI+34の位置に浮動小数点数(FPUスタックからPOP)の内容のバイナリを書き込むとのこと

EDI値がショットごと、プレイヤー(1P、2P、3P、4P)ごとに違う(かもしれない)
さらには、毎回のファミモでも異なるのではないかと推測しなければならない
つまり、コードを見た後に推測(EDI値を逆順に追うなど)しなければならない
これはうまくサーチできている場合であって

普通にサーチするぶんには0x0A9F018Cにたどりつくのも大変だ。画面が常に描画されて数値が変動しており
範囲サーチでもないとたどり着くのすら困難だろうし、次のファミモ、ショット時にはアドレスが変わっていることに気づくはずだ
この場合は、コードを見る前に推測しなければならない


いちいちサーチするのは描画の都合で大変なので、メモリの特定のアドレスに常に書き込まれるように変更してみよう
D95F34の命令は3バイトで、これだけでは絶対的に命令が不足する
こんなときにはコードインジェクションを行うのがよい

まずはジャンプ命令を入れるのだが、ジャンプ先に都合の良いメモリ位置を探そう

mem

元のプログラムが読み込まれる(正確にいえば、ASPack方式でEXEを解凍する)のは0x00401000以降のセクション
少なくともここ以降でなければならないし、領域に適切なアクセス許可が必要である

mem2

ダンプを見るとセクション3は特にデータ無しのようだ。ジャンプ先に都合が良い

ちなみに、たいがいはセクション0(0x00401000以降)の終端付近でよいケースが多い

mem3

プログラムが常にメモリを少し多めに確保するため、このような0で埋まった領域ができる

今回はせっかくなのでセクション3を利用してみよう。まずは元のコードをJMP命令にする

dst4
↓↓↓↓↓↓↓↓↓↓↓↓
inj1

ショートジャンプではないため命令数が5バイトになり、もとの3バイト以上である
次の命令である0x004909B3の内容を潰してしまっている

inj3

そこで、ジャンプ先で命令を復元し、0x004909B8へジャンプさせることで、元の位置へ戻す。
これがパラサイトルーチンである
CheatEngineやMHS、うさみみハリケーンのInject Code、Auto Assembler、さらにはDLL Injector機能を使うと一連の手順が自動化され
大変便利で便利であるが、多機能すぎて使いこなすのが一苦労


たとえばMHSでは
mhs1

ASM、アセンブルコードをコピペすることで書き込み結果も表示してくれる
さらに適当なメモリ領域を自動で探してくれるという親切設計
もちろんCtrl+Zで変更を戻すこともできる。この利便性は画像の編集並みだ


さて、0x00BA300以降を使い、プログラムを自由に弄れるようになった。
上記画像に示されたパラサイトルーチンのように、以下のようにコードを修正した

inj2

・EAXをスタックに保存
・EAXにEDI+34のデータ(FSTP命令でメモリに書き込まれた飛距離、浮動小数点数のバイナリ)を転送
・メモリ0x0BA3020にEAXのデータを転送
・EAXをスタックから復元
仕上げに最後のジャンプ命令を修正しておく

データ転送命令では「メモリ→メモリのデータ転送」はできない(拡張命令なら可能らしい)ため、EAXを一時領域とした
この場合はEAXの元の値をスタックに入れておいて後で取り出すことを想定している
コード修正や改変を行うのであれば、アセンブリ言語を知らなければなりません

POP、MOV命令程度であればCPU負荷はほぼ最小なので、処理速度低下のような問題にもならないでしょう


上記の修正により、メモリの0x0BA3020から4バイトの領域に常に飛距離の値を書き込むようになる
実際にMHSやCE、ねこまんまでサーチすれば納得するはずだ

rslt1

ゲームの描画速度が速いため、メモリデータの読み出し(もしくはPrintScreen)が追いついていない
リアルタイム監視というには遅すぎるため、メモリ監視タイミングを縮める必要がある


rslt2

ゲームの描画速度を落とすことで、デフォルトのメモリ読み込み間隔でも十分に追随することができた
まるで液晶とCRTモニタの遅延を計測してるかのようですね


コードインジェクションをすることで、プログラムを自由自在に弄ることができるようになります


パンヤミドリムシ講座 サイレント


1ma

さて、ちょっとわかりにくいのであるが、ポイントとなるのは1mという表示を行わせる動作のすぐ直前が
?mを表示させるための関数部であることだ
**この画像だけではわかりませんが、解析すればわかります

WindHillでは標準の風速に加え、マップの一定箇所では乱気流(という一定の風向と風速に一定数を加算する)処理を行い
風速に?m、風向表示を変化させ
その「後」に、サイレントウィンドの処理を行う。これは以降強制風速1mである
なので、乱気流に何m加算されようと常に1mになる

そういうわけで、サイレントを使うと乱気流も1mになるのは
解析することで「そういう仕様だから」と知ることができる

**え、今どうなってるかよくしらんけどね
**以前はそうだったと思う

ではこういった動作をメモリのどこで行っているかを探すわけであるが
"1m"という言葉がそれだ

解析において最も重要なヒントはゲーム内動作を達成するためのアルゴリズム
つまり単純なデータ移動やジャンプといった動作の集合体である。内容を理解しなければならず
そもそも、数千行数万行からなるソースをさらに砕いたアセンブラ言語を簡単に読めるはずもない


そこで、別のケースからの手法、たとえば文字列である
実行ファイルに必要な数値を確保しておき、後で参照するといった類である

1mb

ollydbgにおいては、右クリ→All referenced strings

1mc

実にたくさんの文字列が参照されていることがわかる
golfrule.cppだとかwind.cppとかfontinfo.cppとかtrajectory.cppとかlobbymain.cppとか
serverdlg.cppとかspin.cppとかexhibition.cppとかgolfplayer.cppとかwinmain.cppとかuserinfo.cppとか
cppそろそろ省略してtutorial、npc、quadtree、gui_control、Fubutton、clubとか
とにかく多数あるものです

windは風、spinはスピンだというのはもちろん、golfruleはパンヤか否か、ショット種別だとかパンヤの根幹の動作を占めてたりするんですが
こういうことを知っているだけでもヒントになります

画像の下のほうの「Bad,Pangya,PowerSpin」なんかはわかりやすい。これらの文字を読み出してるところがパンヤ止め動作にかなり近いです


文字列の検索と同様の例では

wind_19

さんざんこの画像を見てるけれども
99E120:float 0.1(バイナリで3DCCCCCD, メモリ上は[CD CC CC 3D]、リトルエンディアン)
99D0F0:float 1.0([00 00 80 3F])
9A0CCC:float 9.0([00 00 10 41])
いわゆるconst、constant、定数である。実行ファイルに生のデータで格納されることが多い
文字列ではないが、パンヤの風が標準で1m〜9mであることがヒント
単なる整数値でなく浮動小数点である可能性も考慮に入れるべきである



他にも、ヒントとなるのは All intermodular callsで、主にWindows APIや制作環境のAPI(VC++やDelphiなど)を持つDLLの呼び出しをどこで行っているかを参照することができる

1md

msvcr71.dllによって提供されるものを多数使用している
実行ファイルのパンヤディレクトリにmsvcr71.dllが存在するため想像がつくが、MSVC++環境で制作されているのだと断定できる
kernel32.dllやuser32.dllといったWIndowsAPIも数多いのだが
中には、ntdll.dllによるAPI群も存在する。これをNative APIと呼ぶ

ネイティブAPIは低レベル(より高位の権限)で動作しWIndowsの中核をなすものである(らしい)が
簡単に操作できてしまうとOSの動作、セキュリティ、秘匿性に著しく影響を与えるため、MicrosoftはネイティブAPIの仕様を公開することは無い(なのでntdllの動作については謎が多い)

だがWIndowsの解析が進み、一部のマルウェアがこのAPIを悪用した乗っ取り動作を行うことで知られている
いわゆるアンチハッキングソリューション(nProtectHackShieldCrackProofなど)も、ネイティブAPIを利用することで、OSと同レベルの権限を用いたチート対策を行っている

具体的にはAPIフック。特定のAPIが動作する際にGG(GameGuard。nProではgameguard.desなどの実行ファイル)を通るようにして監視する
CallするWindows APIやNativeAPI 関数のジャンプ先を置き換える手法である


話は逸れたが、WIndowsの動作は殆どすべてがAPIで提供されるものであるため、APIを知っていればヒントになりえる
WindowsAPIやネイティブAPI以外にも、msvcr.dllつまりVC++、Delphi、.Net、VBasic といった制作環境で作られたソフトの動作に特定のDLLが必要なことが多い
そういった外部dllですら、WindowsAPIを参照していたりするが

1ma

たとえばsprintfを知っていれば・・・というところ
文字列をメモリに出力するという、見た目どおりの動作で説明不要だ
こういった動作(API)に着目することが解析のヒントになる

そもそも文字列がある以上、それに対応した関数があるわけで
文字列においてsprintfがセットで使われると思っていいわけだ


おおまかな動作の流れを知れば、あとはそこかしこにブレークポイント(実行されたときにプログラムを一旦停止する)を仕掛けて総当りで探れば、細かい流れも見えるようになるだろう
はっきりいって馬鹿なので総当りでないとワカンネ

パンヤミドリムシ講座 風速風向をデバッグして実際にコードにする


前回の記事にはアンパック済みのとあるものの一部を掲載している
では、実際に風速を0mに、風向を0に固定してしまうコードを作るとしよう

0047C603  |. 8B3D 08089F00  MOV EDI,DWORD PTR DS:[<&MSVCR71.rand>]   ;  MSVCR71.rand
0047C609  |. 75 0C          JNZ SHORT projg.0047C617
0047C60B  |. FFD7           CALL EDI                                 ; [rand
0047C60D  |. 99             CDQ
0047C60E  |. B9 09000000    MOV ECX,9
0047C613  |. F7F9           IDIV ECX
0047C615  |. 8ADA           MOV BL,DL
0047C617  |> 807D 0C FF     CMP BYTE PTR SS:[EBP+C],0FF
0047C61B  |. 75 0D          JNZ SHORT projg.0047C62A
0047C61D  |. FFD7           CALL EDI
0047C61F  |. 99             CDQ
0047C620  |. B9 FF000000    MOV ECX,0FF
0047C625  |. F7F9           IDIV ECX
0047C627  |. 8855 0C        MOV BYTE PTR SS:[EBP+C],DL

まずは第一回の内容を踏まえ、乱数を生成して割り算を行う部分に着目する

0047C60E  |. B9 09000000    MOV ECX,9

0047C60E  |. B9 01000000    MOV ECX,1
とすることで、1で割り算(余りは0)となる

*注意
0047C60E  |. B9 00000000    MOV ECX,0
次の命令がゼロによる割り算になり、エラー。OSに処理が移る。これは例外になりアウトである

割る数を変化させるのもよいが、割り算自体を置き換える方法もある

0047C613  |. F7F9           IDIV ECX
この割り算を行わずMOV DL,'0'(0は即値)と書き換えることで、結果の数値のDLを0に固定する
0047C613  |. B2 00           MOV DL,0

同様に

0047C620  |. B9 01000000    MOV ECX,1
により除算の余りをゼロにし、常に風向がゼロ(コースをまっすぐ見たときの↑方向が0)となる

0047C625  |. F7F9           IDIV ECX

0047C625  |. B2 00           MOV DL,0
割り算を変化させMOV DL,'0'(0は即値)とすることでやはり風向が0となる


風速に対してはこの後処理を行い
乱数を生成した後、 嵒速に1.0を足し」、1未満であれば◆1.0」を、9より上であれば「9.0を代入する」
これを連想してもらうのが第二回の内容の趣旨である

0047C68A  |. DA45 0C        FIADD DWORD PTR SS:[EBP+C]

0047C6C3  |. C745 0C 000080>MOV DWORD PTR SS:[EBP+C],3F800000

0047C6E3  |. C745 0C 000010>MOV DWORD PTR SS:[EBP+C],41100000

これらの部分を全てNOP(90)に置き換えることで数値の変化を行わないようにする



また、△鉢については、それぞれのすぐ上の比較、条件分岐命令を参照すると

△里垢鮎
0047C6BE  |. F6C4 05        TEST AH,5
0047C6C1  |. 7A 10          JPE SHORT projg.0047C6D3

のすぐ上
0047C6DE  |. F6C4 41        TEST AH,41
0047C6E1  |. 75 10          JNZ SHORT projg.0047C6F3

それぞれがAHとの比較をとり
▲僖螢謄フラグが立っている(偶数個である)
ゼロでない(ゼロフラグが立っていない)
それぞれこの条件でジャンプである

TEST(論理積)と浮動小数点のバイト変換を知っていないとわからないのであるが


float 0(0000 0000)、float 1.0(3F80 0000)やfloat-1.0(BF80 0000)等であればジャンプせず、風速を1mとし
float 2.0(4040 0000)や float3.0(4080 0000)、以降中略して 7.0(40E0 0000)などはジャンプする

浮動小数点の上位バイトを05(二進数ビットの0101 、正確にはビット0000 0101)との論理積を比較することで、2未満の数であるかをチェック
float 2.0以上であれば偶数個のビットが立つためジャンプ(1.0mに書き換えない)というわけだ
間違ってたらpgrしてくれていい

float 7.0(40E0 0000)以下であればジャンプして
float 8.0(4100 0000)以上であればジャンプせずに風速を9mとする。float 9.0(4110 0000)も同様である
ビットでいえば(41は0010 1001)

ミソとなるのは(4100 0000)が浮動小数点の8.0であるということだ
割り算の結果が0〜8になるのを覚えているだろうか
ビット単位での割り算(つまり二進数)で考えると、偶然でなく必然であるが
の条件文は△亮,帽圓錣譴襪里ポイントで、最終的には9以上になる値をジャンプしないようにしている
ほんとかよ(

以上により
・AHと比較する1バイトを変更して常にジャンプさせるようにする
・もしくは、条件部分を常にジャンプするようにする(JMP命令にしてしまう)
上記のいずれかに書き換え、条件比較部分を突破することを考える

JMP命令にしてしまうのが、言うまでもなく非常に楽
0047C6C1  |. EB 10          JMP SHORT projg.0047C6D3
0047C6E1  |. EB 10          JMP SHORT projg.0047C6F3


もうひとつは、比較する数値を書き換え
0047C6BE  |. F6C4 00        TEST AH,0
0047C6DE  |. F6C4 01        TEST AH,1
こちらは少々厄介。代表的な値が00、01、FFなどであるが、このようなデバッグを行い、意図したとおりに動くとちょっと嬉しい

条件分岐や数値比較を弄るほうが、書き換えバイト数は減るため「美しい」とされ
NOPで潰すのは「美しくない」というのが「お約束」
NOPで潰すよりもジャンプ命令に着目し、さらに比較する数値まで脳内で想像しよう。楽しいアセンブラ。



以上により、ただ書き換えるだけの目的の、いわゆるわかりやすい形式だと
0047C60F-01(0047C613-B200)
0047C621-01(0047C625-B200)
0047C68A-909090
0047C6C1-EB
0047C6E1-EB

のような形式になる。こちらのほうがミジンコには馴染みあるだろう


そしてここで大前提を忘れているのだが、´↓とした、風速に1.0を足し、1mや9mに変更する条件部分は他にも複数あり
ナチュラル鯖、サイレント(問答無用の1m化)、シルビアキャノンなどで全部別の処理を行っているということだ
よって´↓のようなコードは他にも複数書き換えなければならない

だが、サイレントを適用している部分にジャンプしてやれば、必ず常に1mになる
さらには、サイレント変更先風速を0mにしてしまうことで、常に0mになる。つまり無風である


ちなみに、乱数を生成して0〜8や0〜25「4」の余りの値を出す部分はすべて共通で一括処理であるため、こちらは問題ない(大丈夫だ
すなわち書き換えが楽なのは、「風速1m固定」と「風向0固定」、ということになる

0047C60F-01(0047C613-B200)
0047C621-01(0047C625-B200)
この二行だけでいい


次回の(裏の)パンヤ講座は「必ず常に1mになる」を強調した件について言及したいと思う
サイレントウィンドという超重要(?)課金アイテムがプログラム内部でどのように処理されているかということは
ランカーどころか一般のプレイヤーにとっても気になるところではないだろうか

実のところは「ふーん」「そっかー」程度の内容ではあるが
プログラム内部処理を追わなければ「正確な仕様」を理解することはできない
めんどくさいものである

nov_11?18_2011_projectg


そのままではパックされているため、現在の最新版をアンパックしたものがこちら
前回、前々回の内容を踏まえ、どのような処理をしているのかを追っていくとよい
ほとんど同じだということがわかる

今回も風速風向を乱数から生成する関数部である
続きを読む

パンヤミドリムシ講座 風速 その2


wind_19

上記は一般のケースでは実行されない部分で、同様の演算を行う箇所が2箇所以上存在する。
他にも、シルビアキャノン、ウィンドヒルのように
風速風向が変化する場合の命令部がこの近辺に存在することは想像できるだろうか
こういった、「想像」が、リバースエンジニアリングでは大きなヒントになる
仮にこの部分の命令部が実行されると仮定する


2行目のJE 47A98にジャンプしない条件の場合、FLOAT 0.10000が絡む計算を行うようだ
これはおそらくナチュラルサーバー仕様だと見ていいだろう
FMULは0.1を掛け算し、FIADD [ARG.20]により最初の風速(9での割り算の余り)に足すのだろう、と見ることができる
FMULは浮動小数点の掛け算、FIADDは浮動小数点に整数を足し算する


次のFLOAT 1.00000が絡む計算は、[ARG20]をレジスタに呼び出してFADD、1.0を足す
この計算により、前回の乱数の割り算の余りの0〜8の値が1〜9になるというわけだ


その後、FCOMP 1.0/9.0、1.0と9.0と比較する命令部が見える。COMPの中身はSUB(引き算)でフラグのみ変化
ロードした数値が1.0以下であった場合、ARG.20に3F80 0000を
9.0以上であった場合にARG.20に4110 0000をぶっこむというわけだ
いちいち解説するまでもないが、3F80 0000は浮動小数点数1.0であるし、4110 0000は9.0である


紹介した画像の下半分はARG.19に対しての同様の処理を行っている。
上半分ではFLD(浮動小数点数に呼び出す)直前にARG.20のときはECXから読み取っていたのが
ARG.19に対してはEDXをMOV→FLDしている。こういった数字の流れを読み取ることで
どんな処理をしているのかを適当に読み取ろう



繰り返すが、重要なことは、実際にどんな動作をしているかを想像することだ
想像力を持って読み取っていくのが重要である

ああ、あと、この内容は違う可能性もあるから鵜呑みにしないで自分で調べて欲しい


パンヤミドリムシ講座 風速風向


パンヤというゴルフゲームは「真ん中で止める」のがほとんどすべてであるが
フィーリングで補う部分も多数ある。その多数が、内部ではプログラムによって処理されている

今回は、まず風について、プログラムから推測される現実、すなわち正解を知ること
地道ではあるがスコアに直結する知識となろう


pang_wind

まずは風速であるが

8B3D 58C79900 MOV EDI,DWORD PTR DS:[<&msvcr71.rand>]
75 0C         JNE SHORT 0047A925
FFD7          CALL EDI
99            CDQ
B9 09000000   MOV ECX,9
F7F9          IDIV ECX
8ADA          MOV BL,DL



<&msvcr71.rand>の文字列のとおり乱数を発生させているんだな、とわかれば十分である
アセンブラを直訳すると

msvcr71.dllのrand関数の存在するメモリ上のアドレスを「EDI」に格納し、CALL EDIによってrand関数を実行
する
EAXに乱数が入った後、CDQにより符号拡張して乱数をEDX:EAXに格納する
ECXに9を入れる
EDX:EAXの値をECXで割って、商をEAX、余りをEDXに格納する
EDXの下位1バイトであるDLをBLに格納する

これを簡単に言えば
乱数を9で割った余りをBLに格納する。9で割った余りは必ず0〜8の9種類になる


次に風向であるが、ほとんど同じ内容であるから直訳はしない

FFD7          CALL EDI
99            CDQ
B9 FF000000   MOV ECX,0FF
F7F9          IDIV ECX
885424 50     MOV BYTE PTR SS:[ARG.20],DL

10進数の255(16進数のFF)で割った余りの下位1バイト「DL」の値をARG.20(スタックの20番目)の位置に格納する
余りは0〜254の255通り



こちらはスタックの内容
windstack

ESP値が12EC0Cでベーススタック、その20番目の値に格納するというわけだ
スタック内には複数の数値が格納されているが、たとえばコース情報(ID)などが入っているだろうと予測することができる


ほとんど解析が終わっているとされる現在のパンヤ事情
パンヤ情報なんてのはこれぐらい突っ込んだ内容でなければ価値がないうえ
ランカーにもなればこれぐらいのことは(死ぬほどパンヤしているので)想像がつく
すなわち、記事としての価値を得るためにはこれぐらいの内容が当然である


一般人とランカーの差というものは、単なるデータという知識、計算力、パンヤ止め力だけでなく
プログラム内の処理をある程度知っている。ここが絶対的な識差になっている
制作したプログラマ並みにパンヤのことを知っているわけだ
もはやこの程度の内容が常識になりつつあるといえる


次回はこの続きを追っていく内容である
風速がこのままでは0〜8である。画像をみていただければ想像はつくだろうが
「FADD」命令であるとか、FLOAT 1.0000という数値が見える
その後の処理の流れを次回に紹介していこうと思う

本気で読んでいる方、各自、一個一個の処理の流れを自分で考えて欲しい
コンピュータの中身は、非常に単純な動作の集合体であるから、誰でも理解できるはずだ


使用しているデバッガはollydbg。今後もこれをメインとしつつ
利便性のため別のツールを使うこともある

TP変換


クリスマスイベント以前に、いくつかアイテムをリサイクルしていた

pangya_322

色の濃いアズテックは本当に要らないが、リプレイテープは神アイテムだと思っている
それでもなんとなく処分して50TPほど獲得してアイテムを得る

パンヤゾーン拡大はチートすぎるだろ・・・

風は255通り ○であり×である


モカミクシでも見ればいいし、議論尽くされたネタばかりでごめんなさい

ずれ ずれ 風速係数
1m 9m 風速倍率 1m 9m 9m/9の値

0.000 0.1 0.99 9.90 0.00055 0.00547 0.00061
1.412 4 41 10.25 0.02210 0.22652 0.02517
2.824 7 81 11.57 0.03867 0.44751 0.04972
4.235 11 120 10.91 0.06077 0.66298 0.07366
5.647 18 159.5 8.86 0.09945 0.88122 0.09791
7.059 22 198.5 9.02 0.12155 1.09669 0.12185

試しに255通りの風しかないと聞いてPar3同条件の左上風でやってみた
Par3であれば255通りだが
パンヤのゲーム内ではちゃんと小数点以下もキッチリ物理計算しているらしく
セカンドショット以降でカップを狙う場合は全く参考になりません

1m風x9≒9mという認識でほぼOK
追い向かい5度以下の風に誤差が大きく、真の0度を得るのは難しい

向かい風と追い風の縦風係数


それぞれの風速でのトマ飛距離をメモしたもの


縦風 飛距離 中間距離 -1m差分
↑9m 273.01 262.72 1.12
↑8m 271.89 262.74 1.12
↑7m 270.77 262.77 1.12
↑6m 269.65 262.78 1.12
↑5m 268.53 262.81 1.13
↑4m 267.40 262.83 1.13
↑3m 266.27 262.84 1.13
↑2m 265.14 262.85 1.15
↑1m 263.99 262.85 1.14
0m 262.85 ←想像値 1.14
↓1m 261.71 1.15
2m 260.56 1.15
3m 259.41 1.16
4m 258.25 1.16
5m 257.09 1.18
6m 255.91 1.15
7m 254.76 1.17
8m 253.59 1.17
↓9m 252.42

追い向かい3m以内で計測するのが安全
強風では縦風係数のズレが大きい(といっても小数点第2桁)

実用では、縦風係数は一定値で問題無い

縦風より横風(横ズレ)のほうが100倍以上重要だ

風速換算について 2


すべての数値は参考値です

とりあえず数字を見ていただこう

1 段数 1
34pix 間隔 17pix
sw7 BL1ラフ
15.6 1Wtoma80% 27.7
29.4 1WBS90% 52.5
52?48? 53?47?
52 deg 53
最大から52度 最大から53度
19.7966842 34.6841577
37.3091355 65.7371221
風速換算
0.22926096 0.40166946
0.24691685 0.43505706
1.07701217 1.08312209
37.29pix 17.45pix
2.13696275
1.75201854
29.25000 51.93750
55.12500 98.43750
0.3387377 0.60147655
0.36482462 0.65147253

後半の数値はもはやよく覚えていないが、おそらく2次元平面での傾きを示したものだろうと思う

左がSW7、右がBL1ラフ
地面傾斜表示の緑線の刻みの間隔が17pix、34pixであるとして数値をみてみたもの
3次元表示を2次元表示にしているため、単純に二倍のズレが発生するわけではありません

角度にはdegree(笑)を使っています
実は前回示したデータは34pixの側に似た傾斜を使っており
風速換算時に数値が0.23~0.25と、前回0.22で近似している
とはいえ、毎回計算していては間に合うわけもない

こういった数値からみて、結論としては

ホールごとに風速換算値を暗記する力業で良い

風速換算という方法について 1


ノス活動休止してパンヤネタ
パンヤカテゴリで記事へ飛んできた方へ
すべての数値は参考値です

パンヤ配信を見て時代の流れを感じたが、やっていることは以前と同じであるようだ
折角なので、昔とったデータを色々と公開してみる
以前にも公開していた気はするが、重複はキニシナイ

spin SP Dist 1024
x768
640
x480
yard 横風1m
 1024
倍率/横ずれ /SP/横ズレ倍率係数
1wtoma 100% 291.07 61 38.168 0.3408 272.5 0.22385 0.22385
spin7 97.5% 282.78 54.5 34.101 0.3045 249.6 0.21835 0.22395

95.0% 274.51 49 30.659 0.2737 228.6 0.21435 0.22563

92.5% 266.26 43.4 27.155 0.2425 210.5 0.20618 0.22289

90.0% 258.07 39 24.402 0.2179 193.0 0.20207 0.22453

87.5% 249.95 35 21.899 0.1955 177.0 0.19774 0.22599

85.0% 241.93 31 19.397 0.1732 163.0 0.19018 0.22375

82.5% 234.02 28 17.520 0.1564 150.0 0.18667 0.22626

80.0% 226.24 25 15.642 0.1397 138.0 0.18116 0.22645

1wBI 100% 246.68 62 38.793 0.34637 278.0 0.22302 0.22302
spin11 97.5% 238.22 55 34.413 0.30726 252.0 0.21825 0.22385

95.0% 229.75 49 30.659 0.27374 229.0 0.21397 0.22524

92.5% 221.30 43 26.905 0.24022 207.5 0.20723 0.22403

90.0% 212.92 38 23.777 0.21229 188.0 0.20213 0.22459

87.5% 204.64 33.5 20.961 0.18715 170.5 0.19648 0.22455

85.0% 196.48 29.5 18.458 0.16480 154.5 0.19094 0.22463

82.5% 188.47 26 16.268 0.14525 140.5 0.18505 0.22431

80.0% 180.63 23 14.391 0.12849 127.5 0.18039 0.22549









1WBS 100% 261.46 75 46.927 0.41899 348.0 0.21552 0.21552
spin9 97.5% 253.30 67 41.922 0.37430 317.0 0.21136 0.21678

95.0% 245.17 59 36.916 0.32961 290.0 0.20345 0.21416

92.5% 236.89 52.7 32.974 0.29441 264.5 0.19924 0.21540

90.0% 228.66 47 29.408 0.26257 241.5 0.19462 0.21624

87.5% 220.43 41 25.654 0.22905 220.0 0.18636 0.21299

85.0% 212.41 36.6 22.901 0.20447 201.0 0.18209 0.21422

82.5% 204.52 32.5 20.335 0.18156 183.5 0.17711 0.21468

80.0% 196.77 29 18.145 0.16201 168.0 0.17262 0.21577

まさにデータゴルフ

ある傾斜から打った際のSP、着弾距離
640x480ずれ、1024x768ずれ
ずれを標準横ずれ距離で割ったもの、さらにSPで割ったもの
の順に並んでいるテーブルである


地面傾斜を風速に換算する方法に対して参考値を求めたもの
1Wトマ、BS、BIに関しては、傾斜を風速*SPによって換算して0.21~0.22の誤差になり、数値としてほぼ収束していると考えてもよいだろう


続きを読む

自省と計算ゲー


他人を寄せ付けない信念の強さは重要であるが
強すぎても諸刃の刃となる
指摘しても無駄で、自分で気づかなければどうしようもない

20101221-2-

とある事情でぶち切れていたものの(初めて)沈黙しつつ
本当に久々に1PCで黒子に徹するデスゾ、自分でもどうかしてる
色々な意味で、抑えるようにします


唐突ながら、明日からは一転ゴルフゲーネタに転換する

pangya_324

今から始めてもクリスマスソックス(クリスマスクラブセットツヴァイ)は間に合わないのであきらめ
ミスは当たり前と割り切って、西WizやDIを周回して楽しんだ

どうも、今まで効率を考えるばかりで楽しめなかったようだ

うさヤロウさんと同様、休みが必要なのかも

ネット頻断


原因不明ながら、ネットがよく切れる
ルータではなくモデム含む上位の問題らしく、手のつけようもない
お手上げや


話はかわってパンヤネタを久々に見たけれども、データベースの問題とはまた興味深いですね
設計が古い、アイテム数が膨大、休眠アカウントを処分、といったあたりが生々しい
とはいえ私もシステムの事は全くワカランプレーヤーの一人であるので
こういった説明、釈明の機会があるだけで印象が違うというものです


で、ノスのアップデートはまだかな!
特にシェル出現率周りのカイゼンをと願うものの、最後にやることはシェル掘りであるので、無いか。

風角度 8

でかっ!(へげさせる意味で)

8
sin:0.196, cos:0.981
8


231y

BL2の231yがデータ取りに使いやすかった
それが231という距離にあって
231*112*π/255≒320
画面端クリックにほぼ等しい。
Del0の法則もあって、風を見る際に役立つ。

もっとも、230のほうが数値は近いわけではあるけど
そこまで誤差を考えてない。
画面端クリックが320じゃなくて319.5だったりそれ以下だったりもするため
231で充分と思う。

SS実装以降はSS10に手を出したりしたけども
カベに当たりやすくて鬱陶しい。
結局SC10に行き着くわけですね。

(取り直し)風角度4〜7

4
sin:0.098, cos:0.995
004

5
sin:0.122, cos:0.993
005


6
sin:0.146, cos:0.989
006


7
sin:0.170, cos:0.985
007

ちょっとだけ言いたい

アダルトカテゴリから一般になり、加えて日々更新とかしてると
検索結果がトップに来るようになります。

最近、過去のうんこみたいなパンヤ記事がやけに検索されてくる。
俺より頭の良い人間なんてざらだと思う。
ぜひ自分で考えることをおすすめしたい。
思考する過程に楽しみがあるんです。そして
二位以下の他の優秀なサイトがいくらでもあるから、そちらをオススメします


ほとんど記事は途中でオワッテルんだもの。手抜きなんだもの。

ですが、パンヤをやってて良かったとおもうことが一つ増えました
手をかけて育て上げた、とあるパンヤプレーヤーですが、とっくに俺を超えてたんです。
うれしいような、さびしいような。

つまりね。攻略もいいんだけど
人の繋がりも大事だよねっていうお説教


あと、風の画像って一周分を何度画像を撮り直したか・・・
そもそもがアテにならないっていうのがどうしようもない。

ので、取り直してみたものを改めてあげてみる
よ!

(取り直し)風角度0〜3

0
sin:0.0006, cos:1.000
000

1
sin:0.025, cos:1.000
001

2
sin:0.05, cos:0.999
002

3
sin:0.074, cos:0.997
003

CPガチャ ver2

ガチャ2ということで、せっかくなので適当に回す
所詮10回程度なのでわんわんのかけらも無いが

gacha_p_SS_20091020_19210
gacha_p_SS_20091020_19529
gacha2
gacha_p_SS_20091020_19250
gacha_p_SS_20091020_19645
おいアリンよこせ(ティッキー系は能力的に使わないため好きではないが)
アリンとクー以外いらねえんだよ
美少女セシリアとかまじうnこうnこ
るーこもいらねえ。アリン一筋なんだよアリンありん




CPガチャといえばクリリンとかそれぐらい以前から久々の大幅アップデート
演出的にもカップインすれば当たるようでわかりやすい
「空回し」ができないようになったので注意
そしてアリンクーは相変わらずの絞り具合で乙
「もうやめとけ」と虫の知らせ

2系統パニャ配信

pangyadual
最新のマシンによるHD(640x480@60f)&SD(512x384@30f)パニャ配信
ここまでする意味はまったく無いですけども
有り余るマシンパワーを消費する意味ではありかな

とわりと元気にやってるようには振舞いますが
結構胃に負担が来ます。最近こればかり
あいつも相当キているみたいだけども・・・
いまさらながら、控えるべき。そればかりだ。でもね

控えすぎたがゆえにこうなってるんだけどね
先に壊れたのは俺のほうだったなあ
あの日以来、すべてがおかしくなった
何もかも。

はっきり言ってн(露)t?属性付きそうですよ
吐き気がしますね、こういう属性になるとは思いませんでした
記事検索
最近の記事別
Archives
最新コメント
QRコード
QRコード
  • ライブドアブログ