@Riley Freeman

Thanks for the new GOP. This is the beauty of open source software, anyone can contribute and it will grow faster than the original author could have hoped. I only wish my code was better, so I could release my other tools as well.

@JoeDirt

I've noticed quite a few "complaints" on your thread, mostly concerning flashing original firmware. I will start by saying that I agree with you, original firmware should be flashed with original tools. But since anyone can experience the laziness of needing just one tool, or the mistake of confusing modded with original, here is the solution for flashing any type of firmware. The first and more elegant is to make that evaluation always true:



The second one is to use brute force and ignore the comparison altogether.



The patches are attached. There is also something for the two command id errors, although I'm confused by those. They are triggered by PMU, which I thought is power management unit? But we can see that PMU does the certificate verification, so it is more than that or something else entirely. Then there are some patches for supporting older cards, but I'm almost sure they won't be enough, as I had no hardware to test. The patches are based on 5.287 x64, but it should work in a similar manner on newly 5.292, which was posted on LaptopVideo2Go and Geeks3D.

Released version 1.9.5:
- Updated GT21x to 0x10031, thanks to insanelyDeepak and Riley Freeman
- Updated NVFlash to 5.292, thanks to Stefan from LaptopVideo2Go and Geeks3D
- Updated ISBN/NBSI structure for Pascal support. They added more hashes.

@lordkag

Thank you sir for this. I will apply these as soon as I get back from my work trip. I will also make sure to update my page with credit to you for your additional mods. I am still very much a novice when it comes to this but additions like this help me learn a lot about how to read what is going on and why.

Zitat von lordkag im Beitrag #257

---

Released version 1.9.5:
- Updated NVFlash to 5.292

---

@JoeDirt

For your thread, only the first batch of patches are relevant, the ones concerning Cert 2.0 and Command IDs. The second batch is for supporting older cards, with first generation of certificates or uncertified images. But I didn't tested those patches and I have a strong feeling that they won't be enough, probably the patch needs to be done earlier, before PMU even starts to check the certificate. Without a hardware to test, I can't provide a working patch for older cards, but that can change if someone has an older card to test and agrees to a few tests, with no strings attached. The third batch of patches are there just in case, but I don't see them being invoked in normal cases, probably they are internal errors related to certificate processing. If you plan on using those patches, use just the first batch, the others are untested and not related to your thread.

@morpheus67

Thanks, already got a copy from Station-Drivers, <here> or <here>. But thanks anyway.

1st of all: Thank you for that great tool!

I just got an Asus Radeon R9 290X DirectCU II OC and want to modify the BIOS. Then I found this thread and now I want to update the UEFI GOP as well.

Screenshot:


I guess it's the DJH block thing and I can flash the updated BIOS?

Original and updated BIOS: http://www19.zippyshare.com/v/A1sY94X3/file.html

Thanks in advance. :)

@Dionysos

Yes, it is the DJH block and I haven't found anything that links this to the main VBIOS. It appears to be used only by Asus, probably for GPUTweak or their server, to quickly extract informations from the VBIOS.

@lordkag

So it should be safe to flash the updated BIOS, right?

Many thanks for OP + other members for this app.

I tried using this app to add UEFI/GOP to AMD Fury X non UEFI ROM, mobo will not post with created ROM. To me nothing was wrong with this created ROM, UEFI had been added at right offset location, UEFI was enabled in Legacy ROM and checksum fixed.

Next I updated 2 differing AMD Fury X ROM with UEFI/GOP (113-C8800100-103 & 107) from version 1.59.0.0.0 to 1.60.0.15.50, mobo will post with created ROM.

I have Asus M7 Ranger, FW 3001, testing done with CSM=Disabled, Secure Boot=On, Fast Boot=On.

I have attached ROMs and if anyone can shed some light why 113-C8800100-102 ROM with UEFI/GOP 1.60.0.15.50 will not post I would appreciate it.

Thanks lordkag ，it works with my GTX560 perfectly .it's the gf10* and gf119 efi rom for my graphic card.

@Dionysos

Yes, it would be safe IMO.

I would flash only one bios position and if an issue you can always boot system from other bios position and overwrite the bad flash position. You can flip the bios switch on card whilst PC is on.

@gupsterg

Concerning <this post> and following replies + your additional reports. I don't think the fault to be in my tool. There are already examples of successful updates on AMD, like <on 7xxx>, or <again 7xxx>, or <on 6xxx>, or <on 5xxx>, or <again 5xxx>. From those reports we can safely assume it works on 5xxx - 7xxx, when adding the GOP. We can safely assume that 1.60.0.15.50 works, since it has been tested by you. The only thing left to check is if it works on R2xx and newer cards - when adding the GOP. I don't remember if someone tested on newer cards, but there is <one user interested>. Could they enforce a check on newer cards? Maybe, but we need to break this into smaller things before jumping to conclusions. I don't see any hash or checksum in the AMD GOP, the only integrity check can be done on signed GOPs, by verifying the PE checksum and digital signature. However, it makes no difference, since I don't modify the GOPs in any way. Their integrity can be checked by dumping the .efirom on GOPupd.bat and taking the .efi from temp folder. That file can be checked either with right click -> Properties -> Digital Signatures - Details, or with SigcheckGUI/Sigcheck, or with signtool from Windows SDK. For some reason, Sigcheck is less strict and validates the signature even when the timestamp certificate has expired, which is the case with most of the older GOPs. The EFIROM is not signed in any way, nor is it checksumed - which should have been the minimum standard. We can conclude that any check must be done on the Legacy ROM. By looking at it, it seems the Legacy ROM is better protected against alterations.



