Inverse geotagging from Akaso V1 (2019 version) dashcam footage

[Mickey1962]

Hello,

I am new here, and I decided to ask your help because I am desperately stuck decoding the GPS data of the latest Akaso V1 firmware-generated Dashcam movie.

The exiftool latest version (12.00) does not decode the GPS informations (Lat, Lon, speed, direction, etc.) at all and I have zero knowledge on how to go forward with those strange files (clearly strange because you excellent tool decodes 40 GPS data format...).
The blocks of data are tagged with "freeGPS x" hence it should be standardised though :-(

Anyway, I have uploaded a sample ( https://rabozee.net/dashcamGPS/2019_0529_143945_192.MOV ) and the vendor reader (windows: https://rabozee.net/dashcamGPS/v1-win-1.0.3.rar and Mac: https://rabozee.net/dashcamGPS/GPSPlayer_MAC 2.6.7.zip ) so it could help to see the data extracted by the official tool.

Why I want to be able to read the GPS data myself is because the vendor tool does not offer the ability to export travels :-(

I already have listed the first 11 seconds of Lat, Long, Speed:

Code Select Expand

LAT           50.830141 50.830076 50.830010 50.829943 50.829876 50.829779 50.829683 50.829585 50.829492 50.829388 50.829293
LON            4.433328  4.433369  4.433410  4.433434  4.433452  4.433425  4.433365  4.433297  4.433190  4.433092  4.432973
SPD (km/h)    --        27        28        28        27        35        40        43        45        48        48
    (MPH)     --        16        17        17        16        22        25        26        28        29        30


Do you think it is feasible to decode this particular format ?

Thank you and have a good day,

Michel

[Phil Harvey]

Hi Michel,

I've got the sample, thanks.  I'll take a look at this when I get a chance and post back here when I know more, but my goal is to have support for this in the next release.

- Phil

[Mickey1962]

Thank you already, Phil !

Have a nice day!

Michel

[Mickey1962]

Hello,

I uploaded a second sample (https://rabozee.net/dashcamGPS/2019_0529_143645_191.MOV ) where the GPS is not yet active, then it becomes active (around 2 minutes into the video, GPS record #120). I saw that some bytes change in that case (V00 becomes ANE). This can be useful to see some value changes.

I also saw that the endianness seems to be LITLLE ENDIAN (at least for the year)

from the first 'GPS' record:
  168298: 0e 00 00 00 27 00 00 00 2c 00 00 00 e3 07 00 00 [....'...,.......]
  1682a8: 05 00 00 00 1d 00 00 00 41 4e 45 00 00 00 00 00 [........ANE.....]
  1682b8: f1 4e 3e 3d 90 df ca 40 e3 50 bf 0b 0b 31 a0 40 [.N>=...@.P...1.@]
  1682c8: 4b dc c8 41 9a 79 a7 43 34 58 43 31 4f 37 31 35 [K..A.y.C4XC1O715]
  1682d8: 35 31 32 36 36 35 37 35 59 4e 44 53 0d e7 cc f9 [51266575YNDS....]
0x30 : 0e   14      => hours
0x31 : 00   
0x32 : 00   
0x33 : 00   
0x34 : 27   39      => minutes
0x35 : 00   
0x36 : 00   
0x37 : 00   
0x38 : 2C   44      => seconds
0x39 : 00   
0x3A : 00   
0x3B : 00   
0x3C : E3   2019   => year *LOW* byte
0x3D : 07   2019   => year *HIGH* byte
0x3E : 00   
0x3F : 00   
0x40 : 05   05      => month
0x41 : 00   
0x42 : 00   
0x43 : 00   
0x44 : 1d   29      => day
0x45 : 00   
0x46 : 00   
0x47 : 00   
0x48 : 41   'A' ('V' if GPS not yet available)
0x49 : 4e   'N' ('0' if GPS not yet available)
0x4A : 45   'E' ('0' if GPS not yet available)
0x4B : 00   
0x4C : 00   
0x4D : 00   
0x4E : 00   
0x4F : 00   
(...)

(I know, those were the easy ones... I am lost afterwards :-( )

HTH,

Michel

[Mickey1962]

And for info (as this seems to be on each GPS data record, the serial number of my cam is 4XC1O71551266575YNDS :-)

And I played a bit today, with fresh eyes. I only struggle now on the latitude and longitudes. They seem to be 0x50-0x57 and 0x58-0x5F in the GPS record, but I do not succeed handling the 8 bytes (reading as double does not give something logical).

Regarding speed and track, they seem to be:
SetByteOrder('II');
$spd = GetFloat($dataPt, 0x60); # in km/h
$trk = GetFloat($dataPt, 0x64) + 180;   # (why is this off by 180?)

and the date/time + stat and later and loners are:
($hr,$min,$sec,$yr,$mon,$day,$stat,$latRef,$lonRef) =
            unpack('x48V6a1a1a1x1', $$dataPt);

HTH,
Michel

[Phil Harvey]

Hi Michel,

So far I'm stumped like you.  It really looks like little-endian doubles at 0x50 and 0x58:

Code Select Expand

    0050: f1 4e 3e 3d 90 df ca 40 e3 50 bf 0b 0b 31 a0 40 [.N>=...@.P...1.@]

but this decodes to 13759.126869 2072.521574, which doesn't make a lot of sense.  Plus, the first value jumps around a lot.

Given the lat/lon values you report for the first data point, as simple doubles this would be

Code Select Expand

    0050: cc 08 6f 0f 42 6a 49 40 ad c3 d1 55 ba bb 11 40 [..o.BjI@...U...@]

or in DDDMM.MMMM format:

Code Select Expand

    0050: 20 0c 3c f7 ce b9 b3 40 72 a7 74 b0 fe 9f 7a 40 [ .<....@r.t...z@]

I can't see an obvious way to map either of these to the actual stored value.

The lat/lon must be in 0x50-0x5f, but it looks like they are obfuscated somehow.  I may have to try filling the values with known bytes and seeing what the player reads back, but this will take some time and it may take me a couple of weeks before I can do this.

- Phil

[Mickey1962]

I guess you are right, some bytes are coded or whatever . On the first seconds of the travel of the 2019_0529_143945_192.MOV video, latitude should keep decreasing, but it goes up and down, as you say. The longitude keep increasing though as it should.

But none are near the real values (first 3 seconds):
50.830141   50°49'48.508
50.830076   50°49'48.274
50.830010   50°49'48.036

4.433328   4°25'59.98"
4.433369   4°26'0.128"
4.433410   4°26'0.276"

By the way, I found that byte 0x85 in some GPS records gets values from 0 to 5... Maybe it is related ?

Take your time, it is weeks I grip my hairs on it :-(

Michel

[Mickey1962]

Putting just "00 00 00 00 00 00 CA 40 00 00 00 00 00 00 A0 40" into $50-$5F leads to LAT 49.403432 / LON 4.344482 therefore, the LAT/LON must have a reference somewhere in the file :-(

Moreover, after having manipulated the bytes $56-$57, the same two values continue to be displayed the rest of the file, even if I only touched the first sample... Same behaviour if I touch the bytes $5E-$5F.

And as the other values (direction, speed) are still OK, I did not damage the file structure...

The mystery thickens ... I am frustrated LOL. why did they make those data so obscure ?

PS: the byte 0x85 seems to be the "Z" value in the Akaso Player interface.

[Mickey1962]

(I edited my previous post... my initial conclusions where wrong)

[Phil Harvey]

What is the purpose of the "Z" value?

I was going to try to replicate the initial stored lat/lon bytes (0x50-0x5f) into all GPS records.  Then I would take a look to see if the lat/lon changes, and if so are the changes correlated with the time, or possibly byte 0x85?  If you can find something that changes at the same time as the app-extracted lat/lon while the stored values are constant then you have found the encryption key for decrypting these values.

It is worrisome that changing the first value to something random breaks display of the rest of the values.

- Phil

[Mickey1962]

I have no idea on the purpose of the X, Y, Z values displayed in the Akaso GPSPlayer (in the lower middle of the display).

I just took a video of the first 30" run of the sample file (2019_0529_143945_192.MOV) in the Akaso GPSPlayer: https://rabozee.net/dashcamGPS/IMG_5553.MOV

You can see that the Z: value just display what is in the byte $85. It just jumps randomly in my eyes, with no correlation with the location. The X: value is completely weird also and I have no clue where it is taken from in the 2019_0529_143945_192.MOV file.

[Phil Harvey]

I just tried the GPSPlayer app myself.  There is another wrench in the works:  The player makes an internet connection to goodcam.net. If you disallow this connection then the GPS is not displayed during playback.  I really hope that it isn't using something from goodcam.net to decode this.

- Phil

[Mickey1962]

Wow, that explains why once my connection was off and the display was not running (I just though it was logical that without internet access, the Google map did not show up).

Anyway, as the video is encoded by the Dashcam, which has no internet connection, if anything, it should be a fixed data. Maybe it is just to display the Google map, I hope.

Good catch, I really did not think this kind of app would phone home :-(

[Phil Harvey]

No.  I allowed access to google for the maps, and just blocked the goodcam.net connection.  The map showed up, but didn't move to anywhere because the position indicators were all showing as "--".

I really hate software like this that won't work when the company (inevitably) stops supporting the software, or (more likely for a small company like this) goes out of business.

- Phil

[Mickey1962]

You are right, and I hate this.

By the way, what domain exactly does the application contact ? There is a new player (this time, it is not free, 10$) for Akaso (still basic though :-( ) they moved to: https://www.dvplayer.net

I saw GPSPlayer contacted (but only at startup)
47.89.75.200
47.246.74.100
47.89.88.73
47.246.74.109

And the "GPSPlayer Helper" also makes connections:
47.254.88.82 every second :-( thus for each lat/long decoding

The new DVPlayer calls
47.89.75.200
47.246.74.100
47.89.88.73
47.246.74.109
47.246.74.104

And the "DVPlayer Helper" calls:
150.109.49.96 every seconds

Even if they need something from those ressources to handle the lat/lon, I do not understand how, as the Dashcam itself does not have access to internet therefore has no way to use the same resources...