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.
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.
UEFI_MOD.zip (569 KB)
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.
So :-
113-C8800100-102 ROM + with UEFI/GOP 1.60.0.15.50 , black screen no output on screen, this was a Non UEFI factory ROM.
113-C8800100-103 ROM + with UEFI/GOP 1.60.0.15.50 , no issue system post as it should, this was a UEFI factory ROM 1.59.0.0.0.
113-C8800100-107 ROM + with UEFI/GOP 1.60.0.15.50 , no issue system post as it should, this was a UEFI factory ROM 1.59.0.0.0.
Nothing else was modified in tested ROMs above other than UEFI/GOP, enabling of UEFI module/checksum in Legacy ROM if required. So the test result for 113-C8800100-102 ROM + with UEFI/GOP 1.60.0.15.50 to me is implying some check is failing due to addition of UEFI module. I would assume it is the UEFI module authenticating Legacy ROM and it failing check. The only other info I have seen as to what possibly AMD are implementing is on page 20 of this old >PDF<.
I also ran another set of tests, I took the 103 & 107 ROMs as above and edited OverDrive RAM limit in PowerPlay to 600MHz from default 500MHz, 103 & 107 then failed to post (ie black screen no output on screen). This would imply UEFI has checked "hash/signature" which The Stilt has highlighted (OS driver no longer checks this) and as the Legacy section has changed (protected blocks) it will not post. When CSM=ON SB=Off the mobo will post, I have also seen this same occurrence in modded Hawaii UEFI ROMs, when I owned a Hawaii card.
113-C8800100-102 ROM + with UEFI/GOP 1.60.0.15.50 , black screen no output on screen, this was a Non UEFI factory ROM.
113-C8800100-103 ROM + with UEFI/GOP 1.60.0.15.50 , no issue system post as it should, this was a UEFI factory ROM 1.59.0.0.0.
113-C8800100-107 ROM + with UEFI/GOP 1.60.0.15.50 , no issue system post as it should, this was a UEFI factory ROM 1.59.0.0.0.
Nothing else was modified in tested ROMs above other than UEFI/GOP, enabling of UEFI module/checksum in Legacy ROM if required. So the test result for 113-C8800100-102 ROM + with UEFI/GOP 1.60.0.15.50 to me is implying some check is failing due to addition of UEFI module. I would assume it is the UEFI module authenticating Legacy ROM and it failing check. The only other info I have seen as to what possibly AMD are implementing is on page 20 of this old >PDF<.
I also ran another set of tests, I took the 103 & 107 ROMs as above and edited OverDrive RAM limit in PowerPlay to 600MHz from default 500MHz, 103 & 107 then failed to post (ie black screen no output on screen). This would imply UEFI has checked "hash/signature" which The Stilt has highlighted (OS driver no longer checks this) and as the Legacy section has changed (protected blocks) it will not post. When CSM=ON SB=Off the mobo will post, I have also seen this same occurrence in modded Hawaii UEFI ROMs, when I owned a Hawaii card.
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.
Below is result of "stock" ROMs:-
113-C8800100-102 Non UEFI ROM > no change between flashed ROM and DUMP.
113-C8800100-103 UEFI ROM > DUMP will show 0x260 has changed from 73h to 71h plus Legacy checksum has been recalculated.
113-C8800100-107 UEFI ROM > DUMP will show 0x260 has changed from 65h to 67h plus Legacy checksum has been recalculated.
Next ones with GOP added/updated
113-C8800100-102 + with UEFI/GOP 1.60.0.15.50 > DUMP will show 0x260 has changed from D1h to D3h plus Legacy checksum has been recalculated.
113-C8800100-103 ROM + with UEFI/GOP 1.60.0.15.50 > DUMP will show 0x260 has changed from 73h to 71h plus Legacy checksum has been recalculated.
113-C8800100-107 ROM + with UEFI/GOP 1.60.0.15.50 > DUMP will show 0x260 has changed from 65h to 67h plus Legacy checksum has been recalculated.
Here is >link< to zip for above tests/dumps.
All the tested ROMs in new zip will post when CSM=ON SB=OFF. Only 113-C8800100-102 Non UEFI ROM and 113-C8800100-102 + with UEFI/GOP 1.60.0.15.50 will not post when CSM=OFF SB=ON.
On Hawaii I saw no change between flashed and dumped ROM.
113-C8800100-102 Non UEFI ROM > no change between flashed ROM and DUMP.
113-C8800100-103 UEFI ROM > DUMP will show 0x260 has changed from 73h to 71h plus Legacy checksum has been recalculated.
113-C8800100-107 UEFI ROM > DUMP will show 0x260 has changed from 65h to 67h plus Legacy checksum has been recalculated.
Next ones with GOP added/updated
113-C8800100-102 + with UEFI/GOP 1.60.0.15.50 > DUMP will show 0x260 has changed from D1h to D3h plus Legacy checksum has been recalculated.
113-C8800100-103 ROM + with UEFI/GOP 1.60.0.15.50 > DUMP will show 0x260 has changed from 73h to 71h plus Legacy checksum has been recalculated.
113-C8800100-107 ROM + with UEFI/GOP 1.60.0.15.50 > DUMP will show 0x260 has changed from 65h to 67h plus Legacy checksum has been recalculated.
Here is >link< to zip for above tests/dumps.
All the tested ROMs in new zip will post when CSM=ON SB=OFF. Only 113-C8800100-102 Non UEFI ROM and 113-C8800100-102 + with UEFI/GOP 1.60.0.15.50 will not post when CSM=OFF SB=ON.
On Hawaii I saw no change between flashed and dumped ROM.
As to other modders not moaning I can only think many may not be using "pure UEFI" mode, I will ask some other members to do some tests.
If there is further testing you would like me to do I’m happy to.
@gupsterg
Thank you for the additional tests. If the CRC (or BIOS_IDTF) is changed by ATIFlash on the fly, then it shouldn’t be at blame, only the hash would remain as the probable cause for black screen. The hash is rather difficult to reverse, if there is nothing linked to it. A BSOD with a dump and the driver that caused it - might help, but I understand that this was in the past. If the GOP does check this hash, it is difficult to find where it happens, if no error or message or debug code are displayed. Unless The Stilt provides more details on the hash and how it was cracked, I don’t see where to start. The question is why they force this hash on R2xx and above, why they want to loose even more market share?
But here is the weird thing in your tests. ATIFlash also fixed the CRC in stock ROMs, the untouched ROMs from OEMs? Then what is the purpose of this field, if it gets updated before flashing, instead of being used to validate the image? Next to that, if AMD/OEMs don’t bother with updating those integrity fields, why do they force them on users? If the 8-bit checksum and CRC can change without affecting the hash, it would imply that the hash must exclude them from calculation.
If you are willing, I can think of some tests to figure out CRC:
- Test 1 would be with original VBIOS, changing just a byte in the Date (offset 0x50 or so), flash, dump and compare.
- Test 2 would be with original VBIOS, changing just a byte in the Code Revision of ROM (offset PCIR + 0x12), flash, dump and compare.
- Test 3 would be with original VBIOS, changing just a byte in the padding between Legacy and EFIROM, flash, dump and compare.
All tests must be done with CSM=On, but you can also test them with CSM=Off on a card that had UEFI from factory. This should tell us what are the margins of the region used for CRC (and maybe hash). For a definitive solution to CRC, it would require someone with a spare hardware, disassembly knowledge, a live debugging of ATIFlash when flashing and some comments or breakpoints around the function I indicated just 2 messages back. This is rather dangerous and I wouldn’t recommend anyone doing this unless they have all the cards in their hands.
Thanks, lordkag for this post.
I have the graphics card: Sapphire HD 7970 OC Boost.
I have 2 questions:
1) You think it’s okay to upgrade my video card (I followed the directions I had no errors, and attach screenshots of the result and the original rom)
2) My card has 2 bios (original rom attached and the result is the standard BIOS 950/1425) but I want GOP for bios 2 too (1000/1450).
You think it’s okay/safe to add UEFI to BIOS 2 too (is overclocked by Sapphire) or you think I should only change just one BIOS … and which ones?
Sorry, English is not my native language …
VBIOS_ORIGINAL_GOP.rar (137 KB)
capture.rar (63.1 KB)
Just a small update on the AMD side. It looks like the GOP has a SHA-1 function and it can’t be used on itself, because there is no hash on the GOP and it would be idiotic to verify itself.
It is most likely done on the Legacy ROM, the only thing left to determine is its boundaries and how it transforms from SHA-1 (160 bits) to Some_Hash (128 bits). For the first part we have the tests I suggested to @gupsterg , for the second part there is patience and luck. Still, a very weak security measure from AMD part, that has more chances to annoy its loyal users than to protect.
@coolbreeze
1) Yes, it is OK to update your card. Furthermore, your card doesn’t seem to be affected by the hash check that AMD has added on the latest generation of cards.
2) It is your choice. Whatever you decide, test with one VBIOS at a time, make sure everything is in order on the UEFI side. Only after you are satisfied with the result on the first VBIOS, can you test with the second one. This is just a safety measure, not something enforced.
Thanks, I’m more encouraged to update now.
I’ll try first with Vbios 2 (overclocked).
@lordkag
I have done the 3 tests .
113-C88100-107 date change post .
113-C8800100-107 code revision change not post
.
113-C8800100-107 padding area between legacy & efi change post .
>Link< to ZIP with flashed ROMs & DUMPs.
Above tests are "pure UEFI" mode, any modified ROM regardless of mod mobo will post with CSM=ON, SB=OFF.
Again thank you for your further info and time
and if there are other tests you would like me to run let me know.
.113-C8800100-107 code revision change not post
.113-C8800100-107 padding area between legacy & efi change post
.>Link< to ZIP with flashed ROMs & DUMPs.
Above tests are "pure UEFI" mode, any modified ROM regardless of mod mobo will post with CSM=ON, SB=OFF.
Again thank you for your further info and time
and if there are other tests you would like me to run let me know.
Yes, 113-C8800100-103 was supplied by Sapphire support when I stated the card has come with a Non UEFI ROM and I require UEFI version. 113-C8800100-107 is provided by AMD on community site, >Link<. rhallock is Robert Hallock - Head of Global Technical Marketing at AMD.
Only 113-C8800100-102 (Non UEFI stock ROM) was not changed in it’s unmodified state. This ROM has been on all 6 Fury X I have bought at various times, I have had MSI / Sapphire branded cards. Other than box/stickers they are all the same cards down to the PCB.
No idea :(.
If I flash the dump of a stock 103 or 107 ROM there will be no change of Binary BIOS_IDTF by AtiFlash.
If I flash the dump of a modified 103 or 107 ROM there will be no change of Binary BIOS_IDTF by AtiFlash.
If I flash the dump of a modified 102 ROM there will be no change of Binary BIOS_IDTF by AtiFlash.
When a dump is flashed and "pure UEFI" mode is set on mobo, mobo post results do not change as highlighted in spoiler above and spoiler "My tests" in post 270.
The Binary BIOS_IDTF change on 1st flash (exc. stock 102) or no change result when flashing dump result is the same regardless of:-
i) any Fury X I flash.
ii) regardless of time/date I flash card.
iii) regardless of flash via GUI or CLI AtiFlash.
iv) the dumps will show change if it occurred during flashing regardless if I use GPU-Z or GUI AtiFlash or CLI AtiFlash to dump ROM.
v) the Binary BIOS_IDTF change on 1st flash of a ROM will be same value regardless of method of flash and time/date.
I would concur with this from my test data.
*** edit ***
I think I know why 113-C8800100-102 is not changing between flash and dump when not modified, 113-C8800100-102 is dump of what came from factory on every card, so Binary BIOS_IDTF would have changed when it was flashed. So reflashing it will not change, we already know this from my test data of flashing dump of stock provided ROM 103 & 107 .
FYI: Updated and working.
I think that the changes in either updGOP 1.9.4 or 1.9.5 (For the Radeon microcode relocation) broke at least UEFI GOP on my Radeon 5770. Recently tested my Juniper.rom (Which I uploaded here) upgraded with 1.9.5 and the resulting ROM (Size is 137 KiB) doesn’t work in QEMU when doing Primary VGA Passthrough, while the old one made with 1.9.3 (Size 186 KiB) does. The Monitor simply doesn’t turn on, it should do so and display the OVMF/TianoCore Splash Screen, but does not.
Since I tested this like two weeks ago or so, I forgot the details (Had to write this earlier…), but can reproduce or test a new version if you need.
…drag&drop to GOPupd.bat, and accepting upgrading offer…
************************* GOPupd 1.9.5
Update EFI GOP
Drop VBIOS file on this .bat
Dumping info from = Juniper.rom
ID of ROM file = 1002-68B8
No EFI ROM found!
No EFI ROM found or error on decompression !!!
Extracting with GOPupd…
---------------------------------------------------------------
Processing with GOPupd…
*************************
GOP is not present!!!
AMD microcode was found at offset 0x1A000!
Do you want to update GOP to latest available? Y for yes or N for no: y
AMD microcode will be relocated to offset 0x1E000.
Fixing last-image-bit in PCI Structure of Legacy ROM!
Using AMD byte for checksum!
Fixing ID for EFI image. No checksum correction is needed.
Removing unnecessary end padding.
File “Juniper_updGOP.rom” with updated GOP 1.60.0.15.50 was written!
Update EFI GOP
Drop VBIOS file on this .bat
Dumping info from = Juniper.rom
ID of ROM file = 1002-68B8
No EFI ROM found!
No EFI ROM found or error on decompression !!!
Extracting with GOPupd…
---------------------------------------------------------------
Processing with GOPupd…
*************************
GOP is not present!!!
AMD microcode was found at offset 0x1A000!
Do you want to update GOP to latest available? Y for yes or N for no: y
AMD microcode will be relocated to offset 0x1E000.
Fixing last-image-bit in PCI Structure of Legacy ROM!
Using AMD byte for checksum!
Fixing ID for EFI image. No checksum correction is needed.
Removing unnecessary end padding.
File “Juniper_updGOP.rom” with updated GOP 1.60.0.15.50 was written!
lordkag
Recently updated my inno3D® iChill GTX 660 Ti 3GB HerculeZ 3000 with GOPupd v1.9.5 to [GK1xx - 0x10034 - Oct 9 2015 - 20044574 - 3D99EFA6].
Everything went flawlessly. Like the first time, I used the same NVFlash (WIN) v5.206.0.1 and my clear original BIOS backup (without GOP) as base.
Thank you for your smart thing. Wish you all the best!
Here’s a new GF10x GOP. 0x1002B. ROM dumped from Gigabyte GV-N730-2GI card.
Many thanks for your tool. I’ve used it on a few cards.
GF10x_new_GOP.zip (116 KB)
@ Lordkag, I went ahead and did my (TRY) the novice way and I’m here for the Master to verify if its a success but I think in my opinion the file came out to big to flash. So if everything its a go from your opinion but beside the size of the file for flashing, then I ask you, if I do the vbios backup through NVFlash I shouldn’t get an increase of vbios size plus don’t have to do this extra step that you mention, " if your VBIOS comes from a dump, you must remove the end padding, so that the flasher doesn’t complain about the big size of the file."
