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

[TimeWalker]

Yeah, I've figured:
#define S_IRGRP (S_IRUSR >> 3) /* Read by group. */
#define S_IROTH (S_IRGRP >> 3) /* Read by others. */
are missing.

But the tool doesn't actually do anything properly. It needs a fine to save the dump, but won't save the dump and reads the size of the specified file instead.. can't wrap my head around it. Besides I'm bloody tired today..

Also apparently this tool is used by Google to deploy ChromeOS onto Chrome Books ...

Code:

Copyright (C) 2011 The ChromiumOS Authors.  All rights reserved.
Copyright (C) 2011 Google Inc

86/64 .. what the heck is different .. you can run both arch natively.

Code:

>ifdtool -d backup.bin
Could not open file: No such file or directory

>ifdtool -d 7.1.52.1176.bin
File 7.1.52.1176.bin is 1335296 bytes
Could not read file: No error

>ifdtool -x v3450.rom
File v3450.rom is 4096 bytes
Found Flash Descriptor signature at 0x00000010
  Flash Region 0 (Flash Descriptor): 00000000 - 00000fff
  Flash Region 1 (BIOS): 00180000 - 003ffff
   -------------- Crash -----------------

Hopes were waaay up high for this ...

Code:

>ifdtool.exe -u v3450.rom
File v3450.rom is 4096 bytes
Found Flash Descriptor signature at 0x00000010
Writing new image to v3450.rom.new

It just patches the dumped flash descriptor to "unlock" it and reflash (same as Intel's utility I guess), which can't be done since it's locked.

[nebster]

I think mine is 64bit and is most likely the debug version.
If I strip out the extra information, it is 32KB but then if it crashes we can't trace it to the line!

---

I've attached both 32bit and 64bit versions of it.

[TimeWalker]

Can't debug it either way:
Unhandled exception at 0x7510c035 in ifdtool.exe: 0xC0000005: Access violation reading location 0x005131e0.

[nebster]

You need to run it through gdb:

Code:

> gdb --args ifdtool.exe <args>
.
.
.
> run
...
Access Violation
> bt

[kasar]

tried something

Code:

C:\BIOS MOD\A12 PROJECT\modded menus\ME test\Tools\System Tools\ifdtool>ifdtool -u mydumpfile.rom
File mydumpfile.rom is 4096 bytes
Found Flash Descriptor signature at 0x00000010
Writing new image to mydumpfile.rom.new

C:\BIOS MOD\A12 PROJECT\modded menus\ME test\Tools\System Tools\ifdtool>

then hex compared both files, untouched and "patched one"

it changed following

0B 0A 00 00 0D 0C

to

FF FF 00 00 FF FF

---

Code:

C:\BIOS MOD\A12 PROJECT\modded menus\ME test\Tools\System Tools\ifdtool>ifdtool -u mydumpfile.rom
File mydumpfile.rom is 4096 bytes
Found Flash Descriptor signature at 0x00000010
Writing new image to mydumpfile.rom.new

C:\BIOS MOD\A12 PROJECT\modded menus\ME test\Tools\System Tools\ifdtool>ifdtool -l mydumpfile_unlock.rom
File mydumpfile_unlock.rom is 4096 bytes
Found Flash Descriptor signature at 0x00000010
Writing new image to mydumpfile_unlock.rom.new

mmm, not sure if this tool works properly, tried something

1 unlock
2 relock again

the relock output file is 5 kb instead just 4 kb, and well, there are still many differences

I attacked the files to the post

[TimeWalker]

That's what @CodeRush had to say:

The only way to unlock flash descriptor for 7-series boards is by writing a sequence of 00 00 FF FF 00 00 FF FF 18 01 into address 0x60 using a hardware flasher/programmer.

And I've already quoted it once .. and that's exactly what the tool has done:

But read the part in bold .. it applies to us since Dell will never release v8 ME as desktop board manufacturers do. (otherwise having the v8 flash would unlock the FD and ME) They have updated EC only once to fix adapter detection interval (re-try 3 times every 500ms to extend detection time for Adapter plug-in). Look at Lenovo ... they update everything even for their baseline laptops .. And not it's like Dell doesn't have problems with their EC .. take the stupid fan noise for example.. it's just they ditch their users.

Look at Dell's support retarded employees .. people ask if SecureBoot is possible on XPS 15/17 L502x/L702x and Vostro 3450/3750 and their consultants say 'UEFI Bios is required to support SecureBoot" - they don't know sh*t ..
Actually new Insipiron 17R and Special Edition (SE) have SecureCore Tiano 2.31 and SecureBoot is enabled from the factory and can't be disabled from the BIOS according to what I had read, so people are struggling to install Windows 8 because it won't let them update the Boot Manager...

[jkbuha]

What if we had to flash the descriptor through winflash alongside the main bios?

[TimeWalker]

How do you point WinFlash to update the desciptor? It's not like you have a way of having it as a stanalone file or something .. WinFlash has to load a capusle into memory. How would you know how the descriptor is integrated into the capsule to be able to be recognized in the process of flashing ?

There's an /ALL flag to update everything including the FD region.. as well as /DESC flag .. but.
Since FD signature starts at 0x10 there should be something similar to a sequence of:
5A A5 F0 0F 03 00 04 02 06 02 10 12 20 01 21 00 25 00 00 00 .................... or at least the 'lock' part 00 00 0B 0A 00 00 0D 0C 18 01 08 08
somewhere in the capsule, right? well, too bad the there isn't ...

---

Actually an interesting link I had stumped upon: ftp://ftp.icg.eu/Drivers/Printers/.../Dr...l/Phoenix/

1.5.65.0
Bug fix:
Bugzilla 14819 - Windows
(Emerson) flash tool can not update descriptor region on HuronRiver platform.

[kasar]

well, if the only viable way of getting that thing unlocked is directly program the flash unit by hardware programer, I think we can go for it.

as for me, I made some electronic projects before.

like turn a cheap RC car into a wireless comtroled robot with camera and more stuff, everything controlled from a wrt54gl router.

while I was flashing modded firmwares into it, it got bricked once.

so I had to build a JTAG cable, then I was able to flash and recover the router by conecting the JTAG cable to the parallel port of a computer and the other side to a custom made conector at the router.

I think I may be able to use the JTAG cable to get access to the motherboard, not sure if when I made the internal usb mods to my xps15 I saw some kind of dev internal port, so I manage the get the correct pinouts from that port, I may get all of this working.

this also have some advantages, like if we get a working hardware programer, then we can made a whole backup of the flash, and by having a whole backup of the flash, I supose there will be no posible way our laptop get bricked ever, because we will allways be able to restore our working backup ^^

we also would be able to unlock the descriptor by hex moding the backup by modifing the values timewalker pointed, and then flash it back ^^

some pics of the JTAG cable I made









also, if I manage to get the correct pinouts, I could put that small conector on the l502x ram expansion door, so when I have to flash anything from that, I woulnt have to take appart the whole laptop, just remove the door.

what do you think about this guys, would be a viable option?

---

now some images from the net of the jtag cable ussage






I hope this will works :3

---

well, there are also another solutions

this one for example

http://www.embeddedcomputers.net/products/FlashcatUSB/

you can see our SPI Flash device: "W25Q32BV" unit is supported

[TimeWalker]

SPI is surface mounted and non-removable, you don't have access to pins on the chip. At least this is the case of my Winbond.

Great project though. I have my ways around basic circuit design and soldering, but I wouldn't dare removing a surface mounted chip ;/

Sent from my LG-P500 using Tapatalk 2