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...

[Phil Harvey]

I think you are right.  We must be able to decipher this without an internet connection.

The GPSPlayer contacts the domain that I mentioned.

- Phil

[Mickey1962]

Hello,

I checked further. It seems that host 47.254.88.82 is called every seconds when starting viewing a file, but only 12 times, no more after that (see screen shot of Private Eye).

So I used Wireshark to check the exchange with that server, this is the result. It seems that it exchange some key :-( BUT always the same: p2524489676671331816

And the requests sent by the application already contain the correct LAT/LONG (jd=4.433328166666667&timestamp=1559140784&wd=50.830141166666664) hence, the decoding has already taken place before the calls (which seem to be only a "phone home" to track use of their dashcam (as the requests contain also my cam serial number)... BTW, as I never agreed to send my trip locations, this is in perfect violation of the current privacy laws !!!

I included the PCAP file with the exchange.

Here are the text data of the HTTP exchanges: (only 2, all in an attachment as it is too many characters)

Frame 4: 382 bytes on wire (3056 bits), 382 bytes captured (3056 bits)
Ethernet II, Src: Apple_17:cf:8e (80:e6:50:17:cf:8e), Dst: DrayTek_ee:d7:a0 (00:1d:aa:ee:d7:a0)
Internet Protocol Version 4, Src: 192.168.1.10, Dst: 47.254.88.82
Transmission Control Protocol, Src Port: 53941, Dst Port: 80, Seq: 1, Ack: 1, Len: 316
Hypertext Transfer Protocol
    GET /api/gpscode/getgpstoken?clientid=dbehf9dd4b2216559c89f93gb8e19ee6fb80&clienttype=2&gpscode=4XC1O71551266575YNDS&jd=4.433328166666667&timestamp=1559140784&wd=50.830141166666664 HTTP/1.1\r\n
    Content-Type: application/json\r\n
    X-GPS-Secret: 4b1281bb170e7e30ee42f811ae7ff156\r\n
    host: agps.goodcam.net\r\n
    Connection: close\r\n
    \r\n
    [Full request URI: http://agps.goodcam.net/api/gpscode/getgpstoken?clientid=dbehf9dd4b2216559c89f93gb8e19ee6fb80&clienttype=2&gpscode=4XC1O71551266575YNDS&jd=4.433328166666667&timestamp=1559140784&wd=50.830141166666664]
    [HTTP request 1/1]
    [Response in frame: 5]
Frame 5: 280 bytes on wire (2240 bits), 280 bytes captured (2240 bits)
Ethernet II, Src: DrayTek_ee:d7:a0 (00:1d:aa:ee:d7:a0), Dst: Apple_17:cf:8e (80:e6:50:17:cf:8e)
Internet Protocol Version 4, Src: 47.254.88.82, Dst: 192.168.1.10
Transmission Control Protocol, Src Port: 80, Dst Port: 53941, Seq: 1, Ack: 317, Len: 214
Hypertext Transfer Protocol
    HTTP/1.1 200 OK\r\n
    Content-Type: application/json; charset=utf-8\r\n
    Server: Microsoft-IIS/8.5\r\n
    X-Powered-By: ASP.NET\r\n
    Date: Sat, 20 Jun 2020 10:58:50 GMT\r\n
    Connection: close\r\n
    Content-Length: 22\r\n
    \r\n
    [HTTP response 1/1]
    [Time since request: 0.162687000 seconds]
    [Request in frame: 4]
    [Request URI: http://agps.goodcam.net/api/gpscode/getgpstoken?clientid=dbehf9dd4b2216559c89f93gb8e19ee6fb80&clienttype=2&gpscode=4XC1O71551266575YNDS&jd=4.433328166666667&timestamp=1559140784&wd=50.830141166666664]
    File Data: 22 bytes
JavaScript Object Notation: application/json
Line-based text data: application/json (1 lines)
    "p2524489676671331816"

Frame 12: 382 bytes on wire (3056 bits), 382 bytes captured (3056 bits)
Ethernet II, Src: Apple_17:cf:8e (80:e6:50:17:cf:8e), Dst: DrayTek_ee:d7:a0 (00:1d:aa:ee:d7:a0)
Internet Protocol Version 4, Src: 192.168.1.10, Dst: 47.254.88.82
Transmission Control Protocol, Src Port: 53945, Dst Port: 80, Seq: 1, Ack: 1, Len: 316
Hypertext Transfer Protocol
    GET /api/gpscode/getgpstoken?clientid=dbehf9dd4b2216559c89f93gb8e19ee6fb80&clienttype=2&gpscode=4XC1O71551266575YNDS&jd=4.433328166666667&timestamp=1559140784&wd=50.830141166666664 HTTP/1.1\r\n
    Content-Type: application/json\r\n
    X-GPS-Secret: 4b1281bb170e7e30ee42f811ae7ff156\r\n
    host: agps.goodcam.net\r\n
    Connection: close\r\n
    \r\n
    [Full request URI: http://agps.goodcam.net/api/gpscode/getgpstoken?clientid=dbehf9dd4b2216559c89f93gb8e19ee6fb80&clienttype=2&gpscode=4XC1O71551266575YNDS&jd=4.433328166666667&timestamp=1559140784&wd=50.830141166666664]
    [HTTP request 1/1]
    [Response in frame: 13]
Frame 13: 280 bytes on wire (2240 bits), 280 bytes captured (2240 bits)
Ethernet II, Src: DrayTek_ee:d7:a0 (00:1d:aa:ee:d7:a0), Dst: Apple_17:cf:8e (80:e6:50:17:cf:8e)
Internet Protocol Version 4, Src: 47.254.88.82, Dst: 192.168.1.10
Transmission Control Protocol, Src Port: 80, Dst Port: 53945, Seq: 1, Ack: 317, Len: 214
Hypertext Transfer Protocol
    HTTP/1.1 200 OK\r\n
    Content-Type: application/json; charset=utf-8\r\n
    Server: Microsoft-IIS/8.5\r\n
    X-Powered-By: ASP.NET\r\n
    Date: Sat, 20 Jun 2020 10:58:51 GMT\r\n
    Connection: close\r\n
    Content-Length: 22\r\n
    \r\n
    [HTTP response 1/1]
    [Time since request: 0.161264000 seconds]
    [Request in frame: 12]
    [Request URI: http://agps.goodcam.net/api/gpscode/getgpstoken?clientid=dbehf9dd4b2216559c89f93gb8e19ee6fb80&clienttype=2&gpscode=4XC1O71551266575YNDS&jd=4.433328166666667&timestamp=1559140784&wd=50.830141166666664]
    File Data: 22 bytes
JavaScript Object Notation: application/json
Line-based text data: application/json (1 lines)
    "p2524489676671331816"


HTH,
Michel

[Phil Harvey]

I've confirmed that the latitude is definitely stored in bytes 0x50-0x57, and the longitude in 0x58-0x5f.

I've run a number of tests.  Setting all of the lat/lon values to the same as the first sample results in a constant lat/long that all of a sudden jumps at 14:41:35 in the video.  The same thing happens if I set all the values to the lat/lon from the 2nd or 3rd sample.  But if I leave the 1st sample alone and set the remaining ones to the same as the 2nd sample, then the jump occurs at 14:41:45 (ie. 10 seconds later).  And if I leave the first 2 samples alone and set the rest according to the 3rd sample, it jumps at 14:41:29.  So somehow the history of these values influences the future values.  There appears to be some sort of rolling encryption applied to the lat/lon values.

Latitude seems to be relatively independent of longitude (I can mess with one and it doesn't affect the other), except that if I screw things up too badly the lat/lon stop changing in GPSPlayer.  I guess this happens if it finds an illegal value.

I can play with the lower-order bytes and the position shifts only by a little (eg. from 50.830023 to 50.830100 when bytes 0x50-0x53 are set to 0x00 and 0xff respectively), but incrementing byte 0x54 by 1 results in a shift that is larger than expected (from 50.830010 to 50.844503).

This is all a lot of fun, but I think I'm learning that I the encryption scheme is complex enough that I may not have time to figure it out.

- Phil

[Mickey1962]

  So sad.

I still remain puzzled by the very first sample is decoded from thin air (no previous value to rely on.

Maybe the timestamp is a kind of seed (the one the camera put to the samples) ?

So you definitely think there is no way to guess ? (And Akaso refuses to give away the scheme).

Anyway a big big thank you for having tried 

[Phil Harvey]

I've not given up totally, but I'm not very optimistic at the moment.  My last attempt was to write down the lat/lon values for the first 39 samples, convert them to DDDMM.MMMMM format, turn these into a double-precision floating-point numbers, then xor this with the actual data for each sample and take a look at the differences.  I was hoping it was a simple xor scheme with some key, and if so this would reveal the key, but no such luck.  I expect round-off errors in the first few lower-order bytes, but was hoping for some pattern in the upper bytes.  Here is the result of the XOR in hex:

Code Select Expand

XOR 5aa99aca5d667900 d4b04cc80391da00
XOR 74d1bd5bb25a6300 45dd8f0b0291da00
XOR 6faee3575c547500 f21d5c130e91da00
XOR 6c7ef3b0a7776500 08b788d30491da00
XOR 0b35751e2e6a5300 5030a5160a91da00
XOR 038fbcd3fe3a5600 074d8c721f91da00
XOR f1acad9957547500 401d3026e7aeda00
XOR 48cae2631c056800 900d6c76daaeda00
XOR ecf39f73d8f25000 f101fdc933afda00
XOR 08081ef791a30f00 bfa785cf4eafda00
XOR 6fbb4b0761ec5300 33bc5c0a54afda00
XOR b15f2b8c47627800 364653b8b9afda00
XOR 8484ed21c7667900 30b4b76aeaafda00
XOR b1449f06b88d6d00 4aa0c65a9fafda00
XOR 39d21dabb4fb6900 c206fde281afda00
XOR 613305be35fe5700 f49a854e78aeda00
XOR 21175d2e8faa0d00 610f0b89f2b2d000
XOR 93bbcb25c25f7b00 2efbde0034b5d000
XOR 42de063027606200 1952e22354b5d000
XOR 840f55df7c736400 1e0a796f52b5d000
XOR 197ce57fdf5f7b00 2eb091c632b5d000
XOR 0a375c8f92980900 ac4018f8d3b5d000
XOR b423940996980900 28981bc9f6b5d000
XOR 19c793ccc05f7b00 52bbde8fd2b5d000
XOR 2cf467a54f8a6d00 6cda4b4c31b5d000
XOR 93844426b7e86700 3b0a4cac53b5d000
XOR c7faa14fd04d7700 34626f0470b5d000
XOR 95a724bd4b836f00 7040620a5cb5d000
XOR 2cc9b25aa9bf7300 631e763c32b5d000
XOR f2da182dd6617f00 657a32ca2db5d000
XOR d4833783e5f56400 1d013607d6b6d000
XOR 79aeba1f495b7a00 929d09a5d4b6d000
XOR d4b8c7d72b747c00 2cfae029ebb6d000
XOR 069f3d535a5b7a00 cbfb686ee8b6d000
XOR 97e0b8db5e5b7a00 a4daf79fe0b6d000
XOR 8cd88942ab617f00 f6529105deb6d000
XOR eccc2218cdaf5300 aa92571c26b5d000
XOR 7549d76638627800 2a2b007639b5d000
XOR 26e88f8093910b00 c254549f2bb5d000

I also tried this in DDD.DDDDDD format, but things looked even a bit more random.

- Phil

[Phil Harvey]

The real way to solve this is to step through the GPSPlayer source code in a debugger to see what it is doing, but I lack the expertise to do this efficiently.

- Phil

[Phil Harvey]

AH HA!!!  A bit of a breakthrough!

When I plot the values decoded as double, there are strong periodic features:

The latitude follows a pattern that repeats every 60 samples! -- so the time in seconds is the encryption key.  We just need to figure out the encryption scheme.

The longitude follows a pattern that jumps every 60 samples -- so the time in minutes is the encryption key for this.

There is hope...

- Phil

[Mickey1962]

Excellent ! You brightened my day. I do not want to jinx it but cheers already !

Michel R.

[Phil Harvey]

It is possible that the hour is also convoluted into the mix.  Do you have a video that crosses into the next hour?

- Phil

[Mickey1962]

Hello Phil,

sure, I uploaded 2 files:

https://rabozee.net/dashcamGPS/2019_0524_125730_086.MOV
https://rabozee.net/dashcamGPS/2019_0524_175737_096.MOV

Hope those meet the requirements :-) (the 2019_0524_175737_096.MOV is interesting because the car is quite still when time changes...)

[Phil Harvey]

Thanks!  These should be helpful.

- Phil

[Phil Harvey]

OK.  A bit more information:

1. The hours are not part of the encryption key.  So it looks like only the minutes and seconds of the time are used.

2. The storage format is definitely IEEE 64-bit floating point in DDDMM.MMMMM format.  I have confirmed this by twiddling bits in byte 6 (starting from byte  0) of the latitude value and observing the output in GPSPlayer.  The upper 3 bits of byte 6 are the exponent as expected.  The lower 5 bits behave in expected binary fashion, and the latitude increases/decreases with a predictable pattern when these are changed.  However, changing individual bits in byte 4 doesn't have the expected result.  I'm not sure what is going on here, but more work is needed.

- Phil

[Mickey1962]

Thank you for keeping me updated, Phil !

Crossing fingers, but take your time, I guess it is a nice challenge ;-)

[Mickey1962]

Hi, just passing by to see if you were able to get something new with this ?

Hope you are well, have a nice day

- Michel

[Phil Harvey]

No word, sorry.  I don't hold out much hope but I still have this on my list for things to work on.  I'll be spending more time indoors now that the summer is over so hopefully I'll find time for this.

- Phil

[Mickey1962]

Thank you, and be safe !!

[Vasyoid]

Hello! I am currently working on an android application that plays videos recorded by a DVR and have faced the same problem. I've tried extracting GPS data from the videos using the ExifTool but this data seem to be encoded in the same format, so I just wanted to ask if there is any progress or new information in this matter.

Thanks in advance and have a nice day!

- Vasily

[Phil Harvey]

No progress, sorry.  If I could get more samples with wildly different lat/lon values, I might be able to make more headway.

- Phil

[Mickey1962]

Hello Phil, I can provide that. I have a full trip from Italy to Belgium.

I thought you did not have time anymore for this, hence I did not contact you again to not bother you, sorry for the misunderstanding.

I will upload 13 of them, taken from various locations of the trip. Let me know if this can help.

I will send the links in private message (just to avoid anyone to download them as they contain my conversations with my wife LOL).

Thank you again for investigating this !!!

[Phil Harvey]

Hi Michel,

I've looked at the first one you sent.  This is TS format, not MOV like the earlier samples.  Is it the same camera?

- Phil

[Mickey1962]

Hello, Phil, when I download them, they are correctly retrieved and they read OK in the Akaso Player. Maybe your browser converts them ? Maybe the easiest is to use a command line tool like curl to retrieve them ?

They are stored on the same server as the initial samples I gave you (first post of this thread), so I am pretty sure nothing is in the way there.

If curl does not work, I can force the web server to serve the files as binary octet-stream instead ?

Let me know.

[Phil Harvey]

I need more information.  The earlier files were 2019_0524_125730_086.MOV and 2019_0524_175737_096.MOV

And I just received via email a download link for 2021_0814_233220_136A.TS -- did you send it?  If so, it definitely has a .TS extension.  My browser isn't doing that, but it is possible that the file storage host could.

- Phil

[Phil Harvey]

OK.  I just found the private message you sent with the MOV videos.  Someone else must have sent the .TS file.

- Phil

[Mickey1962]

Ah, I now understand the confusion ;-) No, it is not me who sent the TS.

I "only" sent the 13 .MOV as I said, from a 12 hours trip from Livorno (Italy) to La Hulpe (in Belgium). I took 1 file every 20 and it is mainly speedway so you should have a good information with steady latitude and longitude modifications.

[Vasyoid]

I also have some sample videos but they are in MP4 format and are taken in one single place because my camera is not yet portable. I can send these videos if this helps.

- Vasily

[Phil Harvey]

Hi Vasily,

Sure.  Send me one, it could be useful.  My email is philharvey66 at gmail.com

- Phil

[Phil Harvey]

Mickey:  Could you send one video where the car is stationary for the entire video?  This will help to determine how the encryption is changing the bits.

Thanks.

- Phil

[Mickey1962]

Sure, here they are:

Lat. 50.751449 - Long. 4.493061
https://rabozee.net/dashcamGPS/2021_0226_120349_722.MOV

Lat. 50.736581 - Long. 4.494977
https://rabozee.net/dashcamGPS/2021_0305_171520_777.MOV

You are most welcome !

[Phil Harvey]

Hi Michel,

Great, thanks.  These help, but I need more of them.  (Longer like the other ones if possible)

- Phil

[Mickey1962]

Hmmm.... Not easy, here it is normally forbidden to leave a running vehicle steady. I will try (3 minutes is OK, right ?)

[Vasyoid]

Hi Phil,

I've sent you one sample video. Please make sure you can download it.

- Vasily

[Mickey1962]

Hi Phil, here are "steady" samples:

Lat. 50.734303 - Long. 4.505689
https://rabozee.net/dashcamGPS/2021_0818_175823_002.MOV
https://rabozee.net/dashcamGPS/2021_0818_180123_003.MOV

Hope this helps :-)

[Phil Harvey]

Michel,

You need to have the vehicle running to get the video?  That's interesting.

Anyway, do what you can but don't go to too much trouble.  I'm playing with bit patterns here and am not much closer to figuring out the encryption, so even with these videos I may be stumped.  I'm downloading the new files now.

- Phil

[Phil Harvey]

Vasily,

I downloaded the video you sent OK.  Thanks.

- Phil

[Mickey1962]

Michel,

You need to have the vehicle running to get the video?  That's interesting.

Anyway, do what you can but don't go to too much trouble.  I'm playing with bit patterns here and am not much closer to figuring out the encryption, so even with these videos I may be stumped.  I'm downloading the new files now.

- Phil

I need to have the engine running or at least the vehicle powered up otherwise the dash cam shuts down after 30 seconds (it is how it is wired). I currently cannot have the power on the vehicle without having it running because I do not drive a lot at the moment and the battery is not much charged (bloody modern cars ;-) ) :-)

Anyway, I put above the requested files, I copy again the urls here, will be easier:

Lat. 50.734303 - Long. 4.505689
https://rabozee.net/dashcamGPS/2021_0818_175823_002.MOV
https://rabozee.net/dashcamGPS/2021_0818_180123_003.MOV

Hope this helps :-)

[Phil Harvey]

Hi Michel,

OK.  I have averaged the encrypted latitude values based on the timestamp seconds, and the longitude values based on the timestamp minutes, then subtracted this from the known GPS coordinates you provided for the 2 long stationary videos.  The result gives me the lookup tables below which could potentially be used to decode coordinates from other videos.  The first column assumes the lat/lon are stored in decimal degrees (probably unlikely), and the second column assumes DDMM.MMMM format (I think this is more likely, particularly since the constants are smaller for this case).  But there a few problems with this:

1. We don't have all of the possible minutes values sampled, so the longitude table is incomplete.

2. The encryption may involve more than just minutes and seconds.

3. I don't know if the correction should be done by bitwise operations, or by adding a floating-point offset.  (Currently I'm thinking bitwise.)

