したらばTOP ■掲示板に戻る■ 全部 1-100 最新50 | |
レス数が1スレッドの最大レス数(1000件)を超えています。残念ながら投稿することができません。

技術情報交換スレ

1：管理人★：2004/06/16(水) 20:44
RTXのみならずROや支援ﾂｰﾙ全般に関する技術的な情報を交換するｽﾚです。
ｺｰﾃﾞｨﾝｸﾞに詰まった作者が他力本願的に知恵を増やす目的で設立されましたが、
それだけでなく広く情報交換に使っていただけることを願っています。

管理人の手持ちの情報は少ないですが、RTX/RoTimerの内部動作に関する
御質問などでしたら、できるだけお答えしたいと思います。

規約云々や解析手法の是非などは別ｽﾚ/別BBSへ誘導のこと。
水面下に落ちるまではsage縛りで。
2：Mystle </b><font color=#FF0000>（M.B.S.4s）</font><b>：2004/06/16(水) 21:51
とりあえず >>1 からネタ振り

21f→21g/h で発生した「特定の環境でﾀｲﾏｰがｶﾞｸﾌﾞﾙ問題」ですが、とりあえず
原因となる箇所は判明しました。
DX乗っ取りで実際に書き込みを行うﾀｲﾐﾝｸﾞを変更したのが原因だったようです。

○21f
　2D書き込み：
　　窓ﾓｰﾄﾞでは DirectDrawSurface->Blt() 、ﾌﾙｽｸでは Flip() のﾀｲﾐﾝｸﾞで
　　GetDC() してGDIでﾌﾟﾗｲﾏﾘｻｰﾌｪｽに直接描画、あるいは自前ｻｰﾌｪｽからBlt()
　3D書き込み：
　　Direct3DDevice->EndScene() のﾀｲﾐﾝｸﾞで DrawPrimitive() などを投下
　　
○21g/h
　3D書き込み：
　　EndScene() で （21fと同じ）
　2D書き込み：
　　EndScene() で 3D書き込みを行った後に保存しておいたﾌﾟﾗｲﾏﾘｻｰﾌｪｽの
　　ﾎﾟｲﾝﾀを使って GetDC() して以下略

というわけで 2D書き込みのﾀｲﾐﾝｸﾞを3Dのそれと一本化したのがまずかったようで。
これがどうしてまずいのかは不明です。

3：人柱さん：2004/06/16(水) 23:05
>>2
　
> ○21g/h
>　2D書き込み：
>　　EndScene() で 3D書き込みを行った後に保存しておいたﾌﾟﾗｲﾏﾘｻｰﾌｪｽの
>　　ﾎﾟｲﾝﾀを使って GetDC() して以下略

EndSceneが非同期で動いてると、その後GDI処理するためにレンダリング終了
まで待つ必要があってRO本体の足を引っ張ってるってことはないでしょうか？

EndSceneでプライマリサーフェイスに書き込んでもFlipかBltでなかったことにな
りませんっけ？バックバッファーに書き込んでるのでしたら、サーフェイスが
VRAM上にあった場合には、GetDCやGDIでほげほげするときにシステムメモリと
VRAM間で転送しまくってて遅い可能性も。

DirectX5〜7ぐらいの期間しかDirectXさわってなかったので、記憶違いだっ
たらすみません。それに、プロファイルとったわけでもないので全部予想に
過ぎません。

4：Mystle </b><font color=#FF0000>（M.B.S.4s）</font><b>：2004/06/16(水) 23:55
>>3
21g/h ではこんなふうに書いてたわけですが

// ﾌｯｸした Direct3DDevice->EndScene() 関数
HRESULT WINAPI Nisemono_EndScene(LPDIRECT3DDEVICE7 *lpD3DDevice)
{
　　HRESULT hRes1, hRes2;
　　hDC hDC;
　　
　　/*
　　// 色々と3Dなお絵かき
　　lpD3DDevice->SetRenderState();
　　lpD3DDevice->SetTexture();
　　lpD3DDevice->DrawPrimitive();
　　*/
　　
　　// 本物を呼び出し (ここで3D命令がｸﾞﾗﾎﾞに飛ぶの？)
　　hRes1 = Honmono_EndScene(lpD3DDevice);
　　
　　// ﾌﾟﾗｲﾏﾘｻｰﾌｪｽ (LPDIRECTDRAWSURFACE7 lpPrimarySurface) は
　　// 別箇所 (CreateSurface()のﾌｯｸ関数) で取得・保持しています
　　if (lpPrimarySurface)
　　{
　　　　hRes2 = lpPrimarySurface->lpVtbl->GetDC(lpPrimarySurface, &hDC);
　　　　
　　　　if (hRes2 == S_OK)
　　　　{
　　　　　　/*
　　　　　　// 色々と2Dなお絵かき
　　　　　　TextOut();
　　　　　　Ellipse();
　　　　　　*/
　　　　　　
　　　　　　lpPrimarySurface->lpVtbl->ReleaseDC(lpPrimarySurface, hDC);
　　　　}
　　}
　　return hRes1;
}

*lpD3DDevice自体はﾌﾟﾗｲﾏﾘｻｰﾌｪｲｽから生成されてますから、Honmono_Endscene() を
呼ぶ前に2D描画を試みてもGetDC()自体が成功しません。でこんな順序に。
でもこれだとｶﾞｸﾌﾞﾙするということで

