[b][/b]
[i][/i]
[u][/u]
[s][/s]
[code][/code]
[quote][/quote]
[spoiler][/spoiler]
[url][/url]
[img][/img]
[video][/video]
Smileys
smile
smile2
spook
alien
zunge
rose
shy
clown
devil
death
flash
sick
heart
idee
frage
blush
smokin
mad
sad
wink
frown
crazy
grin
hmm
laugh
mund
oh
rolling_eyes
lil
oh2
shocked
cool
[mail][/mail]
[pre][/pre]
Farben
[rot][/rot]
[blau][/blau]
[gruen][/gruen]
[orange][/orange]
[lila][/lila]
[weiss][/weiss]
[schwarz][/schwarz]
CodeRush
Posts: 246 | Last online: 09.23.2017
Name
Nikolaj Schlej
Date of birth
4. February 1987
Beschäftigung
Firmware Security Engineer
Wohnort
Deggendorf, Germany
Date registered
12.02.2013
Sex
male
    • CodeRush has written a new post "Dell Venue Pro 7130 tablet - ME file system corrupted" 09.14.2017

      Zitat von jockyw2001 im Beitrag #15

      I see that the BIOS region consists of 4 parts: section_0_A.22.data, section_0_A.22.meta, section_0_A.22.mtsg and section_0_A.22.sign
      I guess the last 2 files are signatures of the meta and bios payload respectively. Should I concatenate those 4 parts if I want to flash a BIOS region with fpt ?

      I compared the extracted BIOS part (section_0_A.22.data) with my fpt dump of the BIOS region (bios.bin) and see that they have the same size (0xB00000), but they are not binary identical. Starting from offset 0xF48 the bios dump includes NVARs which are not contained in the extracted bios part. How save is it to flash the extracted part and what are these NVARs? Is that area preserved when flashing with fpt?



      1. You've guessed correctly, .mtsg is a signature for .meta and .sign is a signature for .data. The only file you need is .data (or .payload, if .data is in HDR subsection format, but it's not the case for your file), others are used by Dell's flash writing driver.
      2. Those NVARs are NVRAM variables, that will be created on first boot of the flashed image. There are some rare cases that will require preserving them (because sometimes manufacturing data for a particular motherboard may be stored there), but AMI-based firmware very rarely use NVRAM for such purposes.
      3. FPT doesn't perform any parsing of BIOS region, so it won't preserve anything in it.

    • CodeRush has written a new post "[Experimental] LZMA F86 decompression" 09.03.2017

      Got it, so you want to recompress individual files for older systems. It's indeed feasible and often works out of the box if both 0x01 (EFI11/Tiano) and 0x02 (very often LZMA) are supported by the firmware. I removed it because it was too dangerous for noobs, but if you know what you are doing, it can be added back with ease.

      As for LZMAF86, do you have any links for image files with such sections?

    • CodeRush has written a new post "[Experimental] LZMA F86 decompression" 09.03.2017

      It's feasible (because UEFITool does that every time something in compressed DXE volume is modified), but recompression into a different algorithm very often leads to bricked FW, because DXE core tries to use only one algorithm and disregards the compression type indicated in section header (it is wrong, but IBVs don't really care). Freeing up compressed DXE volume space makes very little sense, because a compressed volume can be trivially grown to virtually any size (it's already supported in UEFITool 0.21.x since ages), as for main DXE volume, I've seen very few cases where there's no more space for anything, and if so, you can just move some files required for network boot or any other rarely used function to ESP.

    • CodeRush has written a new post "[Experimental] LZMA F86 decompression" 09.03.2017

      Thanks a lot. It had it back in v0.19 or so, but then it was deemed to too dangerous (people tried to replace EFI11 with LZMA and it broke many systems back then), so I removed it.
      What is your possible use case for this feature?

    • CodeRush has written a new post "[Experimental] LZMA F86 decompression" 09.03.2017

      Can you provide sources with BSD or compatible permissive license? UEFITool maintainers can then use them to make UEFITool NE truly compatible with LZMAF86.

    • CodeRush has written a new post "ASUS Z97-A BIOS DTS key" 07.30.2017

      No Z97-based board ever had DTS key, AFAIK, don't worry about it.

    • CodeRush has written a new post "Lenovo E530 - BIOS Startup menu with boot options missing" 06.29.2017

      Both chips are "main" on this platform because .FL file is 12 Mb exactly. There's a little sense in splitting ME region in half, so I think that Descriptor, ME and NVRAM are in the Q64 one.
      If you don't have SPI programmer, you should definitely get one instead of buying pre-programmed SPI chips (which cost a lot and have unknown firmware in them).
      The state of this system is definitely fixable, it looks like a corruption of some NVRAM variables required for booting (BootXXXX, for example).

    • CodeRush has written a new post "Lenovo E530 - BIOS Startup menu with boot options missing" 06.29.2017

      This looks like a broken NVRAM issue, you need to dump W25Q64 chip and fix NVRAM in there. It could be rather difficult because there are no tools for doing it besides hex editor, but if you could attach the dump and the .FL1 file, I will try to help.

    • It's great that this brings you fun, @davidm71, way to go! Just wanted to warn you: if you want to share your tool and want others to use it - be prepared of the constant stream of "please patch my BIOS", "why is this shit not working?!" and "you need to pay for repairing my motherboard!!!"
      I very much encourage everyone to share the knowledge and have fun with BIOS modifications, but there's also a big chunk of people who don't understand that we aren't a tech support, we don't have to help anyone with anything and we won't be hold responsible for anything that they read here.
      The whole FW modding community really need people like you, @davidm71, so please don't stop tinkering and having fun because I've said something. I won't be where I'm now without UEFITool, and I still think that "automate everything" is a bad idea, but I don't discourage you from doing anything or releasing anything.

    • @Fernando, about the OROM integration guide: I can't write it just because I don't know anything about them, but @SoniX may know more.
      CSM in general is a bane of every EFI developer's existence, so the sooner we get rid of legacy OptionROMs - the better.
      I know there are still a lot of systems that can't work in pure UEFI mode with disabled CSM, but this is a very good reason to upgrade your system.

    • All my tools are explicitly BSD- and/or GPLv2-licensed, so no one needs any permission to modify them.
      OZMTool is written by TuxUser (with a bit of my help in better understanding the inner works of the 0.2x engine), but it's also based on UEFITool's source code.

      There's a problem with insertion of new stuff in DXE volume if the volume itself is a root volume and hasn't enough space to fit the new driver, and in this particular case, even UEFITool can do nothing with the situation, but this case is very rare on modern systems.

      In my opinion, automation tools like OZMTool, UEFIPatch or UBU are actually making things worse, and I only realized it after 5 years of developing/helping developing them.
      The tool obscures the real complexity and danger of FW modifications, so less and less people are actually understand what they are doing and why they are doing it, switching to mindlessly applying any VBIOS/OROM/ME update they may find, trying to get another 100 IOPS from the same SSD and another 50 Mhz of already overclocked RAM. This kind of tinkering is totally fine, but only if it helps learning how the FW actually works and why you need to change this instead of that, and automation simply destroys this step. A proper guide with explanations and infos is 100 times better than a program that automates it, because if you read a guide - you learn something, and if you run a program - you learn nothing at all, only it's author did during the program development.
      Please think twice before telling the world "hey guys, I've automated your routine BIOS modding task!" as I did, as you will be blamed for every user mistake, every bricked system, every corrupted BIOS and about 10% of those will actually be your fault because a perfect 100% working program can't exist.

    • It makes no sense to change any defaults the was selected by platform manufacturer. You can try decompressing DxeCore, if it was compressed originally, but if it will work or not - depends solely on the implementation in a given FW image. EFI decompression is limited by SPI throughput only, and the difference of compressed/uncompressed is extremely small on any CPU better than 400Mhz Quark.
      I know it's a lot of fun to mess with EFI, but if you just want to insert a NVMe driver and get your drive to be bootable - there's no reason to repack anything, just insert the driver to the end of DXE volume and be happy.

    • I do not understand why the whole OSM community wants to add anything into the DXE volume in the first place. SPI flash is slower than any modern HDD or SSD, and EFI System Partition is a perfect place for such files, but instead of using ESP for it's purpose, OZM folk want to get rid of it to spare 200 Mb of drive space. It makes no sense, FW modifications lead to countless problems, but many people still want "the native experience" of OZM integrated into the FW.
      Why the hell you all do it? I don't know. I've implemented internal volume grow because it's easy and requires very few changes in the FW (root volumes are much harder to resize, I must say).

    • The correct amount of free space will actually depend of a definition of "free space".
      Specification defines free space to be all bytes from the end of the last file of the volume to the end of the volume itself, so volume_header_offset_of(last_file) + size_of(last_file) + size_of(free_space) = size_of(volume).
      There's, however, another possible definition of free space: maximum size of a file that can still fit into the volume. This size will be 0 - 7 bytes less because of default file alignment of 8, or even lesser if the alignment is set to be more than 8 (like it's for Volume Top File, for example).
      Actually, because EFI FFS doesn't define any order, it's possible to rearrange files to have less alignment gaps between them by solving a knapsack problem. This will be implemented in UEFITool NE after I can get to it's development again.

    • @davidm71 ,could you please be more specific about the difference?
      MMTool tend to align all file sizes to 8 (which works, but it's out of spec). so UEFITool may report from 0 to 7 bytes more free space than MMTool, but it's a harmless quirk in the later.

    • CodeRush has written a new post "[check] 3 bioses to verify if they are valid " 01.27.2017

      The only way to "verify" them is to try and restore if they aren't working. Yes, you need a hardware SPI programmer for making backups and for restoring, but it's the only option if you want to be sure. No one but you will check you files.

    • CodeRush has written a new post "What modules in bios safe to compress?" 01.20.2017

      You can tell it by the image structure, if it has "Compressed" sections (i.e. UEFITool shows them with this name) - it's EDK1 for sure.
      OZMTool is written by TuxUser, he's active on insanelymac.org forums.

Recipient
CodeRush
Subject:


text:
{[userbook_noactive]}


Xobor Forum Software von Xobor