ＦＬ以外Uohook５系ツール総合スレ１ - 1298902587

1：名も無きチーター：2011/02/28(月) 23:16:27 ID:JT7k3oTw0: 代表的なUohook５系ツール一覧（FL系以外）

ZeazyUO
IdWand
Logview
lol
mummy
cursedUO
UOSniffer
UOPS
UoTaming
UOPC
Itemcopy(正式ファイル名不明）

などのスレは、こちらへドーゾ

FL系（FL、FLS、FLMなど）は専用スレで。
2：名も無きチーター：2011/03/01(火) 03:28:19 ID:yUB8wbEw0: >>1乙だぜ
3：名も無きチーター：2011/03/10(木) 08:48:02 ID:92RoJN520: メジャー系のツール以外はツール総合でいいだろうに
なぜ分ける
4：名も無きチーター：2011/03/10(木) 09:04:22 ID:QrZBp1Fw0: 聞いたこと無いツール多いな・・・
どれがメジャーでどれがマイナー？
ツール総合レス機能してないからいいんでない
5：名も無きチーター：2011/03/18(金) 19:57:29 ID:LPGJSh5E0: 今詠唱中（硬直中）かどうか判別するほうほうってないかな？
6：名も無きチーター：2011/03/18(金) 20:32:08 ID:iEZD8XwM0: 画面を見る
7：名も無きチーター：2011/03/19(土) 03:35:29 ID:CS38/I..0: zuoで
8：名も無きチーター：2011/04/01(金) 21:28:56 ID:ZJ7x0b.A0: ZeazyUO本体だけでいいんで下さい。
9：名も無きチーター：2011/04/01(金) 22:53:57 ID:gTpzZXCw0: >>8
再配布禁止されてます＞＜

どっかのギルドに入れば持ってる人からもらえると思うけど・・・
10：名も無きチーター：2011/04/02(土) 00:29:52 ID:IfMIMkk.0: ZeazyUOは終わりました。
EUOへ行きましょう
11：名も無きチーター：2011/04/02(土) 19:05:00 ID:eVI21xNc0: EUOじゃ腐り探知機能が動かないんです。そこを何とかお願いします。
12：名も無きチーター：2011/04/02(土) 19:07:35 ID:58.Xbpng0: >>11
なんで動かないの?
13：名も無きチーター：2011/04/02(土) 22:35:24 ID:IfMIMkk.0: 自分で書き直す事ができないからじゃね
14：名も無きチーター：2011/04/02(土) 22:52:36 ID:58.Xbpng0: なんでそんな人が欲しいっていうの？

1から書かないでZeazyUO本体だけあれば使えるって言う状態がわかんない
15：名も無きチーター：2011/04/29(金) 15:35:17 ID:7sAfxevs0: 久々に復帰したらスクリプトが動かん！
Shadowさんのサイトも消えてるじゃないか！
16：名も無きチーター：2011/04/29(金) 16:58:11 ID:xm9GnAHs0: 数年前にとっくに消えてただろ
爺は既に終わってるからEUO行けよ
17：名も無きチーター：2011/05/02(月) 02:27:52 ID:tnPEX3wY0: 俺は今でも使えてるし、今でもバルクリセットBOTを回してる。
18：名も無きチーター：2011/05/02(月) 16:41:16 ID:2rMSH./w0: バルクリセットBOTも多すぎて相場崩壊してるけどなっ
19：名も無きチーター：2011/05/05(木) 08:03:40 ID:.4NVQ.020: コンテナを次々開きたいんだけどうまくいかない
おしえてえらいひと

function wclick(boxId) {
obj.id = boxId;
cmd.doubleClick(boxId);
sleep(2000);
obj.update();
var ids = find.findResult(null, 'pe' + boxId + ', m' + MODEL.Containers.join(','));
foreach (id in ids) {
wclick(id);
}
}
20：名も無きチーター：2011/05/05(木) 10:50:19 ID:XX0ijv.s0: function wclick(boxId) {
obj.id = boxId;
cmd.doubleClick(boxId);
sleep(2000);
obj.update();
var ids = find.findResult(null, 'pe' + boxId + ', m' + MODEL.Containers.join(','));
foreach (id in ids) {
wclick(id);
}
}

srcIds = find.findResult(null, 'g, np2, m' + MODEL.Containers.join(','));
foreach (srcId in srcIds) {
wclick(srcId);
}
21：名も無きチーター：2011/05/05(木) 16:25:46 ID:.4NVQ.020: find.findResult(null, 'pe' + boxId + ', m' + MODEL.Containers.join(','));
この行がどうしても取得できない

3701,2482,3705,3702,2474,3709,3710,2473,3646,3647,3644,3650,3651,3648,3649,2475,3708,9002,9003,2448,9429,9430,9431,9432,9433,9434,9435,9436,9437,3706,3703,4014,11761,11762,11763,11764,3786,3787,3788,3789,3790,3791,3792,3793,3794,5344
これがMODEL.Containers.join(','))の結果
22：名も無きチーター：2011/05/05(木) 16:34:36 ID:.4NVQ.020: 使ってるバージョン
ZeazyUO：070718B
DMonkey：0.3.10
23：名も無きチーター：2011/05/05(木) 16:41:14 ID:XX0ijv.s0: >>22
使ってるuohook5.dllは？
24：名も無きチーター：2011/05/05(木) 16:58:31 ID:iYe/P9KM0: もうEUO行った方が良いぞ
25：名も無きチーター：2011/05/05(木) 17:10:16 ID:.4NVQ.020: uohook5.dllは2009/09/09 7:41版
26：名も無きチーター：2011/05/05(木) 17:44:25 ID:XX0ijv.s0: 前スレ?
爺スレのその日付前後のログ確認してください

