(omg)vflash | Fully Patched nvflash from X to Ada Lovelace [v5.780]

[Deleted member 218758]

Due to recent discussions on voltage limitations of RTX 4000 series cards & the leakage (creation) of a tool with partial access
I would like to share the full version. Now that the cat is out of the bag.
It has been a work of 2 digit months, for going back and forth between testers for functionality verification & ROM/RiscV exploration.
Including novice me starting with lackluster, to zero assembly knowledge.

Spoiler: History of work

Spoiler: Q2 2022

~ elmorlabs private softrelease and attempt of progress collection

Spoiler: Remake and fixes on v5.792 // Still hunting ISSI FW lock ~ first reported success on personal "1.1"

Spoiler: Yet another remake with learned XUSB knowledge // 5.780 and cherrypick people release

Continuing on 1.1 branch forward to 1.3 (1.4 not for public use, internal and public versions differ)

Also continuing mapping out 5.814

Spoiler: Q2 & Q3 2023 // finalization of the tool (the baseline of everything upcoming) with the new findings

Newest version WIP but not really needed anymore.

Final foundation done @ 6th of August, 2023.
Many many months later, given i started with 0 knowledge.

Spoiler: Fact of work ~ confirmations

Spoiler: GTX 650 (my v-unlocked mod) ~ chip & boardID rewrite

GTX 650 to GT1030

Someday i'll replace eeprom of this card, haha

Spoiler: GTX650 to GT740

GTX 1080ti flashes to KP or Galax ~ nothing special just SSID, PCIID & BID
Flash works, but powerlayout differs and voltage handling is done via custom MCU.
Personally using STRIX LN2 Bios with open voltage. Working on making less dangerous version for the public.
And some more shenanigans which omgvflash was needed for

Spoiler: RTX 2080Ti Type-A FW locked [1E07] ISSI GALAX

And his result

Spoiler: 2080Ti Non-A [1E04] (EEPROM Locked) Consumer Vendor

Needs bit of DIY and feeding Nvidia's bird some good food;

For every user of those 1E03/4 or Engineers under us with 1E2D
Use an SPI flasher to downgrade away to VBIOS 90.02.0B

