Vida CEM swapping

[RickHaleParker]

Key in flash zone have 7ff00-7ff30

That is 49 bytes. ( 49 bytes keys ) / 7 bytes = 7 keys. Only 7 keys used to decrypt the entire eeprom?

[RickHaleParker]

They xor it with current eeprom byte offset divided by 7:

Not all offsets are multiples of multiples of 7. Xor only works with real numbers. Imaginary number would xor.

Do you mean if you do the division in hex it will return the real part only? That would work.

[vtl]

They xor it with current eeprom byte offset divided by 7:

Not all offsets are multiples of multiples of 7. Xor only works with real numbers. Imaginary number would xor.

Do you mean if you do the division in hex it will return the real part only? That would work.

This is integer division. [0..6] / 7 = 0, [7..13] / 7 = 1, [14..20] / 7 = 2, etc.

[vtl]

That is 49 bytes. ( 49 bytes keys ) / 7 bytes = 7 keys. Only 7 keys used to decrypt the entire eeprom?

Crypto key for EEPROM encryption/decryption is 0x3d bytes long, 61 in decimal.

I wrote C code that hopefully goes the same thing what the CEM machine code I found does.

[RickHaleParker]

This is integer division. [0..6] / 7 = 0, [7..13] / 7 = 1, [14..20] / 7 = 2, etc.

There is a term for that. It is Truncation. I recall Truncation as an operator way back in the 8 bit days.

[RickHaleParker]

That is 49 bytes. ( 49 bytes keys ) / 7 bytes = 7 keys. Only 7 keys used to decrypt the entire eeprom?

Crypto key for EEPROM encryption/decryption is 0x3d bytes long, 61 in decimal.

I wrote C code that hopefully goes the same thing what the CEM machine code I found does.

You think the the key(s) are flash offsets 7FF00 - 7FF3C not 7FF00-7FF30 as stated by aaivar ?


Notes:
61 is not a multiple of 7.
49, 56, 63 are multiples of 7.

There are 2048 bytes in the eeprom. One would need to recycle the keys to decrypt the whole eeprom. 2048 / 7 = 292. Will need 292 keys to decrypt the entire eeprom. FF₁₆ = 255₁₀ , if you reduce a eeprom byte by more then 255₁₀ the results will be negative.

If the number of bytes in the key block is not a multiple of 7, it could loop back to the beginning creating a different set of keys then the first pass. With 61 bytes in the keys block, the keys would shift by two bytes each cycle.

[RickHaleParker]

They xor it with current eeprom byte offset divided by 7:

Something like this (haven't verified):

Code: Select all

void eeprom_decrypt(unsigned char *eeprom, int len, unsigned char *crypto, unsigned char *decrypted)
{
	for (int i = 0; i < len; i++)
		decrypted[i] = eeprom[i] ^ crypto[i % 0x3d] ^ (i / 7);
}

I tried it with manual calculations. It is not working, at least it does not produce the same results as the files.
Looks like each eeprom byte needs to be reduced before xor with flash key.

Use i/7 to reduce the eeprom byte as you read it from the file ?

[RickHaleParker]

I can send another example if necessary

What software did you use to produce the decrypt file?
Can we get a copy of it?

[aaivar]

I can send another example if necessary

What software did you use to produce the decrypt file?
Can we get a copy of it?

my program will not work without activating a license

[RickHaleParker]

my program will not work without activating a license

Ok but what is the name of the program?
Is it something you paid for or something you wrote?

Can you do this.

• 1. Take a eeprom file and and fill it with all FF.
  2. Take a Flash file and fill it with all FF.
  3. Run the program using the two fake files.
  4. Upload the Decrypt file here.

If my theory is right, the Decrypt file will show the reduction cycles for the whole process. The math is saying it will. Be kind of like analyzing wave interference.

Run the software with the two files in the Zip file below. Then upload the resulting Decrypt file.