直す箇所とかも書いてあるから
27：名も無きチーター：2011/05/05(木) 17:45:08 ID:aFUnyhKI0: 'pe' + boxId
　↓
'pe, ' + boxId
28：名も無きチーター：2011/05/05(木) 18:27:49 ID:iYe/P9KM0: しかし、毎回思うんだが何故そんな判り難いまわりくどい構文組む奴って多いんだ？
find.findで取得してforで.result.length分回して開ければ済む話だろ
29：名も無きチーター：2011/05/05(木) 18:28:46 ID:.4NVQ.020: > "g"を使うと地面に置かれてるコンテナの中身を認識する
> 荷ラマの場合はいままでの"g"の使い方で使える
> 地面に置かれてるコンテナで"p"は使えない
> 地面に置かれてるコンテナの中のコンテナで"p"は使える
> プレイヤーバックパックの中は"p"で使える
> 地面に置かれてるコンテナはfindでは認識できない
> 地面に置かれてるコンテナはuseItem(コンテナID)は使える

こんな書き込みを見つけたので、以下のように書きなおしてみた。

var ids = find.findResult(null, 'g, ' + boxId + ', m' + MODEL.Containers.join(','));
println ('boxId:'+boxId);
println ('ids:'+ids);
foreach (id in ids) {
println ('id:'+id);
wclick(id);
}

そしたら、var idsが再帰処理で呼び出されるたびに上書きされる…。

boxId:コンテナＡ
ids:Ａの中の１個目,Ａの中の２個目
id:Ａの中の１個目
boxId:Ａの中の１個目
ids:Ａの中の１個目,Ａの中の２個目
id:Ａの中の１個目
boxId:Ａの中の１個目
ids:Ａの中の１個目,Ａの中の２個目
id:Ａの中の１個目
以下ループ

こんな感じに…。
30：名も無きチーター：2011/05/05(木) 18:43:39 ID:aFUnyhKI0: そうやりたいのなら
一度処理を通過した箱のIDを変数用意して継ぎ足しで登録しつつ
次の処理の時には ', ig' + 処理済みリスト　のようにして除外しないとだめかと
31：名も無きチーター：2011/05/05(木) 19:10:21 ID:.4NVQ.020: だめだーマニュアル無いからパラメータがわからない
find.findResult(null, 'g, ' + boxId + ', m' + MODEL.Containers.join(','));
この行で隣家のベンダーまで開く…
32：名も無きチーター：2011/05/05(木) 19:57:52 ID:.4NVQ.020: ためしにfind.findで３マス以内にお金があるか探すようにしてみた

dbgGold = new ZzFindCondition(
'g, np3, m0x0EED'
);
var gold = find.find(','+dbgGold);
println(gold);

かなり離れても表示される…もう私には無理…
33：名も無きチーター：2011/05/05(木) 20:27:32 ID:aFUnyhKI0: find.find(','+dbgGold)
の　','+　が余分
それ外せば希望の動作になるだろうけど
テストの時は例えば＞32でやってるのだと
findの中身の文は全文テキスト形式で一度書いた方がよいのじゃないかな
慣れていないうちは書式が本当にあってるかどうか
自分で判断しにくいでしょう

というかどこかからマニュアルを調達してきてから取りかかった方がよいと思いますよ
34：名も無きチーター：2011/05/05(木) 20:32:38 ID:iYe/P9KM0: もうEUO移行した方が確実じゃね
35：名も無きチーター：2011/05/05(木) 20:36:15 ID:.4NVQ.020: 「','+」を外すと見つからないんです
でも、「','+」をつけるとどうも別のものを見つけてるようで、拾えませんでした

マニュアルをみつけるか、ＥＵＯ使うか考えたいと思います
ID:XX0ijv.s0さん、ID:iYe/P9KM0さん、ID:aFUnyhKI0さん、ありがとうございました
36：名も無きチーター：2011/05/05(木) 20:54:46 ID:aFUnyhKI0: find = new ZzObjectFindEx();
var gold = find.find('g, np3, m0x0EED');
println(gold);

まあ私も＞34には同意です
でも質問と直接は関係なかったのであえて移行は勧めませんでした
37：名も無きチーター：2011/05/06(金) 12:40:53 ID:nsNsotk60: そのUohook5.dllでは無理なんじゃないかな？

UOSA になって 0xF3 パケットが新規追加されて、0x1Aパケットと置き換わった
爺本体を対応させるか
Uohook5で
F3>1A、DC>BF10で送りつけるようuohookを修正してるのを使うかののどちらか

