【会員制】ZeazyUO総合スレ03【shadow氏】 - 1302364293

100：名も無きチーター：2018/05/14(月) 14:03:13 ID:qrIgXOJ60: 未確認なため、これらはすべて妄想です

修正案1
　　*(u16*)(p+7)　=　pf3->model_id　&　0x7FFF;

修正案2
　　if　(pf3->model_id　&　0x8000)
　　　　*(u16*)(p+11)　=　pf3->direction;

修正案3
　　if　(pf3->model_id　&　0x8000)
　　　　*(u16*)(p+11)　=　0;

※全角空白注意

何れにせよ、スクリプト内ではモデルID から 0x8000 を引いた値として認識されるなら、固定長で扱える分、修正案1 が良さそうです
ちなみに、532様のすごいところは、全てのフラグを立てることでパケットを常に固定長として扱えるようにしているところ

[仮説]
- art.mul 内では同じモデルでも、向きや色毎に異なるモデルID を持っているが、クライアント内ではそれらは同一のモデルID(基本モデルID と便宜的に呼ぶ) として扱われている
- 基本モデルID から art.mul 内の向き別・色別モデルID を求めるために、1A の追加フィールド (pf3->direction フィールド) が存在する
- 爺本体がこの追加フィールドを使用していないのであれば、修正案2 と修正案3 はどちらであっても違いはない。(描画のために必要な値で、爺では使用していない可能性が高い)

[制限事項]
- 0x8000 以上のモデルID を持つモデルは、スクリプト内では 0x8000 を引いた値として認識される
例) MODEL.TokunoSensou = 0x916F - 0x8000
- スクリプト内では、本当の 0x116F と 0x916F とを区別できない
101：名も無きチーター：2018/05/14(月) 14:06:55 ID:qrIgXOJ60: >98 がリンク切れだったのですが、>100 は、その意図を汲み取ってると思ってます

ちなみに、0x8000 を引いたモデルとして認識されてるなら、アイテム名も変わってしまうんでしょうか？
自分で試せって感じですが…
102：94：2018/05/15(火) 00:28:38 ID:20T89R.c0: >>100
修正案1にならってMSBを常時1ないしは0にしてみたところ、
サイズさえあわせておけばとりあえずトラブルはなさそうです。

ざっくり調べたところ、0x8000以上のモデルIDは結構使われているようです。
見た感じUOHS以降に追加されたものがそれにあてはまり、
今現在は0xA12Dまでが使用(準備)されているかと思われます。
なので、特定のオブジェクトを検索する際にはモデルIDだけでは
よろしくない場合もあることを念頭におく必要があるかもしれません。
103：94：2018/05/15(火) 00:40:23 ID:20T89R.c0: 寝ぼけてたようで>>102の修正です。
件の1バイトはどうやらMultiオブジェクトにのみ関わるようです
104：名も無きチーター：2018/05/15(火) 02:07:14 ID:JTc0QdvE0: 検証ありがとうございます。とても助かります。
当方でも試したところ

修正案1 (追加フィールド無し)は、
- ルナ場内の Moonstone Crystal も徳之島船の船倉 cargo hold も認識しなかった

修正案2 と修正案3 (追加フィールドあり)は、
- 両方ともルナ場内の Moonstone Crystal を 0x9CBB ではなく 0x1CBB としてを認識した
- 両方とも徳之島船の船倉 cargo hold を 0x916F ではなく 0x116F として認識した
- ただ、ヘイブンの徳之島船の船倉は時々うまく検索にヒットしなかった

の結果となりました。94様とは修正案1 の結果が異なるようですが、修正案2 か 3 が無難かもです

別の検証で、pilow (緑地に金色のハート) は、バックパック内では 0x9E1D として認識しますが、
地面に置くと、0x1E1D として認識されます

この辺の違いも考慮してスクリプト書く必要がありそうです
理想は、爺本体のバイナリ書き換えたいですが大変そう…

あと、0x8000 を超えるモデルID については、当方でも画像を作りましたので参考まで