Past all of these,
Please be respectful to @Kefinator, who (i don't know for how long)
took the time to debug and track his behavior by himself.
To what i can read, with the intention against "people keeping it for themselves".

But i personally am not very incline, to trow away all my work out of the window,
Soo here it is Bit earlier than expected but sometimes unforeseen events happen.
Please be careful what you flash

The Positive side for the users​

What can we do now:
> Turing (RTX 2xxx Series) down to Geforce GPUs have full crossflash ability now.
> SubSystem Vendor to Vendor crossflash ability, as long as power headers are identical (Bellow 2000 series, it adapts on 3000-4000 series) & as long as no custom i²c or voltage controller modifications exist (3000+ series)
> Usage of this version without a ring-back server check & without a minimum-req version check
> Ability to downgrade InfoROM & XUSB FW to remove SW EEPROM lockdown // mostly a thing between different EEPROMs like ISSI or for situations with dGPU's on Laptops or similar
> As long as 32-bit & 8-bit checksum on usermod is correct, biosmod flash and bypass FE / VendorCert / XOC Cert / MasterCert ~ golden card system. Basically flash what you desire, as long as EEPROM size can take it.
> Use the patched version to talk with Falcon , in case Developer knows how to contact it & utilize Nvidia™ powrprof.dll + MUTEX // example to build AIB Control tools, like GALAX NVVDD Tool
> Basically created the foundation required to build future projects, ontop with cool features grated to MUTEX access

If it fails for you due to Nvidia's Bird Falcon sleeping, i likely can but in the current state refuse to help.
// The issue sits between sleeping falcon & sw eeprom access lock (XUSB FW) ~ blown fuse.
The damage towards Nvidia™ (workforce required to patch/rewrite) is equally as big, as the backslash to us the buyers and users of their Hardware.

Spoiler: The negative side of the medal, past this leak

Meaning,
What the release of the early versions and now this full versions have in response,
Is a hardpatch to/on Lovelace v2 onwards,
// unless NVIDIA either Copyright Strikes or looks-away & accepts the increased nvidia userbase due to more granted freedom.

The same backslash that happened past the Maxwell modding days,
5-6 years pause past Turing, & the whole shift to the Greenlight online-verified Biosdevelopement program.
A backslash which also affected EVGA's exit ~ and likely still annoys several Boardpartners to what i got to know.
// Outside of small "unverified" Vendors loosing their job with the existence of this greenlight program.

Hence i won't help from this part on further (considering, but the price we pay is too high ~ not worth it).

Also the difference between being annoying/damaging and helpful is very little
I have something bigger than this on plan - but due to what seems to be a release without precautions, i have to rush parts of the project before RTX 5xxx release.

---

To end on a high-note,​

I'd like to credit the work of all people before me, which were a big inspiration on this project

> JoeDirt from OCN ~ to his hard work during the Maxwell modding era
> Liathan from OCN ~ for being publisher and assisting modding in the Maxwell days
> Lost_N_Bios on winraid + Ket as publisher and early UEFI modder ~ for continuing aboves research till Turing. [v5.67x]

I'm not sure if those people ever got the credit they deserved;
So let me be the person that reminds you about their hard work during the Maxwell days onwards

---

The download link:​

~see attachment~
reuploaded as zip, this was supposed to be a 2ndary post, whoops

The PE-File (exe) is also checksummed and signed.
If somebody wants to add something to it - you have full permissions, as long as you credit my work
Or just request it here and i'll update, if possibility exists.
Checksum:
SHA256: 39a7bd30c61903e641afa02d03a689d8a1c4ce51fc35ac1b2b2bc51d3f42951b

How to utilize the tool fully:

Open a CMD/Powershell window with admin permission
and cd (navigate) to your target folder

.\omgvflash.exe -6 filename.rom

-6 triggers the tree of patches and bypasses herby everything


If you fail and want to check what's going on
.\omgvflash.exe -A filename.rom

Anti-Virus Report

VirusTotal

VirusTotal

www.virustotal.com

---

I would like to repeat,
Although @Kefinator (Kefi) was the person who released first & we had a preculiar situation of two developer working on a similar goal
Please do remain polite to him
Everything was cleared in private , and we are in a good contact now.

The situation was unfortunate,
But for you guys this means , releases and releases

I hope you enjoy,
Be careful what you flash

If the tool fails an your custom rom edit,
It means you do not pass both verifications
The 8-bit Checksum's and the 32-bit File-checksum
For RTX 3000-4000+ , this includes the HMAC certificate

Soo feel free to try and best of luck
Also don't flash stupid stuff and complain it won't post

How to repair a bricked card ?​

As long as your EEPROM holds any NVIDIA ROM, it is reflashable

First boot with CSM enabled, from another card.
This marks in UEFI state that card as priority device

Now turn off the PC and put your bricked card into slot two
Do keep your display out to your primary helpers card
Due to the primary card being in priority mode - it will accept boot and not fail detection

Use:
.\omgvflash.exe --index=0 -6 backup_rom.rom

And be more careful next time :)
Anything like a Lightning / Matrix / GALAX HOF card, does utilize modifications on the PCB
RTX cards do mostly adapt to memory and powerplug changes (inconsistencies) but there are limits.

 

[Dr. Dro]

Aha! So this is where the whole talk about Ada VBIOS mods have come from. @Nerboruto has been on my DMs for a few months about it.

If it only had come out a little earlier, I'd give this a spin on my old 3090... I can't wait to see what people do with this invaluable tool. Thanks for sharing. Cheers!

 

[Deleted member 218758]

His work must be something separated We never talked.
I didn't plan to publish it before 5000 series lands to market
Tho it's alright, we just need to work a bit more to complete all other branches of projects faster.
And beg for mercy by NVIDIA/AMD-HQ

 

[Dr. Dro]