4. Since I haven't been able to find a general algorithm that applies to all seconds/minutes, the decryption is based on empirical values averaged from your videos, so the lat/lon values won't be exact.  (Although we could theoretically improve this in time, provided we are doing things correctly.)

If I can generate a complete lookup table (ie. fill in the missing minutes from point 1), then I can test points 2 and 3 with the moving videos to see if I can get the decoding working (but we may get stumped here if more than minutes and seconds are used in the encryption).  If this works, then we can address point 4 to tweak the constants to improve the accuracy.

If this seems like a lot of work, it is.  Sorry, but the first step will be to obtain stationary videos for a complete hour so we can determine the constants for all minutes.

Code Select Expand

--- latitude
00 sec 0x6764fa91bdad7500 0x85241d51ac560b00
01 sec 0xd0f0e86c68827f00 0xeeb00b2c572b1500
02 sec 0xb43fe498d37d8800 0xd1ff0758c2261e00
03 sec 0xc3b399430a678e00 0xe172bc03f9102400
04 sec 0x6c8fdd7068827f00 0x8a4f0030572b1500
05 sec 0xfa939fd2edbc7100 0x1852c292dc650700
06 sec 0x5d6e2fd4edbc7100 0x7b2d5294dc650700
07 sec 0xbd3e897768827f00 0xdafdac37572b1500
08 sec 0x1a95adf35bce9500 0x3854d0b34a772b00
09 sec 0xa9ac148054f48b00 0xc76b3740439d2100
10 sec 0xf262f5b298917b00 0x10221872873a1100
11 sec 0xd13eeb1af3d59300 0xeefe0ddae27e2900
12 sec 0xfe0babf693a47700 0x1bcaceb6824d0d00
13 sec 0x9785764e37738300 0xb544990e261c1900
14 sec 0xcfac2660f0e88e00 0xed6b4920df912400
15 sec 0x1f0f7c779c7e8000 0x3cce9f378b271600
16 sec 0xfd7f4426d3678600 0x1b3e66e6c2101c00
17 sec 0x4cfe277f9c7e8000 0x6abd4a3f8b271600
18 sec 0xaddab7809c7e8000 0xcb99da408b271600
19 sec 0x694d065a37738300 0x870c291a261c1900
20 sec 0xaf678a26e2b49700 0xcd26ace6d15d2d00
21 sec 0xc8281a5a03778200 0xe5e73d1af2201800
22 sec 0xf5d3150185c46f00 0x139237c1746d0500
23 sec 0xa68376dff3e09c00 0xc442999fe2893200
24 sec 0xb268ce65d76a8d00 0xd027f125c6132300
25 sec 0x43183e8d34867e00 0x60d7614d232f1400
26 sec 0x0175030527d29400 0x1f3425c5167b2a00
27 sec 0x1784de7368827f00 0x35440133572b1500
28 sec 0xa98a3e1fa65b9100 0xc74960df95042700
29 sec 0x0b2b018900897d00 0x28ea2449ef321300
30 sec 0x32c2dac3011f9c00 0x5081fd83efc83200
31 sec 0xe63a21df85c46f00 0x03f9449f746d0500
32 sec 0xc20bca47d66a8d00 0xdfcaed07c5132300
33 sec 0xe4d463db8be89a00 0x0293869b7a913000
34 sec 0x8db5d1febfd99200 0xab74f4beae822800
35 sec 0xffc79e3dcf7a8100 0x1d86c0fdbe231700
36 sec 0x8f334cd88be89a00 0xacf26f987a913000
37 sec 0x37a27ad685c46f00 0x55619d96746d0500
38 sec 0x268c656534867e00 0x444b8825232f1400
39 sec 0xdba93b3cd66a8d00 0xf9685dfcc5132300
40 sec 0xcb3258dc726a9900 0xe8f17b9c61132f00
41 sec 0xa4efddf9bfd99200 0xc2af00b9ae822800
42 sec 0x739514459b7e8000 0x915437058a271600
43 sec 0xddec7f2803778200 0xfbaba1e8f2201800
44 sec 0x4d530438cf7a8100 0x6b1226f8be231700
45 sec 0x7b5729959f818700 0x99164c558e2a1d00
46 sec 0x194f037100897d00 0x370e2631ef321300
47 sec 0x77b0d839d66a8d00 0x956ffaf9c5132300
48 sec 0x8a263cf90a729700 0xa7e55fb9f91b2d00
49 sec 0xf3c231b6011f9c00 0x11815476efc83200
50 sec 0x52886c7800897d00 0x70478f38ef321300
51 sec 0x465ec2f9da579200 0x641de5b9c9002800
52 sec 0x25ab21dc8be89a00 0x436a449c7a913000
53 sec 0x466c9ca555b57300 0x642bbf65445e0900
54 sec 0xf6b1170aeff39700 0x147039cade9c2d00
55 sec 0x737cb43803778200 0x913bd6f8f2201800
56 sec 0xc32e1f49cf7a8100 0xe0ed4209be231700
57 sec 0x732cdbdf5bce9500 0x90ebfe9f4a772b00
58 sec 0x7eeb8b198bdd9100 0x9caaadd97a862700
59 sec 0xf79fa3d3bfe49b00 0x155ec693ae8d3100
--- longitude
00 min 0x130b7c45afae7500 0xae46e17b0bce0d00
01 min 0x921f86564b8e8000 0x2d5aeb8ca7ae1800
02 min 0xee85a90ccdf38700 0x89c10e422a131f00
03 min 0xe7b513ca48008f00 0x82f07900a4202700
04 min 0x3f2c6cc9418e8000 0xda67d1ff9dae1800
58 min 0x100a4120a4ae9000 0xab45a65600ce2800
59 min 0x58ba6c10a36e9a00 0xf3f5d146ff8e3200