結局、直せるか直してあるの手に入れられないなら素直にEUOに行った方がいいね
38：名も無きチーター：2011/05/06(金) 12:45:27 ID:nsNsotk60: 今使われてる出回ってるFL本体は対応してあるんで
FLと同じuohook5では対応してない爺では無理ってこと
39：名も無きチーター：2011/05/06(金) 13:13:14 ID:A9KuoG5.0: 解説ありがとう
素直にＥＵＯ使います
40：名も無きチーター：2011/05/06(金) 14:21:44 ID:nsNsotk60: >>39
とりあえず
http://www1.axfc.net/uploader/Sc/so/231293.zip
15時には消す
41：名も無きチーター：2011/05/06(金) 17:24:14 ID:RSP9VH/w0: 一々ばら撒くからいつまでたってもクレクレが出るんだよ
EUOがあるんだからやる気のある奴はそっちに早々と移行させたほうがええ
42：名も無きチーター：2011/05/06(金) 20:21:29 ID:QykuKI9U0: ちょっとスレチになるけど
dllのコンパイルってどうやんの？
uohook5のソースがあるとして
これをコンパイルできるコンパイラーが知りたい
みんなどうやってんだ・・・
43：名も無きチーター：2011/05/07(土) 02:22:30 ID:TQ6WReIM0: ソース見れば判る事だろ
これで判らんなら諦めろ
44：名も無きチーター：2011/05/07(土) 18:51:28 ID:FGI9AZhU0: その辺に落ちてるフリーのコンパイラじゃできない
ってのはわかった
45：名も無きチーター：2011/05/07(土) 20:40:23 ID:CQgwQQg.0: 考えが甘すぎる
46：名も無きチーター：2011/05/07(土) 21:29:42 ID:TQ6WReIM0: 甘い以前の問題
日本語すら読めていないかもしれない
47：名も無きチーター：2011/05/08(日) 22:10:23 ID:kG8DHIFY0: >これをコンパイルできるコンパイラーが知りたい
これが解らん奴が、他人が作ったソースをコンパイルしようとしてるワケ？
もしかして専門学校卒業したてのゆとりですか？
48：名も無きチーター：2011/05/08(日) 22:42:09 ID:TfmlD2dg0: 専門新卒でも拡張子＋"コンパイル"でぐぐるくらいは出来るだろう
49：名も無きチーター：2011/06/05(日) 03:48:23 ID:4V88QkxE0: 相変わらず、誰かがうｐすると、とたんにわらわらと沸いてくるんだなｗ
持ってないやつよりも、持っているやつの方が多いから笑えるｗ
そこまで必死になるほどかね、今のUOは。

shadowが方策をとった以上、締め出された奴らが何をしようと黙認しといてやれよ。
お前らチーターどもも屑なりにそのくらいの度量は持っておけ。
50：名も無きチーター：2011/06/05(日) 10:37:48 ID:KZ3k5hmQ0: 約一月ぶりの湧きがこれかぁ
51：名も無きチーター：2011/06/05(日) 13:07:06 ID:.x/PvIWU0: 俺が何か作ったらこのスレも盛り上がるのだろうか。
52：名も無きチーター：2011/06/05(日) 14:26:54 ID:ymIKIDRM0: いろんな意味で盛り上がると思う
53：名も無きチーター：2011/06/05(日) 17:51:06 ID:.x/PvIWU0: ただ、一人の力では限界があるから、みんなの知恵を貸してほしいな。
54：名も無きチーター：2011/06/05(日) 18:57:42 ID:KZ3k5hmQ0: だが断る
55：名も無きチーター：2011/06/05(日) 22:39:21 ID:.x/PvIWU0: いや、知恵を貸してほしいなと思っただけで要求はしていないよ？
しかし、知恵を貸してほしいなと思っていたのでした。
56：名も無きチーター：2011/08/04(木) 09:15:18 ID:6nf/aWN20: mummy使ってるんですが
ガゴで飛行状態にすると毒に侵されていると勘違いしてしまうんですが
対応済みのものはありますか？
UOAでキャラの変身をしないと　対象の追加で指定しても包帯すら巻いてくれません。
57：名も無きチーター：2011/08/04(木) 09:18:20 ID:6nf/aWN20: >>56ですが使用しているmummyですがVer.070719です
58：名も無きチーター：2011/08/04(木) 13:11:55 ID:nMHxnwik0: そんな物はありません、諦めましょう
59：名も無きチーター：2011/08/04(木) 13:42:53 ID:6p420wgI0: >>57
残念ながら、それが最終バージョン
60：名も無きチーター：2011/08/04(木) 18:58:02 ID:Lo1i9AFg0: mummy080525.exeが手元にあるけど、
それより新しいものが出てるのかどうかはわからん。
61：名も無きチーター：2011/08/04(木) 20:10:00 ID:6nf/aWN20: とりあえずフライングしてから対象追加で自分にすれば　なんとか使えそうです
着陸したら対象クリアでまた追加とかすれば・・・
>>60 さんのmummyはガゴのフライングとかしても毒勘違い状態になったりしませんか？
62：名も無きチーター：2011/08/05(金) 07:52:24 ID:I/csQako0: mummy070719ですがガゴキャラで徒歩なら問題ないみたいです。
フライングしてから対象を追加で自分を選択してもノーダメの時までは
いいんですが　1度でもダメくらってHPが減るとゲージが緑色の毒状態
で包帯は巻きますが　延々と包帯を巻き続けるのか　ダメージを受けていません
と画面左下にメッセージが出続けます・・・
ガゴキャラ対応のmummyが欲しい。。。
63：名も無きチーター：2011/08/05(金) 13:56:44 ID:uj8b4SM.0: そんな物はありません、諦めましょう
64：60：2011/08/05(金) 20:19:12 ID:98m29eys0: >>61
予想通りダメだった。
SAが出たのが2009/9だったはずだから
mummyも0909xxより新しいのでないと
対応してないんじゃない？
あるようならほしいけど、こればかりは>>63の通りだと思う。
65：名も無きチーター：2011/08/10(水) 17:06:26 ID:EB3ugXtY0: UOhookの中身を少し変えるだけでいけますよ。
ガーゴでも普通に使えてるし。
66：名も無きチーター：2011/08/12(金) 21:38:33 ID:9JBNmA4g0: そのhookください！
67：名も無きチーター：2011/08/13(土) 01:24:41 ID:qPWNg2dE0: だが断わる！
68：magcnt@pub87：2014/10/28(火) 20:42:35 ID:O8FkbHlA0: 幸運0 Total:2954 / RankAve:2.19 / 00:49:32
MG-> 748(25%) 1240(42%) 656(22%) 245( 8%) AF-> 50( 1%) 12( 0%) 3( 0%) 0( 0%)

