SATTROY3M
07-11-2006, 09:29 PM
:) MESSAGE TO FTA-ATMEGA-ROOM 101,ROOM 10/11 USERS.
"I hope this is going to quash some rumors and speculation.
Blocker stops DN from changing data on the card, FTAs can't be changed this way, have to plug them into a computer, so no blocker needed, a blocker does not get you any channels.
This latest change has nothing to do with speed or memory size
This is the simplest way I can explain why there is no fix yet:
In a DN card there are 2 MAPs(math processors), that I know of there probably are more, these MAPs change numbers, or modify number strings.
They use irreversible math, so even though you know the number going in and the number coming out you can not determine what math was used to make that change, so you can't duplicate it just by knowing the answer.
The MAPs are readable, but it takes awhile to get each step.
The MAPs themselves can be modified by outside settings; this makes these MAPs multi-level if you will.
So its not just a matter of getting one read of a MAP and your done.
Now to have an FTA fix you need both MAPs and all possible combinations of those, this will take awhile.
For cards you need none of this, the MAPs are built-in, so you don't need to know squat about what’s going on inside the card, this is why card sharing works.
DN has never tried to stop FTAs from getting their channels until now; it does not surprise me that a fix will take some time.
Until now all they did was fake packets and changed the auto-roll signature, so basically they did nothing.
The rev108 update shut down the FTAs for a few days using a few MAPs calls, the rev109 update still has them shutdown using many MAP calls, for how long who knows but they will be back up, at least until rev10A.
I am sure the coders appreciate all the suggestions offered by non-coders but they know where the problem lies, it’s just a matter of getting the info".
"Don't let the FTA makers pull the wool over your eyes. Don't believe them when they say the fix is taking so long because "we have to read through 155 pages of prime number theory, AES ciphering" or "the new bin required is so mA$$ive the coder is exhausted" or my personal favorite "Mr. Viewsat will be putting 1 Canadian and 1 Korean in the same room with a electron laser scope". Complete and utter kaka. The reason FTA, Atmega, Armulator, ROM101, ROM10/11 and everything else (except ROM102) is down is because of these two lines of code:
936E: lda #$57
9370: jsrp #$00, $A822
That’s it! Those buggers are causing all this chaos. That code is A$$embly. A$$embly works by calling and executing various instructions.
The instruction at line 936E: lda #$57 means "load register a with the value 57". The instruction at 9370: jsrp #$00, $A822 means "okay, jump-to-routine MAP function that was loaded in register a, namely 57". So basically, those two lines of code execute something called MAP 57. The problem is, WE DON'T KNOW WHAT MAP 57 is. That is why Mr. Viewsat and the other FTA makers are sweating right about now. You see, without knowledge of MAP 57 their gravy train will run away soon. For those that say, "well, the FTA people will figure it out, don't worry". Start worrying.
Think of MAP 57 as a kind of black box. There is an input to the black box and an output. The idea is to try and figure out what this black box does. For example, if we input 2 and the output are 4, if when we input 3 the output is 6, if when we input 4 the output is 8, then we may reasonably deduce that this black box just multiplies the input by 2. That was easy. The real MAP 57 takes 128 bytes of input, another 16 bytes of input and magically produces a 128 byte output."
"I hope this is going to quash some rumors and speculation.
Blocker stops DN from changing data on the card, FTAs can't be changed this way, have to plug them into a computer, so no blocker needed, a blocker does not get you any channels.
This latest change has nothing to do with speed or memory size
This is the simplest way I can explain why there is no fix yet:
In a DN card there are 2 MAPs(math processors), that I know of there probably are more, these MAPs change numbers, or modify number strings.
They use irreversible math, so even though you know the number going in and the number coming out you can not determine what math was used to make that change, so you can't duplicate it just by knowing the answer.
The MAPs are readable, but it takes awhile to get each step.
The MAPs themselves can be modified by outside settings; this makes these MAPs multi-level if you will.
So its not just a matter of getting one read of a MAP and your done.
Now to have an FTA fix you need both MAPs and all possible combinations of those, this will take awhile.
For cards you need none of this, the MAPs are built-in, so you don't need to know squat about what’s going on inside the card, this is why card sharing works.
DN has never tried to stop FTAs from getting their channels until now; it does not surprise me that a fix will take some time.
Until now all they did was fake packets and changed the auto-roll signature, so basically they did nothing.
The rev108 update shut down the FTAs for a few days using a few MAPs calls, the rev109 update still has them shutdown using many MAP calls, for how long who knows but they will be back up, at least until rev10A.
I am sure the coders appreciate all the suggestions offered by non-coders but they know where the problem lies, it’s just a matter of getting the info".
"Don't let the FTA makers pull the wool over your eyes. Don't believe them when they say the fix is taking so long because "we have to read through 155 pages of prime number theory, AES ciphering" or "the new bin required is so mA$$ive the coder is exhausted" or my personal favorite "Mr. Viewsat will be putting 1 Canadian and 1 Korean in the same room with a electron laser scope". Complete and utter kaka. The reason FTA, Atmega, Armulator, ROM101, ROM10/11 and everything else (except ROM102) is down is because of these two lines of code:
936E: lda #$57
9370: jsrp #$00, $A822
That’s it! Those buggers are causing all this chaos. That code is A$$embly. A$$embly works by calling and executing various instructions.
The instruction at line 936E: lda #$57 means "load register a with the value 57". The instruction at 9370: jsrp #$00, $A822 means "okay, jump-to-routine MAP function that was loaded in register a, namely 57". So basically, those two lines of code execute something called MAP 57. The problem is, WE DON'T KNOW WHAT MAP 57 is. That is why Mr. Viewsat and the other FTA makers are sweating right about now. You see, without knowledge of MAP 57 their gravy train will run away soon. For those that say, "well, the FTA people will figure it out, don't worry". Start worrying.
Think of MAP 57 as a kind of black box. There is an input to the black box and an output. The idea is to try and figure out what this black box does. For example, if we input 2 and the output are 4, if when we input 3 the output is 6, if when we input 4 the output is 8, then we may reasonably deduce that this black box just multiplies the input by 2. That was easy. The real MAP 57 takes 128 bytes of input, another 16 bytes of input and magically produces a 128 byte output."