The Amazon Dash, not to be confused with the Amazon Dash Button, is a device for adding items to an AmazonFresh order, either through voice commands or via its barcode scanner. Recently, someone who had read my Dash Button teardown sent me one he had received for free and taken apart, to see if I could glean more information about it. The hardware can be summarized as a first generation Dash Button with a larger, user replaceable battery and a barcode scanner.
Ricoh provides a “Basic app” for Windows and Mac that will update the Theta S’ firmware and stitch the dual-fisheye video output into equirectangular video. The application UI and glue code,
SphericalViewer.swf, is built using Adobe Flex, while the video stitching portion, camera communications portion, and firmware updater are native code. The video stitcher is built using OpenCV and FFmpeg. Although reverse engineering native code is rather involved, reverse engineering Flash objects is much easier. Running
SphericalViewer.swf through the JPEXS flash decompiler produced fairly readable output.
The most interesting part was related to the configuration file,
CommonConfig.dat. After opening the file in a text editor, it was immediately obvious that it was Base64-encoded, but the decoded output was gobbledygook. However, I was able to decode it by analyzing the appropriate function in the decompiled Flash object. Indeed, the first step was to Base64-decode the file’s contents. The next step explains why the decoded output didn’t make sense—it was encrypted. After the Base64-decode, the result needs to be twice decrypted using an 256-bit AES key in Cipher Block Chaining (CBC) mode. This would normally prove to be extremely difficult, but the encryption key is defined as a variable in the same function, which makes it quite easy. This allowed me to write a configuration file decoder in Python. Once decoded, the configuration file is just an XML file. I’m not sure what the point of encrypting the configuration file is when the encryption key is easily accessible, and I’m really not sure what the point of encrypting it twice is, particularly with the same key.
A few weeks ago, The New World Atlas of Artificial Night Sky Brightness was published in Science Advances. The article is a report on artificial sky radiance, a current update to previous data. The supplement to the article is a light pollution map. Since I didn’t like the quality of the CIRES web visualization of the data, I decided to create a vectorized version. As the GeoTIFF source map isn’t publically available, I used the provided KMZ preview as a starting point. After extracting and assembling the JPEG tiles, I used a bilateral filter and other processing to remove the compression artifacts and convert the image into a usable state. I then used GDAL to apply coordinate information to the image and used makesurface and tippecanoe to create vector tiles of the map. Finally, I visualized the data using the Mapbox Dark style.
A bit over a year and a half ago, I wrote Nugacious, which provides random quantity comparisons. However, I’ve found a lot of the comparisons to be a bit too random, being things I had never heard of. I finally got around to mitigating this issue, by weighting potential comparisons by popularity. The quantity data Nugacious uses is from DBpedia, which is extracted from Wikipedia. Since each data point is linked to a Wikipedia page and Wikipedia keeps page view statistics, a popularity can be inferred for each data point. I integrated this data by downloading three months of Wikipedia page view statistics,1 extracting the view counts, and associating a view count with each data point. Nugacious’ matching code was then modified to use a weighted average based on these counts for close matches and random matches; one non-weighted random match is still returned for each. Nugacious’ code is available on GitHub.