Fix: patch every SSSE check site, not just the first

[ForUltraplayer]

Samsung Settings closes with "service is not working": SSSE binary patch is applied to only one of multiple check sites

Likely the root cause behind #51, #94 and #99.

Summary

Update-SSSEBinary locates every viable (Primary, Secondary) check-site pair in
SamsungSystemSupportEngine.exe, but then patches only the first one:

if ($viableCandidates.Count -gt 1) {
    $viableCandidates = $viableCandidates | Sort-Object { $_.Primary.Offset }
    Write-Host "    Multiple candidate windows found; using earliest match" -ForegroundColor Yellow
}

$target = $viableCandidates[0]   # <-- remaining candidates are silently dropped

SSSE 8.0.5.0 is the first build with two such sites. Every earlier version the
installer can reach has exactly one, which is why [0] was correct until now — and
why the bug appeared out of nowhere with the current $LATEST_SSSE_VERSION.

I extracted the binary from each CAB the installer downloads from the Microsoft
Update Catalog (Search.aspx?q=sam0428) and ran the script's own detector over it:

SSSE version	primary candidates	viable pairs	secondary span (window is 512)
6.1.8.0	1	1	365 B
6.3.3.0	1	1	365 B
7.1.2.0	1	1	378 B
8.0.5.0	2	2	361 B and 466 B

This also explains the workaround that has been circulating since #38 — "install
6.3.3.0 and stay there". It works because 6.3.3.0 has a single check site, so the
old code happens to patch all of it. Nothing about 6.3.3.0 is special beyond that.

Symptom

Samsung Settings opens, reports that the service is not working, and exits. Event log:

Faulting application name: SamsungSystemSupportEngine.exe, version: 8.0.5.0
Faulting module name: ucrtbase.dll, version: 10.0.26100.8875
Exception code: 0xc0000409          <- STATUS_STACK_BUFFER_OVERRUN / CRT fail-fast
Faulting application path: C:\GalaxyBook\SamsungSystemSupportEngine.exe

The installer reports success, so the install looks healthy: GBeSupportService is running,
the DriverStore entry is present, and the registry spoof is applied.

Evidence

Running the pre-fix and post-fix Update-SSSEBinary over an untouched 8.0.5.0
binary (md5 db6b9854dba3bc718d970cdb9ab3cc26, exactly what the Catalog serves):

	0x12CA4	0x12E15	0x68135	0x6830F	resulting md5
untouched	0F 85	75 24	0F 85	75 2D	db6b9854…
v3.1.5 output	48 E9	EB 24	0F 85	75 2D	95cd8b3d…
this PR's output	48 E9	EB 24	48 E9	EB 2D	9c986331…

Those two output hashes are not hypothetical. On the machine where I hit this,
95cd8b3d… is byte-for-byte what v3.1.5 left in C:\GalaxyBook (and in the
DriverStore) while Samsung Settings was crashing, and 9c986331… is the binary
sitting there now with Samsung Settings working. The only difference between the
crashing and the working binary is the second check site.

Both sites use the identical instruction shapes the existing detector already recognises
(0F 85 -> 48 E9, 75 -> EB, Pattern B), so no new pattern handling is required.

Fix

Commit 1 iterates over every viable candidate instead of taking [0]. The
per-site patch/skip logic is unchanged; it is just moved inside a foreach, and the
offset is added to the "already present" messages so partially patched binaries are
readable in the log.

Commit 2 addresses a related weakness found while verifying the first. A
secondary check was searched for within a hardcoded 512 bytes of its primary. Site 2
on 8.0.5.0 sits 466 bytes out — 46 bytes of margin. A modest layout change in a
future build would push it out of range, drop the site from $viableCandidates
before the loop ever sees it, and bring the crash back. The window is now 1024 bytes
and the scan stops at the next primary candidate, so a secondary can never be paired
across site boundaries. The magic numbers are named constants.

Commit 2 is behaviour-preserving: patching all four Catalog builds produces output
byte-identical to commit 1 (identical md5 for 6.1.8.0, 6.3.3.0, 7.1.2.0 and 8.0.5.0).

Verified on

• Install-GalaxyBookEnabler.ps1 v3.1.5, default install path
• SSSE 8.0.5.0 — the script's own $LATEST_SSSE_VERSION, so a default install
  reaches this binary without choosing anything unusual
• Also exercised against 6.1.8.0, 6.3.3.0 and 7.1.2.0 straight from the Catalog
• Device profile 960XGL (Galaxy Book4 Ultra), region KR
• Windows 11 26100, PowerShell 7.6.5
• Samsung Settings 8.0.13.0 paired with SSSE 8.0.5.0 opens normally after patching
  both sites, and the Buds auto-switch page (Galaxy Buds app -> Connection management
  -> Buds auto switch) is reachable

Note

The failure is not hardware dependent: the dropped candidate is decided purely by the
contents of the SSSE binary, so any install landing on 8.0.5.0 leaves the same site live.

