@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 ...
[[File:VBIOS_ORIGINAL_GOP.rar]]
[[File:capture.rar]]

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 :) .

Zitat

---

But here is the weird thing in your tests. ATIFlash also fixed the CRC in stock ROMs, the untouched ROMs from OEMs?

---

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.

Zitat

---

Then what is the purpose of this field, if it gets updated before flashing, instead of being used to validate the image?

---

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.

Zitat

---

If the 8-bit checksum and CRC can change without affecting the hash, it would imply that the hash must exclude them from calculation.

---

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 .

Zitat von Dionysos im Beitrag #261

---

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. :)

---

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...

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.

@ 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."

I have a Gigabyte GTX 770 4GB (WF3X OC Rev 2) @ FW368.81 and despite GPU-Z showing my card as UEFI-capable ("UEFI" Checkbox checked) I couldn't install Win7 (Ultimate, x64, SP1 - Setup-DVD launched from UEFI-BIOS) with CSM turned off - I always get an error message, telling me that either my system or some component is not fully UEFI-compatible. So I had to keep CSM turned on in order to install Win7.

Now, do I need to install a GOP Driver or not? I found User reports on Google complaining GPU-Z shows their card as UEFI-capable while it is actually not (AMD Radeon Fury, for example) - they had to additionally install a GOP Driver in order to get their card truly working...

So far for now...

AZ

@gupsterg

I believe I was in debt with a response for your generous tests. I tried in the first two days to crack either the CRC or the hash, failed miserably, then I postponed the project for some side projects I have (one of them being HP and Toshiba encrypted BIOS images, which ironically it was easier to crack), then personal life came in the way.

What can be deduced from your tests is that Hash comes first and only for a portion of the Legacy image, then CRC for most of the Legacy image, then 8-bit checksum for the entire Legacy image.

CRC is most likely used as internal integrity check, probably during boot, which would explain the use of a faster CRC and the correction during flashing. It has zero use for us, maybe just a nice bonus if we can crack it. For the hash, I'm seeing yet another reference <here>, but this hash cracking seems to be more elusive than a state secret. What I did found, eventually, is that RBE had some findings. I don't know if it was really tested, but they offered a hash bypass for some cards, in Additional features -> Method 1 - Hash. By doing some tests, it appears they were using just these sections:

50h -> 93h = 44h bytes
ATOMBIOS -> ATOMBIOS + 28h = 29h bytes
FirmwareInfo - > FirmwareInfo + 4Fh = 50h bytes

It is obvious that things have changed and at the very least the PCI Structure is included. It is also obvious that they didn't knew too much, seeing how they also included the CRC field, which is why I questioned if it was ever tested. But this shows that only specific regions are protected, not all the ATOM Tables. Inspecting the driver could be more useful than disassembling the GOP, but that thing is a monster and I would need a dump from a BSOD related to signature check. I have done some steps on the GOP and I believe I have found a way to patch this check.









Either this is the hash check or it is for COPP protected content, but I doubt COPP would kick in that soon. To test it, use either Test1 or Test2 (if Test1 fails) to replace the file in GOPupd -> #GOP_Files, update one of your custom ROMs with this patched GOP. The test must be done with CSM=OFF (to activate UEFI and hash check), Fast Boot = ON/OFF (don't think it matters) and Secure Boot = OFF (since I modified the GOP and invalidated its signature). If it works, a similar patch can be done for the driver. If and ONLY if the above works, I would need a copy of atikmdag.sys from someone with an RX480. Otherwise this is just wishful thinking, it is impossible to obtain something from this monster kernel driver, based on Code errors from Device Manager. Just an example, this driver contains some SMU firmwares, among other things:



Lastly, since you have posted MemoryInfo in your threads, you should consider using the updated dll and drivers from GPUTweak. From a quick look, the info is obtained through them, MemoryInfo.exe only does some interpretation of the data. If there are issues, I could look into them, but I can't make any promises for a quick reply.

