DllMain of a packed 32-bit DLL never returns (100% CPU) under Hangover's wowbox64 — reproduced on box64 0.4.2, 0.4.5 and a Nov-2024 build

[deltapath-eric]

Summary

A packed/obfuscated 32-bit DLL never finishes DllMain(PROCESS_ATTACH) when running under
Hangover's box64 WoW64 backend (wowbox64.dll, box64cpu.dll in older Hangover). The thread
enters DllMain and never returns: ~100% CPU indefinitely, no further progress, no window.

It is not specific to Hangover: the same DLL also fails to initialize when box64 emulates a
complete x86_64 Wine (standalone box64 + Wine 11.0 with new-WoW64), which is a completely
different architecture. It reproduces across three box64 generations and also with the
interpreter (BOX64_DYNAREC=0), so I don't think it's codegen-only.

Environment

Device	MANGMI Air X handheld — Qualcomm SM6115 (Snapdragon 662: 4x Cortex-A73 + 4x A53)
GPU	Adreno 610, mesa 26.1.6 freedreno, GL 4.6 (device Vulkan is only 1.0)
OS	ROCKNIX 20260820 (LibreELEC-derived), kernel 7.1.2 aarch64, glibc 2.41
Page size	4096
Display	sway + Xwayland, Wine X11 driver

box64 versions tried, all via Hangover's prebuilt debian12_bookworm_arm64 tarballs:

Hangover	box64	backend DLL name	Result
9.22 (Nov 2024)	version not printed by that build	box64cpu.dll	hang, c000001d ILLEGAL_INSTRUCTION
11.9 (upstream, May 2026)	v0.4.2	wowbox64.dll	hang, c0000094 INT_DIVIDE_BY_ZERO, flags=1
11.16 (mikugirls fork, Aug 2026)	v0.4.5	wowbox64.dll	hang, c000001d ILLEGAL_INSTRUCTION at pc=0x100fe9d9c

Also fails with standalone box64 emulating a full x86_64 Wine

To rule out Hangover's WoW64 shim, I ran the same game on a completely different stack:
ROCKNIX's own x86_64 Wine 11.0 executed entirely under box64 0.4.4 (new-WoW64 handling the
32-bit game). 32-bit cmd.exe works fine through it, so the stack is sound.

relocating ephinea.dll dynamic base 10000000 -> 76dd0000
process_attach (L"ephinea.dll",00000000) - START
MODULE_InitDLL (76DD0000 L"ephinea.dll",PROCESS_ATTACH,00000000) - CALL
MODULE_InitDLL (76DD0000 L"ephinea.dll",PROCESS_DETACH,00000000) - CALL
warn:module:process_attach Initialization of L"ephinea.dll" failed

Exceptions in that run: c000001d ILLEGAL_INSTRUCTION, 80000004 EXCEPTION_SINGLE_STEP,
c0000005 ACCESS_VIOLATION.

Timing detail that may be diagnostic: DllMain spins at ~100% CPU for 1-2 minutes before
failing (at t+1m the DLL is still mapped, no failure logged, CPU 101%; by t+2m the process has
exited). That is the same box64 0.4.4 which, used as Hangover's WoW64 backend, hangs in
DllMain indefinitely (verified over 10 minutes). Same engine and same DLL, but a different
integration produces a different endgame — which to me suggests exception delivery and
continuation semantics rather than instruction translation, though I may be wrong.

The single-step exception is probably the most useful clue in this report. A single-step
means the trap flag was set (or INT 1 executed). Combined with the deliberate divide-by-zero
and the illegal instruction seen in other runs, this looks like exception/trap-flag based
obfuscation: the packer raises faults on purpose and resumes from its own SEH handlers. If
box64's TF emulation or exception-continuation semantics differ from hardware, that would
explain both the hang (handler never resumes) and the crashes (resumed with wrong state).

The DLL

ephinea.dll from the Ephinea PSOBB client (free download, see repro below). 12.6 MB, clearly
packed:

• a section named .banana (3.8 MB) plus several unnamed RWX sections
• prefers base 0x10000000, has DYNAMIC_BASE so Wine relocates it (0x73300000 /
  0x74820000 / 0x73270000 in different runs)
• Wine logs warn:module:alloc_module disabling no-exec because of L"ephinea.dll"

The host process is PsoBB.exe, a 32-bit PE which imports it.

What the failure looks like

trace:module:map_image_into_view relocating L"...\ephinea.dll" dynamic base 10000000 -> 73300000
warn:module:alloc_module disabling no-exec because of L"ephinea.dll"
trace:module:process_attach (L"ephinea.dll",00000000) - START
trace:module:MODULE_InitDLL (73300000 L"ephinea.dll",PROCESS_ATTACH,00000000) - CALL
trace:seh:dispatch_exception code=c0000094 (EXCEPTION_INT_DIVIDE_BY_ZERO) flags=1 addr=000000007A8CF894
   <no matching RETURN — ~100% CPU indefinitely>

The DLL is mapped (grep -c ephinea /proc/<pid>/maps = 1) but DllMain never completes.
Over a 10-minute run: 100% CPU on one thread, read_bytes advanced only ~11 KB, no window.

On box64 0.4.5 the exception becomes c000001d EXCEPTION_ILLEGAL_INSTRUCTION at
pc=0x100fe9d9c — above the 4 GB boundary, so not inside the DLL (mapped at 0x73270000).
If I'm reading that right it's in box64's own JIT region, but I may be misreading it.

Steps to reproduce

The client is a free download and the installer does not need to be run:

curl -O https://files.pioneer2.net/Ephinea_PSOBB_Installer.exe    # NSIS, ~855 MB
7z x Ephinea_PSOBB_Installer.exe -o/path/to/psobb
cd /path/to/psobb

export WINEPREFIX=~/.psobb-prefix
export WINEDLLOVERRIDES="mscoree=d;mshtml=d"
wine wineboot -u

# PSOBB only accepts 16-bit display modes; without this it exits before loading the DLL:
wine reg add 'HKCU\Software\Wine\X11 Driver' /v ScreenDepth /t REG_SZ /d 16 /f

HODLL=wowbox64.dll WINEDEBUG=+loaddll,+module,+seh \
  wine explorer /desktop=pso,1280x720 PsoBB.exe

Then watch for MODULE_InitDLL ... ephinea.dll ... PROCESS_ATTACH - CALL with no matching
return, and a process pinned at 100% CPU.

What I've ruled out

• Not codegen alone: BOX64_DYNAREC=0 (interpreter) hangs identically.
• Not dynarec tuning: BOX64_DYNAREC_SAFEFLAGS=2 BIGBLOCK=0 CALLRET=0 STRONGMEM=3 — still
  hangs. [BOX64] BOX64ENV: Variables overridden: confirms the variables were applied.
• No missing opcodes reported: BOX64_DYNAREC_MISSING=1 printed none.
• Not general 32-bit breakage: wine C:\windows\syswow64\cmd.exe /c echo hi works on all
  three versions, and the rest of this 32-bit game runs fine — it renders D3D8 through
  wined3d/GL, reaches its network login screen, and accepts input.
• Not the Windows version: winecfg /v win7 and /v winxp behave identically.
• Not fixed by newer box64: 0.4.2 -> 0.4.5 changes only the exception type.

Possibly relevant (second-hand)

The PSOBB community reports that standalone box64 0.2.6–0.2.9 boots this game under
Winlator (box64 + a full x86 Wine + box86), while newer versions do not:
https://www.pioneer2.net/community/threads/ephinea-pso-bb-natively-on-android-via-winlator.28655/

I have not verified that myself, and it's a different architecture from Hangover's WoW64 use of
box64, so it may be unrelated — but if it is the same underlying bug, that range might make it
bisectable.

Speculation, flagged as such