His work must be something separated
I didn't plan to publish it before 5000 series lands to market
Tho it's alright, we just need to work a bit more to complete all other branches of projects faster.
And beg for mercy by NVIDIA/AMD-HQ

I must say I doubted most of his claims before, primarily because I believed there was no way around the signing keys so the security processor would block any attempts at a BIOS mod. It seems that you figured this out, which should open a world of possibilities out there. This is the real breakthrough, before a proper editor is even written.

Maybe you should DM him and see what he found? Could turn into an useful collab.

 

[Deleted member 182555]

sorry if I intrude, I'm only answering because I've been mentioned here. I have nothing to do with this tool...

 

[Dr. Dro]

sorry if I intrude, I'm only answering because I've been mentioned here. I have nothing to do with this tool...

I didn't say you did, I tagged you because it might be of interest for you.

 

[zxTheWolfxz]

Interested me! Looking on..

 

[W1zzard]

Wow this is huge

 

[hellm]

Indeed. Very good job, @Veii.

 

[TheQuentincc]

Hi, does this means a vbios manually modded with an hex editor (for instance TDP value changed by hand) can actually be used on any GPU post Pascal (with no code 43) ? or this software just allows the flash of any vbios like we already can with an external programmer ? It's pretty unclear (specially the TPU news).
Still thanks you for your hard work

 

[Deleted member 218758]

The last two posts might explain

NVIDIA BIOS Signature Lock Broken, vBIOS Modding and Crossflash Enabled by Groundbreaking New Tools

DLSS3 uses hardware fourth generation tensor cores and Optical Flow Accelerator that do not exist on 3xxx series, it's not just software Considering that their implementations are closed source we have no idea whatsoever if this really is true or not. My guess is that it more than likely isn't...

www.techpowerup.com

This is what it can do:
~ VendorID bypass
~ SubsystemID bypass
~ PCI BoardID bypass
~ BoardID bypass
~ ChipID bypass
~ USB FW check bypass
~ Mobile iGPU reflash allow
~ version check bypass
~ downgrade-lock bypass
~ Golden Card system bypass (for FE/Consumer/Engineer Board)
So i can call it a "bypass all" version.

Specific in-chip target operations, require the assistance of Falcon
Access to falcon is granted, but operation of Falcon i sadly can not tell.

The very first check, is the 8bit Header Checksum of the ROM & the 32-bit file checksum
There is a checksum for the InfoROM section and a bottom Checksum. (both 8-bit but legacy)

The purposely break of the Header Checksum is what triggers Code 43.
The purpose modification of the Powerplay Table is what breaks the 32-bit checksum. This includes memory straps change or general ROM modification.
^ Pascal/Turing
For that, it is on the modder to get things correct, or somebody makes a BiosEditor.
A BiosViewer from 1000-4000 Series may or may not be in the works. I can't code but dig and debug.
Soo any delay or the existence of it at all, is not on my shoulders - unfortunately

The Tool itself, will attempt to flash everything and progress to flash everything that is valid as a ROM File.
It is on Falcon to decide what it will push through and what it wont.
For example hard-rebrands like ChipID/SKU rebrands depend on this.
Full access on Pascal, partial access on Turing. Unable to verify due to way of securing ROMs (double signing + HMAC ontop).

Ampere & Ada (eventually Ada v2 if too late already) ~ have full crossflash but not hard-rebrand abilities.
Downgrading is allowed, and version checks are disabled. XUSB-FW & generally InfoROM updates are allowed
This basically fixes the introduced lockdowns on Turing.
Type non-A to A hard-rebrands need a lot more work, because it's not on nvflash's shoulder.
Nvflash communicates with Falcon and falcon either executes or doesn't.

Soo basically there is not much more to change on this tool, as it's already full access.
The certification checks onboot belong to the ROM itself and to Falcon.

Try it out and report back.
Sometimes it can be needed to downgrade VBIOS versions, if NVIDIA keeps introducing SW EEPROM access locks.
It will fail with XUSBFW downgrade failed, falcon halted.

