(UEFI) Dell XPS 15z L511z modded BIOS - and HOWTO

[marstone]

jkbuha: still no response this afternoon, i asked again and he said tomorrow he will ask his phoenix colleagues again.

someone said there is only nt32, no nt64 at present and no plan.

[jkbuha]

jkbuha: still no response this afternoon, i asked again and he said tomorrow he will ask his phoenix colleagues again.

someone said there is only nt32, no nt64 at present and no plan.

hmmm - if that were the case, can we use x86 mode in some way to debug DXE?

ArthurianX: Download the latest BIOS of your vendor and run it (but dont flash) - look into your temp folder and you'll find the executable for your system

[marstone]

The Phoenixer said to my firend he has signed contract to not disclosure the source - -#
I will try to ask if he can give us some hints about the menu data structure in the future.

I think the source code can be compiled to either x64 or x86,
however, the ROMs we disassembled are x64, so i do not know how to convert it to x86 or any other methods to let it run in 32 bit environment.

BTW, I think if there are bits to control the menu hidden or not,
there must has some code like this:

if (menu.isHidden == false) // or if (menu->flags & HIDDEN_MASK == true)
{
// showTheMenu...
}

are there any way to let us "nop" the "if" instead?
I also guess, the code is not in the PlatformMenuAdvancedDxe.efi
because other menu tabs also follow this logic to display menus,
so the "if" must locates in some common utilities other than PlatformMenuAdvancedDxe.efi, SystemMenuMainDxe.efi...

jkbuha: still no response this afternoon, i asked again and he said tomorrow he will ask his phoenix colleagues again.

someone said there is only nt32, no nt64 at present and no plan.

hmmm - if that were the case, can we use x86 mode in some way to debug DXE?

ArthurianX: Download the latest BIOS of your vendor and run it (but dont flash) - look into your temp folder and you'll find the executable for your system

[jkbuha]

BTW, I think if there are bits to control the menu hidden or not,
there must has some code like this:

if (menu.isHidden == false) // or if (menu->flags & HIDDEN_MASK == true)
{
// showTheMenu...
}

are there any way to let us "nop" the "if" instead?

That's exactly what I tried to do - nop all ifs, jump conditionally, and approximately 50 flashes later - no progress.

In reality I think the menu is structured more as follows:

Menu Item 1 && Menu Bitmask 1 (Language, default setting, hidden/visible etc)
Menu Item 2 && Menu Bitmask 2
...
Menu Item n && Menu Bitmask n

The biggest issue is trying to find where Bitmask is - as in theory if we find it all we need to do is just enable all the bits (bytes?) for the items we wish to view. Sadly just changing one conditional jump statement doesn't enable the advanced settings, as with the former EFI bioses.

With regards to the NDA your phoenixer signed - that is fair enough. All we need is just a helpful hint about how the menu bitmasks are embedded in the files, so then we can play around with them ourselves.

[ArthurianX]

jkbuha: still no response this afternoon, i asked again and he said tomorrow he will ask his phoenix colleagues again.

someone said there is only nt32, no nt64 at present and no plan.

hmmm - if that were the case, can we use x86 mode in some way to debug DXE?

ArthurianX: Download the latest BIOS of your vendor and run it (but dont flash) - look into your temp folder and you'll find the executable for your system

Ahhhh, I thought that step was for getting the BIOS file if we wanted to customize it ourselves.

Thanks a bunch!!!!

---

What I wanted to ask:

"UPDATE 18/03: Added New (unofficial) Dell A10 BIOS for the 15z. Current - and best performing - BIOS mod is the 0.83V/0.85V"

Is this the untouched A10 BIOS, or is it modded? I'm asking this because I updated to A10 a month ago.

[jkbuha]

The A10 Bios is untouched. It's just the graphics bios which has been changed. So you can mod away

DoiX from another forum pointed out this potential solution for EFI simulation: http://sourceforge.net/projects/cloverefiboot/

