Is there any body test BDC_ATR_Restorer and fixed

007.4

VIP
Messages
364
I've said this many times before. My BDC_ATR_Restorer script will NOT fix a card that has been hit with a time-bomb file.
If you have used a time-bomb file (one from December) and your card has no ATR, then it is permanently dead. No one can fix it. Sorry.
007.4
 

007.4

VIP
Messages
364
Ok thank you we will wait for a new fix atr. .... if there
If, as we suspect, the card bootloader has indeed being wiped, then there can never be a fix.

Imagine trying to load an OS (like WinXP or Vista) to a PC without a BIOS. It's impossible. :(
 

jojor

Senior Member
Messages
114
If, as we suspect, the card bootloader has indeed being wiped, then there can never be a fix.

Imagine trying to load an OS (like WinXP or Vista) to a PC without a BIOS. It's impossible. :(

Could you please explain us exactly the mechanism of card's bios deletion. What happened on 0E25 date ??
 

007.4

VIP
Messages
364
Well I do not know the exact mechanism but I suspect the same method is used to kill the card as we use to virginise a card. The difference being instead of writing a valid bootloader the boot area is just filled with FF's (or possibly 00's).

So on the trigger date (0E25) the killer code is activated and the FF's for the replacement bootloader loaded into an unused area of eeprom. The code will also get the card to enter supervisor mode when required.

Next time the card is hard reset (de-powered/powered - eg when putting the card in a programmer to re-program it) the killer code is run and the OS is deleted and the FF's are copied from eeprom to the bootloader offset.

So, instead of a good OS or bootloader giving an ATR the card has no BIOS = NO ATR = DEAD.

007.4
 

jojor

Senior Member
Messages
114
Well I do not know the exact mechanism but I suspect the same method is used to kill the card as we use to virginise a card. The difference being instead of writing a valid bootloader the boot area is just filled with FF's (or possibly 00's).

So on the trigger date (0E25) the killer code is activated and the FF's for the replacement bootloader loaded into an unused area of eeprom. The code will also get the card to enter supervisor mode when required.

Next time the card is hard reset (de-powered/powered - eg when putting the card in a programmer to re-program it) the killer code is run and the OS is deleted and the FF's are copied from eeprom to the bootloader offset.

So, instead of a good OS or bootloader giving an ATR the card has no BIOS = NO ATR = DEAD.

007.4
So why the same procedure cann't be followed again via a script ???
What I mean is to write to the boot area the OS of the card if the os of the card could be extracted from a "plain"-not decrypted bdc file.
 

007.4

VIP
Messages
364
If the card has no bootloader you cannot communicate with it at all. A script to load an OS (assuming you have one) can only work if there is a working BIOS to accept the instructions.
 
Top