---

I think i should add;
I worked back in 2021/22 with Biosmodifications on 3000 series.

The reason this thing took as much time and was important is,
Because SPI Flashes are not full flashes. Neither the flashback on your Mainboard, nor the EEPROM wipe on our GPUs.
You need access to several locations where not everything sits in EEPROM.
Then add TPM ontop, and basically the SPI / ROM-Hotswap days are gone already

This lays the foundation for future bios creations, and can/does assist Boardvendors to flash their modified versions without having to be in the position of sharing modified nvflashes.
Its not the first or wouldn't be the last time that such has happened.
The Tool itself has no advertisement in it and is made with zero revenue for zero revenue.
It is advertisement free and only includes my name in the description box, while clearly showing who's intellectual property this is.

I hope in-case i can not continue the developement of it - that it will end up useful to everyone
Yet nothing was added which didn't exist beforehand.
The goldencard "system" was modified, so that on normal operations users have access to already implemented debug operations.
Else the user would need a card which hosts a ROM with a high enough priority certificate ~ in order for nvflash to detect and allow its full access.

 

[Space Lynx]

@Veii just fyi, Nvidia is not going to be happy about this. you might want to edit original post, and just at the bottom of page just say "doing this will void your warranty" because Nvidia probably will consider it voided, but I am just guessing, I don't know much about this stuff. I know you have one disclaimer about doing it, but you don't specifically mention warranty voiding

@W1zzard not sure if this is good advice? your advice is welcome. just trying to help out.

 

[W1zzard]

A BiosViewer from 1000-4000 Series may or may not be in the works. I can't code but dig and debug.

That's pretty much what our BIOS Collection already does. Happy to add more readouts if there's something worth adding that you can think of

 

[Deleted member 218758]

@Veii just fyi, Nvidia is not going to be happy about this.

Very aware.
Its a very thin line & there isn't much difference between EVGA/GALAX sharing a modified nvflash in their update package
Or me releasing this enthusiast level of nvflash.

If i pass the line of releasing confidential software, or add modifications to their intellectual property - then call it "my software".
Thats where we have an issue and where i will burn bridges.
I don't want that.

The Tool can not flash random files that the average joe made.
Files made by a Bios editor, won't be such - but it is a different form of access.
One does not change the cards behavior or flash a custom OS.
Falcon behavior remains to NVIDIA™ property, and RiscV loads Nvidia™ proprietary software.

You are correct that one is leaning quite far out of the window.
But there remains pretty much zero difference between Boardpartners bundled nvflash.
This very much includes GALAX-TW in building their XOC tools based on nvflash & sharing them on HWBot
Now if we have to talk about 3000/4000 series and how to bypass the certification on ROM level ~ that's a completely different story

 

[Space Lynx]

Very aware.
Its a very thin line & there isn't much difference between EVGA/GALAX sharing a modified nvflash in their update package
Or me releasing this enthusiast level of nvflash.

If i pass the line of releasing confidential software, or add modifications to their intellectual property - then call it "my software".
Thats where we have an issue and where i will burn bridges.
I don't want that.

The Tool can not flash random files that the average joe made.
Files made by a Bios editor, won't be such - but it is a different form of access.
One does not change the cards behavior or flash a custom OS.
Falcon behavior remains to NVIDIA™ property, and RiscV loads Nvidia™ proprietary software.

You are correct that one is leaning quite far out of the window.
But there remains pretty much zero difference between Boardpartners bundled nvflash.
This very much includes GALAX-TW in building their XOC tools based on nvflash & sharing them on HWBot
Now if we have to talk about 3000/4000 series and how to bypass the certification on ROM level ~ that's a completely different story

I understood about half of that, you are way smarter than me, so I think you are good lol

 

[rusTORK]

Veii, man, it's good to see you here! Helped me with DDR4 timings, now with GPU? =))

 

[TheQuentincc]