Worth flagging for diagnosis: everything Update-SSSEBinary prints goes through
Write-Host, so Applied N patch(es) never reaches the install log. That is part of
why this went unexplained for so long — the logs attached to #94 and #99 could not
have shown it. I left that alone here to keep the diff focused, but it would be a
cheap improvement.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Patch every detected SSSE hardware-check site

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Patches every detected SSSE primary/secondary check-site pair instead of only the earliest.
• Sorts candidates deterministically and reports offsets for checks already patched.
• Prevents surviving hardware checks from crashing Samsung Settings on multi-site SSSE binaries.

Diagram

graph TD
  A["SSSE Binary"] --> B["Detect Sites"] --> C["Pair Checks"] --> D["Sort Pairs"] --> E{"Each Pair"}
  E -->|Next| F["Patch Missing Checks"] --> G["Report Offsets"]
  G -->|More| E
  G -->|Done| H["Write Binary"]

Loading

High-Level Assessment

Iterating over every detector-approved pair is the appropriate strategy because candidate validation already exists and each patch is independently idempotent. Expanding pattern matching or hard-coding version-specific offsets would add risk without addressing the actual candidate-selection defect.

Files changed (1) +21 / -20

Bug fix (1) +21 / -20

Install-GalaxyBookEnabler.ps1Patch all viable SSSE check-site pairs +21/-20

Patch all viable SSSE check-site pairs

• Sorts all viable SSSE candidates and applies the existing primary and secondary byte patches to each pair instead of selecting only the earliest. Logging now reports candidate counts and offsets for already-patched sites, improving diagnosis of partially patched binaries.

Install-GalaxyBookEnabler.ps1

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can ask Qodo to dismiss a finding you disagree with, with your reason on record

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[stevebrajesh9]

Hi I tried using your ps1 but I am still facing the same error

i selected book 4 ultra and fresh install am I missing something thanks....

i fixed it by using the 6.3.3.0 SSSE version which made settings work i am hesitant on trying to upgrade to 8.0.5.0 since that seems to have been the issue for me.....

[ForUltraplayer]

Thanks for testing, and good news — your 6.3.3.0 result actually fits this PR's
explanation exactly, so let me lay out what I found since you posted.

I pulled every SSSE build the installer can get from the Microsoft Update Catalog and
ran the script's own detector over each one:

SSSE version	hardware-check sites
6.1.8.0	1
6.3.3.0	1
7.1.2.0	1
8.0.5.0	2

The installer patches only the first site it finds. Up to 7.1.2.0 there is only one,
so that was always enough. 8.0.5.0 is the first build with two, and the second one
survives unpatched — which is what kills Samsung Settings. So "6.3.3.0 works" isn't a
coincidence or something about that version being better: it works because there is
only one site there for the old code to miss. Staying on it is a perfectly reasonable
place to stop.

Also, to clear one thing up: the "Book 4 Ultra" choice is a device profile and doesn't
select the SSSE version, so that wasn't the problem.

Which file did you actually run, though? The documented one-liner
(irm .../main/Install-GalaxyBookEnabler.ps1 | iex) always pulls main, and this fix
is only on the fix/patch-all-ssse-check-sites branch — not in main, not in any
release. And since the PR doesn't bump $SCRIPT_VERSION, both print "3.1.5", so even
the install log can't tell them apart. On top of that, everything the patch step prints
goes through Write-Host and never reaches the log at all. If you ran the one-liner,
what you saw is exactly the bug this PR describes rather than a counter-example to it.

For what it's worth, here is what the two code paths produce from an untouched 8.0.5.0
binary, read straight from the files:

	0x12CA4	0x12E15	0x68135	0x6830F
untouched	0F 85	75 24	0F 85	75 2D
v3.1.5 output	48 E9	EB 24	0F 85	75 2D
this branch's output	48 E9	EB 24	48 E9	EB 2D

The middle row is byte-for-byte what was sitting in C:\GalaxyBook on my machine while
Samsung Settings was crashing; the bottom row is what's there now with it working.

If you ever want to check an 8.0.5.0 install without reinstalling anything, this is
read-only:

$b = [IO.File]::ReadAllBytes('C:\GalaxyBook\SamsungSystemSupportEngine.exe')
foreach ($o in 0x12CA4,0x12E15,0x68135,0x6830F) { '{0:X6}: {1:X2} {2:X2}' -f $o,$b[$o],$b[$o+1] }

No need to touch your working setup on my account, though — I'm mainly trying to work
out whether anyone has actually run the patched code yet.

[stevebrajesh9]

So what i did is i went to your branch, and downloaded the ps1 which you had send for a commit and then I ran it.

./Install on it with bypass execution policy....

I tried a few times to make it work with 8.0 but I think I was messing it up somewhere until I decided to leave it at 6.3 I will try to get it to 8.0
thanks for letting me know....

I will test and let you know my outputs.

[Bananz0]

I think I'll just have to disable the 8.0.5.0 path for now. There's an issue that fixes this.

For now have a look at this:

My guess is that the issue lies in the registry settings rather than the driver files. After overwriting the Galaxy Book 3 configuration files, it worked normally, but as a result of the overwrite, unsupported hardware features were also displayed (battery settings, activated when the lid is opened).

After the SamsungSystemSupportService started running and I performed several reboots, the unsupported hardware features disappeared.

sfourswcomp15.inf_amd64_aa796d95102eb75d.zip
SamsungSettings.zip
SamsungSystemSupportService.zip

Originally posted by @Minpeach0501 in #51 (comment)