21fでは if (lpPrimarySurface) { ... } のﾌﾞﾛｯｸがそっくり 偽Blt() の中にありまして、
Nisemono_EndScene() はRTXの3D描画を終えた後すみやかに
　　return Honmono_EndScene(lpD3DDevice);
してますた。これだとｶﾞｸﾌﾞﾙしない、と

5：人柱さん：2004/06/17(木) 00:50
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/jpdx8_c/hh/directx8_c/_dx_d3dcaps8_graphics.asp
を見ると

一般的には、BeginScene と EndScene のペアの外側で 2D 処理を実行する
ことを推奨する。2D 処理がBeginScene と EndScene のペアの間で実行される
場合は、D3DCAPS2_NO2DDURING3DSCENE 能力をチェックする必要がある。この
能力が設定されている場合、アプリケーションでは、BeginScene と EndScene
の間にある 2D 処理は破棄されると考えなければならない。

とあるので、GetDCが成功しないのはそういうことなんじゃないのでしょうか？


ところで、ゲームの一般的な処理って

入力読んだりネットワーク通信したりいろいろ情報更新
BeginScene
DrawXXXなんかで描画
EndScene←ここでバックバッファーに画面が作られる
Flip/Blt←ここでバックバッファーからプライマリサーフェイスに転送
適当にSleep

の繰り返しですよね。だとするとEndSceneの直後にプライマリサーフェイスに
いろいろお絵かきしても無駄じゃありませんか？

##なんか私がどっか勘違いしてる気がしてきた。

6：人柱さん：2004/06/17(木) 02:12
当方、コンシューマー機畑の人間、オマケにヒッキーなので
DirectX(というよりGefのドライバ)がどうなっているのかは知らないのですが、
調べてみた限りでは、>>3の説が濃厚な気がします。

つまり、EndScene直後ではまれなタイミングでしかGetDCに成功せず、
ほとんどのRTXの2D描画が廃棄されｶﾞｸﾌﾞﾙ。
しかし、Blt重あてをしていて、Flip/Bltまでドライバに時間が与えられていれば
GetDCに成功し、概ね描画可能になっている、のだと思います。

問題の発生しない環境だと、VGAにぶちこむディスプレイリストの再構築の間、
プライマリは好きにしてもいいよ、な実装になっていて、直後でもS_OKがもらえるんじゃないでしょうか。

7：2&5：2004/06/17(木) 03:26
>>6
私の言いたかったのは、GetDCが成功したり失敗したりってそういうことでは
ないです。単純に呼び出しが失敗しているのなら作者さん気がつくでしょうし。

IDirect3DDevice9::EndSceneのドキュメントに

When this method succeeds, the scene has been queued up for rendering
by the driver. This is not a synchronous method, so the scene is not
guaranteed to have completed rendering when this method returns.

って記述がありました。(手元にはDXSDK9しかなく、DirectX 7のドキュメント
はだいぶ前に処分したので実際どうなのかはわからないです。)

また、GetDCするときに内部的にはサーフェイスをLockしているようです。
しかし、Lock後に整合性を保つにはLockの前にレンダリング済ませる必要が
あるはずです。

それらのことから、もしROがEndSceneがすぐ戻ってくることを前提に書かれて
いてEndScene→Flipの間に非同期に何かやろうとしてることがあったとすれば
それを同期的にしか処理できないことでフレームレートが落ちる可能性がある
んじゃなかろうかっていう推測です。

とりあえず、もう寝ます。

8：7：2004/06/17(木) 03:27
2だと管理人さんじゃん。3と5と7でした。

9：6：2004/06/17(木) 03:59
GetDCの動作を理解していませんでした。
EndSceneについては自分で調べた通りで、だから6のような妄想をしてしまったわけですが、
なるほどROクライアント本体で何か、という推測は成り立ちますね。

ｶﾞｸﾌﾞﾙの実際の動作がどうなっているのか気になります。

1．ROｸﾗは普通に動作/RTXの3D描画も普通に動作/RTXの2D描画のみがｶﾞｸﾌﾞﾙ
2．ROｸﾗは普通に動作/RTXの3D/2D描画ともにｶﾞｸﾌﾞﾙ
3．ROｸﾗからRTXから全部ｶﾞｸﾌﾞﾙ

外野から想像できるのはこんなところでしょうか。

10：人柱さん：2004/06/17(木) 15:44
うちも21gでｶﾞｸﾌﾞﾙ(((;ﾟДﾟ))) してましたけど、文字列（2D表示）がちらついてない
ので、GetDC() 自体は成功してるんじゃないかなと思います。

おそらく EndScene() から返ってからその3D描画が実現するまでのレイテンシが、
直後に 2D描画を突っ込むことでロスされる、というのが真実かと。

（2D描画をBlt()部に分離した試作版いただきましたが、正常動作しました）

関係ありませんがここってパケの話とかはOKですか？
ウンバラで最初取引チャイム出なかったのはやっぱ新パケなのかなと

11：Mystle </b><font color=#FF0000>（M.B.S.4s）</font><b>：2004/06/17(木) 16:12
>>10
それでﾋﾞﾝｺﾞのようです。
とりあえず再びBlt()/Flip()のところに文字列描画を引き離すことで事なきを得ましたが、
最終的には面倒くさがらず2D描画もDIB→動的Texture変更など使ってGDI撲滅の方向へ
いかなければなりませんでしょうか……

