I assume Setup modules (which essentially are tabs from the BIOS setup) generally are safe to modify .. well, to a certain degree...
It's the options we unlock that can cause some unwanted results .. like CMOS corruption or an option that if enabled will cause the machine to fail during post/boot.
I've looked at the strings related to TPM and it appears to be checking whether or not there is a TPM device installed on the board .. which I assume is your standard USB-hosted Biometric reader that has a key (fingerprint enrollment) storage that you could use to unlock your laptop when it boots. Vostro 3450 has one, but the functionality in windows is poor.
The crisis recovery feature of course is a number one priority, however reading on IXBT I have seen cases with Insyde H20 that even USB recovery won't boot anymore after tampering with PEG/SG and other stuff.. so you still have to be really careful to do even slightest adjustments. And bear in mind that Insyde is pretty much deciphered already as there are scripts and software that parses the *.efi modules and translates them into human readable text.. which we don't have such a privilege with our Tiano.
Posts: 5
Threads: 0
Joined: May 2012
Reputation:
0
I know this is offtopic, but:
I can't find any forums that discuss the new OSX posibilities coming with the unlocking of the BIOS, any idea where we could talk about this?
I've been following this thread religiously and I am very glad it's unlocked, congrats to all the hardworking devs on this, jkhuba especially.
I tried installing OSX (Lion) a few months back with little to no success, could only boot from a USB Stick (I guess that's fixed now with UEFI Boot enabled), and I had [censored] with the graphics card, long story short here's a list with all the problems I had http://www.tonymacx86.com/lion-laptop-su...ll-10.html if you care to read (same username, ArthurianX).
My question now is, could someone (someone who's got OSX working) possibly upload and document all the files and modifications he or she did to make OSX work for our XP15z's? I'm willing to help, and to make tutorial/howto for others to make our laptops run OSX.
Thank you for reading, and even greater thanks for future answers and problem solving,
Arthur
What i know for sure is that with classic locked bios you can't boot anything of off GPT-formated HDD/USB flashdrive. Since 15Z and Vostro 3450 share almost identical Phoenix SecureCore Tiano one can assume that everything below will be common for these series of machines:
With UEFI Boot unlocked we are now able to install EFI windows 7/8 or UEFI Clover onto a GPT disk .. however according to dmazar - one of the coders for Clover who is responsible for most of the UEFI fixes... even though our memory map looks cleaner than any other UEFI version out there and in theory wouldn't need any fixes to boot OSX... theres is a problem with runtime services and NVRAM implementation, so the system boots and hangs for about 10 minutes, you cant click on anything, but everything is active.. it's sort of like a transparent layer that prevents you from clicking on things. After 8 to 10 minutes it magically unfreezes and you are able to use the system just fine. According to dmazar it's not fixable yet.. and theres no ETA, because the reason is unknown. I can access third-party shell to set up an additional bcfg entry which points to cloverx64.efi in /EFI/BOOT folder but it's unusable at this point of time.. as you can't do much without with a OS that does not support runtime and NVRAM ...
I believe you are still unable to boot something like Chimera/Chameleon/XPC of off GPT disk because it wil say "No Operation System Found" as only thing UEFI Boot does is looks for the bootx64.efi file in /EFI/BOOT those allowing you to boot with OEM efi modules/drivers.
P.S. You are welcome here
Posts: 523
Threads: 0
Joined: Aug 2011
Reputation:
23
10-03-2012, 09:04 AM (This post was last modified: 10-03-2012, 11:57 AM by TimeWalker.)
It actually IS a part of the bios of you look closely. There's even an option to access it which is hidden.
Shell.efi C57AD6B7-0515-40A8-9D21-551652854E37_1_967.ROM
Also using a third party UEFI shell through /EFI/BOOT/bootx64.efi with UEFI Boot enabled can get you somewhere .. just don't know where ..
Also I just thought of something ... would it be possible to rename SystemCrisisRecoveryPei.efi as bootx64.efi and place it into /EFI/BOOT/bootx64.efi with UEFI boot enabled to be able to initiate the recovery .. I think you can extract the module using MMTOOL .. Technically if the module starts with MZ it will be called if dependencies are satisfied. Of course to access it we would have to have a somewhat bootable machine. If It doesn't start with MZ we would have to delete the header part until MZ is the initial offset, because we are unable to call for defined offset by booting in this manner.
P.S. Stumbled upon this abstract description over at mydigitallife forums:
1) Download latest bios for Dell Vostro 3450 (assuming XPS shares the same BIOS it would apply as well)
2) Open with 7zip -> Vostro_3450_AXX.exe -> .rsrc -> 1024 -> RCDATA -> 7000 (this is the BIOS.cap) file.
3) PFlash.efi lives inside.
This might help with the Phoenix UEFI Crisis Recovery process previously documented.
Also this:
Quote:To create the Crisis Recovery disk:
1 Prepare a removable USB storage device with a capacity size greater than 10 MB.
Note that all data on the USB storage device will be cleared during the creation of the crisis disk.
2 Set up a computer running the Windows OS and plug in the USB storage device into an available USB port.
3 Use the text editor to create a file named startup.nsh with the following contents.
fs0Flash.efi/bb1/silent/sv/sd xxxxxxxx.fd (where xxxxxxxx.fd is the new BIOS image file)
4 Copy the startup.nsh file and the following folder and files to the USB storage device.
– EFI folder
– BIOS.cap
– PFlash.efi
– CrisisRecovery.efi
– BIOS image file
5 Eject and reconnect the USB storage device, and make sure the files are saved to the device.
source: http://forums.mydigitallife.info/threads...res/page82
The last method seems legit. Having Shell named as bootx64.efi in /EFI/BOOT on your usb stick would execute shell as soon as you boot of off the USB flash drive (with UEFI boot enabled) the startup script startup.nsh (placed nearby bootx64.efi) would be executed right away (I have tried it already to do UEFI dump) which in hand would run CrisisRecovery.efi from filesystem0 (same diskXs1) that would fash the image ..
Posts: 397
Threads: 1
Joined: Nov 2011
Reputation:
23
Hey guys - good to see some progress made since I've last been here. I have a couple of questions:
1) I haven't yet tried to patch the Security dxe module with the suppress efi module. Has anyone done so, and if so, to what effect?
2) @TimeWalker - I think your method could possibly work. If you do manage to do this let me know so I'll try and replicate it on a non-battery removable device such as the xps 15z.
3) Something else crossed my mind as well - there's the fvrecovery.fd file which is extracted during each bios flash. Surely this contains some form of recovery module?
Posts: 523
Threads: 0
Joined: Aug 2011
Reputation:
23
10-03-2012, 12:05 PM (This post was last modified: 10-03-2012, 12:07 PM by kasar.)
(10-03-2012, 11:56 AM)jkbuha Wrote: Hey guys - good to see some progress made since I've last been here. I have a couple of questions:
1) I haven't yet tried to patch the Security dxe module with the suppress efi module. Has anyone done so, and if so, to what effect?
2) @TimeWalker - I think your method could possibly work. If you do manage to do this let me know so I'll try and replicate it on a non-battery removable device such as the xps 15z.
3) Something else crossed my mind as well - there's the fvrecovery.fd file which is extracted during each bios flash. Surely this contains some form of recovery module?
1)
I replaced both 0A 82 45 8A (00) 00 00 00 00 00 00 00 45 0A strings at the SystemSetupSecurityDxe.efi module with 0A 82 45 8A (01) 00 00 00 00 00 00 00 45 0A
I am going to flash it and will report any change, I supose I have to expect extra stuff at the security tab inside the setup, right?
3)
yeah, I though about that several times, but I have no idea about how to access that file.
edit: I found that it can be also opened via PhoenixTool app, it also extracted several modules, I think that is worth of a deeper analysis
10-03-2012, 12:16 PM (This post was last modified: 10-03-2012, 12:31 PM by TimeWalker.)
keep us posted, kasar!
Well, in a nutshell ... this is what's crawling my mind right now.
1. startup.nsh with fs0Flash.efi/bb1/silent/sv/sd xxxxxxxx.fd <- this is clear so far, of course if the arguments are universal for all the Phoenix Tiano machines. fs0: defines working directory for the file system .. specifying PFlash.efi and arguments runs the respective efi module much like a terminal program .. which shell is .. in a way.
2. xxxxxxxx.fd is the new BIOS image file <- ok. we can get this *.fd file after every fw extraction. if it's indeed the BIOS image file then it's check.
3. BIOS.cap <- according to a ost regarding Vostro 3450 this can be obtained from the official updater
4. PFlash.efi <- BIOS.cap (or *.scap to be precise) are the files (firmware containers) that are being used by Apple to hold the firmware, you can extract the modules neatly using MMTOOL .. I have done it previously. So PFlash.efi should be there its the module that is executed when you run the official updater from within WinFlash. The blue interface thingy that beeps like crazy
5. CrisisRecovery.efi <- this can probably be extracted the same way.. if no, then backup plan like I said previously .. we know the GUID, if it starts with MZ -> cool, if not -> we trim it
6. BIOS image file <- that's already taken care of ...
We just have to gather everything together then .. I have a somewhat important test on Friday, so I'm not really willing to tamper with this at this point of time, but I will take a look tomorrow wether I can gather all the stuff for my Vostro to test the method.