[REQUEST] ASUS TUF A15 FA506IV BIOS Unlock

[KnoxMe]

Hello KnoxMe,

Thank you for your continued patience with this! Hopefully soon you'll have access to not only the CBS Menu, but also the Chipset Menu.

I have prepared another mod for the Chipset Menu. This mod involves edits to the AMITSESetupData module that change the required access level for the chipset menu to "USER" instead of "DEFAULT". Let me know how this flash goes!


The rest of this post is an informational reference containing the details of the mod. You can skip over this if you wish or read it if you want to know what is going on behind the scenes.

0x19921 Form: Chipset, Form ID: 0x2713 {01 86 13 27 1E 00}

The last two bracketed bytes (1E 00) in the line above appear in AMISESetupData for each menu and sub-menu (these bytes will be different for different menus and sub-menus, of course). This line was taken from the IFR text given from Donovon6000's Universal IFR Extractor run on the Setup module extracted from the UEFI image using UEFITool.


1E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
04 00 00 00 00 00 00 00 01 00 01 00 31 00 00 00
01 00 00 00 02 00 00 00 04 00 01 00 66 07 00 00

The code segment above is 0x30 bytes long and occurs at offset 0x2120 in the extracted AMITSESetupData module. As you can see, "1E 00" are the first two bytes. This code segment corresponds to the Chipset Menu. The first byte in the third row "01" controls which access level is assigned to the menu/sub-menu defined by the first two bytes "1E 00" (in this case, the Chipset Menu).

"01" represents an access level of "Default". I think the "Default" access level is defined someplace elsewhere in the BIOS image. I'm not sure how to edit that, but that is unnecessary (in theory). We can change "01" to "05" to set the access level to "User", which I believe is the access level you have when you enter your BIOS Setup Utility.

Based on what shows up in the AMITSE and Setup modules I believe that, unless there is some lock hidden somewhere I haven't yet looked, this access level lock is the only thing hiding the Chipset Menu.

Report about the latest BIOS, Nothing being exposed again, just like a stock BIOS, do you need a dumped BIOS of flashed modded BIOS to check something?

[Sml6397]

That's a good idea, actually. Could you upload a dump of the modded BIOS? If the BIOS chip isn't being erased properly before the modded BIOS flash, then unerased regions could be skipped in programming.

[KnoxMe]

That's a good idea, actually. Could you upload a dump of the modded BIOS? If the BIOS chip isn't being erased properly before the modded BIOS flash, then unerased regions could be skipped in programming.

I would like to, but my crappy clipper doesn't allow it now. I can't get a good grip on chip now.

[KnoxMe]

That's a good idea, actually. Could you upload a dump of the modded BIOS? If the BIOS chip isn't being erased properly before the modded BIOS flash, then unerased regions could be skipped in programming.

Is there a command in AFUWin that allow unsecured BIOS (Modded) to be flashed?

[Sml6397]

I had this same issue. I eventually had to purchase the Pomona 5250 clip. It gets a really good connection to the chip every time in my experience and is the one BDMaster recommended to me. This is the one I purchased: https://www.amazon.com/CPT-063-Test-Clip...w?dchild=1&keywords=CPT-063+Test+Clip+SOIC8+Pomona+5250&qid=1624914166&s=industrial&sbo=RZvfv%2F%2FHxDF%2BO5021pAnSA%3D%3D&sr=1-3

You may be able to find it elsewhere for less or even with a neat ribbon cable already attached.

Note that you will either need to solder the old wires to the new clip or you will need to purchase 8 female-to-female jumper cables (I recommend 40+ cm). They often come in pack of 40, 80, or more. I didn't have the proper number of these cables, so I had to improvise, as can be seen in the attachment to this post.


Could you try getting a backup from AFUWIN or AFUDOS? This would work too and would allow me to verify that the flashes are working correctly (I imagine they are but you bring up a good point that would be nice to clarify).

Until then, I will go back to the drawing board. I may have to disassemble some of the modules and figure out what is happening. My experience with this is somewhat limited and I am not even sure if my Ghidra disassembler is configured correctly right now, so the next mod might take a little longer than the others.


--Reference info that you can skip over if you wish--

There are many repeated lists of the BIOS menu IDs in the AMITSE module. Maybe some of those lists are subject to certain checks that are elsewhere in the image that might disable certain menus. This differs from a lot of other AMI Aptio V images, however, as normally I would expect there to be one or more lists of exclusively disabled menus and one or more lists of exclusively enabled menus, not a bunch of copies of lists containing all menus... If by exploring the assembly language code I can figure out which of these lists are subject to checks - if any - I can simply remove the Form ID of the Chipset Menu from that list.

