Atmega asm (not a fix!!)

Been so long since I messed with Atmel assembler I cant say its fully correct but i'm sure your on the right track with your thinking.

You need to be aware though that the position of the mangled bytes will change, probably depending on which of the keys they are actually updating.
 
Last edited:
Code: 
You don't have permission to view the code content. Log in or register now.

next i'm hoping we'll need something similar to this

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

Anyone know how to xor just 1 bit of R16 as we don't want to xor entire key
 
You need to do more excludes when checking to see if this is of type keyroll 7. As the EOR value and the actual bytes being EOR'ed change they should be excluded.

You then need to locate the bytes to EOR (AD and B2 in your KEYMASK data) within the key itself and then EOR it with the actual value given in the EMM (10 and 18) in your KEYMASK data.

Remember that the data bytes AD and B2 and the values to EOR 10 and 18 change according to whether key0 or key1 is being updated so you need to take this into account. The actual base structure of the EMM from what I've seen doesn't so you can make assumptions such as where AD/B2 and 10/18 are within the EMM.
 
Sorry the 10 I quoted above is hex 10 (ie 16 decimal)

Assuming the offsets are correct and if that is the current EMM (which it isn't) then it would work but change the EOR value and data byte address and it'll stop working, so that code most likely would have worked yesterday.

To make the code more flexible you really need to read the contents of data byte 8=0x10 which is what to EOR the byte of the key with. You then need to read the contents of data byte 0A or 0C and use that as an offset to point to the actuall byte in the key to EOR with. Then repeat this for the second EOR.
 
Thanks, I THINK I see what you mean. For some reason I was loading the $AD and $B2 instead of the location of xor value.
 
Sorry to keep throwing snippets of code up for comments but every time I look at it again I'm tempted to change something else.

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

Couple of points, when loading register (r16) i'm assuming this loads 8 bytes not just the one i want to xor which is why I should use 0a or 0c as a ref point, and if so any hints on how to do it.
 
This is a rather disappointing 4th consecutive post to a thread that hasn't yet been resolved. Nozzer has already pointed out that most of the info required to fix the auto update has been available for quite some time. No one is asking thatyou commit hours to the cause and there is plenty of help available to get you started (certainly more appealing than my fun is down is there a fix?)
 
tonmedia11 said:
Sorry to keep throwing snippets of code up for comments but every time I look at it again I'm tempted to change something else.

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

Couple of points, when loading register (r16) i'm assuming this loads 8 bytes not just the one i want to xor which is why I should use 0a or 0c as a ref point, and if so any hints on how to do it.
Click to expand...

You've still got an explicit reference to the EOR value (0x08) and the keys data byte (MP + 0x30) that will be EOR-ed.

You can easily load the EOR value using an LDS command with an offset pointing to the actual EOR value in KEYMASK7.

Getting the byte address from the data in KEYMASK7/EMM is slightly more tricky, you'll have to read the relevant data byte, then use an offset to get from the data you've just read to the actual byte in the key you need to EOR, you'll then need to convert the resulting value to a physical address, then read in that key value that physical address, EOR it and then save it back. Once you've got this working then simply copy this for the other byte that need EOR-ing.

You can then save the resulting value away.
 
Just running this by so I can make sure Im on the right lines - basically we need to first check the emm is a keyroll and of what type - once we have confirmed this is a speciific type (and using the current one as an example) we then decrypyt the emm to obtain the keys and then use an offset to EOR the bytes that are in the wrong place and then write this back to the physical memory at the correct point to ensure the correct keys are in the right place??
 
gooner71 said:
Just running this by so I can make sure Im on the right lines - basically we need to first check the emm is a keyroll and of what type - once we have confirmed this is a speciific type (and using the current one as an example) we then decrypyt the emm to obtain the keys and then use an offset to EOR the bytes that are in the wrong place and then write this back to the physical memory at the correct point to ensure the correct keys are in the right place??
Click to expand...

The EMMs already decrypted by the time it hits the autoroll.asm, you just need to identity the type of keyroll which is done by byte matching, once you've found the correct EMM you then need to process/massage the data where key0/key1 are, with this keyroll it's EOR-ing bytes of key0/key1 depending on the EMM.
 
Does this look any better (no offset value in place yet)?
Code: 
You don't have permission to view the code content. Log in or register now.

IAmATeaf said:
you'll then need to convert the resulting value to a physical address, then read in that key value that physical address, EOR it and then save it back.
Click to expand...

so this would mean something like the above but after the ADDI R16 I need to store this value somewhere then EOR that with R17 Not EOR R16 with R17
 
Last edited:
tonmedia11 said:
Does this look any better (no offset value in place yet)?
Code: 
You don't have permission to view the code content. Log in or register now.
Click to expand...

The code above looks good and as is wouldn't need an offset.

You are reading the actual XOR value which is good so if this value were to change then the code would still work but you are still making an explicit reference to the byte to change in the key so if the CC's change this, which they seem to be doing, it would stop AUing.
 
Ok, so if I load r16 with the value that shows the location of the data to be xor'd something like

LDS R16, (MP + 0x10) ;load affected byte location
how do i get to the actual byte to xor it with R17
 
tonmedia11 said:
Ok, so if I load r16 with the value that shows the location of the data to be xor'd something like

LDS R16, (MP + 0x10) ;load affected byte location
how do i get to the actual byte to xor it with R17
Click to expand...

You get to it with what I've termed the offset. The EMM references the data byte with 1 value ie the contents of 0x10, within the keyroll itself it uses another, the difference between the 2 would be the offset which you'd use to get to the data byte from the value you've loaded from 0x10.

I'm off out now but may be back on later tonight, if not then maybe tomorrow :)
 
Sorry to interupt your learing session, but i'm want to start learning. If its ok with you Nozzer, iamateaf and tonmedia11.
 
You must log in or register to reply here.

Similar threads

F
keyroll emm and the fix (code it ur self)
7 8 9 10
Replies
191
Views
32K
dstream
D
D
re: Atmega asm (not a fix!!)
Replies
2
Views
330
digital_ace
D
M
@nozzer
Replies
3
Views
463
nozzer
N
D
re atmega challenge
Replies
0
Views
363
digital_ace
D
Back
Top