I tried modding Pascal vbios back in 2019/2020 so my memories are a bit old, also information about vbios modding is very sparse, I pretty much stopped looking into vbios modification after LaneLyng works on "Mobile Pascal TDP Tweaker" and previous adventure of Dreamonic on voltgrounds forum.
My last memory about this period was prema mod successfully made a customized vbios for a mobile Quadro P5200 (stock vbios is running with low clocks and his vbios uses way higher 1070/1080s clocks).

So your tool have nothing to do with the certifications checks on boot and the magic trickery Nvidia does when manufacturer are validating their vbios ? it just allows more "nvidia approved" to be flashed on any GPU ? Or else it does flash the eeprom but also part of the core/Falcon firmware to allow the modified vbios to work ?

Actually I'm not really aware if we have the full knowledge on how the checksums in nvidia vbios works at all, so that we can't modify whatever we want and then fix the multiple checksums ?

 

[bug]

Just noting, but while the section that explains how to recover from a failed flash mentions CSM, some of the newer video cards will not boot in CSM mode. Not many, so not a huge problem atm, but possibly a bigger problem going forward.

That said, great stuff and thanks for your work!

 

[Deleted member 218758]

@TheQuentincc
Yes, i found his mobile Pascal tweaker.
Which to what i see was the initial work of the OhGodATeam (team).
NVIDIA employed one developer, and xilinx employed another. Then their data got wiped.
Then there was the initial viewer work for ABE - but , ah the backstory is a bit dark.
He worked a lot on OCN and was my grudge (reasoning) to inspire digging into nvidia's layout since now 2-3 years.

Sadly Lanelyng had the wrong offsets for consumer GPUs, but as for mobile GPUs - it works.
Its a bit absurd why Pascal and so Turing, never took off. For 4-5 years, zero.
But i guess the introduction of the online Bios-toolkit programm for both Vendors, caused a lot of shift in the industry.
I'm still holding a grudge to RDNA2/3, and play with the idea how to release there the rebrand exploit (which i found).
Which actually is an exploit, unlike here. But let's talk Nvidia for a bit

The certification checks are inside the customOS the RiscV (GPU) runs at.
Guardkeeping is Falcon. Nvidia's Bird which is responsible for processing MUTEX commands, API calls, manages remain driver calls and responsible for the flashing procedure.
Handling EEPROM, handling RT cores and managing? other accelerators. Holding instructions for the VFT-Curve and so on.

Talk to Falcon happens with nvflash and with external methods.
Talk to the chip itself happens with external methods. SW or HW.

Biosmods are just a shell of data , which contain blobs of API calls, raw data and other bigger instructions/identifiers ~ which can not fit inside the little OS.
This includes the I/O matrix, powerplug amount, i²c identifiers and remain libraries, memory straps, shader identifiers and couple more VFT curves for several clock's.

The tool bypasses the checks that are done, before the flashing instruction is given to falcon.
Sure it misses the checksum checks, but in reality the integrity of the ROM file depends on itself and is checked on low level (on card)
Its just fast computed by nvflash, before it is pushed forward.
This check remains, soo if it says invalid file-image, then indeed it is a user file error.
// EDIT: I could fix that, but should i even ? Its better to have some sort of protection and indicator if your Mod has any chance of booting or not

I've experimented (in the process of) flashing and rebranding pascal.
Sadly there is not much to rebrand or unlock with a 1080ti ~ but a wrong header checksum wont fail flash.
A wrong 32bit file checksum, aka file identifier ~ this will halt flash.
A wrong signature , actually i dont know on this one given there is a Cert2.0 bypass from founders ~ but should also halt flash.

If the tool validates your ROM, it will attempt to flash.
It will continue till the very end (you need to confirm every missmatch step)
~ till falcon either accepts the flash, or refuses the flash (mostly/only on DevID/SKU rebranding)

This custom version can autosign couple of stuff too, but you can figure it out
It will only utilize Nvidia's servers like the public version, for signature generation. If needed
It will not sign it but you can make your HULK check, or replace InfoROM + CS fix it, if you have good contacts at Nvidia ~ for their Server to sign it.
Then you can import it either into the card or the rom itself.

