ROM1x_dataspace_fix

[irratic]

i had to run one card back threw the script again mate. it opened in nagra then....

 

[mrjai66]

thanks but i tried that mate but it just says something like this card does not have a bad dataspace pointer and the script stops ,but thanks anyway
jai

 

[wonko]

in that case it may not have a bad dsp m8

 

[hackmax]

pmsl @ wonko !!!!!!!!!!!!!!!!!

 

[mrjai66]

no it did have have a bad dataspace but ran it through script and it apprantley fixed it but when i try and read through nagra or xncs it wont read just says bd3 login failed or card may hve update or disabled ,does not matter anyway but was fun getting datspace back lol,,

 

[edcase]

no it did have have a bad dataspace but ran it through script and it apprantley fixed it but when i try and read through nagra or xncs it wont read just says bd3 login failed or card may hve update or disabled ,does not matter anyway but was fun getting datspace back lol,,

If you no longer get the 6985 response to a normal class A0 command,and the card's revison has apparantly changed then the D7 must have executed correctly (the dataspace pointer will be fixed and the bugcatcher table size will still be zero - open card!). The only thing that could be stopping nagra from reading/writing the card must be some unusual tier arrangement in your dataspace. This will sometimes cause nagraedit to try to log in with an incorrect systemID. Try using XNCS instead.
MROM may also be a good cure - unless it activates the bugtable for any reason (although I cant imagine why it would)

edcase

 

[jumpinjo]

no it did have have a bad dataspace but ran it through script and it apprantley fixed it but when i try and read through nagra or xncs it wont read just says bd3 login failed or card may hve update or disabled ,does not matter anyway but was fun getting datspace back lol,,

sounds like card needs glitched open

 

[hackmax]

No. If it was not open before it would be toast!!!!

If it's run through the script it will be open. The backdoor keys are the problem. XNCS or MROM are the best bet.

 

[gentlex]

woow talk about a stroke of luck had a bad data card meant to chuck it out a week ago along with my no atr cards.. just found this thread 20 mins ago, and now the card is back to life thanks david.... i think i will hold on to my 4 no atr's a bit longer u never know they might get a 2nd chance @ life too..

 

[tonmedia11]

Just out of curiosity, has anyone checked what the otp tag area shows at c022 on a repaired card.

 

[michael1]

Just out of curiosity, has anyone checked what the otp tag area shows at c022 on a repaired card.

it shows 06 as it should .

 

[tonmedia11]

Cheers, I probably should have loaded the script and read the haeder first. I just wasn't sure about stopping the card getting killed right away again as i thought otp would be marked as 06.

 

[edcase]

Cheers, I probably should have loaded the script and read the haeder first. I just wasn't sure about stopping the card getting killed right away again as i thought otp would be marked as 06.

If the card was one that went to datapointer is bad in november when it executed the killer emm sequence then $C022 will be marked 06. This is the flag that will trigger the killer EMM to execute again even if the card is re-written with an image that passes the current checks. If your card is marked with 06 then it will require a blocker of some description, either to prevent the killer emm from executing, or preventing it from writing the kill into codespace.

This script will also repair some "dataspace pointer is bad" cards that did not take the killer emm but were somehow corrupted by glitching. Note I said some - if it gives the 6900 response to the D7 (backdoor blocked) then it wont work. If it gives the 6300 (incorrect password) then it will work.

edcase

 

[maca]

If the card was one that went to datapointer is bad in november when it executed the killer emm sequence then $C022 will be marked 06. This is the flag that will trigger the killer EMM to execute again even if the card is re-written with an image that passes the current checks. If your card is marked with 06 then it will require a blocker of some description, either to prevent the killer emm from executing, or preventing it from writing the kill into codespace.

This script will also repair some "dataspace pointer is bad" cards that did not take the killer emm but were somehow corrupted by glitching. Note I said some - if it gives the 6900 response to the D7 (backdoor blocked) then it wont work. If it gives the 6300 (incorrect password) then it will work.

edcase

when you say c022 is this it in the eeprom
C020: 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 this is from a card that reported cam date failed ran it through the data pointer fix and is ok is there any way to remove this flag or do you need a blocker image for it hope im not sounding a bit thick thanks : colors1

 

[michael1]

when you say c022 is this it in the eeprom
C020: 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 this is from a card that reported cam date failed ran it through the data pointer fix and is ok is there any way to remove this flag or do you need a blocker image for it hope im not sounding a bit thick thanks : colors1

you need to use a blocker image as it will take the killer emm .

 

[afcwomble]

Hi guys-I have just run this card through and it repaired it. It wasn't a card hit but one that was screwed up prob by myself sometime ago. When read now it gives the OTP area as below-is this still OK to use or will it give problems?

C020: 03 BF 74 00 F4 3D 00 00 00 00 00 4E 69 70 50 45

Thanks

 

[edcase]

Hi guys-I have just run this card through and it repaired it. It wasn't a card hit but one that was screwed up prob by myself sometime ago. When read now it gives the OTP area as below-is this still OK to use or will it give problems?

C020: 03 BF 74 00 F4 3D 00 00 00 00 00 4E 69 70 50 45

Thanks

Hi mate,

You will need to use a blocker on that card as $C022 is marked in way that will trigger the kill if you fail the tier ID check.

Your $C022 is currently 74 - 01110100

As you can see bit2 is set to 1 so it is effectively marked as 04 - 00000100

If you fail the tierID check now it will get the 02 mark added (set bit1) which even normal subbed cards get and your $C022 will then look like this 01110110 - this value gets a logic and operation performed on it with 06 - 00000110 and the result will be 06 - the card will be fryed.

You could add the tierID that the emm looks for and prevent the 02 mark but I would use a blocker to be sure.

edcase


EDIT: Also lol @ the start of the nipper string in the OTP: 4E 69 70 50 45
Guess that must have been caused by some serious crazy glitching

 

[afcwomble]

Hi mate,

You will need to use a blocker on that card as $C022 is marked in way that will trigger the kill if you fail the tier ID check.

Your $C022 is currently 74 - 01110100

As you can see bit2 is set to 1 so it is effectively marked as 04 - 00000100

If you fail the tierID check now it will get the 02 mark added (set bit1) which even normal subbed cards get and your $C022 will then look like this 01110110 - this value gets a logic and operation performed on it with 06 - 00000110 and the result will be 06 - the card will be fryed.

You could add the tierID that the emm looks for and prevent the 02 mark but I would use a blocker to be sure.

edcase


EDIT: Also lol @ the start of the nipper string in the OTP: 4E 69 70 50 45
Guess that must have been caused by some serious crazy glitching

Thanks Edcase-Yes this one was probably in my early days when I got my glitcher and wen't into it head first without reading anything properly!! I have a few other cards in a drawer somewhere with various problems, I might have a look around for them and see waht I can find.

 

[dogiatal10]

Works great, thanks to all involved, well done

 

[iamhim]

The delays that I have been using are:

Rom 10: from &h0B36

Rom11: from &h11E5

edcase

I CAN CONFIRM THEY ARE THE BEST DELAYS TO USE AND HAVE FIXED CARDS IN LESS THAN 5 MINS.