I'm a Mac and Linux user, not a Windows type, but had to build a Windows system (I had XP lying around, so used that) in order to use the Radeon BIOS Editor (RBE), ATI WinFlash, TechPowerUP GPU-Z, and HP bootable USB flash drive tools. AFAIK, there is no substitute for RBE and the ATI flashing tools (ATI WinFlash and the DOS-only Atiflash) that works under Linux.
However I have enough Windows experience to do some digging - and checked out the errors thrown off by the Windows Catalyst drivers when an altered card was 'blocked'. I didn't need to go farther than the Event Log to find a load of messages relating to 'checksum' and 'card identification' and 'code signing'.
It's not *any* change that will trip the Windows Catalyst drivers though. It's mainly the 'Maximum Overdrive Limit', and the standard clocks. The problem with the 1GB 6950 cards is that most have a hard-coded 'Maximum Overdrive Limit' of 840 MHz core clock. Hence the weird behaviour when clocking above this number with AMDOverdriveCtrl in Linux - the clock is reported as higher, but the hashrate actually DROPS when mining. This hard Upper Limit needs to be removed. I'm sure Windows does it - but the problem is that the Linux Catalyst drivers (from 11.6 upwards) also DO respect the Overdrive Upper Limit - either that, or it's a BIOS thing and the card itself ignores requests to go faster.
Now you can use RBE to alter the Maximum Overdrive Limit, but on 69xx cards, it's *this* data that's signed by AMD, IMO. Either signed, or checksummed, or something that the drivers look up against each card model. Changing the manufacturer in RBE often causes all sorts of artefacts and is unwise (different RAM speeds, voltages, etc.). So using the 'second' RBE method to remove the 840 MHz Maximum Overdrive Limit (for core clock) cannot be done - the new values don't match the checksum and even the Linux driver won't allow the card to be used.
You have to use the 'first' RBE method - which takes a hashed and checksummed portion of the BIOS that contains the 'Maximum Overdrive Limit' and overwrites your *original* BIOS with the data. Of course, this is useless unless you have a card with a higher Maximum Overdrive Limit core clock from the factory. Fortunately there are such cards about - the Asus DirectCU II has a maximum core clock of 950. So I extracted *this* data using RBE, and pasted it into the OEM BIOSes on my Sapphire and XFX versions of the 6950. Along with a shader unlock, all cards flashed fine and also booted fine into Windows (test) - working perfectly in Linux at 900+ core clocks.
The trouble is getting the memory clock lower than 100 MHz less than the core clock - something I'm still working on
Incidentally - any 6950 cards I've seen with the switch for dual-BIOS operation will flash correctly within Windows using RBE and ATI WinFlash. The cards without the switch (Sapphire and XFX rev.2) will flash perfectly but you have to boot to DOS and use ATIFLASH.EXE. You'll get the 'Cannot Erase ROM' error in Windows. The cards with no switch that work use the PM25LV010 flash controller.
TL;DR - forget changing clocks in RBE, the only important factor is the 'Maximum Overdrive Limit' (you can change clocks using your favourite overclocking tool later). Changing this the normal way will duff up the card. You need to get the checksummed / signed Max OD Limit from a card that has high OEM limits (e.g. Asus DirectCU II, with 950/1350 Max OC Limit) and patch it OVER the OEM BIOS. Then unlock the shaders (in RBE), write the new ROM to a file. Depending on card type, flash in Windows or boot to DOS and flash with ATIFLASH. The card will perform as standard... but you'll be able to overclock all the way to the new, higher maximum limit