box64 0.4.2 reports the divide-by-zero with flags=1 (EXCEPTION_NONCONTINUABLE). Packers
commonly use exception-based control flow — raise a deliberate fault, catch it in SEH, resume —
so I wondered whether a continuable guest exception is reaching the handler as non-continuable,
which would explain a hang. I have not verified this, and 0.4.5's illegal-instruction symptom
doesn't fit it neatly.

FEX (Hangover's other backend) fails differently on the same DLL: EXCEPTION_ACCESS_VIOLATION
inside the DLL's own range, at a nearly identical address on two versions (0x779CD33C and
0x7790D33C), after which Wine logs Initialization of ephinea.dll failed and the app
continues without the DLL.

Happy to help

The device has SSH access and I can run any env vars, log levels, or patched builds and report
back. If there's a preferred way to capture a useful trace of the hang (BOX64_LOG=2, dynarec
dumps, etc.), tell me what would help most and I'll produce it. I can also try building a
minimal 32-bit PE that raises a continuable divide-by-zero, catches it in __try/__except and
resumes, if a small repro would be more useful than an 855 MB game.

[ptitSeb]

Thanks for the report, I'll check localy if I can reproduce the issue and debug the obfuscation.

[deltapath-eric]

Thanks! Two things that should make this much cheaper to look at.

Minimal repro: one DLL, one command — no game, no server, no account

The hang is entirely inside DllMain, so rundll32 is enough to trigger it. With only
ephinea.dll (12.6 MB) in an otherwise empty directory:

HODLL=wowbox64.dll WINEDEBUG=+module,+seh \
  wine C:\\windows\\syswow64\\rundll32.exe ephinea.dll,X

box64 backend — reproduces exactly as the game does:

trace:module:MODULE_InitDLL (... L"ephinea.dll",PROCESS_ATTACH,00000000) - CALL
trace:seh:dispatch_exception code=c0000094 (EXCEPTION_INT_DIVIDE_BY_ZERO) flags=1
   <no matching RETURN; process stays alive at ~90% CPU indefinitely>

FEX backend, for contrast: exits immediately with
warn:module:process_attach Initialization of L"ephinea.dll" failed and c0000005.

So none of the setup from my first post matters — no 16-bit ScreenDepth, no
explorer /desktop, no login, no PSOBB install. Please skip the 855 MB installer. The single
file is all that's needed, and it can be pulled out without running the installer:

7z x Ephinea_PSOBB_Installer.exe -o/tmp/psobb    # then just take ephinea.dll

box86 runs the same DLL correctly — possible reference to diff against

On the same device I also have a second stack: box86 v0.3.9 driving a 32-bit x86 Wine
(win32 prefix). There ephinea.dll initializes without complaint — the game reaches its title
screen showing EPHINEA SERVER CLIENT v1.861 and logs in successfully. So the DLL is runnable
under emulation, and the split falls along translation target rather than project:

engine	translation	result
box86 v0.3.9	x86-32 → ARM32	works
box64 0.4.2 / 0.4.4 / 0.4.5 / Nov-2024 build	x86-32 → ARM64	DllMain never returns
FEX (Hangover 2605 and 9.22-era)	x86-32 → ARM64	DllMain access-violates

Worth noting both box64 integrations fail: as Hangover's wowbox64 WoW64 backend, and as
standalone box64 emulating a complete x86_64 Wine 11.0 with new-WoW64 (32-bit cmd.exe works
fine in both, so the stacks themselves are sound). That's what makes me think it's the
32-bit-on-AArch64 path rather than either integration.

One more possibly useful detail: across configurations the exceptions were
INT_DIVIDE_BY_ZERO (with flags=1), ILLEGAL_INSTRUCTION, and EXCEPTION_SINGLE_STEP.
The single-step is what makes me suspect trap-flag-driven control flow — deliberate faults with
SEH resume — rather than a mistranslated instruction. BOX64_DYNAREC_MISSING=1 reports no
missing opcodes, and BOX64_DYNAREC=0 (interpreter) hangs the same way.