幸運1200 Total:2884 / RankAve:2.24 / 00:46:31
MG-> 670(23%) 1234(42%) 644(22%) 257( 8%) AF-> 60( 2%) 13( 0%) 5( 0%) 1( 0%)

幸運1800 Total:2935 / RankAve:2.34 / 00:48:42
MG-> 626(21%) 1190(40%) 739(25%) 268( 9%) AF-> 93( 3%) 15( 0%) 3( 0%) 1( 0%)

幸運2900 Total:2958 / RankAve:2.39 / 00:49:13
MG-> 592(20%) 1175(39%) 753(25%) 322(10%) AF-> 92( 3%) 19( 0%) 5( 0%) 0( 0%)

幸運2900(2) Total:2932 / RankAve:2.38 / 00:49:46
MG-> 634(21%) 1119(38%) 753(25%) 296(10%) AF-> 103( 3%) 24( 0%) 3( 0%) 0( 0%)
69：名も無きチーター：2016/08/29(月) 00:53:29 ID:cBCpZDWw0: 短命なスクリプトを気軽に抜き差しするにはちょっと信頼性が足りなかったんで uohook5_7000 を整理した。

uohook5s_20160828.zip
http://www1.axfc.net/u/3711654.zip?key=UOH5S

変更点:
・安定化
・突然死耐性
・固定長バッファ (受信 64 KiB, 送信 256 KiB x 2)

新機能:
・BOOL UOHOOK_WaitEvent(DWORD ms)
　機能：イベントを待つ。
　引数：待ち時間(ミリ秒)。0 なら即座に制御を返す。INFINITE だと待ち続ける。
　復帰値：イベントの有無。

非互換:
・GetEvent で取れる可変長送信パケットの長さの部分を Big Endian に変更

uohook5.dll との差し替えについては某腐り家検出器は問題なさそうだった。他は知らん。
70：名も無きチーター：2016/08/30(火) 02:27:02 ID:JzXSjmzk0: 抜けてちゃまずい行が抜けてたんで上げ直した。

uohook5s_20160830.zip
http://www1.axfc.net/u/3712262.zip?key=UOH5S
71：名も無きチーター：2017/09/07(木) 01:56:53 ID:Q3REbXuA0: uohook5 のソースコードの解説ってどこかにありますか？
ソースコード見させて頂きましたが、
UO client 側でフックしてツール側に send event する処理と
ツール側で get event する処理との相関関係がよくわかりませんでした
72：名も無きチーター：2017/09/07(木) 14:50:45 ID:Q3REbXuA0: uohook5 及び uohook5s のソースコードを読んで理解したことを、書いていきます

### 初期化フロー
* ツール側のプロセスが uohook5.dll をロード
* ツール側の uohook5.dll が event をシグナル状態に
* ツール側のプロセスから UOHOOK_GetEvent() を呼び出す
* ツール側の uohook5.dll の UOHOOK_GetEvent() 内で、event を補足
* UO クライアントを探し、見つかったら SetWindowsHookEx() で UO クライアントに uohook5.dll をインジェクション
* UO クライアント側のプロセス内に uohook5.dll がロードされ DllMain() が呼ばれる
* UO クライアント側で uohook5.dll の初期化
* UO クライアントの process ID や window handle を保存
* UO クライアントのパケット送信関数をフック
* set_patch1()内で jmp 命令？を書き換え？
* UO クライアントのパケット受信関数をフック
* set_patch2()内で関数の先頭？の 4byte の命令書き換え？
* UO クライアントに SetWindowsHookEx() でもう一つメッセージフック
* (この2つめのメッセージフックの目的や処理内容がよくわからない)

* とりあえずここまでが初期化のフロー
73：名も無きチーター：2017/09/07(木) 14:52:00 ID:Q3REbXuA0: ### UO クライアントからサーバーへのパケット送信のフロー
* UO クライアント側の uohook5.dl 内のフック関数 hook_send() が呼ばれる
　　* 引数 adrs は恐らく、パケットのペイロードの先頭アドレス
　　* パケットを global.packet_buffer にコピー
　　* event をシグナル状態に
　　* セマフォで待機
* ツール側のプロセスから UOHOOK_GetEvent() を呼び出す
* ツール側の uohook5.dll の UOHOOK_GetEvent() 内で、event を補足
　　* パケットの先頭アドレスを返す
* ツール側のプロセス内でパケットを取得
　　* **ここで、いろいろできる**
* ツール側のプロセスから UOHOOK_FreeEvent() を呼び出す
　　* セマフォ解除
* UO クライアント側の uohook5.dll 内のフック関数 hook_send() が終了

* **この間がよくわからない**

* UO クライアント側の uohook5.dll 内のメッセージフック関数 HookProc2() が呼ばれる
* HookProc2() でオリジナル？の送信関数 hook_send_send_adrs() を呼ぶ
* UO クライアントからサーバーにパケットが送信される