Looks interesting...

[AHMED HOSSAM]

Hi All ,

We already knew before that its like an if statements checking for flags or bytes , we haven`t any thing new after this .
noping the if statement will not work as this will brick the routine and may also brick the whole setup modules , we should modify the byte or flag to make the condition true to show the menus and options .
its programmed like this :-

if statement ------ language ----- menu offset in string table ----- default setting ------

the code doing this is not found in the routines in the start of the file , it found far away after the strings table , its inside the menus itself not something in the code which initialize the whole menus .
you should knew these facts :-
1) the codes and routines in the end of the setup module ( like dll entry point and others ) are responsible for showing or hiding TABS NOT MENUS AND OPTIONS .
thats why when i have modified the code , i could hide the advanced menu ..... and could show it in another UEFI bios where the advanced tab was hidden .
this is easy in assembly and could be noticed clearly .

2) the module is divided into sections :

a: the code and routines in the end of the file which is responsible for strings and TABS initialization and calling the menus routines ..... etc .this section can show the tabs ( if its hidden ) but can`t do anything with options or menus inside tabs .

b: the strings itself in the start of the file .

c: after this , we should find the strings table which works as a pointer to the strings , every 2 bytes refer to the address of a specified string .

d: after this we should find the bytes of the menus it self , inside this you can find bytes which are calling addresses in the strings table , when its called , it calls the required string ............... and we find the if statement responsible for hiding options or menus , also the bytes ( or flags ) responsible for indicating what language is this string and some other bytes which i don`t knew about yet .


so , for Marstone , we already knew about these information and i expected some interesting news from you just kidding , i knew about NDA for all great companies and expected that your friend tell you this , we just need phoenix to release an emulator for UEFI , just like the PBE for normal phoenix BIOS ............. we can knew where menus are but we can`t knew what condition it checks to make the menu hidden , thats why i asked for emulator not the source code as i knew its impossible to get source code

[marstone]

The phoenixer gives no help. :-( and I was busy working these days and made no progress.

I read something here:
http://www.phoenix.com/pages/phoenix-sec...e-tiano-tm
It mentions something about its "moduler" & "object oriented" source code architecture
but no ANY information about tools for OEM development
I think maybe phoenix securecore tiano is still to young and leak of tools /debug/emulation support.

to jkbuha: I take a glance at Clover EFI bootloader
It mentions DUET, I think it is some kind of UEFI "simulation",
which simulates UEFI based on BIOS, and provide interface for higher level OS & apps to run above.

but what we need is some kind of UEFI "simulator",
which simulate Hardware based on OSes (may be a user space process)
and provide interfaces for higher level UEFI to run above

to ahmed: I am wondering whether the utilities in the end of the ROMs can invoke any other utilities in another ROMs?
If it can,
I think maybe "DrawTheMenuItem" or "CheckTheHiddenBit" or etc are "common" utilities in some common ROM, not in the PlatformSetupAdvancedDxe.efi(CFEF94C4....ROM) itself.
I also find in the beginning of PlatformSetupAdvancedDxe.efi, the strings are not the menu itself. it is the Helps for the menu items in different languages, which can be show be press F1.
the hint of "Press F1 for help" is in the bottom of the Setup Program, and the string "F1" and etc in the bottom is found in another ROM.

That's to say, there must be some way to call utilities or read data between different dumped ROM files. then I will ask, is there something special in the utilities which can be invoked (such as DLL entry declarations)? it so, we can identify the location of the menu data/menu render utilities easier.

[dkinsano]

see if it heps anyway:
http://www.osxbook.com/book/bonus/misc/legacyboot/

and this:
http://blog.fpmurphy.com/2011/01/edk2-ue...ra-14.html

[jkbuha]

Interesting links - guys we're making some progress here!
@marstone - what do you think on dkinsano's links? I've had a look and there seems there's a lot of potential...