Device: SM6115 (4x Cortex-A73 + 4x A53), ROCKNIX 20260820, kernel 7.1.2 aarch64, glibc 2.41,
4 KB pages. Both the working box86 stack and the failing box64/FEX ones are installed side by
side, so I can A/B any env var, log level or test build on request.

[ptitSeb]

Ok, this is very verbose ticket, I suspect you use some AI to help with the redaction.
Anyway, I don't see any link to the download of the package.

from what I understand, if the program loaded in the early days of box64 and if it also works with box86, that means some of the later changes made so DRM games work better seemed to have broken something, somewhere. Either some Divide by 0 of TF flag behaviour. I need to download something so I can analyse (thanks for the minimum test, that might be usefull indeed).

[ptitSeb]

As far as I can tell, I think the issue is because some written code get a wrong address somehow, as highlighted in this picture

I assume this code is generated, or at least some address are changed. I need to understand when this address is written (also need to check if the address are constants)

[deltapath-eric]

Download: https://files.pioneer2.net/Ephinea_PSOBB_Installer.exe — 855 MB NSIS, 7z x extracts
it without installing. ephinea.dll is the only file the minimal repro needs.

One correction: I've never actually seen any box64 version work with this DLL. The
"older box64 works" idea is second-hand from Winlator users, on a different stack (standalone
box64 + a full x86 Wine) and about the game booting rather than this DLL initialising. Hangover
9.22 (Nov 2024 box64) fails here exactly like 0.4.5. So I wouldn't assume a recent regression.

I also just tried hangover 11.16 release (published yesterday: FEX 2608, Box64 v0.4.4, the fixed
vararg exit thunks). No change — box64 still never returns from DllMain (85.8% CPU, c000001d
at 0x100D7D834), FEX still fails at the same offset. Worth noting box64 v0.4.4 now fails
in both integrations I can test: as Hangover's WoW64 backend, and as standalone box64 emulating
a complete x86_64 Wine.

On your address question: Wine relocates the DLL every session — bases I've seen include
0x73300000, 0x764f0000, 0x76dd0000, 0x77a10000 — so nothing inside it can be a constant address.

Running rundll32 ephinea.dll,X repeatedly with just the DLL present:

• FEX: always c0000005 at a constant RVA 0x31AD33C, which sits inside the .banana
  section near its end. That offset is identical across FEX 2605 and 2608 and four different
  ASLR bases:

  build	base	fault	RVA
  Hangover 11.9 (FEX 2605)	0x74820000	0x779CD33C	0x31AD33C
  Hangover 11.16 fork	0x77a10000	0x7ABBD33C	0x31AD33C
  Hangover 11.16 upstream (FEX 2608)	0x779f0000	0x7AB9D33C	0x31AD33C

• box64: faults outside the DLL and differs per run — 0x100D9601C / 0x100D7D834
  (c000001d, above the 4 GB line so presumably your JIT region) and 0x7A8CF894 (c0000094).

So FEX dies at a fixed spot in the packed code while box64 ends up somewhere else entirely,
which fits your "written code gets a wrong address" hunch.

[ptitSeb]

I tried to use some older box64 version and I indeed never got it to run. I also failed to run the dll with box86, are you sure it's working there (the dll loading, not the full game)?

[deltapath-eric]

Good question, and my claim was looser than it should have been.

What I actually observed under box86 was the game working: PsoBB.exe loads ephinea.dll, the
title screen prints EPHINEA SERVER CLIENT v1.861, and login succeeds. I never tested a bare
rundll32 ephinea.dll,X there — so your box86 failure may be entirely consistent with my result,
since the packer may check which executable loaded it. I've since wiped that setup, so I can't
retest it quickly; if it matters I can rebuild it, but see below first, because I think I found
something more useful.

(If you do retry box86: in a win32 prefix rundll32 lives in system32, not syswow64.)

