Thread: Fuel Types and Vehicle Charge Points for Europe

Originally Posted by catymag

I guess nuvi will see it like every unencrypted POIs, if unlocked.

Caty is right. No need to encrypt it back after any changes.

Originally Posted by lolypop000

Will post it here when i repair all SL to SK and all SK to SL.
I start working on this gpi at 1:40PM ( when i wrote previous post ) and still workimg on it
Its a lot string to change.

What are you changing?
it seemed to me that 3 things should be done:
1. autochange every <hr>SK to <hr>XX
2. autochange every <hr>SL to <hr>SK
3. autochange every <hr>XX to <hr>SL

Something occurred to be more complicated?

As for the encryption by repetitive special_adding of the fixed double word.. it's strong!

Originally Posted by dasilvarsa

What is the fixed double word ?
Can you explain further please.
I see that every 4th byte is unencrypted.
The encryption starts first byte after the part number.

48 06 B3 00
i called these 4 bytes - a double word. It is the same for "encrypting" all the file tail (starting at pos 312h = 786 decimal)

"special_adding" is as follows:
Let's take a byte @312h: namely 09
Let's add the first syllable of 09 (0) with the the first syllable of 48 (4) - resulting in 4, LSbits of the sum will be the first syllable of "ecrypted" byte
Let's add the second syllable of 09 (9) with the the second syllable of 48 (8) - resulting in 11, LSbits of the sum will be the second syllable of "ecrypted" byte
So "encrypted" byte @312h is 41

Let's take a byte @313h: namely 00
Let's add the first syllable of 00 (0) with the the first syllable of 06 (0) - resulting in 0, LSbits of the sum will be the first syllable of "ecrypted" byte
Let's add the second syllable of 00 (0) with the the second syllable of 06 (6) - resulting in 6, LSbits of the sum will be the second syllable of "ecrypted" byte
So "encrypted" byte @313h is 06

Let's take a byte @314h: namely 08
Let's add the first syllable of 08 (0) with the the first syllable of B3 (B) - resulting in B, LSbits of the sum will be the first syllable of "ecrypted" byte
Let's add the second syllable of 08 (8) with the the second syllable of B3 (3) - resulting in B, LSbits of the sum will be the second syllable of "ecrypted" byte
So "encrypted" byte @314h is BB

Let's take a byte @315h: namely - we don't care due to the corresponding byte of our dword is 00 - special_addition with 00 doesn't change the other argument
So "encrypted" byte @315h is the sameas in the non-encrypted file (ahh.. 00 - we are lucky!)

Let's take a byte @316h: namely 3A
Let's add the first syllable of 3A (3) with the the first syllable of 48 (4) - resulting in 7, LSbits of the sum will be the first syllable of "ecrypted" byte
Let's add the second syllable of 3A (A) with the the second syllable of 48 (8) - resulting in 12, LSbits of the sum will be the second syllable of "ecrypted" byte
So "encrypted" byte @316h is 72

and so on
i can write one unique formula, but cannot decide which bit/byte-operation functions are well-known to the readers.
In fact it is sufficient to use chr(), asc() and mod(,16)