- Phil

P.S. We got a couple of rainy days in a row, which is why I have time to play with this now.  And the forecast is for rain again tomorrow.

[Mickey1962]

Wow ! Great .

Tomorrow morning (European time), I will record like 1:15 hour of steady videos then (25 files). I found a spot where I am quiet to do that (near the one from the 2 videos this afternoon). Then I will upload them. Is this timing OK for you ? (now it is 21:00 here hence run the engine for one hour is not a good idea, I am in a quite silent external environment.

Thank you !

[Phil Harvey]

Hi Michel,

That would be great, thanks.  Try to give me as accurate a GPS position as possible for where you take the videos.  Also, it would be best if you have a clear view of the whole sky (no large objects around) to make the GPS as stable as possible.

- Phil

[Mickey1962]

No problem, the area is wide in the open, I will wait for GPS stabilisation and provide the lat/long as the Akaso Player gives.

[Mickey1962]

Hello Phil, I just sent you an email with the details of the location of the files - just to avoid anyone to download those large files -.

Lat. 50.734150-50.734190 - Long. 4.505630 - 4.505670 (variations due to satellites, the dash cam was firmly fixed on a pole at 25 cm from the ground)

PS: I do not know why I did not think about that yesterday (the sad weather here as well maybe...) but it was way easier to unmount the dash cam from the vehicule, power it with a USB adapter, and put it in the alley near my house... no vehicule involved :-) How stupid I am.