Here's an example of one such listing:
4A 10 59 7B 0D C0 58 41 87 FF F0 4D 63 96 A9 15 *11 27* 00 00 07 10 00 00
4A 10 59 7B 0D C0 58 41 87 FF F0 4D 63 96 A9 15 *12 27* 00 00 08 10 00 00
4A 10 59 7B 0D C0 58 41 87 FF F0 4D 63 96 A9 15 *13 27* 00 00 09 10 00 00
4A 10 59 7B 0D C0 58 41 87 FF F0 4D 63 96 A9 15 *15 27* 00 00 0A 10 00 00
4A 10 59 7B 0D C0 58 41 87 FF F0 4D 63 96 A9 15 *14 27* 00 00 0B 10 00 00
4A 10 59 7B 0D C0 58 41 87 FF F0 4D 63 96 A9 15 *16 27* 00 00 0C 10 00 00

11 27 = Main, 12 27 = Advanced, 13 37 = Chipset, 15 57 = Boot, 14 27 = Security, 16 27 = Save & Exit

Offsets that may be of interest to disassemble in AMITSE are 0x373B8 (starts with 11 27 - may be useful figuring out what visible menu code looks like) and 0xF02F5 (starts with 13 27 - might help figure out what the hidden Chipset menu code looks like).

[Sml6397]

That's a good idea, actually. Could you upload a dump of the modded BIOS? If the BIOS chip isn't being erased properly before the modded BIOS flash, then unerased regions could be skipped in programming.

Is there a command in AFUWin that allow unsecured BIOS (Modded) to be flashed?

Didn't see this post before my previous reply. This goes into territory I am less experienced in, but if you can try it and give me the error code, we may be able to remove flash locks in the way through RU.EFI. First try getting a backup though. That way we can verify that the hardware programmer is working properly (ie: it is erasing first then writing).

I cannot guarantee that an AFU flash will not result in a brick. The AFU flash would probably fail to even execute if the BIOS image is not in the right format. I'm not sure if your notebook expects BIOS updates to be delivered through an AMI Aptio Capsule yet.

With the SPI programmer, we can directly write to the chip, so we can write whatever we want to it as long as long as it is exactly 16MB.

[KnoxMe]

That's a good idea, actually. Could you upload a dump of the modded BIOS? If the BIOS chip isn't being erased properly before the modded BIOS flash, then unerased regions could be skipped in programming.

Is there a command in AFUWin that allow unsecured BIOS (Modded) to be flashed?

Didn't see this post before my previous reply. This goes into territory I am less experienced in, but if you can try it and give me the error code, we may be able to remove flash locks in the way through RU.EFI. First try getting a backup though. That way we can verify that the hardware programmer is working properly (ie: it is erasing first then writing).

I cannot guarantee that an AFU flash will not result in a brick. The AFU flash would probably fail to even execute if the BIOS image is not in the right format. I'm not sure if your notebook expects BIOS updates to be delivered through an AMI Aptio Capsule yet.

With the SPI programmer, we can directly write to the chip, so we can write whatever we want to it as long as long as it is exactly 16MB.

Finally, I use brute strength to keep the clipper on the chip (quite a pain). The file is uploaded in the google drive, file name is dxd.rom

[Sml6397]

Finally, I use brute strength to keep the clipper on the chip (quite a pain). The file is uploaded in the google drive, file name is dxd.rom

Thanks! I can say for sure that the SPI flash is working properly. This comparison allowed me to discover that there is only one module that changes between reboots (or at least between reboots with no OS re-installations or BIOS setting changes occurring). In this image, the GUID of this module is CEF5B9A3-476D-497F-9FDC-E98143E0422C. More importantly, the name of it is "NVAR Store". It looks like this might be the table that contains some or all of the UEFI variables that can be edited in RU.EFI to change settings without a BIOS mod (see the attachment). I still need to investigate this before I can say for sure that this module stores the UEFI variables. I will check this on my test machine at a later time.

Anyways, I will go back to the drawing board and see if I can get my disassembler working properly and then figure out what is going on in the image that could be hiding the Chipset Menu.

[Sml6397]

Here is a preview of the Chipset Menu to give you something to look forward to!

The left pane contains the sub-menus in the Chipset Menu. The right pane contains the settings just in the Graphics Configuration sub-menu.

[KnoxMe]

Finally, I use brute strength to keep the clipper on the chip (quite a pain). The file is uploaded in the google drive, file name is dxd.rom

Thanks! I can say for sure that the SPI flash is working properly. This comparison allowed me to discover that there is only one module that changes between reboots (or at least between reboots with no OS re-installations or BIOS setting changes occurring). In this image, the GUID of this module is CEF5B9A3-476D-497F-9FDC-E98143E0422C. More importantly, the name of it is "NVAR Store". It looks like this might be the table that contains some or all of the UEFI variables that can be edited in RU.EFI to change settings without a BIOS mod (see the attachment). I still need to investigate this before I can say for sure that this module stores the UEFI variables. I will check this on my test machine at a later time.

Anyways, I will go back to the drawing board and see if I can get my disassembler working properly and then figure out what is going on in the image that could be hiding the Chipset Menu.

Thanks, It'll be long for sure, for me to receive the Pomona clipper.

I've ordered one in Aliexpress.