Fuel Types and Vehicle Charge Points for Europe

**sbog** · 28th June 2013, 06:23 PM

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)

**dasilvarsa** · 28th June 2013, 09:05 PM

Originally Posted by sbog

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:
***Hidden content cannot be quoted.***
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)

@sbog
Very good work, It works well for starting with a unencrypted file and creating a encrypted file.
What I want to do is to start with a encrypted file and end up with a unencrypted file.
Could you please do the explanation for decrypting.

**sbog** · 28th June 2013, 11:34 PM

Originally Posted by dasilvarsa

@sbog
Very good work, It works well for starting with a unencrypted file and creating a encrypted file.
What I want to do is to start with a encrypted file and end up with a unencrypted file.
Could you please do the explanation for decrypting.

i think i'll have some gap this (upcoming) monday.
it's a pity but i have no time right now although this looks to be easy enough.
monday, ok?

**Giomen** · 29th June 2013, 02:14 AM

Originally Posted by sbog

"special_adding" is as follows:
***Hidden content cannot be quoted.***
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)

OK! You are genius! I have tried to do simple subtraction for each whole byte from key:
48 06 B3 00
but I always got some random wrong decrypted byte as say above. It had entered me to a screeching halt!!! The key was obvious after comparing of two simple and very small file that was made by GPICreator - one is encrypted and second is non-encrypted. Script for HEX editor worked fine. But always just a little broken result was on screen.
It is pity what HEX editor is not operable with this algorithm. I am a deep stupid. So hope to you or may be syzygy give a ready for use program decision...

**sbog** · 29th June 2013, 12:50 PM

Originally Posted by Giomen

OK! You are genius!

No, i'm sbog.

Originally Posted by sbog

monday, ok?

In fact i've done this.
i wrote it in FoxPro, the "tool" is rather rough with the header analysis (no time to study its structure, maybe on monday) but it works for this "Fuel types" and for all "Cyclopes" from the parallel thread.

By some reasons i shall not distribute full standalone executable, - only small one for VFP.9 (but user must install FoxPro libraries from elsewhere). If it is ok - i can do this.
Anyway - here is the source:
[hide]para _fnam1
if type([_fnam1])#[C] or !file(_fnam1)
?[source (encrypted) file does not exist..]
retu -10
endi

bb=fcrea([$dec_]+_fnam1)
if bb<0
?[can't create output (decrypted) file..]
retu -11
endi

aa=fope(_fnam1)
if aa<0
=fclo(bb)
?[can't open source (encrypted) file..]
retu -12
endi

_o=0
L0=frea(aa,4)
do case
case L0==chr(0)+chr(0)+chr(0)+chr(0) && not our case but often met
?[i'll think of it tomorrow. after RTFM. maybe..]
_o=-13

case L0==chr(0)+chr(0)+chr(8)+chr(0) && our case (Cyclopes & Fuel)
L1=frea(aa,4)
=fwri(bb,L0+L1)
L0=doubval(L1)+65536*doubval(subs(L1,3))
L1=frea(aa,4)
=fwri(bb,L1)
L1=doubval(L1)+65536*doubval(subs(L1,3))
if L0-L1#13
wait wind [unusual (not 13) difference: ]+allt(str(L0-L1))
endi
L0=frea(aa,L1)
if L1>13
L0=stuf(L0,13,1,chr(asc(subs(L0,13,1))-4))
endi
=fwri(bb,L0)
L0=frea(aa,2)
=fwri(bb,L0+frea(aa,doubval(L0)))
L0=frea(aa,4)
=fwri(bb,L0+frea(aa,doubval(L0)+256*doubval(subs(L0,3))+4))

dime skey(4,2) && 48 06 B3 00
skey(1,1)=4
skey(1,2)=8
skey(2,1)=0
skey(2,2)=6
skey(3,1)=11
skey(3,2)=3
skey(4,1)=0
skey(4,2)=0

L0=0
do whil !feof(aa)
L0=iif(L0=4,1,L0+1)
L1=asc(frea(aa,1))
=fwri(bb,chr(16*mod(int(L1/16)-skey(L0,1),16)+mod(mod(L1,16)-skey(L0,2),16)))
endd

othe
?[yet unknown (to me

gpi-type]
_o=-14
endc

=fclo(bb),fclo(aa)
retu _o

func doubval
para _
retu asc(_)+256*asc(subs(_,2))[/hide]

**Giomen** · 30th June 2013, 12:42 AM

Originally Posted by sbog

By some reasons i shall not distribute full standalone executable, - only small one for VFP.9 (but user must install FoxPro libraries from elsewhere). If it is ok - i can do this.

OK! If WinHex or sbog have some reason do not want to make a full standalone executable - Microsoft Excel with copy-paste do it in any case