yusuftok516.com my scratchpad

Bypassing the Hardware Lock in the Samsung Phone App via Reverse Engineering

5 may 2026

Ethical warning: Reverse engineering and patching can cross ethical boundaries depending on the purpose, but what I describe here is absolutely ethical in my opinion. If I buy that fucking phone, I should be able to access its app, without restrictions. Sly Samsung thinks it can trap me in its ecosystem with digital fences. đź‘Ž

OEM restrictions (hardware locks) that only allow software to run on specific hardware are one of the most entertaining puzzles in the reverse engineering world. In this article, I will examine step-by-step the long and instructive adventure I embarked on to run the Samsung Phone application—which is normally exclusive to "Galaxy Book" devices—on a standard Windows computer (an Asus laptop in my case), the misconceptions I fell into, and the ultimate solution.


Stage 1: Initial Assumptions and the Superficial Spoofing Fallacy

At first, I thought the problem was simple. Many applications in the Windows ecosystem look at superficial text (string) values in the Windows Registry (HKLM\HARDWARE\DESCRIPTION\System\BIOS) to determine the device manufacturer.

To trick the app, I used a simple .bat script (galaxybook_mask) that would change the SystemManufacturer and SystemProductName values to "SAMSUNG ELECTRONICS CO., LTD.". The result? Disappointment. The application didn't even react.


Stage 2: Digging Deeper and the WMI/SMBIOS War

When the Registry didn't work, I assumed the app was querying the SMBIOS tables directly via WMI (Windows Management Instrumentation) at a deeper level.

To bypass this, I introduced a Spoofer running at the EFI Bootloader level (even before Ring 0). I patched the random spoofing EFI project from the https://github.com/Acrozi/SmbiosChanger project (likely used by people banned in Valorant) by hardcoding it to return 'Samsung' instead of random values. As the device booted, I intercepted the Type 1 and Type 2 (BaseBoard) SMBIOS tables in RAM and patched my Asus hardware identity to Samsung at the hardware level. When I ran WMI queries via PowerShell, the system perfectly mimicked a "Galaxy Book".

However, the application still wouldn't open. Why? Because the app might have been looking at raw ACPI tables or specific OEM embedded controller (EC) certificates beyond WMI. Messing with guesswork and hardware tables was dragging me into a massive rabbit hole. I stopped trying to trick the system and decided to patch the application itself.



Stage 3: Dropping the Sledgehammer and Grabbing the Scalpel (Discovering Electron and Binary Patching)

When I attached to the .exe file with x64dbg to figure out the app's logic, the rules of the game completely changed. I wasn't facing a monolithic block of code compiled in C++, but an Electron application packaged inside an app.asar.

The main source where the app asked "Is this device a Samsung?" was the ui/static/js/main.a78fc6c1.js file, which manages the interface (Renderer) process. Upon inspecting the file, I found the hardware validation blocks (if statements) throwing the This device is not supported model and Model Not Supported errors.

At first, I tried the standard method of unpacking the app.asar archive with asar extract, patching the code, and then repacking it. But this method increased the file size and corrupted the references to the .unpacked native modules (like .dlls) inside the app, causing it to crash. Furthermore, the massive JSON directory at the very beginning of the app.asar file, which holds the size and starting address (offset) of each file, was getting corrupted.

Consequently, I developed the "Binary Patching" (Byte-Level Patching) technique. Without unpacking/packing the archive at all, I intervened directly inside the app.asar over memory using a custom Node.js script. To avoid breaking the file's original JSON offsets, I added spaces to the end of the code blocks I modified to keep them at the exact same length (byte size).

Here is the Binary Patch where I bypassed the hardware check in the interface:

// BEFORE (42 Characters) - Original hardware check
if(r=e.sent,!(0,ke.V)(r)){e.next=16;break}

// AFTER (42 Characters) - Validation bypassed, missing bytes balanced with spaces
if(r=e.sent,!0){e.next=16;break}

Thanks to this elegant intervention, the size and internal structure of the massive 83 MB app.asar file didn't change by a single byte; only the answer to the "Is it a Samsung?" question in the app's mind became true forever.


Stage 4: Hitting the AppX Integrity Barrier

When I put the patched file in place and ran the application, Windows harshly intervened. Microsoft Store (AppX/MSIX) applications are cryptographically signed with AppxBlockMap.xml and AppxSignature.p7x files. Even if a single byte changes (even if I keep the content the same size, the hash changes), the integrity test fails, and Windows kills the process instantly.

To overcome this barrier, I switched to "Developer Mode". I moved the application folder out of the locked WindowsApps directory into my own workspace, deleted the signature files, and cleanly registered my patched manifest to the system via PowerShell (Add-AppxPackage -Register).

Stage 5: The Final Bosses - DRM and Defense in Depth

The integrity test was passed, and the app was opening, but a few seconds later, it was either force-redirecting me to the Microsoft Store or flashing the "This device isn't supported" error in the middle of the screen again. I was facing two new barriers:

  1. Entitlement (License/DRM) Check: The developers had designed a brilliant "Defense in Depth". If the hardware check was bypassed, the application would look for an official Samsung Phone ownership license (token) attached to the Microsoft account in the background. When it couldn't find one, it forced me to download the original version by redirecting me to the Microsoft Store (via the ms-windows-store:// URI), thereby overwriting and deleting my patch all by itself!

  2. Main Process Validation: I had patched the process rendering the interface (main.a78fc6c1.js), but the dist/electron/src/hardware.js file inside the Main Process—the heart of the application—was still triggering the MS Store redirect.

I drew my Binary Patching weapon once again. I found the functions triggering the store redirection inside hardware.js, such as activationUri, redirectSamsungAccountMSStore, and redirectSamsungPhoneMSStore. I patched the function opening the MS Store so that it would return successfully without doing anything (again, staying loyal to the exact byte count):

The Binary Patch that Silenced the Store Redirect:

// BEFORE (69 Characters) - Original Store Redirect Trigger
return[0x4,electron_1[_0x45a5f4(0xd4)][_0x45a5f4(0x96)](_0x41d4fd)];

// AFTER (69 Characters) - Operation returns successfully (Padded with spaces)
return[0x4,true];

With this final patch, I completely hollowed out the functions performing the license check. The application was now fully convinced that it was running on a Samsung device and possessed the original store license.