Todays Emm disasmebled

yup, just bin reading up on it, and yes i suspect we gotta add RCALL CHKKEYMASK6 method into the autoroll, still cant say for sure.
 
hint:

Location $07 is NOT a memory location - its a register. You dont necessarily read back what you write to it. This is why that particular location was chosen by Kudelski and why a lot of emulators are broken.

The actual value read back after the sequence of bset/bclr instructions is $03.......
 
KEYMASK6_data:
.DB 0x3F,0x00,0x01,0xFA,0xCD,0x82,0x3D,0x15,0x07,0x10,0x07,0x12,0x07,0x14,0x07,0x11
.DB 0x07,0xB6,0x07,0xA4,0x07,0x48,0x88,0xB8,0xAA,0xB7,0xAA,0x84,0xB8,0xB4,0xB7,0xB4
.DB 0xCD,0x82,0x23,0xA6,0x25,0xCC,0x6B,0x01,0x83,0x00,0x01,0x00,0x00,0x00,0x00,0x00
.DB 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00

CHKKEYMASK6:

LDI YH, high(M) ;Set Y pointer to start of decrypted EMM in RAM (0x019B)
LDI YL, low(M)

LDI ZH, high(KEYMASK6_data * 2) ;Set Z pointer to start of KEYMASK6 * 2 in Flash (0x0A70)
LDI ZL, low(KEYMASK6_data * 2)

CLR R18

KEYMASK6TOP:
CPI R18,0x01
BREQ KEYMASK5CHKLOOP


; Byte is a mask byte so check that its what we expect
LPM
LDD R17,Y+0
CP R0,R17
BRNE KEYMASK6CHKLOOPEND ; No, not an EMM we can use so exit


KEYMASK6CHKLOOP:
ADIW R30,0x01 ;Increase the ZL Flash pointer
INC R28 ;Increase the YL EMM Buffer pointer
INC R18
CPI R18,0x28 ;Have we done all 28 bytes of the EMM?
BRNE KEYMASK6TOP ;No, carry on checking the mask
RCALL DOKEYROLL6 ;Yes, this is a keychange EMM so handle type6 keyroll

KEYMASK6CHKLOOPEND:
RET

Is this roughly where we are expected to be before moving on?
 
looks functional - as to how good a solution it is I dont know but I have something virtually identical that works atm

@nozzer - that might explain why sosia seems to be having difficulty lol
any idea what implications this would have re. robustness of the existing solution?
 
tonmedia11 said:
KEYMASK6_data:
.DB 0x3F,0x00,0x01,0xFA,0xCD,0x82,0x3D,0x15,0x07,0x10,0x07,0x12,0x07,0x14,0x07,0x11
.DB 0x07,0xB6,0x07,0xA4,0x07,0x48,0x88,0xB8,0xAA,0xB7,0xAA,0x84,0xB8,0xB4,0xB7,0xB4
.DB 0xCD,0x82,0x23,0xA6,0x25,0xCC,0x6B,0x01,0x83,0x00,0x01,0x00,0x00,0x00,0x00,0x00
.DB 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00

CHKKEYMASK6:

LDI YH, high(M) ;Set Y pointer to start of decrypted EMM in RAM (0x019B)
LDI YL, low(M)

LDI ZH, high(KEYMASK6_data * 2) ;Set Z pointer to start of KEYMASK6 * 2 in Flash (0x0A70)
LDI ZL, low(KEYMASK6_data * 2)

CLR R18

KEYMASK6TOP:
CPI R18,0x01
BREQ KEYMASK5CHKLOOP


; Byte is a mask byte so check that its what we expect
LPM
LDD R17,Y+0
CP R0,R17
BRNE KEYMASK6CHKLOOPEND ; No, not an EMM we can use so exit


KEYMASK6CHKLOOP:
ADIW R30,0x01 ;Increase the ZL Flash pointer
INC R28 ;Increase the YL EMM Buffer pointer
INC R18
CPI R18,0x28 ;Have we done all 28 bytes of the EMM?
BRNE KEYMASK6TOP ;No, carry on checking the mask
RCALL DOKEYROLL6 ;Yes, this is a keychange EMM so handle type6 keyroll

KEYMASK6CHKLOOPEND:
RET

Is this roughly where we are expected to be before moving on?
Click to expand...

Looks good to me except the typo :)
 
wonko said:
@nozzer - that might explain why sosia seems to be having difficulty lol
any idea what implications this would have re. robustness of the existing solution?
Click to expand...

Without knowing the functioning of that particular register its hard to tell but tbh, I probably wouldn't worry about it. I'd be just inclined to keep it simple and XOR the relevent 2 bytes with the constant $06

Perhaps not very resiliant but I doubt they will change the core programming of the keychange method so that some other value is produced.

If they did change the core program then it would probably qualify as a new keyroll anyway - would it get through your filters for this method ?
 