* 疑問点
　　* hook_send() は単に return していてオリジナルの送信関数を呼んでいないように見える
　　* オリジナルの送信関数を呼ぶ代わり、メッセージフック関数内で hook_send_send_adrs() を呼んでいる？
　　* 何でこれでいいのかよくわからない。逆汗が必要かも
74：名も無きチーター：2017/09/07(木) 14:52:45 ID:Q3REbXuA0: ### サーバーから UO クライアントへのパケット受信のフロー
* UO クライアント側の uohook5.dl 内のフック関数 hook_recv() が呼ばれる
　　* recv_recv_packet() および analyze_packet() 内でツール側に対応させるための加工を行う
　　　　* bswap は length 2byte のエンディアンの変更のため？
　　　　* パケットの仕様変更があった場合は、この辺を変えれば良さそう
　　* 共有メモリに player_id、xpos、ypos 等の情報を保存
　　* (加工した)パケットを global.packet_buffer にコピー
　　* event をシグナル状態に
　　* セマフォで待機
* ツール側のプロセスから UOHOOK_GetEvent() を呼び出す
* ツール側の uohook5.dll の UOHOOK_GetEvent() 内で、event を補足
　　* パケットの先頭アドレスを返す
* ツール側のプロセス内でパケットを取得
　　* **ここで、いろいろできる**
* ツール側のプロセスから UOHOOK_FreeEvent() を呼び出す
　　* セマフォ解除
　　* hook_recv_recv_adrs_ret() にジャンプ
　　　　* hook_recv_recv_adrs_ret() はオリジナル？の受信関数？
* UO クライアント側の uohook5.dll 内のフック関数 hook_recv() が終了

* **この間がよくわからない**

* UO クライアント側の uohook5.dll 内のメッセージフック関数 HookProc2() が呼ばれる
* HookProc2() でオリジナル？の受信関数 hook_recv_recv_adrs_top() にジャンプ
* サーバーから UO クライアントにパケットが受信される
75：名も無きチーター：2017/09/07(木) 15:35:13 ID:Q3REbXuA0: ### ツールから UO クライアントへのパケット送信のフロー
* ツール側のプロセスで、送信用のパケットを生成
* ツール側のプロセスから UOHOOK_SendPacketToClient() を呼び出す
* ツール側の uohook5.dll の UOHOOK_SendPacketToClient() 内では、
　　* パケットを global.packet_buffer にコピー
　　* UO クライアントに PostMessage() でメッセージ送信
* UO クライアント側の uohook5.dll 内のメッセージフック関数 HookProc2() が呼ばれる
* UO クライアント側の uohook5.dll の HookProc2() 内では、
　　* send_recv_packet() 内で、パケットサイズが大きい場合に複数パケットに分割して送信する処理？がある
　　* send_recv_packet() 内から UO クライアントへのパケット送信関数？ hook_recv_recv_adrs_top() にジャンプ

* これでツール側から UO クライアントにパケットが送信されるみたい

### ツールからサーバーへのパケット送信のフロー
* ツール側のプロセスで、送信用のパケットを生成
* ツール側のプロセスから UOHOOK_SendPacketToServer() を呼び出す
* ツール側の uohook5.dll の UOHOOK_SendPacketToServer() 内では、
　　* パケットを global.packet_buffer にコピー
　　* UO クライアントに PostMessage() でメッセージ送信
* UO クライアント側の uohook5.dll 内のメッセージフック関数 HookProc2() が呼ばれる
* UO クライアント側の uohook5.dll の HookProc2() 内では、
　　* send_send_packet() 内で、パケットサイズが大きい場合に複数パケットに分割して送信する処理？がある
　　* send_send_packet() 内から UO クライアントへのパケット送信関数？ hook_send_send_adrs() を呼び出し

* これでツール側からサーバーにパケットが送信されるみたい

もしかして、hook_send() や hook_recv() の後に HookProc2() は呼ばれない？
76：名も無きチーター：2017/09/07(木) 18:01:50 ID:Q3REbXuA0: client.exe version 7.0.59.5 を逆アセしてみました

code2, code5, code7 のバイト列は見つかりませんでした
uohook のソースは >70 のソースを参考にしました

