したらばTOP ■掲示板に戻る■ 全部 1-100 最新50 | メール | |

FL以外Uohook5系ツール総合スレ1

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

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

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

FL系(FL、FLS、FLMなど)は専用スレで。

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
そんな物はありません、諦めましょう

6460: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
だが断わる!

68magcnt@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<垢ぼ〜ん>:<垢ぼ〜ん>
<垢ぼ〜ん>


新着レスの表示


名前: E-mail(省略可)

※書き込む際の注意事項はこちら

※画像アップローダーはこちら

(画像を表示できるのは「画像リンクのサムネイル表示」がオンの掲示板に限ります)

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