今は毎ﾌﾚｰﾑﾌﾟﾗｲﾏﾘｻｰﾌｪｲｽにTextOut()する、という信じられないようなことをしている
のですが、ﾀｲﾏｰって少なくとも1秒ごとに文字列が変わるわけで、画面上に20本のﾀｲﾏｰが
出ていたら、文字列不変をｽｷｯﾌﾟしても、1秒ごとに20個のﾃｸｽﾁｬをﾛｯｸする必要があるわけ
ですよね。今は毎ﾌﾚｰﾑｻｰﾌｪｲｽﾛｯｸ1回のみなわけで。
やっぱこれでも3Dに統合した方がﾊﾟﾌｫｰﾏﾝｽ出るのかなぁ


>パケの話
全く問題ありません。
とりあえず、ｳﾝﾊﾞﾗの取引要請でしたっけ？

// 取引要請(受)
R 00E5 → R 01F4 <trader's name>.24B <trade id?>.L <LV>.w

// 取引要請(攻)
R 00E7 → R 01F5 <success>.B <trade id?>.L <LV>.w

以降のｼｰｸｴﾝｽはいままでと同じです。

<trade id>.L は取引中保持され続ける固有値ですが、同じ相手と
再び取引しても同じ値だったり。生成方法は不明。

12：人柱さん：2004/06/19(土) 15:34
先ほどfpatchに置かれた20040619RagexeHC_jp.rgzですが、
どうやら何らかの方法で圧縮かかっているようです。
800KBと、半分以下になっていますし、逆アセンブラも通りません。

13：人柱さん：2004/06/19(土) 16:06
>>12
ASProtectで圧縮されてる。

14：RoAddr.ini v31の中の人：2004/06/19(土) 16:26
>>12
Thanks!　解凍できました。

15：人柱さん：2004/06/19(土) 18:09
unpack済みのexeとメモリ内で展開されたexeでアドレス違ったりしないんだろうか。
展開の方法にもよるんだろうけど。

16：62：2004/06/19(土) 19:01
>>15
私が使ったUnpackツールは途中まで走らせたやつを吸い上げるみたいだから、
たぶん大丈夫…だと思いたい

17：Mystle </b><font color=#FF0000>（M.B.S.4s）</font><b>：2004/06/21(月) 13:37
ASPack/Protect圧縮部の自動解析機能は準備できました。

ただ、ログインシークエンス自体が変わっている （0x200系OP） ようで、
もしかすると新たな暗号化の可能性もあります。
したがって現行開発版が次パッチで動作可能かどうかは不明です。

ログイン部分やスキル使用など、kSakrayのパケログをお持ちの方が
いらっしゃったら、ぜひ送っていただきたいです。


それはそうと、RTXでは手法が異なるので影響を受けていないのですが、
インポートテーブルを参照した標準的なAPIフックがうまくいかないという話を、
他ツールの方々からお聞きしました。

これについても、役に立つ情報などありましたらお寄せください。

18：人柱さん：2004/06/21(月) 17:03
> インポートテーブルを参照した標準的なAPIフックがうまくいかない

ragexeのPEヘッダに書かれてるインポートテーブルはASProtect
展開ルーチン用のインポートテーブルを指してるせいではないでしょうか。
(覗いてみると、明らかにインポートされてる関数が少ない)

ragexe用のインポートテーブルを探してそちらを書き換える必要があるかと。

19：人柱さん：2004/06/21(月) 18:32
IATはさっくりと出るのですが、
INTが無いですね...

20：人柱さん：2004/06/22(火) 05:18
例のexeでダミーWS2_32.dllかませて最初の送信パケだけを眺める

unpackしてみたもの
send> 04 02 b0 2f b3 a4 00 e9 c8 30 9d 52 c1 a8 9e e9 6f d6
send> db 01

オリジナルそのまま
send> 04 02 ff 66 ac 95 5e 9d f8 62 d6 cd 8b 90 c5 73 0d f7
send> db 01

OPの後に16バイトの時点で察した通り、ragexe.exeのMD5送ってますね
だからどーしたと言われたらそれまでですが…

21：Mystle </b><font color=#FF0000>（M.B.S.4s）</font><b>：2004/06/22(火) 07:09
>>18-19
オリジナルのIATは容易に出せますし、これだけでフックも可能ですが、
複数ツール間でフックが競合することを念頭におくと、どうしてもINTが欲しい。
でもみつからない∧||∧

また、フックするにしても .adata+.data の正規セクション（.text/.rdata/.data）
への展開が完了したタイミングを検知してからフックしないと成功しないようで、
これがまた大変なようです。


>>20
サクライでは少し前から S 0204 仕様のようです。

S 0204 <ragexe/sakexe md5>.16B

これと S 0064 を対にして send しないと認証が成功しません
本鯖でのログインシークエンスは、さしずめ

S 0204 + S 01db
R 01dc
S 01dd
R 0069
S 020b + S 0065
R 006b
（以下略）

といったところでしょうか。

exeのmd5送信は、クライアントの改竄防止としては有効期間が短すぎます。
むしろ、昔のバグありクライアントを継続使用、といった弱い形での不正利用を
やんわりと抑止するのが目的ではないでしょうか。

