[NEED HELP] Newer version of libhoudini refuse to work

[hmtheboy154]

There is an issue with newer houdini, If I put them into BlissOS and then run an ARM app it will start freezing as soon as the app started to call its libraries, which prove that houdini is not working even though it said Initialized .

This issue can be found on 2 versions of houdini so far :

• hpe branch, houdini pulled from Google Play Games for PC image running Android 12
• wsa-13 branch, houdini pulled from Windows Subsystem for Android running Android 13

I started to notice the issue when I pulled houdini from some of the early WSA13 image, around that time Intel's Project Celadon has this change : https://github.com/projectceladon/device-androidia-mixins/commit/41fb55938e48f1d9515a6041b51a7123a570305f

I'm guessing that there's some sort of refactoring or a new change that make us can't be able to use it. If someone can help, I'll happy to provide more info.

[cnRrex]

Haven't find the code changes about it yet. In celadon source I can't find any other changes for houdini besides linkerconfig. Probably check for some houdini changes may help though. In previous versions, the houdini binary could output version information using --version. In the hpe branch, the houdini file also seems to contain some "Initialize Houdini(%s RELEASE)...". failed.\n" in the hex. Also, maybe take a look at the new houdini12, or the tencent-exclusive version (at https://sj.qq.com/, version: 12.0.1.z.Tencent_AoW_Com5.8). In this version, the houdini binary doesn't have "Usage: --version" in the hex, but you can output the version information in the adb terminal (very strange, may due to obfuscation). This version of libhoudini also has some changes in the exported symbols starting with _Maze_flags_start64. Houdini13 has changed a lot, the nb folder, libaeabi_map, and linker files are gone. libtcb in nb is now in the arm folder. The libs in the arm folder are no longer purely arm libraries, but some of them are now from the former nb folder (which only contains some of the exported symbols for calling svc instructions). Houdini binary became a few kilobytes in size and started to depend on libhoudini. Similarly to the new houdini12, both houdini and libhoudini libtcb have exported symbols starting with _Maze_flags_start64. And houdini binary have other usages, libhoudini has two modes: bin and android app. These changes may mean that we are missing some houdini configurations, and that the Android source code should also lack some patches from intel to support the new houdini.

[hmtheboy154]

Maze_flags_start_64

It's like they want to block us from using this. Like a DRM.....

btw houdini does allow you to run bin even in older version with the houdini program. Although in the later version with Android 13 houdini it's stay in a loop just like when running Android apps

[hmtheboy154]

Latest houdini for Android 12 right now is from HPE images (Google Play Games for PC). They also got the developer emulator and that thing has houdini too.

Houdini will activate if they detect that you are using an Intel CPU

Latest houdini for Android 13 is from ChromeOS, maybe WSA too if they have a new version

[cnRrex]

Well I've found so far that the Maze_flags symbols are just some compilation information.They don't have code inside, and are inserted in some specific locations (e.g. a flag with autoversion.c would be inserted after the start function). Some strings can be converted from hex to plaintext.

For exmaple in Houdini 13.0.0a_z.39188.g, there is a symbol's name:

_Maze_flags_start_64_7838365f36342d756e6b6e6f776e2d6c696e75782d616e64726f6964_256_2d6e6f2d6d7367626f783b2d736565643d33383734333932363b2d636f6e7374686964653b2d72656f70743b2d66636c6f6e653b2d6262667261676d656e746174696f6e3b2d6262636c6f6e653b2d6366672d696e6469726563743b2d626273687566666c653b2d6366672d6a756e6b3b2d7468726573686f6c643d302e353b_2f6c6f63616c6469736b2f486f7564696e6942696e6172792f54454d502f3078312e35326532353835306538626138702d332f74656d706f726172792f6c69627562745f736f5f7573657272656c656173655f7836342f486f7564696e695f31332e302e30612f7372632f736c2f616e64726f69642f696d706c2f66616b655f6d6170735f66696c652e6331363934343833363431

it can be converted to:

_ Maze_flags_start64 x86_64-unknown-linux-android 256 -no-msgbox;-seed=38743926;-consthide;-reopt;-fclone;-bbfragmentation;-bbclone;-cfg-indirect;-bbshuffle;-cfg-junk;-threshold=0.5; _ /localdisk/HoudiniBinary/TEMP/0x1.52e25850e8ba8p-3/temporary/libubt_so_userrelease_x64/Houdini_13.0.0a/src/sl/android/impl/fake_maps_file.c1694483641

But in addition, these versions of libhoudini.so contain two strange strings that appear in a jump table. They are _maze0423e8fbe5f668ec7c1dbff81b471805d and _maze274069114e73bddbb791766397fab3fea. The part after the underscore part is the md5 of the front part (maze0 or maze2).

By Checking houdini 11 or 12, Google versions does detect CPU (must be GenuineIntel) to initialize.

[hmtheboy154]

does it need some kind of libubt to continue ? If it does then I'll try to check new firmwares

[cnRrex]

does it need some kind of libubt to continue ? If it does then I'll try to check new firmwares

No I don't think you could find that. I think ubt is something like an abbreviation of userspace_binary_translation, a module of HoudiniBinary. And libraries like libhoudini, libtcb are parts of that.

Something noteworthy about this is that in libaeabi_map of houdini12.0.1_z.39041.g or other versions, there is a similar string: /localdisk/HoudiniBinary/TEMP/0x1.c809e6ab5bfd7p-1/temporary/houdini_elf_userrelease_x64/Houdini_12.0/src/sl/standalone/Gen/impl/aeabi_map.c

In libtcb of houdini12.0.1_z.39041.g particularly, a maze_flags symbol contains this path: /localdisk/HoudiniBinary/TEMP/0x1.c809e6ab5bfd7p-1/temporary/libubt_so_userrelease_x64/Houdini_12.0/src/ubt-ia/bt/autoversion_parse.c

[cnRrex]

I just hava a test on houdini13. houdini13 elf is no longer a standalone verison, and will freeze on other Android when running arm elf. I pull houdini, libhoudini.so, arm folder to a folder named test. Then I rename houdini to houdidi, libhoudini.so to libhoudidi.so. Rename the needed of houdidi, libhoudidi.so, libtcb.so, to let them load the renamed libhoudidi.so. Then I push "test" to /data/local/tmp in WSA. chmod 777 to them and export LD_LIBBRARY_PATH to make sure libhoudidi could be loaded. After that houdidi could output version correctly. I also push a arm elf of fastboot. This fastboot has no needed lib, and run well on arm Android. Then I run ./houdidi ./fastboot to see if it work. In WSA, 39168.m and 39190.m could run this fastboot and output usage while 39188.g couldn't.

[cnRrex]

I also test in Androws. In this A12 Tencent celadon vbox, arm fastboot output usage with 39188.g, and 39168.m couldn't.

[hmtheboy154]

Updated all the affected branch and also upload new ones like chromeos_hatch and chromeos_volteer which is also affected