It has an 8-bit checksum (offset 0x21), it has a 32-bit checksum (named BIOS_IDTF in ATIFash and pointed by CRC offset in ATOM Header), it has a hash after this checksum. The first one is easy to overcome and it is already done by any modding tool. The second one is on my list, but I can't pinpoint the boundaries. It seems to be an Adler32.



But I don't have the hardware to go any further than that. The hash is most likely the hardest one to crack, but The Stilt gave <some insights>, although the length of the hashes don't match. If you look at the reports I added in the beginning, you will see that those cards also have the same integrity fields, how come those aren't checked and why it happens on latest cards? If I understood you correctly, you tested all cards on the same system and only some worked after the GOP update? If they were tested on different systems, you need to consider the booting environment, like in <this post>.

On the Nvidia side, the GOP is always signed and PE checksumed, which is already added to next version of GOPupd.



I don't see any other checksum or hash on the Nvidia GOP. The EFIROM and any other ROM is 8-bit checksumed. No other hash or checksum on them, but NVidia is using a separate image with an NBSI/ISBN structure to hash and sign the entire image. Use ISBN=1 and DEBUG=1 in GOPupd.bat to see it.

To summarize:
- AMD is using an 8-bit checksum, an Adler32 checksum and a hash on Legacy ROM, , nothing on EFIROM, a digital signature and a PE checksum on GOP (optional), nothing on the entire image.
- Nvidia is using an 8-bit checksum on Legacy ROM, 8-bit checksum on EFIROM, 8-bit checksum on any other special ROM, a digital signature and a PE checksum on GOP (always), an NBSI block on entire image.
- When it comes to PE checksum, AMD is a hit and miss, only signed have PE checksum. Mac GOPs use the PE checksum, but a peculiar situation is that some of them are off by 10. Nvidia GOPs are always signed and PE checksumed, which makes them perfect for integrity check.

Finally, you can upload a copy of GOPupd on your thread, as long as you add a notice/warning that any reports related to it must be added to this thread.

Using a separate post, as an edit might be missed.

@gupsterg

How did the card failed to POST? Did it showed an OEM logo and failed to boot Windows - which will point to driver doing the check? Or did it showed a black screen the entire time and failed to POST - which will point to GOP doing the check? I just don't see AMD doing this on purpose, it will be suicide to them at this point. Further more, there are a tons of modders out there, especially on your threads, I haven't seen them complain about failure to POST, although they are doing a lot more changes. Do they all use CSM = On?

Maybe someone knows an AMD rep and ask them for a statement on this matter and an updated GOP or driver? But if I'm to be honest, after working with several AMD Firmwares (VBIOS, CPU microcodes, AGESA, PSP, SMU, IMC, XHCI), they have lower standards than me - and I'm not even a junior coder, just bellow a script kiddie! Just comparing the clear structures of Intel and Nvidia with the mess AMD is using in their modules, makes me angry beyond any level. They simply change stuff between generations and revisions (with no visible gains or necessity), like they forgot or assigned a different team to work.

Here is more weird stuff from AMD. If you look at this image,



you will notice that all changes are above ATOM Header + Tables and unrelated, with the exception of Image Indicator from PCI Structure. Yet, the Adler-32 checksum and hash are changed. In the past, AMD used custom EFI images, where they ported the ATOM Tables to GOP, inside a smaller Legacy ROM container. Like in the image bellow, where left is Legacy ROM and right is the dummy ROM inside GOP:



Notice that the CRC and hash are unchanged, yet there are more changes above ATOM Tables and in ATOM Header, including Image Indicator. Even the Tables are completely different, due to relocated structures and changing pointers.



The only logical explanation is that they ported the checksum and hash from Legacy. And the reason for that being... classic AMD. Maybe they wanted a fast comparison between Legacy Tables and GOP Tables, to be sure they ported the right thing, but in that case why use the CRC and hash in the first place? This adds to my previous idea that AMD has no basic standards.

@lordkag

Many thanks for your swift reply :) and your time plus share of insight :) .

I agree the UEFI/GOP are unmodified by yourself/app. The post on Litecoin by The Stilt I had seen before, due to Hawaii bios mod investigations. IIRC in that thread it is also highlighted by The Stilt "the Chinese" at some point cracked it, if I understood the post correctly >Link<. I do not deem GOPupd was at fault when using 113-C8800100-102 ROM + with UEFI/GOP 1.60.0.15.50 why system did not post. The ROM that had been created is as it should be in relation to what I/we know concerning enabling UEFI in a Non UEFI ROM. Testing was done on all the same hardware/system only ROM on Fury X was being changed. The test was mobo must post with display output and UEFI usable whilst CSM=Off, SB=ON and FB=ON, SSD/HDD was disconnected for this testing.

Zitat

---

It has an 8-bit checksum (offset 0x21), it has a 32-bit checksum (named BIOS_IDTF in ATIFash and pointed by CRC offset in ATOM Header), it has a hash after this checksum. The first one is easy to overcome and it is already done by any modding tool. The second one is on my list, but I can't pinpoint the boundaries. It seems to be an Adler32.

---

Now you see what is called BIOS_IDTF in ATIFash gets changed when flash occurs plus Legacy checksum gets recalculated, I don't know why. I have tested in the past with AtiWinFlash (GUI) taken from various AIB Fiji ROM packs released on their support sites plus tested using windows command line version. There is no pure DOS version of AtiFlash which supports Fiji, when I use -biosfileinfo switch with pure DOS AtiFlash it will show info for Fiji ROM. When flashing command used it states no adaptor found, I tried varying versions of DOS AtiFlash upto v4.18 which supports Tonga.