@zir_blazer

First of all, I would need a copy of your original VBIOS, for some tests. I can think of three reasons why it happened:
- the hash check is also present on older cards, but doesn't include the PCI structure and you can safely use GOPupd, but no other mods like microcode relocation. However, I seem to remember that you said you already used RBE on that VBIOS? Do you remember what you modified with RBE?
- the unusual size tricks QEMU and it only loads a partial image.
- the GPU microcode is actually loaded this time and it causes an error for your boot environment.

The only difference between old working image and the newer one is the relocation of microcode and an updated pointer for that microcode. That is, the first image points to a region where there is no microcode and no microcode is loaded, while the second image is patched to point to the new offset of the microcode, thus the microcode should be loaded. Please upload a copy of your VBIOS which you intend to use and I will upload tests for each of the above 3 reasons of failing: one image with an older GOP that still fits the microcode at the original offset, one image that is rounded to 256KB, one image that points to a different microcode offset, but no microcode will be found at that offset.

@docspace

Thank you for the new GOP. Will be present in the next release, along with proper credits.

@Camp Anaconda

If it already had an EFI, the size shouldn't be a problem, as the difference is not enough to "spill" over chip space. On top of that, the replacing of an existing EFI image is a lot easier than inserting one on a non-UEFI image. You should be safe with updating.

@AbsoluteZero

The GOP is only a part of the solution. You need an EFI driver for every bootable device, which includes Lan, AHCI/RAID, GPU, NVMe, plus the usage of GPT for your drive. Without a link to your mainboard it is hard to offer assistance.

Zitat von lordkag im Beitrag #283

---

@zir_blazer

First of all, I would need a copy of your original VBIOS, for some tests. I can think of three reasons why it happened:
- the hash check is also present on older cards, but doesn't include the PCI structure and you can safely use GOPupd, but no other mods like microcode relocation. However, I seem to remember that you said you already used RBE on that VBIOS? Do you remember what you modified with RBE?
- the unusual size tricks QEMU and it only loads a partial image.
- the GPU microcode is actually loaded this time and it causes an error for your boot environment.

The only difference between old working image and the newer one is the relocation of microcode and an updated pointer for that microcode. That is, the first image points to a region where there is no microcode and no microcode is loaded, while the second image is patched to point to the new offset of the microcode, thus the microcode should be loaded. Please upload a copy of your VBIOS which you intend to use and I will upload tests for each of the above 3 reasons of failing: one image with an older GOP that still fits the microcode at the original offset, one image that is rounded to 256KB, one image that points to a different microcode offset, but no microcode will be found at that offset.

---

@lordkag

Many thanks for your time and modified GOP, I appreciate it a lot :) .

I'm not a miner but know a person who is heavily involved in mining, I will ask him to ask on mining forum if there is an app for cracking ati bios. I don't think there is, otherwise I would not be getting requests on OCN by him to help solve "signature issue" for miners with RX 480.

Thank you for the tip on MemoryInfo ;) I will update it and see if it improves compatibility for RX 480 owners. As the bios signature is a bigger issue for those owners at present I won't be too fussed about MemoryInfo and will not ask you to spend your time on it :) .

I added the GOP from folder Test1 to GOPupd and then updated a custom non UEFI ROM I use 24/7. I can report it PASSES testing (SB = OFF FB = On CSM = Off) mobo posts and enters UEFI :D . If I enable SB then mobo will show this on-screen. As Windows 7 UEFI will not load up with CSM Off I'm gonna install Windows 10 and see what goes on :) , if your Test1 GOP passes Win 10 OS load test I will get some other Fiji owners on OCN to test and report back to me.

Here is a Zip, it contains my Custom Non UEFI ROM (custom.rom), that updated with stock GOP and the test1 GOP.

*** edit ***

Did fresh install of Win 10 (SB = OFF FB = On CSM = Off) using custom rom with test1 GOP and all successfully installed :D (System information > Bios mode: UEFI :D ).