HW2 Anonymous Snapshot

[luckyj]

So today I was able to capture one of the anonymous snapshot/image/video uploads that got pushed out over my home network. The file was uploaded via cleartext HTTP post to Amazon s3, file name of snapshot-cc2ae3b6-b884-42f2-9c18-be531f34cfcf-0000.tgz. It was 40MB in size, ~80MB uncompressed. Some files named like this: "892383829920.img.data.h265", others like this "890192887360.img.data" in a path named img\replay and img\main in that tarball.

So far, only partial success in getting anything useful out of it. One example is below. Seems to be stills, as far as I can tell. Not all files are decoding. There are some files that are larger, but the format is eluding me so far. There was also a snapshot.can file in a path named \var\log\canrx in the tarball, which I suspect is a capture of the CAN bus data for a brief period, but still working on that too. Might need to re-examine the capture, as there were re-transmissions and some out of order packets in the stream. Might be causing some of the problems.

So, not sure if I'll be able to get anywhere else with this, but it was interesting!

 

[Saghost]

Look over here and talk to @lunitiks and @verygreen and @DamianXVI. They have come up with all sorts of useful things to do with the information...

 

[luckyj]

Well now, that's interesting. I'll have to read up before I waste any more of my time lol.

 

[verygreen]

It was 40MB in size, ~80MB uncompressed

This looks like something else other than a random snapshot that are typically bigger and incorporate all cameras (~150-200M compressed).
Did you trigger FCW on that trip? That matches more the footprint you have. There's an archive_info.json file in there that lists the requester and that's how you know what triggered that particular snapshot (FCW for FCW, random for random snapshots and so on).

 

[luckyj]

No FCW. The archive info listed "requester": "rob-silent",

 

[verygreen]

No FCW. The archive info listed "requester": "rob-silent",

hm, never saw anything like that.

 

[whitex]

Can you access the destination server and look at the content you just uploaded? If yes, can you see any other content?

 

[luckyj]

If I could freakin figure out how to change the title of the thread I would add something like (maybe) to the anonymous part, since it seems suspect at this point.

The server has some access control, so far not been able to see anything else.

 

[oktane]

That's it I'm going to moon my forward camera or wash my car naked. Time to give the Tesla engineers a nice surprise.

 

[verygreen]

If I could freakin figure out how to change the title of the thread I would add something like (maybe) to the anonymous part, since it seems suspect at this point.

btw there's another clue.
If wall-time time is same as monotonic-time (first 10+ digits anyway) - it's an anonymous snapshot, otherwise it's not.

Every time APE turns on it creates a "log snapshot", so if you catch that you can get some interesting info in there too, e.g. in the telemetrypackager logs you can see what requests were pushed to the mothership, how often were they to trigger and such.

To trigger APE start: do the car poweroff thingie from CID display, all screens turn dark, don't touch anything for 70 or so seconds until you hear a loud fan from gloves compartment that dies down after about 2 seconds or so. Now your APE is off. Touch the screen or otherwise wake the car: now APE would wake up and generate the logs snapshot to be sent to the mothership.

 

[Saghost]

If I could freakin figure out how to change the title of the thread I would add something like (maybe) to the anonymous part, since it seems suspect at this point.

The server has some access control, so far not been able to see anything else.

You can edit things for up to about fifteen minutes on TMC, then they become locked.

If you need something change in a post/thread after it's locked, you can report the post and put in a comment to the Mods about what you'd like changed and why. They're usually pretty helpful.

 

[luckyj]

Okay, here's the full archive_info. Wall-time and monotonic time are massively different. They seem like different date formats entirely. wall-time is obviously a unix ns timestamp and matches my drive this morning. monotonic and request-trigger are not obvious. Do you know something about the format/reference for them, verygreen?

{
"snapshot-version": "0.3",
"wall-time": "1496667012458718256",
"monotonic-time": "899911173376",
"sha1": "0b94b5135537be0f",
"requester": "rob-silent",
"faux-board-id": "2b27044c-0558-4328-9b1a-9b446435d5d9",
"request-clock-type": "monotonic",
"request-trigger-time": "899906401440",
"boot-sec-info": "0x00000002",
"vehicle-type": "MS-LHD",
"entries": ""
}

 

[verygreen]

monotonic-time is ns time since last boot. It's also used in filenames for camera snapshots.
wall-time is unix ns time as you correctly indicated.
request-trigger-time is when it actually triggered (also relative to boot time).
anonymous snapshots masquerade wall-time as truncated monotonic time based on a sample I have. Or actually I might be wrong about it and it was just a coincidence they were close enough and I did not look carefully.

Here's a real random snapshot header sample:

{
    "snapshot-version": "0.3",
    "wall-time": "1494994624053269366",
    "monotonic-time": "14991075828894",
    "sha1": "0b94b5135537be0f",
    "requester": "random-replay-0007",
    "faux-board-id": "33141313-ef16-40d2-8fed-b5fbb5cb4afa",
    "request-clock-type": "monotonic",
    "request-trigger-time": "14991075748926",
    "boot-sec-info": "0x00000002",
    "vehicle-type": "MX-LHD",
    "entries": ""
}

faux-board-id is regenerated every time your APE restarts.
sha1 is the firmware checksum, so I see you are on 17.17.4

FCW snapshots have "FCW_sparse" as the requester.
boot-sec-info is what fuses are on on your car. I.e. all 0 is a development car.

 

[verygreen]

Granted, I guess all request names are pushed from the mothership so they don't need to remain in this same format forever, they can also change what info they request.
But when I was tracking it, they did request every camera and the requests were numbered every time with a probability trigger.
You really need to look into your logs to see what exactly was it requested from your car with what sort of a trigger.

 

[watchdoge]

Granted, I guess all request names are pushed from the mothership so they don't need to remain in this same format forever, they can also change what info they request.
But when I was tracking it, they did request every camera and the requests were numbered every time with a probability trigger.
You really need to look into your logs to see what exactly was it requested from your car with what sort of a trigger.

I've read the disassembly code of snapshot_trigger_client and found it receives some data from Hermes and write it in the /home/telemetry/triggers.json, but I don't think the Hermes could send "FCW_sparse" requester to the trigger because it could not know the FCW was triggered, so I'm confused that who send the "FCW_sparse" requester to snapshot

 

[verygreen]

I've read the disassembly code of snapshot_trigger_client and found it receives some data from Hermes and write it in the /home/telemetry/triggers.json, but I don't think the Hermes could send "FCW_sparse" requester to the trigger because it could not know the FCW was triggered, so I'm confused that who send the "FCW_sparse" requester to snapshot

triggers.json is stuff from hermes - i.e. from mothership - those are timed, so cannot really be triggered on FCW or other such sporadic events.
In addition snapshots could be requested by other parts of the autopilot code automatically/internally. if you read around you'll see in addition to FCW there's all sort of crash detection that also triggers a snapshot.