ttps://dotup.org/uploda/dotup.org1533922.jpg.html
ttps://dotup.org/uploda/dotup.org1533923.jpg.html
ttps://dotup.org/uploda/dotup.org1533924.jpg.html
105：名も無きチーター：2018/05/16(水) 02:08:03 ID:b/fPLQPA0: ZeazyUO.exe のバイナリ変更

66 25 FF 7F 66 89 43 0C 66 3D 06 20
でバイナリサーチすると(爺のバージョンによらず) 1ヶ所に絞れると思う
そこを下記のように書き換え (FF 7F を FF FF)
66 25 FF FF 66 89 43 0C 66 3D 06 20

意味は eax &= 0x7FFF を eax &= 0xFFFF に変更
この変更と uohook5.cpp ソースの修正案2 か 3 の変更とを合わせると
地面のアイテムも 0x8000 引いた値とならず、元のモデルID で認識されました

解析結果は別途あげるかも
ほんと、94様のおかけです
106：名も無きチーター：2018/05/20(日) 20:08:11 ID:dYAM8.eM0: >>105様によるZeazyUO.exe書換え情報のおかげで、
モデルIDの取得・判別はうまくいくようになりました。
ありがとうございます。

なお、パケットF6を受信してもZeazyがスルーしているため、
船の移動時に自身ないしは同乗しているオブジェクトの位置情報が
更新されないという不具合もあったりします。
ただこれはZzInfo.getXYFromMemoryをオンにしてやれば
追従してくれるので問題はなさそうです。
107：名も無きチーター：2018/05/23(水) 02:33:53 ID:mCrbBH6c0: 報告ありがとうございます。動いているようでよかったです。

F6 については爺もハンドリングしてませんし、uohook 側での対応も難しそうそうなので
>106 の対処法が良いように思います。

(船の座標が変わった後、サーバーからプレイヤーの座標更新パケットが来るわけではなく
パケットのやり取り無しに、クライアント内部でプレイヤーの座標を再計算しているぽい？)

(爺内の座標とクライアント内の座標がずれたときは、何でもいいのでパケット受信すれば、
同期される作りになっています。なので、open paperdoll とか open status とか適当に
送信するのでもいけそうですが、それより >106 の方法が簡単ですね)

話変わって、パケット 78 についても潜在的には 1A と同じ問題を抱えていて
装備品やペットで 0x8000 以上のモデルID の場合 0x8000 を引いた値で認識される気がします。

まあ、今は問題起きてないようなので、その時が来れば修正する感じですかね
108：名も無きチーター：2019/09/18(水) 17:12:59 ID:/PTDBW8w0: パケットを、使って直接ログインさせたいのですが、何か参考になる情報は無いでしょうか。

爺の公式が健在な頃に落としたスクリプトは、クライアント上でID PASを入力する方式でした。
色々思案してるのですが、解決できません。
109：名も無きチーター：2019/09/19(木) 01:24:00 ID:5jET.t2A0: C->S: 0x80: Account Login Request (Login Request)
S->C: 0xA8: Servers List (Game Server List)
C->S: 0xA0: Play Server (Select Server)
S->C: 0x8C: Play Server Accept (Connect To Game Server)

* ここまでの接続先IPはログインサーバー、次からの接続先IPはゲームサーバー

C->S: 0x91: Game Server Login
S->C: 0xA9: Characters List (Characters / Starting Locations)
C->S: 0x5D: Play Character (Login Character)

* C = Client, S = Server.
* 0x73 の Ping パケットが時々流れるらしい
* 下記リンク先を参考にしただけで、実際に試したわけではないので誤っている可能性があります
* Razor でパケット記録して観察するとよいと思います

ttps://sites.google.com/site/ultimaonlineoldpackets/protocol/login-server
ttps://sites.google.com/site/ultimaonlineoldpackets/protocol/game-server-login
110：名も無きチーター：2019/09/19(木) 14:26:28 ID:lgHvX2bM0: >>109
ありがとうございます。

頂いた情報を元に、トライして見ます。
111：＜垢ぼ～ん＞：＜垢ぼ～ん＞: ＜垢ぼ～ん＞
112：名も無きチーター：2024/07/27(土) 15:27:02 ID:OqWZykoc0: client.exe への dll injection に失敗している
SetWindowsHookEx のエラーコードは 1114
client.exe の逆汗が必要そう
外してたらごめんだけど、ホワイトリスト化されたのかも？