>70 の uohook は今でも動いてますか？それとももっと新しい uohook があるのでしょうか？
77：名も無きチーター：2017/09/07(木) 20:22:07 ID:Q3REbXuA0: * code1
```asm
.text:0044C0F0 init_x_y_position_sub_44C0F0 proc near ; CODE XREF: WinMain(x,x,x,x)+121
.text:0044C0F0 push 4000h ; size_t
.text:0044C0F5 push 0 ; int
.text:0044C0F7 push offset dword_73AF98 ; void *
.text:0044C0FC call _memset
.text:0044C101 mov eax, 0FFFFFF80h ; code1 の先頭
.text:0044C101 ; B8 80 FF FF FF
.text:0044C106 add esp, 0Ch ; 83 C4 0C
.text:0044C109 mov dword_73AF94, 0 ; C7 05 94 AF 73 00 00 00 00 00
.text:0044C113 mov dword_73AF90, 0 ; C7 05 90 AF 73 00 00 00 00 00
.text:0044C11D mov hook_ypos_addr_dword_739F88, eax ; code1 からの offset 29
.text:0044C122 mov hook_xpos_addr_dword_739F8C, eax ; code1 からの offset 34
.text:0044C127 retn
.text:0044C127 init_x_y_position_sub_44C0F0 endp
```
78：名も無きチーター：2017/09/07(木) 20:24:17 ID:Q3REbXuA0: * code4
* hook_packet_table はソース見てもよくわからなかったのだけど、各コマンドに対応するパケット長が格納されている配列？
```asm
.text:00480840 hook_recv_send_addr_sub_480840 proc near ; CODE XREF: sub_462000+95
.text:00480840 ; sub_4620F0+23
.text:00480840
.text:00480840 arg_0 = dword ptr 4
.text:00480840
.text:00480840 mov edx, [esp+arg_0]
.text:00480844 mov al, [edx]
.text:00480846 cmp al, 0F9h
.text:00480848 jnb short loc_480862
.text:0048084A movzx ecx, al ; code4 の先頭
.text:0048084A ; 0F B6 C8
.text:0048084D lea ecx, [ecx+ecx*2] ; 8D 0C 49
.text:00480850 movzx ecx, hook_packet_table_word_6F4E70[ecx*4] ; 0F B7 0C 8D 70 4E 6F 00
.text:00480850 ; code4 からの offset 10 は hook_packet_table
.text:00480858 shr ecx, 0Fh
.text:0048085B jz short loc_480862
.text:0048085D movzx eax, word ptr [edx+1]
.text:00480861 retn
.text:00480862 ; ---------------------------------------------------------------------------
.text:00480862
.text:00480862 loc_480862: ; CODE XREF: hook_recv_send_addr_sub_480840+8
.text:00480862 ; hook_recv_send_addr_sub_480840+1B
.text:00480862 movzx eax, al
.text:00480865 lea edx, [eax+eax*2]
.text:00480868 mov ax, hook_packet_table_word_6F4E70[edx*4]
.text:00480870 retn
.text:00480870 hook_recv_send_addr_sub_480840 endp
.text:00480870
```
79：名も無きチーター：2017/09/07(木) 20:25:47 ID:Q3REbXuA0: * code6
* call 命令を書き換えて hook_send() を呼ぶようにしている
* やっぱり、オリジナルの hook_recv_send_addr_sub_480840() を呼んでいないように見える
```asm
.text:00462150 ; int __stdcall sub_462150(void *)
.text:00462150 sub_462150 proc near ; CODE XREF: sub_45CF60+F
.text:00462150 ; sub_45CFF0+5B
.text:00462150
.text:00462150 arg_0 = dword ptr 4
.text:00462150
.text:00462150 push ebx
.text:00462151 push esi
.text:00462152 mov esi, [esp+8+arg_0]
.text:00462156 push edi
.text:00462157 push esi
.text:00462158 mov edi, ecx
.text:0046215A call hook_recv_send_addr_sub_480840 ; code6 からの offset -4
.text:0046215F movzx ebx, ax ; code6 の先頭
.text:0046215F ; 0F B7 D8
.text:00462162 movzx eax, byte ptr [esi] ; 0F B6 06
.text:00462165 add esp, 4 ; 83 C4 04
.text:00462168 push ebx
.text:00462169 push eax
.text:0046216A lea ecx, [edi+6Ch]
.text:0046216D call sub_480050
```
80：名も無きチーター：2017/09/10(日) 00:17:12 ID:WVu4Z1pY0: * code6 補足
　　* code6 は call 命令内の関数アドレスを指す
　　* set_patch1() にて call 命令を書き換えて、hook_recv_send_adrs() を呼び出す代わりに hook_send() を呼び出すようにフックしている

* hook_send() 内の下記 3行は、オリジナルの hook_recv_send_adrs() と等価の処理
* そのため、オリジナルの hook_recv_send_adrs() を呼ばなくてもよい
```c
　　int len = share.packet_table[*adrs];
　　if (len == 0x8000)
　　　　len = *(u16*)(adrs +1);
```

* hook_recv_send_adrs() は UO クライアント的には GetRequestPacketLength() みたいな役割
81：名も無きチーター：2017/09/10(日) 00:20:20 ID:WVu4Z1pY0: * code2
　　* code2 は関数の先頭アドレスを指し hook_send_send_adrs として保存
　　* uohook5 では、ツール側からサーバーにパケットを送信する際に呼び出す
　　* hook_send_send_adrs() は UO クライアント的には PushRequestPacketQueue() みたいな役割だと思う
　　* hook_send_send_adrs() の先で length が 0x8000 の場合のみ htons() を通過する
　　* send_send_packet() 内の rol ax,8 は、恐らくそれと関連している

```asm
.text:0045CF60 hook_send_send_adrs_sub_45CF60/ proc near ; CODE XREF: sub_43EEC0+1EF
.text:0045CF60 ; sub_43EEC0+23B
.text:0045CF60
.text:0045CF60 packet_addr_arg_0= dword ptr 4
.text:0045CF60
.text:0045CF60 mov ecx, dword_AA1DE4 ; code2 の先頭
.text:0045CF60 ; 8B 0D E4 1D AA 00
.text:0045CF66 test ecx, ecx ; 85 C9
.text:0045CF68 jz short locret_45CF74 ; 74 0A
.text:0045CF6A mov eax, [esp+packet_addr_arg_0] ; 8B 44 24 04
.text:0045CF6E push eax ; packet_addr_arg_0
.text:0045CF6E ; 50
.text:0045CF6F call send_packet_sub_462150 ; E8 DC 51 00 00
.text:0045CF74
.text:0045CF74 locret_45CF74: ; CODE XREF: hook_send_send_adrs_sub_45CF60+8
.text:0045CF74 retn
.text:0045CF74 hook_send_send_adrs_sub_45CF60/ endp
```
```c
global.hook_send_send_adrs = adrs;
```
82：名も無きチーター：2017/09/10(日) 00:27:43 ID:WVu4Z1pY0: > code2, code5, code7 のバイト列は見つかりませんでした