in that case all I need to do is tidy up my mask as it's a bit catchall atm lol - ie it's virtually the same as above - it will break if anything in the first 27 bytes (yep I am that lazy lol) apart from byte 1 is different

and then wait for the very next keyroll to break it lol
 
Last edited:
wonko said:
in that case all I need to do is tidy up my mask as it's a bit catchall atm lol - ie it's virtually the same as above

and then wait for the very next keyroll to break it lol
Click to expand...

Surely if the bits did change and you masked over the bits to identify it as this keyroll the code would still XOR with $06 therefore writing away the wrong keys?

So would fail anyway?


EDIT: Just re-read your post mate, should learn to read properly, I see what you're saying and are going to remove the additional masks which you put in to make it generic, soz. :)
 
Last edited:
Next bit tonmedia11 would be take the code I already pasted in this thread and use that, remember 0x3 doesn't equal 0x6 which is where I made my mistake. Dupe this to also deal with key1, then add the tail section to write the keys and you should be good.
 
Last edited:
Just out of interest I had a look to see what jsr $823D does:

Code: 
You don't have permission to view the code content. Log in or register now.

It seems to disable interrupts and clear bits 1 and 2 of $07
 
IAmATeaf said:
Surely if the bits did change and you masked over the bits to identify it as this keyroll the code would still XOR with $06 therefore writing away the wrong keys?

So would fail anyway?
Click to expand...
yep - given the 2 area's emm's as far as I can see there is nothing wrong with my catchall mask atm - aint seen a 5C one yet but given the 5A's identicalness (is that a word lol) I would imagine the same code would work fine at recognising one of them as well - so not much point it tidying it

I would lay money that "type 7" will simply be a mod of this tho lol - what worries me is that this may be on the next keyroll - but what the hell - I still aint had to do any coding yet :)
 
wonko said:
yep - given the 2 area's emm's as far as I can see there is nothing wrong with my catchall mask atm - aint seen a 5C one yet but given the 5A's identicalness (is that a word lol) I would imagine the same code would work fine at recognising one of them as well - so not much point it tidying it

I would lay money that "type 7" will simply be a mod of this tho lol - what worries me is that this may be on the next keyroll - but what the hell - I still aint had to do any coding yet :)
Click to expand...

I sort of said that when method 5 hit the fan last September, remember saying hang on they can change it at will to swap any 4 bytes to any of the key0/key1 values so I actually re-wrote keyroll5 to read the relevant data out of the EMM, locate the 4 bytes and locate the target write location. I also merged method 4 and 5 together as they were similar to free up space in the flash but alas they never changed or modded it at all, rather disappointed but did learn a fair bit.
 
IAmATeaf said:
Just out of interest I had a look to see what jsr $823D does:

Code: 
You don't have permission to view the code content. Log in or register now.

It seems to disable interrupts and clear bits 1 and 2 of $07
Click to expand...

Thing that got my interest was the crazy orders that it seems to do these things in. Something that needs more investigation I think.
Why clear bit1 twice, then clear bit2 then have to clear bit1 again? Huh lol.

It also does crazy setting an unsetting in the other jsr aswell, maybe certain bits can be set if other bits are in a certain state. I dont know, just a thought.

edc.
 
bet the gits dont give us a keyroll for ages so I can find out either lol
 
edcase said:
Thing that got my interest was the crazy orders that it seems to do these things in. Something that needs more investigation I think.
Why clear bit1 twice, then clear bit2 then have to clear bit1 again? Huh lol.

It also does crazy setting an unsetting in the other jsr aswell, maybe certain bits can be set if other bits are in a certain state. I dont know, just a thought.

edc.
Click to expand...

Well the disable interrupts is a must as this is an important update and you don't want another EMM coming along and interrupting a key change, I asked the same question to you on another forum, I wondered if it was to do with an keychange EMM having to be a certain size maybe?
 
nozzer said:
hint:

Location $07 is NOT a memory location - its a register. You dont necessarily read back what you write to it. This is why that particular location was chosen by Kudelski and why a lot of emulators are broken.

The actual value read back after the sequence of bset/bclr instructions is $03.......
Click to expand...

Is there a simple explanation why the value is 3 and not 6 as I would have thought?
 
very nice guys, well i fkd up. guess i will have to alter my map call as well arrrggghhh.


again very nice work guys
 
You must log in or register to reply here.

Similar threads

S
help to understand log
Replies
1
Views
824
acebing
A
T
oscam server running, no scrambled on the tv but the video have lagging.
Replies
0
Views
2K
theviper0308
T
T
Need help with rqcamd on DM500
Replies
0
Views
3K
tonydix
T
S
vu solo crash
Replies
1
Views
1K
pazza
P
johnny bravo
epg location reverts back to internal flash
2
Replies
32
Views
5K
johnny bravo
johnny bravo
Back
Top