razor も動いていないんだっけ？（自分では未確認）
razor は、razor の子プロセスとして、client.exe を CreateProcess していて、client.exe の main() の前にフックしてたはずだから、少なくとも injection は出来てるはずなんだけど、自分では未確認

ちなみに、
ASLR と DEP は相変わらず無効
フックする code は code5 だけ重複があるため、変更が必要
113：名も無きチーター：2024/07/28(日) 13:37:16 ID:3MNCgHKU0: FL使えなくなってしまってるのね。残念だ。　
ZeazyUOの時代からのお知り合いで、FLカスタムしてくれていた方は
引退してしまったようで連絡つかなくなってるし。
IRCにも来なくなってるし、これからどうしよう。
めんどくなったなぁ。。
114：名も無きチーター：2024/07/28(日) 17:19:11 ID:VJYCjVuc0: なんとかして無理くり使ってる
115：名も無きチーター：2024/08/03(土) 21:01:26 ID:D/eHB7dQ0: NewLegacy
uohook5.dll を更新しました
https://ux.getuploader.com/uohook5/download/1

変更履歴
2024/08/03
* client.exe v7.0.104.0 の仕様変更に対応
　　* code5 が重複していたので一意になるよう変更
　　* code_pathfind を探すため探索範囲を拡大
* 制限事項
　　* Cliloc の仕様変更には未対応 (本来は uohook でははく ZeazyUO 側で対応すべきもの)
　　* これにより ZeazyUO 側では Cliloc から文字列を取得できなくなっている
　　* 制限事項の詳細は README.txt をみて下さい

pass: この投稿の1行目
md5 : d5b96be19c4694d2bcddf9b68666285c uohook5_20240803.zip

※ウィルスが検出されてダウンロード出来ない場合
Windows セキュリティを開き、複数の原因が列挙されているので、
それぞれ、「デバイスで許可」を選択してください
ダウンロード完了後に再度 Windows セキュリティを開き、
「脅威をブロックする」に戻して下さい

> SetWindowsHookEx のエラーコードは 1114
これは単に自分のバグでした
code5 と code_pathfind を修正したら dll injection は成功しました
逆汗して文字列検索した限りではホワイトリスト化は無さそう
116：名も無きチーター：2024/08/03(土) 21:02:24 ID:D/eHB7dQ0: ■制限事項
client.exe v7.0.104.0 (2024-07-26) において Cliloc の仕様変更がありました
このため ZzObjectDetail.display (det.display) が取得できなくなっています

■影響ありなもの
* メッセージを文字列として取得や比較している場合
* プロパティを文字列として取得や比較している場合
* 正規表現系は大部分が動作しないと思ってください

■影響無しなもの
* メッセージを MSGID として扱っている場合
* プロパティを det.display ではなく PID として扱っている場合
* 幸い ID 自体は変更無しのようなので、文字列としてではなく ID として扱っている場合は影響ありません
* ZzObjectInfo.name (obj.name) は影響無し (Cliloc ではなくパケットから取得しているため)
* 未確認ですがジャーナルも影響無し (Cliloc ではなくパケットから取得しているため)

■影響ありなコード
```javascript
det.display.match('undead slayer');
```
```javascript
det.id = find.find('be, m0x22c5'); // RuneBook
det.display.match('Trammel');
```
```javascript
det.id = find.find('m0x190, 0x191, np8'); // Human
det.display.match('banker');
```
```javascript
if (det.display.length == 0) return false;
```

■影響無しなコード
```javascript
find.find('d1060479'); // undead slayer
```
```javascript
det.id = find.find('be, m0x22c5'); // RuneBook
det.findText(0x105682).match('Trammel');
```
```javascript
det.id = find.find('m0x190, 0x191, np8'); // Human
det.items[0].text(2).match('banker'); // text(2) は職業の模様
```
```javascript
if (det.items[0].text(1).length == 0) return false; // text(1) は名前の模様. obj.name と同じ??
```

