Todays Emm disasmebled

Well I've got a revised atmega flash sort of working, am still testing it at the mo.

Pretty lonely in this thread isn't it, sort of me talking to myself :)
 
I've been keeping an eye on it too, while trying to recap some of the stuff i learned in nozzer's challenge thread, which for any other lurkers out there is well worth a read (with some filtering...it's a long one).
 
tonmedia11 said:
I've been keeping an eye on it too, while trying to recap some of the stuff i learned in nozzer's challenge thread, which for any other lurkers out there is well worth a read (with some filtering...it's a long one).
Click to expand...

TBH, with the info I've posted in this thread and a good read of nozzers glorious atmega tutorial thread there's enough there to create a revised flash for an atmega that will work. :)
 
been looking back at challenge thread too - in conjuction with the info here - its sort of making sense...
 
making it work isnt the issue - it's making it robust enough to survive the next keyroll - surely they will alter at least both the initial bit mask, the value it's and'ed with and the bytes amended? or what was the point.

need to see anothe providers version or just wasting time- might as well just add 2 to first byte of keys lol

btw anyone got a version keys.ini which actually supports pure ntl lol
 
Last edited:
you cant make a keyroll robust, as for keys they in the download section. Think we need to wake nozzer up and put all out of their misery!!!
 
I'm not sleeping - just lurking !

I'm letting you lot do all the hard work this time - its nice to see that at least a few people learnt something from last time :)
 
Well I'll try and do a log on exc&w when I get access to box and feed, but that won't be till the weekend. No feed at home. But I'd enjoy messing about with the code and trying to get it to work for myself, so thats something to do next week when I have free time from monday :D I did read nozzer's challenge, but I'd have to go back over it again to get it fresh in my memory (it starts to go when you get old ya know)

: multi :
 
wonko said:
...surely they will alter at least both the initial bit mask, the value it's and'ed with and the bytes amended? or what was the point....
Click to expand...

I'm not too sure tbh. They've always been rather reluctant to actually change keyroll code. I suspect they simply buy the code from Kudelski and then just plug the keys into that code (or likely some software does it automatically).

Still, its nice to program for all eventualities even though its probably wasted effort !
 
Quote:
Originally Posted by tonmedia11
After thinking about the curent position of 00 00 00 00 and why they picked that point, it seems to be the only location for 4 bytes of data that can affect both keys at the same time, not sure if that would make them less likely to change location or not.

Quote:
Originally posted by Nozzer
Your probably right !

The position they have chosen makes the same keyroll applicable to either key so the chances are they probably will not change things.

Its often a difficult decision to know how far to take a solution. Do you keep it simple and get a quick solution or do you spend forever tweaking and making it handle every conceiveable situation. The answer is really up to you - do you enjoy coding or do you enjoy watching TV !

Edit - this comes from the original challenge thread
 
Sorry guys had to go out last night, I can see what people are saying about making things robust and for keyroll method 5 I actually made it more robust and merged it with keyroll method 4 in the hope that they'd use that method but with differing offsets but it does look like nozzer is correct that they are not keen to change simple things which would stop the emulation cards going off.

I've done the easy fix for now but will look at making it more robust later, onto the task.

Here's the EMM for pure:
Code: 
You don't have permission to view the code content. Log in or register now.

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

Changed it slighty so that it's easier to see where key0 (8 x 0x11) and key1 (8 x 0x22) are in the data

Remember that in the initial compare code you need to ignore any provider related bytes which for the above is 54/55. Then work out how many bytes you're going to compare to establish that this is infact a keyroll 6 type EMM, I always stop at the byte before the byte dump above.

Let me know when you've got this far and we'll move onto the next bit. :)
 
Last edited:
nozzer I asked this before on another forum but still am not 100% sure but would it be possible to explain the following?

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

The above results in $07 being set to 110 - right?

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

ensures that no other bits in A are set so A = 110 - right?

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

the above results in A = 1100, this is the bit that's really confusing me as the first bytes of the keys are definately being XOR'ed with 110.
 
IAmATeaf said:
nozzer I asked this before on another forum but still am not 100% sure but would it be possible to explain the following?

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

The above results in $07 being set to 110 - right?

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

ensures that no other bits in A are set so A = 110 - right?

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

the above results in A = 1100, this is the bit that's really confusing me as the first bytes of the keys are definately being XOR'ed with 110.
Click to expand...

Looking at that code I would say we are Xoring with #$0C - 1100.
I haven't looked at the keys etc. Im not bothering with it until I can see a keyroll from another provider.

edcase

EDIT: Just had a quick look and I see what you mean. Just gonna scratch my head for a min, must be goin crazy.
 
Last edited:
hmmm...ur are right - wonder where I got the additional AND from thats needed to make it actually give the keys we got

upto 0092:

sets bit pattern to $6 and makes sure no other bits than the first 3 can be set - so value must be $6 in this case but can in no event be more than $7

0092: 48 lsla

would then seem to shift this left 1 bit which would result in the accumulator being $C which is then placed on the stack

obviously this doesnt give the correct values when applied to the key - so a mistake has been made somewhere - tho I fail to see where

btw this is TW version

Code: 
You don't have permission to view the code content. Log in or register now.
not a lot of help there then lol

works prefectly if these 2 lines are reversed lol
Code: 
You don't have permission to view the code content. Log in or register now.
 
Last edited:
So really, im thinking that it shouldnt be too hard to handle the double keyroll isnt it? all we have to do in theory is add on some code to handle the second keyroll, right?

Gotta do some reading up on the atmega challenge thread.

lol @ nozzer, ur not wrong at all there mate.
 
the code to handle this keyroll is already in this thread - it works - but I suspect it may not handle the next type 6 keyroll - especially given it isnt actually an implementation of the emm code - as that doesnt give us the right keys for some reason
 
You must log in or register to reply here.

Similar threads

S
help to understand log
Replies
1
Views
828
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