Images taken from slim19198's guide to Manual key entry on DM500
The interesting bit is the image I've attached "dreamboxkeys(5).jpg". It's a screen grab of the keylist.txt file after the key roll on April 3rd. And the juicy bit is that it shows the 00 key for ROM7, ROM10 and ROM11 clearly.
Guess how many characters the ROM7 and ROM10 keys differ by?
Answer: 2
Guess how many characters the ROM7 and ROM11 keys differ by?
Answer: 2
Guess how many characters the ROM10 and ROM11 keys differ by?
Answer: 2
The 00 keys:
Given three 00 keys I could build the correct ROM7 key in this instance immediately.
Key values in positions 1-9 were identical in all three keys.
Position 10
ROM11[00][10] = 6
ROM10[00][10] = 7
ROM7[00][10] = 7
=> The correct value is 7
Position 11
ROM11[00][11] = 2
ROM10[00][11] = 2
ROM7[00][11] = A
=> The correct value is 2
Position 12
ROM11[00][12] = 3
ROM10[00][12] = 2
ROM7[00][12] = 3
=> The correct value is 3
The corrected key was:
N 5E01 00 ********7233**** ; ROM 7
Only one character had to be changed to get the correct key and maybe it's just a coincidence but by comparing it against the ROM10 and ROM11 keys, took the guess work out of costructing the correct ROM7 key. So there we have it, now all we need to do is code it up and wait for the next key roll to test the theory further, but by the looks of this we have the solution without needing to get somebody to rewrite the EMUs.
:banana:
Shit - I didn't realise it's almost 4:30am already and I have to get up for work in three hours. Right I'm off to sneak into bed, I'll be back tomorrow at some stage.
This is an interesting approach but a bit limited. I feel its actually far easier to just look at the actual keyroll code from the Emm, suss out whats its doing and then manually correct.
For instance, take the following representative decoded (but fake
) Emm
Now, using data from Nagrafaq we can see how this Emm breaks down
The 1st byte is always a filter. In this case 3F means the Emm is meant for all cards. This filter is always followed by two bytes of provider Id Information.
The next byte, FA, is a nanocommand. Its a nasty one because its function is to tell the card to interpret all following information as executable code. Luckily we know that the processor is a modified 6805/ST7 core so we know how to turn the machine code back into pneumonic instruction codes. This gives -
Notice that the code is always disassembled from a base address of $0081. This is the fixed address of the cards EmmBuffer.
Ok, you can see from this that the code is loading some data from address $06. In this case, address $06 is a register rather than a memory location (all addresses below $20 can be treated as registers)
Registers are a little different than memory locations in that they are physically linked to and control hardware objects like timers, serial ports or interrupts etc. Because of this action only certain bits within the register may be readable or writable. Bits may also change as hardware status changes (ie, a bit may get set or cleared when there is some information in the serial receiver or a timer expires).
The next instruction, 'swapa', is fairly simple. It just swaps the nybbles of a byte around. So, if the accumulator contains F3 before then it will contain 3F afterwards.
after that, we have an 'and #$20'. This performs a logical AND operation on the accumulator with the constant value $20. A logical and operation compares two binary values and only gives a 1 bit result where the two corresponding input bits are also 1 bits.
ie.
72 = 0111 0010 in binary
ANDED WITH
20 = 0010 0000 in binary
GIVES
Res 0010 0000 in binary or $20 in hex.
The net result of this AND operation is to produce a result of $20 ONLY if the Accumulator had bit 5 set to 1. (bits numbered 76543210)
This kind of operation is called a mask. Its function is to mask out bits we aren't interested in. In this case we are only interested in bit 5 of the accumulator.
Because of the 'swapa' instruction, this is actually bit 1 from register $06. We have assumed that this bit reads as a logic 1 value
The next couple of instructions 'eor $AF' & 'sta $AF' perform an exclusive-or on the Accumulator with the contents of memory location $AF and then store the results back to location $AF.
Memory location $AF is actually a part of the Emm code. So here something in the Emm is being changed. A little bit of de-mangling going on perhaps
An exclusive-or is another logical operation similar to the AND described above. In this case the ouptut of an exclusive-or bit is only one if bothe input bits are different. If the bits are the same then you get a 0 output bit
The data at address $AF is $24
ie.
20 = 0010 0000 in binary
XOR WITH
24 = 0010 0100 in binary
GIVES
Res 0000 0100 in binary or $04 in hex. The result is to flip bit 5 of the 2nd operand.
So, now we have -
The next section of code is very similar to that already shown above.
The sei & cli instructions disable & enable interrupts. This would likely be a bit of protection to stop any interrupts that may occur by manipulating this particular register from actually occuring.
blcr & bset instructions clear or set respective bits at a address location. So, 'bclr1,$06' would clear bit 1 of address $06 (reg6) whilst 'bset7,$06' would set bit 7.
The clever bit here is that you must remember that address $06 is a register. Setting or clearing a registers may not actually occur. What is being relied upon here is that these values aren't changing in the way you would expect simply by looking at the code !
I'll let you all think about that little bit of code and what it might do
Just to finish off, the last few bits of code -
returns processing back to the cards Emm processor. Placing the constant #$26 in the accumulator instructs the Emm processor to continue processing Nanocommands from Address $26 + $80 or $A6
If you look at $A6 then
you will see that it contains $83, this is a valid Nano. The rest of the Emm will read as
See NagraFaq for details of Emm Nano's