■対応方針
* プロパティは det.display の代わりに det.findText() で PID を指定する、
* もしくは PID が不明な場合は det.items[x].text(x) に変更する
* メッセージは、MSGID で扱っている場合は問題無し。文字列として扱っている場合は MSGID に変更する
117：名も無きチーター：2024/08/03(土) 22:02:09 ID:D/eHB7dQ0: ■ Cliloc の暗号化について
client.exe v7.0.104.0 から Cliloc ファイルが暗号化されました。
逆汗した限りでは単純な XOR 暗号ではありませんでした。

Cliloc_open_and_parse_sub_58E360 ファイルオープンと、復号化後のパース処理
↓
decode_Cliloc_sub_58E280 復号化の準備。ライブラリか独自クラスかは不明
↓
decode_Cliloc_sub_58DFB0 復号化の準備。ライブラリか独自クラスかは不明。key を作っているっぽいけど全く分からん。
↓
decode_Cliloc_sub_4289E7 実際の復号化処理。シャッフルみたいなことをしている

解析していて、Cliloc の復号化方法を求めるのは生産性が無いと判断しました
Cliloc が無くても動くように変更するのが現実的です
どうしても Cliloc を復号化したい場合は、

decode_Cliloc_sub_58E280() の中の memcpy(dst, src, len) をフックして
dst か src を len の長さ分メモリダンプする
これは元の Cliloc と同じフォーマット(パース前) です
118：名も無きチーター：2024/08/03(土) 22:45:47 ID:kUjYDkyw0: 解析お疲れ様です & 対応UOHOOK5作成と公開ありがとうございます。

長いこと家維持だけだったので自作スクリプトなどが動くかどうかアレですが、
これでちょっとがんばれる気がします。
119：名も無きチーター：2024/08/04(日) 16:21:31 ID:hgis5rJ.0: 新HOOK、ありがとうございます。
生産系で重宝しているので助かります。
120：名も無きチーター：2024/08/16(金) 13:21:04 ID:NnMbxbOY0: 本体がないのだ（しょぼん）
121：名も無きチーター：2024/08/16(金) 18:45:47 ID:mGxa2FRk0: Python
Python から uohook5.dll を呼び出すサンプルです
https://ux.getuploader.com/uohook5/download/2

公開するつもりはなかったのですが、恥ずかしながら自作スクリプトを晒します
作りかけなので動作未確認です。自分で修正できる人向けです

機能
1. UO クライアントのマクロキーを押すだけの擬似的な包帯マクロ
2. お金をルートする機能は、中身を修正すれば動くかも？

pass: この投稿の1行目
md5 : a2cc4ad3e7ef7fbf852ee5f8ce4b1e8a script.zip

欲しいのはそれじゃないんだよって方はごめんなさい
m(__)m
122：名も無きチーター：2024/08/16(金) 19:42:04 ID:mGxa2FRk0: 誰も興味ないだろうけどチラ裏日記

■ Cliloc の暗号化についてその2
OpenSSL の実装と比較してみたのですが、AES や DES とは異なるようです
恐らく独自の暗号化だと思われます

最初の 4 バイトがチェックサムとなっていて、
5 バイト目以降は、復号化の過程で何度も何度もローテーションされて、
最終的に、5 バイト目から 260 バイト目までの 256 バイト分を足すと、
最初の 4 バイトと同じ数字になる (正確には違うけどイメージはこう)
で、その 256 バイト分がキーっぽく動作して、シャッフルして、復号化が完了

みたいな、おおまかな流れは掴んだけど、逆汗コードを読んでも、
何してるかわからんかった
C++ は this ポインタが厄介過ぎて C より難易度跳ね上がる

■ ZeazyUO.exe のバイナリ変更
※ここからは未確認です。自己責任でお願いします。
※バイナリ書き換え前の exe を必ずバックアップしておいて下さい

ZeazyUO.exe をバイナリエディタで開いて、"cliloc" を文字列検索すると
1 箇所見つかります
ここを例えば、"clizzz" のように書き換えます (文字数は同じにすること)

暗号化される前の Cliloc を用意して、下記のようにファイル名を変更します
Cliloc.jpn → Clizzz.jpn
Cliloc.enu → Clizzz.enu

