This repair will likely require a mod of some kind. Any information or advice/recommendations help. I do not have a repair shop anywhere nearby who can help me.
Yes this is my third post, a lot has changed, and I have more information that will hopefully allow for the full recovery of my laptop. I will provide everything I have at this point. This repair will likely require a mod of some kind.
Device Specs:
Model: ASUS G614JV-AS73
Serial: R6NRKD033360231
MFG Date: 2023-06
Intel i7-13650HX
RTX 4060 Mobile
UEFI flash: Winbond W25R256JV(EN) (link)
Table of Contents:
A. The bricking process
B. Description of symptoms
C. Attempts made
D. The request
E. Relevant Files
A.
The story: followed a bad guide from AI (lesson learned). The goal was to allow my arch linux install through secure boot in order to be able to have my dual boot setup work and also be able to play Valorant.
Steps
-
Cleared secure boot keys and put in setup mode in bios (UEFI, old habits)
-
Booted into Arch
ran:
3) sudo sbctl status
setup mode was enabled
-
sudo sbctl create-keys -
sudo sbctl enroll-keys -m -
rebooted
this is where everything died. I know now that I should have run:
sbctl status
to verify that sbctl was working
sbctl verify
to show what files I had that were unsigned
sbctl sign -s /boot/vmlinuz-linux
sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI
sbctl verify | sed -E 's|^.* (/.+) is not signed$|sbctl sign -s "\1"|e'
I have learned quite a bit not only about doing better research but about some of the things that could be causing this issue. For additional information see this link: (Arch Wiki: Unified Extensible Firmware Interface/Secure Boot)
section 3.1 has a warning:
“Warning Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the firmware settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware (OpROMs), that get executed during boot, are signed using Microsoft 3rd Party UEFI CA certificate or vendor certificates. This is the case in many Lenovo Thinkpad X, P and T series laptops which uses the Lenovo CA certificate to sign UEFI applications and firmware”
and there is also this:
“Note For some PCs, for example with a Framework laptop, it is recommended to also include the OEM firmware’s built-in certificates, if you want to retain the ability to upgrade the firmware and run others boot applications provided by OEM. In this case run instead: sbctl enroll-keys -m -f"
for ASUS it would probably be something different and not -f but regardless…
B.
So now here I am with a non posting non booting laptop. No logo, no display, Nothing. Remains on, fans spin, keyboard lights work. Drive light flashes occasionally when a drive is in.
C.
What I have tried:
Holding the power button for 40 seconds and all troubleshooting steps and combinations related to: battery connected/disconnected, AC adapter connected/disconnected, etc.
Leaving the laptop unplugged overnight
Hunting for jumper pads/a CMOS battery (there are none)
This is the point when I discovered this forum, realizing that even if I did find a CMOS clear, the secure boot keys are located in the NVRAM and may not be clearable in that way
So, I bought a CH431A programmer and a WSON8 pogo pin test tool and was able to successfully dump and verify the dump.
Next, I attempted using UEFI-Editor (link) following the documentation as closely as possible*. Attempted turning Secure boot off, and secure boot off and csm on. Followed by a wipe, blank check, flash, and verify using NeoProgrammer. This presented a different issue where the laptop would turn on, fans spin up, etc, and then shut down after about 65-70 seconds (i used a stopwatch multiple times, human error accounts for the variance). I reflashed the original bricked file and we are now back to the device remaining on with a black screen.
*UEFI-Editor asks that I use the Section_PE32_image_Setup_Setup.sct.0.0-en… file, but in my experience it could not display any data using that file and only using the .0.1 version.So here I am. In the meantime, I purchased another laptop (a later revision) which I hoped to use to fix this one and also so I am not without a laptop. The unfortunate situation is that upon dumping the new device’s flash with Intel FPT (FPTW64.exe -d donor_dump.bin), they are structured completely differently, so I can’t just replace the device specific information (MAC addresses, Serial Number, Windows activation, etc) from the old dump into the new dump, flash, and call it a day (well, maybe I could try that, but I’ve had some other issues as well).
The other issues: difficulty finding the device specific info on the bricked dump due to not being able to use offsets in the donor file to find the relevant info.
Here is what I have:
(Using HxD)
Serial Number in bricked file: Offset 010059B0C0
Serial Number in Donor file: Offset 0101FA50
MAC Addresses in Donor File:
MAC Addresses obtained via ipconfig /all and then ctrl + F in HxD
LAN: Offset 0101FE00 Line: FF FF F8 FF (10 7C 61 71 F5 D9) 7E 06 8A FF FF FF
Wi-Fi: Offset 01021560 Line: 01 06 00 03 14 03 0B 25 00 (F8 FE 5E 81 A8 B7) 00
At these offsets there is nothing resembling a MAC address, and as I mentioned the offset for the serial number is different as well
In an effort to be as informative as possible, the new laptop’s specs are:
Model: ASUS G614JV-AS74
Serial: S3NRKD000768119
MFG Date: 2024-03
Intel i7-13650HX
RTX 4060 Mobile
UEFI flash: unknown, loath to disassemble the new one right now (should be the same Winbond W25R256JV(EN) (link) ), the boardview I have should be for all of the G614JV models, but I can’t be sure. I can tell you that there isn’t a different support page on the ASUS site, but that may not mean much…
D.
So here I am. What next? Can someone please help me get this dang thing to post?
I was able to observe that the backup of the secure boot keys is located in the bricked dump, is there a way to move them to the active region?
Could the bricked bios be edited to reset to factory defaults?
Could information in the donor dump be used to somehow reconstruct the bricked dump?
Is there something else I could be missing?
I’m feeling in a little over my head with the hex editor so if someone could make the needed changes for me I would really appreciate it.
E.
Both BIOS dumps as well as the changes I attempted, maybe someone can catch a mistake or something: Proton Drive (everything zipped): Password: Win-Raid (if you would like the files shared a different way let me know, happy to oblige for peace of mind)
Thank you all in advance for your help. I may have made a stupid mistake but I am ready to do everything I can to fix it.
Edit by Fernando: Thread title shortened and customized