Frida runtime notes, summarized for helpers.

Environment:
- LDPlayer / Android emulator, device 127.0.0.1:5555.
- Package: com.huanmeng.zhanjian2.
- APK contains ARM64 libunity.so, but on this emulator it is executed through libhoudini.so.

Hooks tried:
- AssetBundle.LoadFromFileAsync_Internal
- AssetBundle.LoadFromFile_Internal
- AssetBundle.LoadFromMemoryAsync
- AssetBundle.LoadFromMemory_Internal
- AssetBundle.LoadFromStreamAsync
- AssetBundle.LoadFromStream
- AssetBundle.SetAssetBundleKey
- NativeLoadFromFileAsync / NativeLoadFromFile / NativeLoadFromMemory / NativeLoadFromStream
- Possible NativeSetKey around libunity offset 0x5a1cc4
- Possible VerifyUnity3dChina around libunity offset 0x5a0fac
- libtolua AES_set_encrypt_key / AES_set_decrypt_key / wrapper AES_SetEncryptKey / AES_SetDecryptKey
- libc open/open64/openat/fopen/fopen64/read/fread/memcpy/memmove and checked variants
- MemoryAccessMonitor on the in-memory "#$unity3dchina!@" string

Observed:
- File-open hooks work and show many .unity3d files loaded from /storage/emulated/0/Android/data/com.huanmeng.zhanjian2/files/.
- The string "#$unity3dchina!@" exists in mapped libunity.so. One run found it at runtime address 0x43a8cbf with libunity base 0x3164000.
- Memory access to the signature mostly comes from libhoudini.so or libc/string scanning noise, not a clean ARM64 libunity call path.
- Hooks placed at ARM64 libunity offsets can attach, but key/verify hooks did not capture a usable key on LDPlayer.
- data2.unity3d opens/read events were seen, but its local content starts with 68 6c 90 4d... and has no UnityFS/PK marker.
- Earlier PK/UnityFS captures attributed to data2 were later considered false positives caused by fd/FILE* reuse. After close/fclose tracking was fixed, no real data2 plaintext blob was captured.

Current interpretation:
- On this emulator, ARM64 native observation is distorted by Houdini. A real ARM64 Android device may make direct libunity hooks more useful, but it is not guaranteed that a key exists for the normal files, because most normal bundles parse after second-UnityFS stripping.
- The unresolved target is now the special data/data_cn/data_extra/data2 container or index format.