ExePath の指す場所 (通常はインストールフォルダ) にリネームした
Clizzz ファイルをコピーします

これで、ZeazyUO.exe が暗号化前の Clizzz を読み込んでくれるはずですが、
未確認です。

■レジストリの ExePath について
ZeazyUO.exe はこのパスから、 xxxxx.uop ファイルと Cliloc.xxx ファイルを読み込みます
なので全ての uop と Cliloc を別フォルダにコピーすれば、ExePath をその別フォルダに
変えても動くと思います。
通常は client.exe のインストールフォルダを指定しておくのが適切だと思います

※どれか一つでも足りないと ZeazyUO.exe がクラッシュします

Cliloc が暗号化されたってことは、NewLegacy をネタバレされたくなかった
んでしょうね (開発者の気持ちわかる)
123：名も無きチーター：2024/08/16(金) 21:11:23 ID:mGxa2FRk0: >>121
> 2. お金をルートする機能は、中身を修正すれば動くかも？

コードを見返したら、未実装だらけで詐欺もいいとこですね
棺桶が開くところまでは確認したっぽくて、その後は完全に未実装ですね

パケット 0x07 Pick Up Item
パケット 0x08 Drop Item
の送信処理 2つがまず未実装

アイテムを探すロジックを 3 種類ぐらい考えている途中で、力尽きたっぽい
参考にすらならなくてすみません
124：名も無きチーター：2024/08/18(日) 10:58:46 ID:8ka8a7HI0: >>115-123
対応uohook5を公開およびその他情報、ありがとうございます。
とりあえず爺&UOAとクライアントの組み合わせで無事起動しました。

とりあえず雑に触ってみたところ、謎な現象がありました。
game infoウィンドウで見るとplayerBackpackIdが0だったりバックパックIDの上半分だったりと妙な数値を示しておりました。
当初、パケットの仕様変更でずれが生じたかと思いましたが、0x78を見る限りそうでもないような？
爺.exeのバイナリ内テキストとClilocファイル名をClilokと書き換えただけなので、そこに何かしら原因があるかもしれませんが、可能性は低いと考えています。
調査の時間がとれずおま環か判断つかないのですが、一応ぶちまけときます。
125：名も無きチーター：2024/08/18(日) 11:36:32 ID:8ka8a7HI0: ついでといっては何ですが、失敗談。
同梱の.regファイルを参考にレジストリを書き換えたところ、クライアントパッチャーがそちらに当て始めてしまい、あやうく現形式での古いファイルをもっていかれるところでした。
なのでとりあえず、"CliPath"というキーを作成して爺.exeもバイナリ書き換えで対応しました。
(ということは"Cliloc"文字列の書き換えは不要?)
126：名も無きチーター：2024/08/18(日) 12:41:38 ID:DpzTUkM.0: どなたか暗号化前のcliloc.enuを頂けないでしょうか。。
127：名も無きチーター：2024/08/18(日) 19:56:20 ID:6ASaEgZ20: >>124
同梱の doc/basic_specification.txt
のファイル内に、バイナリの書き換え箇所を紹介しています。
公開している uohook は ZUO 側で、この 3 箇所を書き換え済み
なことが前提です。不親切ですみません。

この 3 箇所書き換えてもなお、挙動がおかしい場合は
再度教えて下さい

Cliloc については、
ファイル名を変更するのではなく、レジストリキーを変更する方法が良さそうですね
後者の方がクライアントへの影響が少なくてすみそうです
(後者は Cliloc.xxx のファイル名はそのままでよいです)

ただ、ClipPath には uop と Cliloc を全部コピーしておく
必要があります

>>126
FLCS のスレを見ると幸せになれると思います
128：名も無きチーター：2024/08/18(日) 22:14:48 ID:8ka8a7HI0: >>127
ご指摘いただいた箇所を参考に、バイナリの書き換えで正常動作するようになりました。
0x78がらみの2カ所は書き換えていなかったようです。
ドキュメントをよくヨナまかったせいです、ごめんなさい。
そして7,9,13についての対処法についての記述、ありがとうございます。

過去レスみたら7年前(?!)にこの話が・・・。