わら半紙 : パンヤ - livedoor Blog（ブログ）

パンヤ

2019年11月01日23:24

カテゴリ: パンヤ

パンヤの裏話 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年たってもだ。作ったやつはほんと天才だ

かりんごのあれは、特に証拠はないけど、最後の大会に参加したのだけ覚えてる

スコアで画像も晒したので画像持ってる人は多いと思う

2019年10月30日00:54

カテゴリ: パンヤ

パンヤの裏話 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でも募集かけてて門戸は広かったはず

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

プレイヤー名は敬称略

2014年06月25日17:49

カテゴリ: パンヤ; 風角度

今更パンヤ、BL2H231y風表示

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

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

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

2013年04月07日03:35

カテゴリ: パンヤ

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

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

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

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

2012年11月07日17:14

カテゴリ: パンヤ

キモクナイ

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

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

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

2011年12月05日01:16

カテゴリ: パンヤ

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

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

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

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

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

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

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

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

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

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

flo

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

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

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

dst

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

dst2

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

dst3

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

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

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

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

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

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

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

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

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

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

mem3

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

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

↓↓↓↓↓↓↓↓↓↓↓↓

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

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

たとえばMHSでは

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

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

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

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

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

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

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

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

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

2011年11月29日18:05

カテゴリ: パンヤ

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

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

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

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

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

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

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

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

1mb

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

実にたくさんの文字列が参照されていることがわかる
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」なんかはわかりやすい。これらの文字を読み出してるところがパンヤ止め動作にかなり近いです

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

さんざんこの画像を見てるけれども
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の呼び出しをどこで行っているかを参照することができる

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

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

だがWIndowsの解析が進み、一部のマルウェアがこのAPIを悪用した乗っ取り動作を行うことで知られている
いわゆるアンチハッキングソリューション（nProtect、HackShield、CrackProofなど）も、ネイティブ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を参照していたりするが

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

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

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

2011年11月26日07:10

カテゴリ: パンヤ

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

前回の記事にはアンパック済みのとあるものの一部を掲載している
では、実際に風速を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に書き換えない）というわけだ
間違ってたらｐｇｒしてくれていい

③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になる」を強調した件について言及したいと思う
サイレントウィンドという超重要（？）課金アイテムがプログラム内部でどのように処理されているかということは
ランカーどころか一般のプレイヤーにとっても気になるところではないだろうか

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

2011年11月21日18:30

カテゴリ: パンヤ

nov_11?18_2011_projectg

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

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

2011年11月19日19:24

カテゴリ: パンヤ

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

上記は一般のケースでは実行されない部分で、同様の演算を行う箇所が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している。こういった数字の流れを読み取ることで
どんな処理をしているのかを適当に読み取ろう

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

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

2011年11月18日20:16

カテゴリ: パンヤ

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

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

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

まずは風速であるが

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。今後もこれをメインとしつつ
利便性のため別のツールを使うこともある

2010年12月28日01:59

カテゴリ: パンヤ

TP変換

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

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

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

2010年12月27日02:44

カテゴリ: パンヤ

風は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度を得るのは難しい

2010年12月26日01:31

カテゴリ: パンヤ

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

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

縦風	飛距離	中間距離	-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倍以上重要だ

2010年12月25日00:23

カテゴリ: パンヤ

風速換算について　２

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

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

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で近似している
とはいえ、毎回計算していては間に合うわけもない

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

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

2010年12月23日00:02

カテゴリ: パンヤ

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

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

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

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の誤差になり、数値としてほぼ収束していると考えてもよいだろう

続きを読む

pugyapugya

2010年12月22日06:40

カテゴリ: パンヤ; Nostale_JP(終了)

自省と計算ゲー

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

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

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

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

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

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

2010年07月15日02:52

カテゴリ: パンヤ

ネット頻断

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

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

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

2010年03月07日01:41

カテゴリ: 風角度

風角度 8

でかっ！（へげさせる意味で）

8
sin:0.196, cos:0.981

2010年02月18日00:55

カテゴリ: パンヤ

231y

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

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

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

2010年02月07日14:20

カテゴリ: 風角度

(取り直し)風角度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

2010年02月04日17:46

カテゴリ: パンヤ

ちょっとだけ言いたい

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

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

ほとんど記事は途中でｵﾜｯﾃﾙんだもの。手抜きなんだもの。

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

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

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

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

2010年02月04日17:43

カテゴリ: 風角度

（取り直し）風角度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

2009年11月21日00:23

カテゴリ: パンヤ

CPガチャ ver2

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

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

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

2009年10月26日02:59

カテゴリ: パンヤ

2系統パニャ配信

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

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

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

はっきり言ってн(露)t?属性付きそうですよ
吐き気がしますね、こういう属性になるとは思いませんでした