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)
Becouse i search in text not hex
Slovenian and Slovakian user now have working Fuel Types and Vehicle Charge Points.gpi thank to syzygy for decrypted file i hope user will give Rep to syzygy.
[Only registered and activated users can see links. ]
And i like to thank you again @sbog for tip for autochange becouse i forget this function.
p.s.
I am not programmer so i don't know all tips and tricks but i try to learn from you who know how to do it.
My only goal is to help other users who don't know how to do it.
So, respect and thank you both for all your help and tips.
p.s.
the same link for repaired gpi is also in post n18 on previous page.
You have also in post #18 picture how is look before and after.
Also in Caty post #2 you have link for download
The difference between stupidity and genius is that genius has its limits.
Albert Einstein.
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...
Last edited by Giomen; 29th June 2013 at 02:17 AM.
Garmin, how much is 30 pieces of silver for Judas today? Were they worthy for crucifix of GPSPower?
No, i'm sbog.
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]
Last edited by sbog; 30th June 2013 at 09:59 PM. Reason: Code changed in order to fully correspond both Cyclops and Fuel types POIs :)
Bookmarks