Thank you !

[Phil Harvey]

I've spent a couple of hours working with the new files so far.

When I apply the decryption offsets calculated from the stationary videos, the residual error is about 20-30x larger than expected using both bitwise xor and floating point subtraction when I assume the floating point is stored in DDMM.MMMM format.  The residual would be 100x larger if I assumed DD.DDDDD format, so this isn't it.   So I tried using larger scaling factors to reduce the residual to expected range.  After this I got good results for the stationary video, but GPS from a moving video was garbage.  So I don't think I'm on the right track here.  A complication is that the encryption can be applied to either the binary or the floating point values, and the floating point could be scaled by an arbitrary amount, and with some unknown encoding.  The combination of all of these factors leads to a large number of possibilities.  I've explored about 6 of them so far, without success.

I'll move on to analyzing the moving videos to see if I can find any patterns that would give hints as to the strategy used.

- Phil

[Mickey1962]

It is really strange they added so much complexity to that thing. Also because so many computations are not easy on such a small device (I mean, the footprint of the internal memory and the velocity of the processor should not be so big).

[Phil Harvey]

Hi Michel,

I've bashed my head against this for another couple of hours, but no luck.

ExifTool 12.31 (not yet released) will extract GPSDateTime, GPSSpeed and GPSTrack from these files, and un-decrypted GPSLatitude and GPSLongitude.  Maybe someone will be able to figure out how to decrypt this.  I'm attaching the output of the following command for ExifTool 12.31 run on the stationary files at 50.734170,4.505650, and for the moving files from your trip.  These attachments show the stored values of lat/lon before decryption, interpreted as double-precision floating-point numbers.

