Recently I was working on recovering data from dead (bricked PSU) Windows XP machine, which included some client certificates installed into IE 6. I plugged in a temporary PSU and tried to export the certificate, only to be told that "these certificates are marked as non-exportable, and thus the private key can not be exported".

I've done some searching around the intertubes, however the only advices I could find were related to pre-install scenarios (ie. there is apparently an option which you can check during the installation to avoid this situation).

My questions would be:

Is this a real security measure? It seems to me that you can simply patch the verification logic in IE6 (or the CryptoAPI) and force the export of the certificate / private-key

Is there a ready-made tool to do this? (for backup purposes for example)

If is so easy, go ahead, patch the verification logic of IE and CryptoAPI. If you succeed, put out a tool that exports an unexportable private key. For, ahem, backup purposes and such...

First of all the CryptoAPI and friends don't refer to files and memory only. The really strong security is implemented in hardware modules. Even a trivial employee badge and card reader that refuses to export the private key is all but unbeatable for the vast majority of use cases.

Second, even in the file system and memory world of the soft crypto providers there are layers of security. CryptExportKey is just a moniker for the real work. The real cryptographic modules are hardened against a lot of possible attacks. Afaik part of getting the FIPS compliance is to prove that they can detect tampering and such.

Maybe can you try another tool with other private keys functions : "mimikatz", it export other keys that other cannot export (non exportable, medium protected, orphan, etc..)
The "bit" is not altered on system file, only the program context is altered :)
For example, an user (not administrator) can export his own protected / non exportable keys without particulars rights.