=============================================================== Till yesterday there was key morphing on the first number of Key 00 and of Key 01. Since yesterday the key morphing has changed ot the second number. The logic applied is the same.
Real_2nd_number = autorolled_2nd_number XOR 43H
I will publish the table in my second post for those who want to work from a table. It is great to be able to use a table if you can't access the internet or the sites are busy.
The DN ECM has changed only slightly in concept.. If you have new BIN since yesterday install it and it will correct the problem If you do not have a new BIN, let the new keys roll in under the old BIN and then turn autoroll off and change the second number of Key 00 and 2nd number of Key 01. You can either use new key posted and do a manual change. Or if you know hex arithmetic, do a XOR o\with 43 of the 2nd numbers as stated Or use the table below on the second numbers. Basically, the attention of the ECM has shifted from the first number in each key to the second number of each key
1st Digit ......... 2nd Digit --------- 1st Digit ......... 2nd Digit 0 = 4 ............. 0 = 3 ---------------- 8 = C .......... 8 = B 1 = 5 ............. 1 = 2 ---------------- 9 = D .......... 9 = A 2 = 6 ............. 2 = 1 ---------------- A= E .......... A = 9 3 = 7 ............. 3 = 0 ---------------- B = F .......... B = 8 4 = 0 ............. 4 = 7 ---------------- C = 8 .......... C = F 5 = 1 ............. 5 = 6 ---------------- D = 9 .......... D = E 6 = 2 ............. 6 = 5 ---------------- E = A .......... E = D 7 = 3 ............. 7 = 4 ---------------- F = B .......... F = E
Hi Nalin I have been using the XOR 43 method ever since you first told us about it, it's generally faster than looking for the keys on the internet and I use windows calculator, in scientific mode, to do the arithnetic.
With regard to your new post above, I think what you are saying is that the second pair of Hex digits, in each key, is what is being morphed now instead of the first pair as before. Am I correct?
htiek. Your are right. Ever since 17th August I had to take back my old Pansat 2500 clone back from a close relative and her use my Sonicview. I have been using the XOR 43H ever since. It was on the first byte (number) of each key and now they have shifted the attention to the second byte ornumber.
Technical: A XOR (exclusive OR)in binary arithmetic in Software is equivalent to the inverter logic of hardware. 0 XOR 0 is 0 0 XOR 1 is 1 1 XOR 0 is 1 1 XOR 1 IS 0
Currently we are using 43H against the unknow number. 43H is 0100 0011 Wherever in the binary representation of 43H there is a 1, that is the bit that will be inverted.
Any unknown binary number XORed with binary 1, gets inverted.
There was this big talk about MAP 57 calls several months ago. So far what I have noticed is that after the keys come into your receiver from God (as opposed to entering them manually), a Map 57 call is made to alter some bits in the keys. The people who are revising the BINs are trying to figure out an answer to the specific change made at a particular time. There should and would be a method of looking at the general way in which the alteration is taking place (usually a XOR operation) and devise a software patch inside the flash that looks at the Map call in operation, figures out what it is doing and act accordingly.
Anyway, I am going to try out the older BINs again and see in what way they behave under the current minor ECM. I am pretty certain that all the older BINs sin 281T would be valid now except for the same minor but identical defect. However, without testing I would not categorically say so.
This is interesting, I was using 293T on my pansat 2500a clone, then I found a table to replace the first digit on the key. So I never upgraded the bin.
But know is two digits so the third and four digit of the key are changing, but also I thing first digit is still changing for my pansat.
So last time I second couple of digits where 96 and I changed by 53.
What if the BIN in use already has some sort of anti-morphing correction built in, (like 294 and possibly 293), will not the keys it shows you, after rolling, be already altered, according to the method used when the BIN was made. Now that the rules have changed, with the second byte morphed instead of the first, at the receiver, both the first and the second byte could end up wrong because of this. I am still using 286T which does not try to fix the keys and is therefore unaffected.
What do you think, does this make sense?
As you suggested, Nalin, some kind of adaptive BIN that could automatically adapt to these changes would be the best.
From another site where I posted this, I found out that with the 293 BIN the first number is altered - bits 6 and 7 are inverted or XOR with C0 to get the correct. With BIN 293 the second number is also altered but I do not have enough data to find the logical operation. If somebody is still using 293 or 293T, and I get the data re what came in and what it should have been and the positions in both the keys, I don't think it would be difficult to formulate a temporary rule.