exiftool -p "$main:filename $gpsdatetime $gpslatitude# $gpslongitude# $gpsspeed $gpstrack" -ee FILES > OUT.txt

I don't have the time to go any further with this right now.

- Phil

[Mickey1962]

OK, Phil, thank you for all the time you spent on this.

I guess it is a lost cause :-( BTW I downloaded the 2 result files you attached, just in case I come to some brilliant idea (I doubt it, but who knows), maybe it could be interesting to have the encrypted lat/lon in hexadecimal format ?

[Phil Harvey]

Hi Michel,

Getting an output which includes hexadecimal would be a bit of work for me.  But if anyone is doing some serious work with this, converting from double back to hex should be easy.  However, let me know if you really need this and I can do the work to add the hex.

- Phil

[Mickey1962]

Hi Phil,

no, do not bother; I thought it was just a matter of format in a sprintf or such, just to prevent the output in double and instead have it in raw hex bytes. Sorry, I do not know the internals of exiftool, I am too much thinking in terms of C ;-)

Have a nice remaining of day, and again thank you for having tried !

[Phil Harvey]

I went back and read my posts from last year.  I should have done that earlier, but it was good for me to look at this with fresh eyes.  I re-discovered some things that we already knew from earlier, but I tried some different things this time which is good.  Unfortunately none of them have panned out so far.

- Phil