バイト列の 0xff は any という意味です
これはさすがに、コメントに書いておいてほしいですね
83：名も無きチーター：2017/09/10(日) 02:44:55 ID:WVu4Z1pY0: * code5
　　* hook_recv_recv_addr_top は jump 命令のアドレスを指す
　　* hook_recv_recv_addr_ret は jump 命令の次の命令のアドレスを指す
　　* set_patch2() にて jump 命令を書き換えて、loc_482451 のルーチンに飛ぶ代わりに hook_recv() に飛ぶようにフックしている
　　　　* 相対ジャンプなのでアドレス計算が面倒
　　　　* あと、この実装だと仮に条件にマッチした場合 loc_482451 に飛ぶことは決してない気がするけど問題ないのでしょうか？
```asm
.text:00481839 loc_481839: ; CODE XREF: sub_481780+8D
.text:00481839 ; sub_481780+98
.text:00481839 push esi ; packet_addr
.text:0048183A mov ecx, ebx
.text:0048183C call sub_4620F0
.text:00481841 movzx edi, byte ptr [esi] ; edi = packet_cmd
.text:00481844 lea eax, [edi-0Bh] ; switch 237 cases
.text:00481847 cmp eax, 0ECh ; code5 の先頭
.text:00481847 ; 3D EC 00 00 00
.text:0048184C ja hook_recv_recv_adrs_loc_482451 ; 0F 87 FF 0B 00 00
.text:00481852 movzx edx, ds:byte_482770[eax] ; 0F B6 90 70 27 48 00
.text:00481859 jmp ds:off_482528[edx*4] ; switch jump
```
```c
global.hook_recv_recv_addr = addr + 7;
global.hook_recv_recv_addr_top = global.hook_recv_recv_addr - 2;
global.hook_recv_recv_addr_ret = global.hook_recv_recv_addr + 4;
```
84：名も無きチーター：2017/09/10(日) 02:49:44 ID:WVu4Z1pY0: ### ツールから UO クライアントへのパケット送信のフロー (更新)
* ツール側のプロセスで、送信用のパケットを生成
* ツール側のプロセスから UOHOOK_SendPacketToClient() を呼び出す
* ツール側の uohook5.dll の UOHOOK_SendPacketToClient() 内では、
　　* パケットを global.packet_buffer にコピー
　　* UO クライアントに PostMessage() でメッセージ送信
* UO クライアント側の uohook5.dll 内のメッセージフック関数 HookProc2() が呼ばれる
* UO クライアント側の uohook5.dll の HookProc2() 内では、
　　* send_recv_packet() 内で、パケットサイズが大きい場合に複数パケットに分割して送信する処理？がある
　　* send_recv_packet() 内から UO クライアントへのパケット送信関数内のラベル hook_recv_recv_adrs_top にジャンプ
　　* hook_recv_recv_adrs_top は hook_recv() を呼ぶように書き換え済なので、hook_recv() に更にジャンプ
　　* hook_recv() が終わると hook_recv_recv_adrs_top+6 の位置に復帰

* これでツール側から UO クライアントにパケットが送信される
* ツールから UO クライアントにパケットを送信した場合は、自分で生成したパケットを自分で拾うようになっている
85：名も無きチーター：2017/09/10(日) 02:54:01 ID:WVu4Z1pY0: > uohook5のSendPacketToClient()を呼び出してパケットを送ったときも
> そのパケットをuohook5が捕捉していたよ。

大昔、ZeasyUO のスレでこの発言を見て、自分で実験もせずホントなの？って思ったけど、事実でした
86：名も無きチーター：2017/09/10(日) 03:04:03 ID:WVu4Z1pY0: ### 補足情報

* search_patch_adrs()
　　* UO クライアント内の様々なアドレスを見つける処理
　　* client.exe の PE header の DllCharacteristics は 0x0000 なので ASLR も DEP も無効
　　* ASLR が無効なので base address が 0x00400000 となることが保証される
```c
static bool search_patch_adrs()
{
　　for (u8* adrs = (u8*)0x00400000; adrs < (u8*)0x004fffff; adrs++)
　　{
　　}
}
```

* hook_recv() は jump で飛んで来るのでスタックの保存と復元が必要

これで大体の解析は終わったと思います
要望があればまとめたものをアップします
87：名も無きチーター：2017/09/14(木) 15:08:41 ID:qNwFtiC.0: まとめたものをアップして欲しいです。
88：名も無きチーター：2017/09/25(月) 02:33:20 ID:75zw0TNM0: ZUO スレと重複してすみませんが、一応ここでも宣伝させていただきます

>87
遅くなりましたが、ソースと解析メモを公開しました
参考にしてください

ttps://www.axfc.net/u/3848216
89：名も無きチーター：2017/10/04(水) 14:33:36 ID:I6Zi9yXg0: >>88
GJです、頂きました。
ここ数年、ステ値が取得できなかったので自前でステ要求パケット→ステ取得をやっていたのが解消されそうです。
ちなみに、各種DLL不足で起動できませんが、Releaseで配布したら解消されたりしますか？
足りないDLLを用意したら動いたので良いのですが、もし治るなら。
90：名も無きチーター：2017/10/07(土) 02:11:33 ID:pVDkw/zA0: 動的リンクでビルドしているので、VC++ 2015 再頒布パッケージが必要かもです
それ以外に、足りない DLL もしくはインストールしたものがあれば、教えてください

