Difference between revisions of "Capture services"
(→Videos) |
(→Videos) |
||
| Line 11: | Line 11: | ||
== Videos == | == Videos == | ||
| − | [[4.0.0]] includes video playback etc support in Album via mp4. These include a JPEG thumbnail, which is presumably used for video "validation". The EXIF from this JPEG doesn't seem to contain the same HMAC data as the original Album JPEGs. The EXIF is also now much larger, with random-looking data at | + | [[4.0.0]] includes video playback etc support in Album via mp4. These include a JPEG thumbnail, which is presumably used for video "validation". The EXIF from this JPEG doesn't seem to contain the same HMAC data as the original Album JPEGs. The EXIF is also now much larger: the MakerNote is 0x498-bytes, with random-looking data for all of it starting at offset +0x8. |
Revision as of 15:54, 23 October 2017
caps:a
caps:c
Notes
capsrv is responsible for validating the MACs for screenshots stored on the SD card, if the setting capsrv!enable_album_screenshot_filedata_verification is non-zero.
Screenshots are validated as follows: The JPEG's MAC is extracted from the EXIF maker note, and stored. A timestamp string is generated by calling snprintf(&str, 20, "%04d:%02d:%02d %02d:%02d:%02d", ...); with stored timestamp values. If this doesn't match the timestamp string stored in EXIF, then an error 0xA34CE is returned. Otherwise, the entire JPEG is loaded into memory, and the stored EXIF maker note is cleared to zeroes. Then, an HMAC-SHA256 is computed over the entire JPEG using a hardcoded secret key. if (memcmp(calculated_hmac, stored_hmac, 0x10) == 0), the screenshot is valid, else 0xA3ACE is returned.
Videos
4.0.0 includes video playback etc support in Album via mp4. These include a JPEG thumbnail, which is presumably used for video "validation". The EXIF from this JPEG doesn't seem to contain the same HMAC data as the original Album JPEGs. The EXIF is also now much larger: the MakerNote is 0x498-bytes, with random-looking data for all of it starting at offset +0x8.