今回はASProtect導入と併せてダブルチェックを狙っているものと思われます。
もっとも、どのみちメモリ上でパッチ当て＋ S 0204 自前送信、で回避されて
しまうわけで、不慮のトラブルでパッチを当て損ねた人への誤爆だけが増えた、
などということにならないよう祈っています。

22：人柱さん：2004/06/22(火) 12:58
重力の斜め上開発能力を考えると、クライアントの改竄防止を
無理を承知でやってみた気配。

もしかすると、本気かもしれませんががが

23：人柱さん：2004/06/22(火) 15:30
boterが喜ぶだけの解析はやめてもらいたいもんだ
これだけ改変嫌がってるんだから開発止めてもいいと思う。

24：人柱さん：2004/06/22(火) 15:38
開発(改良?)したunpack技術を公開しないのに何故Botterが喜ぶかは不明
Mystleさんの作品を逆汗して技術だけ盗めるようなスキルのBotterはもう既にunpack技術の開発に乗り出してるはずです

それとココは技術情報交換所なので23さんの意見はスレ違いなので
http://jbbs.shitaraba.com/bbs/read.cgi/computer/6346/1085343913/l100
ここの議論スレにて発言するとよいでしょう

25：人柱さん：2004/06/22(火) 15:58
開発も何もASProtectは既存の技術で複合も検索すればツールが見つかるし。
まぁ、この板で話してる程度のことじゃBotterにもそのBOTの開発者にも
何の影響も及ぼさんよ。特に役に立つようなことはかかれてないし。

とはいえ、堂々とパケやらを載せるのはどうかというのは他所でも出てる意見。
その辺はまぁ、管理者のモラルによるもんだろ。

