iidx10: Game doesn't boot on XP-based machines #99

Closed icex2 closed 1 year ago

In GitLab by @konmai69 on Aug 4, 2022, 12:09

Summary

On Windows XP machines, IIDX 10th style will not boot with SQ-INIT error happening after elapsed time reaches 1200. This doesn't happen on Windows 10/11 machines.

Expected behavior

Should not happen, game boots.

Current behavior

Game gets stuck mostly on SQ-INIT error, although in rare cases the game will boot with no errors.

Detailed Description

This seems to be a bug with EZUSB security hook (EZUSB_SECURITY_MEM), when looking at the logs when the error happened, it always stops out a bit after "Reading security plug v1 white data".

Sometimes the game works; looking at the logs reveals that it should be reading the black dongle (security plug v1 black data) again instead of the white dongle. sq-init

Steps to reproduce

On Windows XP machines, run IIDX 10th style with Bemanitools. Configuration, default or not, doesn't matter since it has no effect on the SQ-INIT error.

Context (Environment)

Bemanitools version(s) affected

5.42 and older

Game(s) and version(s) affected

IIDX 10th style

Other games pre and post iidx10 tested and no issues there, e.g. iidx9, iidx17

Log output

Log file when game errors out at SQ-INIT error: sq-init_error_log.log
Log file when game is working: working_log.log

Configuration files

Stock configuration.

Command line arguments

Only enabled log output for diagnosing this issue

APIs used

Default eamio-keyboard and iidxio-keyboard APIs.

OS version

Windows XP Professional (SP3)

Hardware specs

Tested on two PCs.

PC 1
CPU: Athlon II X2 270
RAM: 4 GB
GPU: FirePro W5000, 2 GB
Controllers/IO: Keyboard
OS: Windows XP Professional, SP3
Bemanitools version: v5.37
PC 2
CPU: Core 2 Duo T5870
RAM: 1 GB
GPU: Intel GMA X3100, 384 MB
Controllers/IO: Keyboard
OS: Windows XP Professional, SP3
Bemanitools version: v5.42

Thanks for the detailed report. I think we had some report mentioning that in the past but haven't received further feedback or something. Can't find it anymore right now in the issues.

However, let me mention that iidx10 is in general very flaky if it comes to running on any hardware that is not the intended stock hardware for various reasons, see also https://dev.s-ul.net/djhackers/bemanitools/-/issues/52

I think one of the "mitigations" in the past was to simply try "re-starting the game a few times until it boots". The issue was definintely not deterministic and properly reproducable the last times I heard about this.

Can you test and report how consistent that error is for you?

What's definintely notable, though unclear regarding impact, the hardware specs of your PCs are fairly old. Knowing that the ezusb code is very poorly written with a lot of sleeps to enforce specific timing/fix timing issues on the original hardware, your "choice of hardware" might underline my assumption that the security code of iidx10 is just garbage and it is an unlucky situation. Actually comming up with a reasonable fix in bemanitools might be fairly difficult.

In GitLab by @JeffPaine on Oct 17, 2022, 21:19

Just to add to this, I patched out the SQ-INIT error for the OP and he reports it's still crashing. The log shows the error occurs when it tries to read the PCBID from the white dongle and gets "00000000000000000000" The game then bitches because the PCBID header is 00 instead of 01

In GitLab by @JeffPaine on Oct 19, 2022, 05:50

More information, this appears to be an issue with the ezusb hook. I successfully patched out all the USB I/O and security dongle errors for the OP but then both card r/w unit checks fail. Just for fun I tried patching the exe to skip the card r/w unit checks, it just crashes the game when he tries to card in.

Also I was able to recreate the USB I/O and security dongle errors on my end by malforming the dongle configuration in iidxhook-10.conf, but I was unable to recreate the card r/w unit failures, leading me to believe these were not caused by my patches.

In GitLab by @JeffPaine on Oct 19, 2022, 16:40

Actually maybe ignore the previous comment, OP reports that it's working fine now and the card r/w error only happened once

I'll edit this with hexedits later today for anyone else having this problem, but now OP is reporting another security error after the game over screen so I want to try to get around that first, I just don't have time at the moment

EDIT: I can't patch out the security error after game over, the game will just hang instead EDIT 2: Actually I can, see next comment

Anyways here's some hexedits to at least get it playable. Just make sure go into the test menu during the game over screen or the game will error out afterwards

bm2dx.exe (version JAE):

283E: 0F 85 A9 01 00 00 -> 90 90 90 90 90 90
28B6: 0F 84 -> 90 E9
2D73: 74 -> EB

ezusb.dll

8EF7: 74 13 -> 90 90

What this will do is:

Bypass the SQ-INIT error (first patch for bm2dx.exe)
This will then cause the game to fail trying to read the PCBID from the white dongle and getting only 00000000000000000000 in response rather than a proper PCBID. The patch for ezusb.dll will force the game to always read from the black dongle.
Now the game will error out with SECURITY No Match. The second patch for bm2dx.exe will take care of that.
Now you'll get NG(SECURITY) error, the last patch for bm2dx.exe will bypass that

In GitLab by @JeffPaine on Oct 20, 2022, 08:34

Arrgh, I hate to spam this issue but I fixed the final security error after the game over screen. Stupid oversight on my part that I just remembered I forgot to try

In bm2dx.exe:

DB4C: 74 0E -> 90 90
DB51: 0F 85 38 01 00 00 -> 90 90 90 90 90 90

This and the hexedits from the previous comment will get your 10th style running perfectly if you're having the same problem as the OP.

Thanks for the details. I guess these are helpful to mitigate those weird issues for anyone who is having them. The white dongle data reading '00000000000000000000' sounds weird and might be a start to debug this also in btools.

I am grateful to have this here as future documentation for whoever can pick this up at some point. I have been quite busy for a while and juggling different projects and responsibilities. So I cannot give you any ETA when I might pick this up. Any help regarding debugging and development work is appreciated and I am happy to support with knowledge and pointers as much as I can.

I was able to finally identify this issue as a data race caused by konami's non thread safe ezusb implementation + bemanitools incorrect configuration of security data. A detailed analysis and reasoning is provided in the ezusb dev journal entry dated to 2023-04-03 and is included in https://github.com/djhackersdev/bemanitools/pull/236

Fixes also included in PR and BT version 5.44. Considering this issue closed.,

djhackersdev / bemanitools