I suspected the load base rather than the emulator, and tested it — it's not that. My box86
setup used a win32 prefix where 0x10000000 is free, while every failing config here is
win64/WoW64 where wine relocates the DLL (bases logged: 0x73300000, 0x74820000, 0x764f0000,
0x76dd0000, 0x779f0000, 0x77a10000, 0x78410000). So I cleared
IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE (0x0040 -> 0x0000) on a copy to force the preferred base:

mapping PE file ...\ephinea.dll at 0x10000000-0x131b0000
Loaded module ...\ephinea.dll at 10000000      <- preferred base, not relocated
fault addr = 0x131AD33C                        -> RVA 0x31AD33C

Identical RVA, both with FEX and with box64 0.4.5-git. So relocation isn't involved — probably
not worth your time.

That makes RVA 0x31AD33C invariant across FEX 2605, FEX 2608, box64 0.4.5 (55083ea), and
eight different load bases including the preferred one. It sits inside the .banana section near
its end. Whatever the packer does at that offset looks like the actual problem.

My box86 config, for reference: box86 v0.3.9, a 32-bit x86 wine (wine-9.0-x86) from a winecellar
rather than the distro wine-11.0, win32 prefix on ext4,
BOX86_LD_LIBRARY_PATH=/usr/lib32:/usr/share/box86/lib. Scripts and notes:
https://github.com/deltapath-eric/pso_wine/tree/master/pso/rocknix

[deltapath-eric]

Rebuilt the box86 stack and tested both hosts. Two things, and the first one is a correction
that affects how you test.

1. rundll32 is not a valid host — my minimal repro can only show failure, never success.

host	box86 v0.3.9 + wine-9.0-x86, win32 prefix
rundll32 ephinea.dll,X	Initialization of L"ephinea.dll" failed
PsoBB.exe	succeeds: process_attach - END, no failure, then THREAD_ATTACH on 4 threads

So your box86 result was right and mine was measuring the wrong thing — the packer clearly checks
its host process and bails. Please use PsoBB.exe as the host, not rundll32. Pass/fail is
process_attach (L"ephinea.dll",00000000) - END without a preceding
Initialization of ... failed.

2. In the working run the DLL raises dozens of exceptions on purpose and survives them all.

box86 + PsoBB.exe, the configuration where DllMain succeeds, logged 263 exceptions:

96 x 40010006 (OutputDebugString)   95 x c000001d (illegal instruction)
55 x 6ba (wine RPC)                 45 x c0000094 (divide by zero)
13 x 80000003 (breakpoint)           4 x c0000027

So c000001d and c0000094 are the packer's normal control flow, not failures. It raises faults
and resumes from its own SEH handlers, repeatedly, during DllMain. Which suggests the problem
isn't the faulting instruction but the resume path.

The fault sites line up with that. Distinct in-DLL exception addresses in the working run
(base 0x76A20000):

RVA 0x9EEBDD, 0x2324707, 0x2324730, 0x2D04960, 0x2D05835

• 0x2324730 is one of them — and that is exactly where box64 v0.4.4 dies. box86 raises there
  and continues; box64 stops.
• 0x31AD33C is NOT in that list (zero hits). So when box64 0.4.5-git and FEX fault there,
  they've likely already diverged before reaching it — which fits your "some written code gets a
  wrong address" note better than anything I've suggested so far.

Also, box86 works with the DLL relocated (0x10000000 -> 0x76A20000), so relocation is
definitively not involved — that settles my earlier speculation in the negative.

Config, freshly rebuilt so it's reproducible: box86 v0.3.9, wine-9.0-x86 (Kron4ek build, not the
distro wine-11.0), win32 prefix, BOX86_LD_LIBRARY_PATH=/usr/lib32:/usr/share/box86/lib,
WINEDLLOVERRIDES=mscoree=d;mshtml=d. Scripts:
https://github.com/deltapath-eric/pso_wine/tree/master/pso/rocknix