26：人柱さん：2004/06/22(火) 16:32
>>23-25
っ[議論スレ

27：人柱さん：2004/06/22(火) 19:01
お前らがやってることはBOTerと同じってことですよ、恥を知れ

28：人柱さん：2004/06/22(火) 19:12
文句いってる奴らはとりあえず
消えろ
うざい
邪魔だ

29：人柱さん：2004/06/22(火) 19:28
つ[http://jbbs.shitaraba.com/bbs/read.cgi/computer/6346/1085343913/l100
マターリしましょうねー

30：人柱さん：2004/06/22(火) 19:49
ああ、おかげさんでASProtectだって事だけ参考にさせてもらいますた。
zone動くまでにキー要求ﾊﾟｹをMD5送信ﾊﾟｹに置き換える作業出来て多謝ｗ
今は改造ｸﾗをﾌｯｸなどとめんどくさいのでragexeのMD5算出ｺｰﾄﾞ潰すor
別ﾌｧｲﾙのMD5取って来るように改造ちゅ。

鳩スレなんかに降臨したりする低級紙でもありませんのでご安心。
31：人柱さん：2004/06/22(火) 19:57
>>30
超頑張ってくださいorz

32：人柱さん：2004/06/22(火) 20:43
>>30
MD5算出コード潰したら結局自前で送信しなきゃいけなくなって面倒な予感
うちはまあめんどいけどunpack済蔵をフックしてMD5を外部テキストから取得して送信させてる。

33：人柱さん：2004/06/23(水) 00:49
以前ちょこっと見かけたことあるんですけど、
Rotimerのバーの数を増やす方法（INIに追加書き込み？）ができるというのを調べに来たんですが、
なかなか見つからないので書き込みしてみました。
どこらへんにあるか教えてもらうのってできますかね
・・・というか、できるのかなぁ？

34：人柱さん：2004/06/23(水) 01:27
>>33
(´･ω･)っ[ http://jbbs.shitaraba.com/computer/bbs/read.cgi?BBS=6346&amp;KEY=1087386415 ]
その質問はこちらへどうぞ。

35：人柱さん：2004/06/23(水) 16:11
内容が内容ですが・・・
以下の通り、ログイン以外でもMD5の認証があると
話があちこちで出ています
この点、RTXは大丈夫なのでしょうか・・・


462 ：（○口○*）さん ：04/06/22 20:10 ID:TpBDzWTS
今回のは実はかなり画期的。
定期的かつ簡単に求めるパケ（正確には違う？）を変えられて、不正者が一目瞭然。
BANする気ならほとんど全滅できるし対策もしづらい。
つまり、これからBOTがはびこった場合は、調査に時間が掛かるとかのいい訳は全然通じなくなり、
全責任癌に押しつけられ、言い逃れは効かない。普通にプレイしてる奴が不正なパケ吐くはずないからBoterを躊躇なくやれるしな。

915 名前： ネトゲ廃人＠名無し [sage] 投稿日： 04/06/22 20:15 ID:???
まあ、癌が本気なら、MD5要求に応えなかったら即切断するだろうけどな。
893 名前： ネトゲ廃人＠名無し [sage] 投稿日： 04/06/22 20:04 ID:???
>>885
アリーナ送られるだけならいつものことじゃん
910 名前： ネトゲ廃人＠名無し [sage] 投稿日： 04/06/22 20:13 ID:???
>>893
今回は送られる原因が不正パケって言い逃れが効かないものだから癌が本気ならどうしようもない。
864 名前： ネトゲ廃人＠名無し [sage] 投稿日： 04/06/22 19:52 ID:???
おまいらわかってないな。入れる、動くじゃねーんだよ
定期的？に合い言葉？を求めるパケに返信できねーと自動アリーナをどう回避するのか？が問題なんだろーよ？

36：人柱さん：2004/06/23(水) 16:19
>>35
そのどこが技術的情報交換なんだ？
なにを根拠にRTXの何が大丈夫でないと懸念しているんだ？

37：人柱さん：2004/06/23(水) 16:27
RTXは別に不正なパケットを送信してるわけじゃない
正規クライアントにログイン時以外にMD5(一部でも)を送信する機能があったとしても
普通に使ってる人なら何ら問題は無い

で、何を根拠にRTXの何が大丈夫でないと懸念してｒ

38：人柱さん：2004/06/23(水) 18:13
たとえ正規以外のMD5送信したとしても
もしクライアントDL解凍失敗などで壊れている人も、正規ではないMD5送ることになります。
心配なら使わない、これが一番だと思いますが。
スレ違いだからこのあたりで終了。

39：人柱さん：2004/06/23(水) 18:51
解凍失敗した事例をあなたはお持ちですか？
確率的に頻繁に起こりえないことが今だけは頻繁に起こるとでも言いますか？
議論スレにいけというならあなたも来ましょうね
行けとだけ言って自分はこないことがここではよくありますから

40：人柱さん：2004/06/23(水) 21:00
勝手にexeが書き換わってMD5がかわる
って人はたまに現れるね。
ウィルスかと言われているけど実際どうなのかは知らん

41：人柱さん：2004/06/23(水) 23:41
それでそれとRTXに何の関係が？

42：人柱さん：2004/06/24(木) 00:41
>>21
>また、フックするにしても .adata+.data の正規セクション（.text/.rdata/.data）
>への展開が完了したタイミングを検知してからフックしないと成功しないようで、
今までの方法で失敗してる？

タイトルバーに"Ragnarok"と出ていればASProtectの展開は完了してる

現在のクライアントは全言語共通（サクライはちょっと違うがほぼ同じ）
中国鯖（本土）はタイトルバーが違う
clientinfo.xmlの内容で決めているので展開する前ではタイトルバー設定は不可能

>exeのmd5送信は、クライアントの改竄防止としては有効期間が短すぎます。
>むしろ、昔のバグありクライアントを継続使用、といった弱い形での不正利用を
>やんわりと抑止するのが目的ではないでしょうか。
台湾・テスト鯖でもＢＯＴ対策と思われるパッチ（移動・アイテム使用パケ長変更）があった
こっちはＢＯＴ全滅したがパッチ当て直後は（ＢＯＴ問わず）Zoneにログイン不可能だった
一週間たたないうちに元に戻してある（中国鯖のftpパッチにもあったが適用されず）

テストされてるんだよ

今回のパッチだけで結論を出すべきじゃない

43：人柱さん：2004/06/24(木) 00:44
>>42
INTとIATを使ってフックするものに関しては展開完了していてもできないはず
できるというのはINTを無視して他のAPIHookを使用するツールを完全に排除した場合

44：人柱さん：2004/06/24(木) 00:47
>>42
ハムの人？

45：人柱さん：2004/06/24(木) 02:04
>>43
最初にフックを仕掛けたアプリがIATからINTを復元する、くらいしか思いつかないなあ。
まあフックが必要なアプリ全部でそのコード持つのも辛いから、
RoAddr.dllあたりにやってもらうか、あるいは独立したIAT復元サーバを作るか。

ところで、あちこちで見る「INT」って、ImportNameTableの略だと推測してるのだけど、
これって（MSDNのPE仕様書で言う）ImportLookupTableと同義？

46：人柱さん：2004/06/24(木) 03:37
展開後のイメージ(Neko57v110のPEdump)がW32dsm89で逆汗できるかやってみたが
ASProtectした日蔵はダメだった

47：人柱さん：2004/06/24(木) 03:46
それは単にPEヘッダやidataの再構築などができてないだけじゃ？
Unpackerで展開すればきちんと逆アセンブルできますよ

48：人柱さん：2004/06/24(木) 09:40
支援スレでこんなカキコを見たんだけど、ホントなのかな？

支援ソフトを"支援する"スレ Ver 8
ttp://jbbs.shitaraba.com/bbs/read.cgi/computer/6135/1085058178/809,811

>ログイン時以外でもマップ移動時にツールを使用している場合に不正パケを送るようになったので、
>RoAddr.ini系のツールを使うとひっかかる、という情報を聞いたのですが本当でしょうか？

>RoAddr.iniがRagexe.exeと同じフォルダにあるとき、なんか送ってるよ。

49：人柱さん：2004/06/24(木) 10:58
>>48
ttp://jbbs.shitaraba.com/bbs/read.cgi/computer/6135/1085058178/812,814
も見れ
811は809を煽るただの騙りだぞ

50：人柱さん：2004/06/24(木) 11:50
>>48
噂交換スレじゃなくて技術情報交換スレなので、そういった話題を振りたいなら、
自分でパケログを採って、分析結果だけ報告しよう。
51：人柱さん：2004/06/24(木) 15:13
>>45
自分で持った方がいいかも

x-koreはフック必要なんで
>独立したIAT復元サーバ
こんなことしたら・・・

別な話
詠唱時間がＤＥＸで減るんだけど
キリエとワープポータルは同じ係数（20ms）減るんだっけ？

それと詠唱時間が必要なスキルＤＥＸ０（基本値）時の一覧ある？

52：人柱さん：2004/06/24(木) 15:23
>>51 詠唱時間が必要なスキルＤＥＸ０（基本値）時の一覧ある？

ttp://acolyte.s26.xrea.com/acolyte.htm
ttp://acolyte.s26.xrea.com/priest.htm

53：人柱さん：2004/06/25(金) 03:43
>>52
アコとプリーストだけで
アコ・プリ以外は無いのか

54：人柱さん：2004/06/25(金) 03:45
マジWizはこことか。
http://cgi.f31.aaacafe.ne.jp/~wizard/index.php?SkillMagician
http://cgi.f31.aaacafe.ne.jp/~wizard/index.php?SkillWizard

55：人柱さん：2004/06/25(金) 18:07
>>51
キャスティング時間が存在するスキルだけをまとめた表というのは
知りませんけど、情報サイト(ROM776とか)にスキル個別のキャスティング時間は
掲載されてますので、そちらで調べた方が早いと思われます。

56：人柱さん：2004/06/25(金) 22:05
>>51 >>55
ただ、総合情報サイトは告知とかそのまま載せていることもあるので、各職業特化サイトよりは情報が古いとか正確性に欠けることがあるので鵜呑みにしないようにと。

57：人柱さん：2004/06/29(火) 13:18
>51
全スキルの一覧がみすとれ巣にあるはずです。
2月以来更新されてないので信頼性はあんまりないと思いますが。

58：人柱さん：2004/06/29(火) 17:14
あまりRTXどころかROのツールにすら直接関係無くて申し訳無いののですが、
当方でも何かしらのツールを作ってみようと考え、まずはどんなパケットが流れるのかを調べてみようと、
FreePeekなるパケットキャプチャのソフトを使用しているのですが、ネットワーク方面は全くといって良いほど
畑違いの分野で…な状態です。

RO関連のパケットを送受信だけを効率良く取れるようなフィルターの設定など
ご教授できればと思い書き込みさせて頂きました。

59：人柱さん：2004/06/29(火) 17:19
送信元PortやIPで絞り込めばいいんじゃ？

60：人柱さん：2004/06/29(火) 18:04
>>58
つ http://rosv.zive.net/

61：人柱さん：2004/06/29(火) 18:07
>>60
あぁ・・・なるほど・・・
ROの鯖のIPアドレスとポートを列挙して、そのパケットを監視すれば良いのね。

62：人柱さん：2004/06/29(火) 22:39
>>58 >>60
現状、5121番に絞ればいけるんじゃないかなっと。

63：人柱さん：2004/06/29(火) 23:12
>>62
FreePeekってポートまで指定してフィルタ掛けられたっけ？

他のフリーソフトでポートまで指定できる奴もあったから、
それならいけるかな？

ただ、俺もちょっと疑問に思ったんだが、
ソフトによっては受信時のパケは取れるのに送信時のパケが取れないのもあるんだよな…
フリーでお奨めのソフトってないかね？

64：人柱さん：2004/06/29(火) 23:50
FreePeekは知らないけど、Etherealはポートまでいけます。

65：人柱さん：2004/06/30(水) 00:16
>>63
>ソフトによっては受信時のパケは取れるのに送信時のパケが取れないのもあるんだよな…
Win98SE使うべし

Win2000・ＸＰは送信時のパケが取れない（場合がある）
Win2000・ＸＰは特殊な仕様(WSASocket)

66：人柱さん：2004/06/30(水) 00:22
FreePeekはポートのフィルタできるぞ。
APIhookじゃなくてdevicedriver使うからsocketは関係ない。

67：人柱さん：2004/06/30(水) 02:01
FreePeekはWinPCapsライクな自作ドライバだし
EthernalはWinPCaps使ってるから
RawSocket横取りのように取りこぼしはないよ

65氏は多分勘違いしてるかと
RowSocket横取りできるのは確かに2000以降のNTカーネル系なんだけどね

68：人柱さん：2004/06/30(水) 02:21
パケットを取ってみて、ちょっと疑問に思った・・・（程度が低い質問で申し訳無い）

FreePeekでアナライズして取得したパケットと、
RoAddr.dllに付属しているサンプルコードを見て、どうにも腑に落ちない・・・

RoAddr.dllのサンプルプログラムでもGetPacketProcのコールバック関数を利用すれば、
アナライズしたソフトと同じように受信したパケット情報のデータはダンプでき、
双方の結果も一緒になった。

で、RoAddr.dllのソースをみると、受信したパケット情報の先頭2バイトが
コマンド？というのかな？
つまりキャラ情報を受信したとか通常会話を受信したとかの区分なんだなという事も大体分かった。

しかしながら、そのサンプルコードで『memcpy(&cmd, p, 2);』でその区分を取ってきた値が、
なぜ1バイト目と2バイト目が逆になったものが出てくるのかが不思議・・・

つまりパケットダンプでは
1A 01・・・・
というふうになってるのに、memcpyで取ってきた値は『0x011a』となっている。
パケットの先頭から2バイトをコピーしてるのに、なぜ逆？

どこかで何かを見落としている様な気がする今日この頃・・・

69：人柱さん：2004/06/30(水) 02:29
ネットワークバイトオーダーの話ですか？htonsとかntohlとか。

70：人柱さん：2004/06/30(水) 02:31
>>68
「エンディアン（endian）」や「バイトオーダー（byte order）」で調べてみるといいかも。

71：人柱さん：2004/06/30(水) 09:40
>>69、>>70
なるほど・・・そういえばC言語を覚えたての頃にそんな用語と実験をしたような記憶が・・・（何年前だ）

試しに下記のようにプログラム書いてみた。
確かに実行結果は格納した値の逆で出てきた。

#include <stdio.h>

void main()
{
　　unsigned int iValue = 0x12345678;
　　unsigned char *cValue = (char *)&iValue;
　　printf("x x x x\n", cValue[0], cValue[1], cValue[2], cValue[3]);
}

72：人柱さん：2004/06/30(水) 09:41
あ・・・printfの％の部分が消えてる・・・まぁ分かるよね・・・

73：人柱さん：2004/06/30(水) 10:24
>>72
ネットワークバイトオーダーと、そのマシンのエンディアンを相互変換するときは、
手動で入れ替えるんじゃなくて>>69のいってるように
ttp://black.sakura.ne.jp/~third/system/winapi/winSock4.html
を使用しる。

74：人柱さん：2004/06/30(水) 10:41
>>73
あぁ、単純に値が入れ替わってるという事の確認の為のプログラムなので、
その辺は十分理解しました。

75：人柱さん：2004/06/30(水) 13:36
>>68
＞で、RoAddr.dllのソースをみると、
読みたいんだけど、手に入らないな．．．。

76：人柱さん：2004/06/30(水) 13:44
>>75
御免。
正確にはRoAddr.dllに付属してくるサンプルソースの事。

77：人柱さん：2004/07/01(木) 01:31
さて、また程度の低い質問で申し訳無い。

ネットワークバイトオーダーあたりもある程度は理解し、
とりあえず受信パケットでダンプしたりして、
よくある発言やチャット会話のログなんかを出力してみたりして遊んでみました。

そこで、この受信したパケット情報を使って何か今までに無い新しいツールは無いものかと思案した結果、
Gvの砦前で敵勢力が終結した時に、どのギルドの人間が何人居るかという情報を画面に表示できれば、
砦前監視役の人間の報告が楽になるのでは？と考えた。

パケットを見る限り、恐らくキャラIDやら名前やらギルド名やら役職などの情報も受信しており、
それらの情報を抜き出してログに出してしまうと、某Lv抜きツールになってしまう恐れがあるが、
単純に、○○ギルド△△人という情報だけならば、そこまで問題にならないような気がします。

そこで、質問なのですが、受信パケットに『ギルドID』なるものは存在するのでしょうか？
そもそも『ギルドID』なるものがRO自体に存在するかも分からないのですが、
データベースの事も考えると恐らく存在していると思っています。

また、ギルドIDが存在するならば、どのパケットの時の何バイト目からの情報がギルドIDなのでしょうか？
（そもそもこういった情報ってパケットだけで調べる方法がわからないです）

78：人柱さん：2004/07/01(木) 02:22
>>77
ギルド名はキャラクターにカーソルを合わせたときに送られてくるキャラ名パケと共に文字列で送られてきます。
それ以外に他人のギルド情報がパケに乗っているかどうかは知りません。
他になければ実装はかなり厳しいでしょう。

>そもそもこういった情報ってパケットだけで調べる方法がわからないです
ひたすらバイト列とにらめっこ。一握りの勘。それだけです。

79：人柱さん：2004/07/01(木) 02:35
>>78
キャラにカーソルを合わせた時に、0x0095と0x0195の場合にキャラ情報を受信する事と、
0x0095はギルドに所属していないキャラの情報で、
0x0195はギルドに所属しているキャラの情報という事まではパケットダンプの情報で分かりました。
また、0x0195にギルド名の情報もある事も確認しました。

最初は、これらの情報を使い、キャラIDとギルド名を取り出し、
キャラIDは単純に人数のカウントの重複を避けるために使用し、
画面に例えば

ABCD同盟（52人）
【A：12人　B：19人　C：10人　D：11人】

EFGH同盟（○○人）
【E：XX人　F：XX人　G：XX人　H：XX人】

無所属（9人）

などのように画面内の任意の位置に表示ようと考えてました。
（正確に人数をカウントできないかもしれないけど、ある程度の目安として・・・）

同盟関連などは設定ファイルなどを使用し、どのギルドが何処と同盟で通称○○同盟などという情報は
使用者に編集してもらおうと思っていましたが、文字だけで管理すると1文字間違えただけでも集計がおかしくなります。

そこで、キャラIDとは違いギルドIDならば抜き出しても悪用されるような事は無いだろうと考え、
ギルドIDとギルド名の対応表が作れればと考えていました。

80：人柱さん：2004/07/01(木) 03:28
ギルドIDはキャラ列挙出現移動系パケに入ってる
どこに入ってるかはパケログ見つめりゃわかる

81：人柱さん：2004/07/01(木) 06:21
S 0151 <guild ID>.l
エンブレム要求

らしいね

82：人柱さん：2004/07/01(木) 10:40
>>81
＞S 0151 <guild ID>.l
＞エンブレム要求
＞
＞らしいね

この『S』って『Send』ってことで送信パケって意味でいいのかな？
逆に『R』が『Rcev』で受信パケ？

RoAddr.dllで送信パケまで見れないですよね？
それにその送信パケでギルドIDを取り出したとして、ギルド名とギルドIDの対応付けをどうするのかが疑問。

とりあえず、>>80の情報のパケットダンプで、同じギルドに所属してる人間のダンプ結果を並べて、
ANDで同じ部分のバイト列を列挙して、次に違うギルドの人間のダンプ結果を並べて、
XORで異なる部分のバイト列を列挙している。

同じギルドの人間なら、同じ並びのバイト列が存在して、
違うギルドなら上で調べたバイト列が異なるって事だから、
多分方法的には間違ってないと思うんだが、いかんせんギルドIDとかのバイト長も分からないからなかなか確信持てない。

83：人柱さん：2004/07/01(木) 11:47
・同じキャラを二つのギルドに所属させて比較する
・エンブレムのファイル名と比較する

84：人柱さん：2004/07/01(木) 15:09
カーソルを合わせないでもGvMapでキャラの頭上にエンブレムが出ることから察しましょう

85：人柱さん：2004/07/01(木) 15:53
あの・・・今回の解決方法をはやく書いていただきたいのですが・・・
こちらとしても突破口のヒントが欲しいので・・・

86：人柱さん：2004/07/01(木) 16:05
>>85
何様ですか

87：人柱さん：2004/07/01(木) 16:10
>>86
釣りorBOTer様だろ

88：人柱さん：2004/07/01(木) 16:42
>>83、>>84
エンブレムか・・・盲点だった・・・

確かに異なるPC・異なるアカウントでログインして、エンブレムのファイル名とファイルの内容は同じ物だった。

ただ、此れはギルマスじゃないと出来ないので質問で申し訳無いのだが、
エンブレムのファイル名がギルドIDだとすると、エンブレムを変えた場合、エンブレムのファイルの内容も同様に書き換わるという事でいいのか？
もし、エンブレムのファイル内容まで書き換わるなら、WIKIやＧｖ関連のＨＰなどでＧｖ結果でギルド名とエンブレムを書くときに、
ギルド情報をＤＢ化しておけば、エンブレムも自動で拾えるってことですね？

Ｇｖでの砦取得状況をログに出し、ギルド名、ギルドＩＤ、エンブレムをＤＢ化しておけば、
PerlなどでＧｖ結果の一覧をすぐに出力できると・・・

良い感じでツールの構想が膨らんできました。

89：人柱さん：2004/07/01(木) 16:47
ワールド名_ID_更新回数.ebm

らしいね

90：人柱さん：2004/07/01(木) 16:52
>>88
ちなみに、RoAddr.dllに依存するならPv/GvMapでは動かないことを頭に入れておきましょう

91：人柱さん：2004/07/01(木) 16:56
>>90
承知しております。

Ｇｖ関連の機能といっても、砦取得のログもＧｖエリア以外で取るつもりですし、
今考えてる、砦前での監視員用の敵勢力終結の情報表示機能も、
砦の外での情報ですので問題無いと考えています。

92：人柱さん：2004/07/01(木) 17:21
とりあえず、01daの場合のパケットで、39バイト目と40バイト目でギルドＩＤ、43バイト目で更新回数が取れました。

ただ、ギルドＩＤ2バイト、更新回数1バイトじゃ少ない気がしますし、
エンブレムでも更新回数部分が256を越えるものもありましたので、もっとバイト数は多いはずですね。

恐らく、39-42の4バイトがギルドＩＤで43-46の4バイトか43-44の2バイトが更新回数って所でしょうか・・・
ワールド名ってこのパケの中にワールドＩＤなるものでも入ってるのかな？
それとも別なのかな・・・

93：人柱さん：2004/07/01(木) 17:30
そのぐらいお願いだから逆汗して調べてください…

94：人柱さん：2004/07/01(木) 17:46
>>93
パケログみるだけじゃなくて、逆アセンブラも有効な手段なのね・・・
了解した。

95：人柱さん：2004/07/01(木) 20:39
93は明らかに釣りだろｗ
とりあえず私も調べてみるとするか

96：95：2004/07/01(木) 20:59
01d8
byte 34-37 guildId, 38-41 updateCount
かな？

01d9, 01daはｼﾗﾈ

97：人柱さん：2004/07/01(木) 22:09
>>93
OLLYDBGなる逆アセンブルソフト使用して、何となく眺めて勉強してます。
ちなみに、RoAddr.iniの値算出程度は出来ますが・・・

修行を積んで精進してきます。

>>96
情報サンクス。
01d9の場合も01d8と同じ場所がギルドIDと更新回数みたいですね。

問題は鯖名だけど、この情報はやっぱりログインしたときの情報で取ってくるしかないのかな・・・
パケログ見ると、ワールドグループ選択後の鯖が列挙されてるデータとかあるから、
キャラがログインした時あたりのパケに、現在の鯖が何処なのかが分かるパケ情報があるのかな？

激しく質問ばかりで申し訳無い。

※実際に調べてる人ってどんな手段で調べてるんだろう・・・
※こういった調べ方も技術情報としては有用なんだろうけど・・・

98：人柱さん：2004/07/01(木) 22:12
接続先のIPアドレスでわかるだろ

99：人柱さん：2004/07/01(木) 22:17
というかRoAddr.dllのAPIでワールド名は取れるだろ

100：人柱さん：2004/07/01(木) 22:31
>99
全くその通りでした・・・
RoAddr.dllのヘッダーを見る前にDependencyWalkerでエクスポートされてる関数まで見てしまった・・・

まさしく、色んな所を万遍なく見ないといけないという事ですね。

掲示板管理者へ連絡 無料レンタル掲示板