But for a couple of years, I was successfully storing ~150GB of compressed, encrypted data inside JPEG images within Amazon Prime Photos using CubicleSoft Cloud Backup because unlimited photo storage was, well, unlimited! In case you are excited about this, let me burst that bubble: This solution is actually fairly dead because the Amazon Cloud Drive API is broken (by design). Let's just say that Amazon isn't all that great at designing APIs and that there are much better alternatives to using their services, especially for something as critical as data backups and I'll leave it at that. At the time, it worked fine.Ĭloud Backup used to support Amazon Prime Photos via the Amazon Cloud Drive API until the API stopped working altogether. Then it dumped the real compressed, encrypted data payload into the APP5 marker and uploaded the final ~10MB photo to Amazon Prime Photos. For each payload, the previously retrieved image was then drawn on with the current timestamp so the actual image data portion of the file would be unique.
#Amazon prime photos price free
First, a single image was retrieved from Unsplash (a free photo site with a simple API).
#Amazon prime photos price code
The ApplyPhoto() function in the code went out of its way to make the uploaded images fairly unique but also be real images. The implementation used in Cloud Backup went a slight step further. Obviously, it worked or this post wouldn't exist:
#Amazon prime photos price download
The first step was to check/verify two things: Did Amazon servers modify JPEG images that were uploaded in any way and, second, did they count the JPEG images as real images and flag them as valid "photos" for the "unlimited" side of the service or did they count against the 5GB data file limit? Those were pretty simple questions to answer that involved grabbing a JPEG, stuff some test data in an APP5 marker, verify that Photoshop still opened the file, upload the file, download the uploaded file, and check the result to see if the original file was identical to the downloaded file. Therefore, correctly dealing with the situation of using APP markers for shoving 10MB of extra data into the image almost certainly requires writing a custom image processing library.
That is, most, if not all, image libraries will still verify that the image is a real JPEG image. Most JPEG libraries will generally ignore or pass through unknown custom application markers. But instead of just picking an APP marker and irresponsibly using it, we're going to allow the marker to be infinitely extended should someone else want to do something with APP5:Įnter fullscreen mode Exit fullscreen mode While some APP markers are in fairly common use, a few are not used at all. These are defined as APP0-APP15 and are 0xFF 0圎n. The JPEG file format specification also allows for what it calls custom application markers.
There are many other markers for specific purposes that have been reserved for JPEG itself within its own file format. Similarly, the End of Image (EOI) marker is 0xFF 0xD9, which means we have found the end of a JPEG image. For example, a JPEG image starts with the Start of Image (SOI) marker, which is 0xFF 0xD8, so we know that if we see that sequence, we have found the start of a JPEG image. What this means is that JPEG format reserves the 0xFF byte for "markers" for the start of each "chunk" and each chunk has a specific structure. The JPEG file format is a chunked, structured binary file format. It all starts with modifying the JPEG file format in ways not really conceived of before. It has been several years since the Amazon Cloud Drive service API went from "okay" to "completely non-functional." Since I haven't used the service for quite a while, I figured it would be an okay time to reveal how I used to use Amazon Prime Photos as an unlimited storage backup service.
0 kommentar(er)
