AFAIK there is not a big difference between Intel 8- and 9-Series Chipsets regarding the NVMe support capability, but neverteless the mainboard manufacturers only put the required module into the BIOS of 9-Series mainboards. So I think, that you can use any NVMe module you find within an Intel Z97 chipset mainbord BIOS.
Interesting. It seems that there is no NVMe 8-Series BIOS out there. So i think we can’t do much about it for now.
I managed to flash the BIOS with another version of AFUWINx64 (4.05.04) and the /GAN option. I changed the Setup and SonySetupCallback module with no change at all. After flashing my keyboard and the touchpad driver wouldn’t work anymore as expected… but hey… the flash seems to be successful ^^ I am going to use AMIBCP as a next step…
I also have one question that really bugs me: In every tutorial out there everybody says to use a dumped BIOS. Why not use a vanilla one?
Why not? The fact, that the mainboard manufacturer do not put the required modules into 8-Series Chipset BIOSes, does not mean, that the same module will not work with these boards. The only difference may be, that the user has to insert the module(s) himself.
@e.v.o I have the USA Model, and yes it came with a Samsung SSD from Factory. Just not sure why the new replacement SSD is being recognized. I will keep checking in to see your progress.
This is a very good link I will try this out to see if it gives me what I need without changing the modules.
See one of my latest posts: I did everything in this article and it didn’t change anything. But feel free to do so, maybe you have more luck
I also changed my AMITSE module this night and flashed it (so Setup, SonySetupCallback and AMITSE module were changed). Also with no change visible change inside the BIOS. I used AMIBCP to set the root nodes to USER, extracted the module with UEFITool and reinserted it with UEFITool into a freshly backuped BIOS.
Now i really don’t know what else to do. Any Suggestions?
— Maybe resetting the EC would help. But how to achieve this without opening the laptop? Sony uses the /ECX switch (which is undocumented…) with their afuwin tool to achieve this. But this won’t work with /GAN i think…
There is more than one way to lock/unlock the settings. The top level solution is to use the form table and target individual tabs. This can only be changed from that table alone, not even AMIBCP can help. Lower than this is to lock specific options by setting the visibility to hidden for normal user. This can be changed with AMIBCP. The last (that I know of, there may be more) is to lock options only under specific conditions, by using “Suppress If” statements. This can be changed by nullifying the condition.
All three methods have been successfully used on this thread, with unlocking done here and here. AMITSE should be used for porting the changes done with AMIBCP, while Setup[…] should be used for altering the formset table and changing IFR statements. For changing statements you can look into Donovan’s guide, with opcodes examples in his tool → EFI.h and UEFI.h. Even if his example is for Insyde, the idea is the same, as it is still based on EFI/UEFI specs.
The main problem with this unlocking is that it opens the door to dangerous settings, bricks happen all the time for this reason. When you know your hard work will be met with a nice brick because the user changed something just to see what it does, or that it bugs you with silly questions, then you learn your lesson not to help in such cases. Unlike those users you seem to know a few things and you actually try to learn and use the unlocking for good uses. Maybe you will find something useful in the mentioned thread and guide.
Qualified questions never disturb, but absolut unneeded questions do (example: >this< thread). Note: This Forum has meanwhile nearly 4.000 members (99% of them are just "leechers", only a very few are "seeders") and the time, which the Forum experts are able and willing to spend for answering questions from a single Forum member, is absolutely limited.
Hoping for your understanding Dieter (alias Fernando)
Thanks for your answer and again thanks everyone for the help.
I am very aware of bricking my laptop, thanks for the advice. I hope that everyone else is also aware of it…
Here is what i did already: - The IFR extract shows absolutly no sign of any condition to supress any tabs or settings expect the normal conditions (like when there are options that refer to another setting when enabled/disabled) - AMITSE is changed with AMIBCP and replaced: No change - Setup module (01010101…) replaced: No Change - SonySetupCallback (0000000001010101…) replaced: No change
I check every change i make against a vanilla module to understand how exactely it works. So if you a handle to USER/etc. with AMIBCP one of the following gets set:
1 2 3 4 5 6 7 8 9 10
Access/Use Show -------------------- 00 Default No 01 Default Yes 02 Ext. User No 03 Ext. User Yes 04 User No 05 User Yes 06 Supervisor No 07 Supervisor Yes
Which possible alternatives are there to get the settings unlocked? (Sony is a real bastard when it comes to configuring hardware...)
This is really frustrating and the only option left is to rip everything apart with IDA :(
This what I see in your laptop. There are 6 AMI tabs and 5 Sony ones. The AMI ones are loaded in Setup at offset 0xDFD0 (without ffs header) and are all set to visible. The Sony ones are called in SonySetupCallback at offset 0x57B0 and are all set to visible. So there doesn’t seem to be a lock in here, unless it is a different type of lock. If you process the Setup(s) with IFR Extractor and compare the two of them by ignoring the offsets, you can see that they are identical, with Sony just adding/changing a few options. This can also be seen in AMIBCP, the Sony options are just complementary. The Recovery tab is provided by ReFlash module.
The questions are these: - what tabs do you see in your UEFI menu and in what order? - what settings seem to prevail? Are the AMI ones, the Sony ones, or a mix? - what exactly have you changed with AMIBCP or hex editor, in what order and how you repacked the file?
I know you answered these questions, but I would like a clear response to each one and an appropriate amount of details.
Perfect. You found excatly the same. This is good news. Thanks.
Main | Advanced | Security | Boot | Exit
Mixed: All SonySetup tabs expect the Security tab which is replaced with the Setup ones. My information is based on this: The SonySetup Security tab is empty according to AMIBCP (everything is filled with handle FFFF).
- AMITSE changes: Open backup ROM with AMIBCP. Set first six tabs and "Recovery" to User. Save. Open ROM with UEFITool. Extract section FE612B72-203C-47B1-8560-A66D946EB371 (AMITSE module). Open fresh backup ROM. Replace body of section FE612B72-203C-47B1-8560-A66D946EB371 with modded one. Save. Flash.
Two things you did wrong. Actually you did everything wrong, but I’m trying to lay it out the easy way.
- The first one was that you followed that tutorial without investigating on your own. If you know how to use IDA, than it would have taken <1 minute to see where the formset is checked. Once again, the boolean values start at the offsets I told you. Just extract the body of the PE32 section in both Setup and and go to the mentioned offsets or even open them in IDA. All bits are already set to true, what you changed is at best relevant, if not worse. - The second thing is that you replaced an entirely different section. Have you even compared the checksum before and after, just to blindly check if it is changed? You either replace AMITSE all together or you change the PE32 section. The PE32 section is the key, it stores the executable part. - not a mistake, but a failure to communicate. When I say tabs, I mean the 6/5 tabs. When I say settings/options, I mean the individual lines bellow each tab. So my question was, do you see the settings from each Setup combined under the same parent tab, do you see a tab that has only settings from one Setup, do you see something else?
Other notes: the chipset tab should have been visible - if AMIBCP doesn’t bring it to life, the locking code is other that the 3 mentioned, so it needs further investigation; the second observation is that you don’t necessarily get all the settings once you unlock a tab. You still need to use AMIBCP or hex edit the IFR statements to show the missing ones. But take it one action at a time: first leave Setup as default, second change tabs to user with AMIBCP and replace body of PE32 under AMITSE (this process is needed to avoid any corruption from AMIBCP), third action is to unlock individual settings.
In the guide from MDL his BIOS shows only the first items and that the last ones are not visibile. In my case it’s the opposite. I found the exact same offset you said and thought to myself: if everything from this point is set to visible and IFR tells me that the not visible tabs are before this offset then i just have to 01 them. It all made sense to me: there were 01 were they should have been and there were 00 before them. What simply makes no sense was to change the setup module… was a bit late the last days…
When i take a vanilla BIOS, change only one setting to User, then extract the changed AMITSE there are only two bytes changed: One in the ffs header (right before the pe32 section begins, so it’s the checksum) and one from 01 to 05. Since nothing happens inside the PE32 section there was no need to extract the whole part as UEFITool updates the checksum.
Was my vault since i mixed it up but thanks for clarification.
I only see settings from the Sony Setup under each parent tab. My guess that the security tab gets shown from the setup module was wrong.
You seem to make the wrong assumptions. Let me clear some of them. AMIBCP shows you ALL the available tabs+options, not necessarily what you should see. For this reason you have the Recovery tab, which probably appears as a separate screen/menu when you press a key or a combination of keys. For this reason you have multiple tabs with the same name, which you should never see in your BIOS, unless something went wrong. AMIBCP takes Setup and displays its tabs and settings, takes SonySetupCallback and does the same, takes ReFlash and displays Recovery tab and its settings. I repeat, you should never see all these tabs unless you or Sony break something. In your case Sony has hijacked AMI tabs and settings. I don’t know if they are abusing AMICallback or if this was the original intention of AMI, to let OEMs wreck as they please, but Sony pretty much butchered your menu. But you should also note that AMI is offering the same set of settings in its sources, so hiding some settings it is not only acceptable, but actually needed to prevent non-working or dangerous settings.
For your Sony (or any AMI based machine), you just take what tabs you see in your BIOS and pair them with a boolean value (01 = True) in the order as they appear. Then you use IFR Extractor on Setup and do the same with those tabs. The last thing is to match the two lists and add the missing items to the first list as False or 00, change in second list the missing tabs to 00. “But I have them in the wrong order!” you might say. It doesn’t matter, AMI is (always) using the order you see in Setup and every tab has a handler and/or a GUID to be referenced latter in any order OEM pleases. I would say 99% that the second array is the one to be searched in Setup, but you still have the chance to search for the first array if the second is not found. Even more than that, you can search for hex string EE2E2071535FD940AB3D9E0C26D96657 in Setup (not sure if all APTIO 4 have the same!) and the 8 bytes before it are the tabs, with the last two being null or reserved. But push this further, you can open Setup in IDA and go to the offsets you suspect are the tabs.
Edit: This doesn’t fully apply to your BIOS, simply because Sony replaced the AMI tabs with tabs from SonySetupCallback. But nothing stops you from playing with the bits in Setup and SonySetupCallback, just to see how the tabs are hidden/displayed.
Second error/confusion is the AMITSE ffs file. The GUID B1DA0ADF-4F77-4070-A88E-BFFE1C60529A is the AMITSE module and what you see bellow it as leafs are its sections. This is marked in UEFITool -> Type tab. If UEFITool is confusing (forgive me for saying this, but it could be confusing only for those who do not know about UEFI basic specs), than search AMITSE in MMTool. What AMIBCP is changing is in the AMITSE file and in the PE32 section of this file. Do this simple test: extract the sections from original AMITSE, change some settings with AMIBCP and save, extract the same sections from modded AMITSE, compare. What sections have changed? Whether I’m right or wrong, you should either replace AMITSE entirely, or at least compare the sections before replacing them.
I hope I didn’t made it more confusing than it was. For your laptop, if the AMI settings are gone, then Sony simply replaced the settings using AMICallback function, not hide them. You can try to unhide the AMI ones with AMIBCP, but I have a suspicion it would do no good. You are faced with a one way road from here on, every solution is dangerous. You could remove SonySetupCallback, but maybe your machine won’t boot or won’t display the menu anymore. You could replace the handler/GUID of Sony tabs with the AMI ones, but maybe your laptop will explode. If you want a small degree of safety, you should disassemble both Setup files + AMITSE to see how you can prevent the Sony tabs from loading. To have all the settings and all the tabs (if it is even possible), you must disassemble the files and also have a strong knowledge about UEFI, at the very least about HII specification.
I’m sorry to say this, but I can’t follow this road with you. I know it means a lot to you, but it just doesn’t justify my time. Hope you understand and don’t think I’m trying to squeeze a reward from you. If I can help with little advices, sure, but I have no attraction for diving into disassembly for this issue.
I thought about the same since yesterday and i also think the only way to go is to fire up IDA and completely understand how Sony is abusing the BIOS. Have you seen anything like this ever before? The only thing that makes sense after making all those changes was one of my first guesses: as the name implies AMITSE loads Setup which itself loads SonySetupCallback (^^) via a Callback function that overwrites the original Setup.
Regarding AMITSE and comparing the changes: Already did this. Only changes that take place are the checksum (for the complete ffs module, so this is before the pe32 section even begins) and the settings that declare for whom it’s visible (User, Default, etc.). Just read my answer above.
If i could get this thing unlocked then this method could be used on all other Aptio based SV-Series laptops from Sony. I really hope to achieve this.
I haven’t seen such a tedious work to slash and replace the options, but on the other hand, I don’t unlock menus all day. It might be a Sony thing, because I haven’t seen this in Asus.
You were right about AMITSE. I was sure the change is in PE32, as comparing the original and modded AMITSE resulted in the changing being at around 3xxx or 4xxx offset and I thought it is a enough proof without further comparing the sections. But I must have compared something else or I missed a digit, because when trying to prove my point I ended up with this.
This is why you should either work with the whole ffs file or compare the before and after result. A mental calculation and assumption can sometimes smash into the wall of reality. I apologize for not testing this before writing.
If you sum up the actions, we have this: - the tabs are already visible, but even if I was wrong again (unlikely, triple checked with array, hex string and IDA), you also tested your theory with all 11 bits. - using AMIBCP is a dead end. But if I may say so, the tabs are already visible (minus Chipset), so you should have used AMIBCP on individual settings from AMI tabs not present in Sony tabs and not preceded by "Suppress If". Most likely a useless change, as Sony replaced the tabs and not the settings.
Whatever you do from here on, check the result with AMIBCP before flashing. For instance, I quickly checked with removing Setup, removing SonySetupCallback, replacing its body with body of Setup, changing tabs handler/GUID, changing AMICallBack GUID, replacing Sony new tabs with AMI tabs etc… AMIBCP always shows the same tree for tabs and settings, with empty lines where the settings are unavailable. Even after removing both Setup it will still present the same tree, full empty this time. Although it was a quick test and maybe I have made some mistakes when replacing, this shows that the general structure is already decided in AMITSE (?) and the Setup(s) only provide the filling. You said that the visible Security tab is the AMI one, as the Sony one is unavailable for some reason, as demonstrated by AMIBCP. The funny thing is that the Security Tab is present in Sony tabs, as seen in IFR Extractor. This can also be checked by switching the body of Setup and SonySetupCallback, the Sony Security tab re-appears as it should. This is probably a Sony mistake, but can be used to deduce the following: if a Sony tab is unavailable, an AMI one is used.
To summarize: if you want the easy and dangerous way, remove SonySetupCallback or replace Sony tabs with AMI tabs, just to make them unavailable; if you want the safe way and maybe to join the settings under same parent, disassemble AMITSE and break the loading of Sony tabs.
i always checked everything twice/tripple/etc since i don’t wanna fuck anything up. i used mmtool and uefitool to extract the modules, rip them apart with HxD and compare the shit out of it. i’ll play around with the modules and the GUIDs. i also took a quick look at the aptio source for ivy bridge but that didn’t helped much. it just confused me more… but i think that the GUIDs are the key. Just like you said… that would totally make sense There must be a nice, clean, smart and straight forward solution that has to be plain stupid. "The less you have to patch the better"
@Viabobed If you got the guts to flash one of my versions i will have one for you. But don’t forget: it could brick your pc (but i really think it won’t since the setup module isn’t loaded during boot)
Just a quick update: The freeform module/section/part (however you call it) which holds the form sets doesn’t has a unique GUID. The same GUID is used for the menu inside AMITSE, Setup and SonySetupCallback module (along others, just search for it in UEFI Tool). If you open those modules with IFR Extractor you will get the menu structure of your BIOS. Except for AMITSE: IFE Extractor parses the file but the corresponding file is emtpy. This file is also the only one that get’s changed by AMIBCP. So the complete “structure” of the setup is set via AMITSE module and get’s later filled with the strings from Setup, SonySetupCallback and ReFlash (yes this one also holds some strings). So if you delete Setup and Sony, AMITSE still nows which tab to show or how they are set (eg User, Default, Supervisor). Since everything is set to Show where’s the problem? Because of the Sony module there are always two bytes you have to change. I don’t fully understand how the internal structure of AMITSE is. It should follow the HII Database Protocoll but sometimes this doesn’t make sense in the case of AMITSE.
I dissected AMITSE (there really is no need to but i did it anyway… maybe useful for someone else)
HII Package: Header + Body HII Package Header: Descibes package type (8 types), package size (bytes) Package types: 8 different + 1 GUID for expansion(s) + 32 vendor specific One Form Set per Tab
Offset: 0x000210h - String Pkg [40 02] [00 00 00 00] [00 00] [80 02] [00 00] [00 00] [00 00] Length: 0x0240h Empty: 0x00000000h Lang Name String: 0x0000h Empty: 0x0280h Printable Language String: 0x0000h Empty: 0x0000h Number Strings: 0x0000h
Which and where bytes get changed via AMIBCP in AMITSE (second freeform):
Offset Nummer Name Old[Show] New[Show] Old[Acc] New[Acc] -------------------------------------------------------------------- Set First Main To Show: No 0x0244h 0002 Main 00[Yes] 01[No] Default Default 0x316Ch 0002 Main 01[Yes] 00[No] Default Default
Set First Main To Show: No \ Set Second Main To Show: No 0x0244h 0002 Main 00[Yes] 01[No] Default Default 0x316Ch 0002 Main 01[Yes] 00[No] Default Default
0x2E1Ch 0014 Main 00[Yes] 01[No] Default Default 0x32ECh 0014 Main 01[Yes] 00[No] Default Default
Set First Advanced To Show: No \ Set Second Main To Show: No 0x1014h 0004 Adv 00[Yes] 01[No] Default Default 0x2E1Ch 0014 Main 00[Yes] 01[No] Default Default 0x31ACh 0002 Adv 01[Yes] 00[No] Default Default 0x32ECh 0014 Main 01[Yes] 00[No] Default Default
Set First Main Access: User 0x316Ch 0002 Main 01[Yes] 05[No] Default User 0x32ECh 0014 Main 01[Yes] 05[No] Default Default
Set Chipset Access: Ext. User \ Set Second Main Access: User 0x31ECh 0006 Chip 01[Yes] 03[No] Default Default 0x32ECh 0014 Main 01[Yes] 05[No] Default Default
Set Chipset Access: Ext. User 0x31ECh 0006 Chip 01[Yes] 03[No] Default Default