Bios signing is not handled by nvflash.
The request/generation and communication is handled with it + falcon.
Also tools that modify things like MVDD/FBVDD are running through nvflash and its dll's ~ well its ability to communicate with falcon , which executes given calls.

Just noting, but while the section that explains how to recover from a failed flash mentions CSM, some of the newer video cards will not boot in CSM mode. Not many, so not a huge problem atm, but possibly a bigger problem going forward.

It is one of the ways i figured out.
It likely makes it even easier, using an APU, soo the only card that can be identified is the half-dead bricked card.
As long as anything is detected in the DeviceManager ~ you can reflash it

The CSM trick is to skip the failed UEFI-PCI check.
Else it won't allow you to post with a "bricked" card.

---

My Kepler is still braindead.
I had fun with rebranding a 650 to a GT730 or a 1030
Tool can do that. It can also on Pascal and half-way on Turing
All depends on Falcon's mood.

But the core ability to communicate with it, is given
You may or may not need to find old VBIOS versions that allow , or push it a bit with other methods.
omgvflash tool is there to assist with pushing. Yet it's not its work
It's work is to forward the flash commands, forward the file and let falcon give an OK

This "ok" is needed only for hard-rebrands
Nothing small like a Vendor'rebrand, or a signed XOC bios and other small stuff.
For example removing the 2080ti Type-A downgrade/flash lock , which was supplied by new vbioses.

 

[agent_x007]

Does it work with Volta ?
(Making "GeForce Volt"[tm] out of Titan V sound interesting )

 

[Deleted member 218758]

Does it work with Volta ?
(Making "GeForce Volt"[tm] out of Titan V sound interesting )

Try and report
All sorts of ChipID mismatches, are hard-rebrands.
It's not nvflash's work to approve or deny.
Well it can deny, but it won't deny.

If falcon listens, is on you
Try and report back a screenshot attempt.
It will also warn you if EEPROM size is too small.
Its enthusiast but not thaat dangerous~

 

[HyenaDae]

Awesome tool, I still have some silly questions though it is very early. Basically reflashing non-OC models to OC Models (assuming you actually have stock-stable silicon) is back on the menu?

I'm assuming that custom BIOSes by individuals for voltage and frequency tweaking is not doable due to the whole signature+checksum verification issue, right? And, we cannot flash say an RTX 4060M to allowing slightly over 1.0v to 1.1v because of the above issues?

Just curious... I read there's an 8 bit and 32bit checksum, what algorithm does Falcon/NV use and how much processing power, if any is even feasible to find a collision based upon 'garbage' being added (or semi-random adjustments, but in-range settings values) to make things match, lol. Not sure if I can ask this either, but recalling to a certain accidental 'open-sourcing' incident last year, do you know if the potentially leaked signing certs for the BIOSes and their Driver are compatible (if even needed later), though I doubt it.

 

[Michael_O]

I'm interested in whether we'll soon be able to flash consumer cards like the 3090 etc in to their pro quadro counterpart.

 

[Deleted member 218758]

Awesome tool, I still have some silly questions though it is very early. Basically reflashing non-OC models to OC Models (assuming you actually have stock-stable silicon) is back on the menu?

Yes, and jumping the 1.1v route back.
Anything nvflashk tool can, this can (to this date) but with double the featureset.
It released a bit early

Please don't ask me about Falcon's algorithms, RiscV topic or leaked/stolen intellectual property.
If i start to talk about similar topics, i can leave this industry. I wouldn't want to I'm neither a rebel nor a leaker.

Do not flash Matrix/Lightning/Kingpin/HOF OC-Lab bioses to unsupported PCBs.
Their voltage controller layout differs strongly and a lot is managed by 3rd party MCU, where your card has no way to simulate that.

EDIT:
Bellow 2000 series, please match the 8pin amount and i/o display out.
Those card could not auto adapt. It is ok with 3000-4000 series

 

[mouacyk]

Wow this is huge

Not really, unless it can restore the glorious days of Maxwell BIOS editing