次に公開するときは治すことにします
現時点は、VC++ 2015 再頒布パッケージが必要、ということでご利用ください
91：名も無きチーター：2017/10/07(土) 11:05:18 ID:ArZEoMIA0: >>90
vcruntime140d.dllとucrtbased.dllですね。
用意さえすれば問題なく動いてますので、対応するしないはお任せします。
92：名も無きチーター：2017/10/08(日) 10:40:25 ID:/QrU.vII0: >>90
あと、uohoock5.ddlを変更してから、ZeasyUO終了後にプロセスが残ることが増えました。
残った状態でZeasyUOを新たに起動すると、そちらがフックできなくなるので気づきました。
何か今回の修正の影響がありますか？
93：名も無きチーター：2017/10/08(日) 11:05:10 ID:/QrU.vII0: >>90
あと、FastLootあたりと併用するとかなり確率で強制終了します。
94：名も無きチーター：2017/10/09(月) 10:13:22 ID:9dlHxpjo0: 情報ありがとうございます

>>92
これは私が修正する前から同じ症状が出ています
なので、今回の修正の影響ではないと思います

>>93
こっちは、複数のツールで >>88 の uohook5.dll を共有すると、落ちるということですか？
それとも、>>88 の　uohook5.dll と別の uohook系DLL (uohook5s.dll とか)と共存すると、落ちるということですか？

どちらにせよ、今回の修正と関係あるかどうかは不明です。
Windows のイベントビューアから、落ちているアドレスが分かれば、対処できるかもです。
95：名も無きチーター：2017/12/28(木) 22:44:19 ID:tAk5HqRo0: ぽんぽん！
96：名も無きチーター：2018/02/14(水) 02:27:18 ID:h4vLDKXE0: >>92
プロセスが残る問題の原因が分かりました

■チラ裏・調査報告

ZeazyUO.exe のダンプファイルを解析しました

01 0713fee0 6f7419a7 00000270 fffffaf2 00000000 KERNELBASE!WaitForSingleObject+0x12 (FPO: [Non-Fpo])
02 0713fef4 0054f61c 0713ff2c 0713ff24 0713ff20 uohook5!UOHOOK_GetEvent+0x41
03 0713ff34 0042a6a9 0713ff48 0042a6b3 0713ff6c ZeazyUO+0x14f61c

WaitForSingleObject() の第二引数に 0xfffffaf2 (約1193時間)という大きな値が渡っています

コードはこうなっていて、負の整数オーバーフローが起きているようです
```c
int wait = 100 - (tm2 - tm1);
if (WaitForSingleObject (global.event_handle, wait) != WAIT_OBJECT_0)
```

UOHOOK_GetEvent() が呼ばれる間隔が 100 msec 以下であることを期待していますが、
それを超えたときはプロセスが残ってしまうことがあったと思われます

タイムアウト値は固定値 100 msec にすると、手元では再現しなくなりました。
近日中にソースと DLL をアップ予定です
97：名も無きチーター：2018/02/14(水) 02:28:09 ID:h4vLDKXE0: >>91
当方の設定ミスでした。VC++ 2015 のやつ入れてもだめだったんですね。
静的リンクに設定変更したので、次回のバージョンでは追加の DLL は必要無くなる予定です
98：名も無きチーター：2018/02/15(木) 00:10:12 ID:UYj0YbWU0: ZUO スレと重複してすみませんが、一応ここでも宣伝させていただきます

ttps://www.axfc.net/u/3888233
99：名も無きチーター：2018/02/15(木) 00:13:20 ID:UYj0YbWU0: >>93
落ちる件については、一旦最新バージョンで様子を見てもらって、まだ再現するようなら、情報提供待ちとさせてください
100：名も無きチーター：2018/11/18(日) 11:13:38 ID:gLUlKAVQ0: パケットのエンディアンについて (備忘録)

- UO のパケットは基本的に big endian (ネットワークバイトオーダー)
- ただし length フィールドの 2 byte だけ little endian 、という変態仕様
- 一方 uohook では、全てのフィールドを big endian で扱えるように length の 2 byte を BE から LE に変換している
- ただし、これも片手落ちで、クライアントからサーバへのパケットだけは変換していない

- つまり
- server to client : ツール側では全てを BE として扱える
- uohook to client : ツール側では全てを BE として扱える
- uohook to server : ツール側では全てを BE として扱える
- client to server : length の 2 byte のみ LE として扱う必要がある
- UOHOOK_GetPacketLength の戻り値は LE

- 対応策としては
- client to server のときは、length フィールドの長さ(BE)を使わず、UOHOOK_GetEvent の第二引数や UOHOOK_GetPacketLength の戻り値を長さ(LE)として使用する

- ちなみに、
- uohook5s は client to server のときも BE に変換している
- つまり全てのケースで BE として扱える
- uohook5s の作者様が互換性が無いと言っているのはこのこと (uohook5s の client to server の length は BE)
101：名も無きチーター：2018/11/18(日) 11:15:47 ID:gLUlKAVQ0: 訂正

誤一方 uohook では、全てのフィールドを big endian で扱えるように length の 2 byte を BE から LE に変換している
正一方 uohook では、全てのフィールドを big endian で扱えるように length の 2 byte を LE から BE に変換している
102：名も無きチーター：2019/09/09(月) 07:16:32 ID:Ah2yZxLI0: ge
103：名も無きチーター：2019/10/22(火) 14:01:00 ID:8k5a5lTQ0: LOL
104：名も無きチーター：2020/05/13(水) 12:11:47 ID:hft5ZPJU0: String Alertってwin10だと使えないんだがどっかにないですか
105：名も無きチーター：2020/11/13(金) 18:57:05 ID:GcZsGlIY0: >>104
そのまま使えてる
106：＜垢ぼ～ん＞：＜垢ぼ～ん＞: ＜垢ぼ～ん＞