Connecting the iDOTs (2020)
hackerfactor.com
hackerfactor.com
edit: the name of NSO's iMessage zero click exploit is ForcedEntry
The second comment just seems like a dig at apple in general.
there are levels to this absurdity
There is an iMessage zero-click exploit from NSO Group used in the wild. Project Zero did a deep dive on it:
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
After a series of steps, the exploit eventually arrives at the need to do general computation. They achieve this by utilizing a part of the JBIG2 decompression algorithm, effectively using the phases of decompression to emulate logic gates to eventually build NAND gates, and from that a simple instruction set for a virtual computer. They then execute arbitrary code on this virtual machine.
> use those to emulate a threaded cpu, and launch a multithreaded decoding process on that cpu
This is a tongue-in-cheek joke I suppose. Even if you built multi-threading support on the virtual machine, it is still an emulated environment running within a single-threaded decompression algorithm. So it is effectively single-threaded on the real machine.
> which finds the original decompression process in memory and executes on the same image being decompressed
The original exploit is quite meta, so OP is just making a meta joke here.
When I read the comment I suspected immediately that it was a joke in reference to the above exploit, but it was cryptic enough that I wasn't quite sure.
> I was involved in adding this to PNGs in ~2011 or so. I don't remember the details but you've got this pretty much right.
> The reason was indeed performance: on the first retina iPads, decoding PNGs was a huge portion of the total launch times for some apps, while one of the two cores sat completely idle. My guess is that it's still at least somewhat useful today, even with much much faster single-thread performance, because screen sizes have also grown quite a bit.
Interesting that PNG parsing was a severe bottleneck a decade ago...
Of course, "every UI element is a bitmap" is not a good idea anyway, for other reasons, but seems to have someone become the norm for web and mobile.
Except that we're in a conversation about the relative resource consumption of bitmaps and png, not a conversation about what the best way to draw UI elements is.
This isn't how GPUs work meaning it will be slow.
Memory and bandwidth. To decode/display an image it's got to be loaded from storage. In the case of a Retina display iPad that's 2048x1536px. With a 24-bit color depth that's a 9MB bitmap to load from disk (SSD or whatever).
I just did a test with ImageMagick. The same 2048x1536 image encoded to an uncompressed Windows bitmap is 9MB while the same image as a PNG (PNG24, zlib level 9, with adaptive scanline filtering) is only 4MB. That's less than half the data to load off disk.
Unless CPU power is at an absolute premium you're probably better off with an image with lossless compression rather than completely uncompressed.
A generalized on-disk representation is safer and likely more forwards compatible.
Really depends on the exact situation. If your image decompression algorithm runs at 100 MB/s, but your disk bandwidth is 250 MB/s and you have plenty of space...
Bottlenecks are relative. If your goal is to shave a couple hundred milliseconds off of app launch times, eventually you have to start digging deep. It may not have been prohibitively slow, but for image-heavy apps it could have been the low hanging fruit that moved them closer to the goal.
The LaunchImage was definitely about perceived launch time of an app. The idea is you show an image that was similar to the main screen of your app and once the UI initialized it would just magically swap that for the static LaunchImage. So you'd want a really fast PNG decoder to be able to get it on screen and let the CPU do the work of initializing the application.
Then someone posted the GitHub repo, and now someone has the posted the link that provided the initial insight (linked to on the original page)
Really curious that it happens in Safari sometimes though...
I found this commingling of human-readable data and metadata quite novel. I can't bring to mind another format which does this.
This is backwards, I guess? 0x40 is clearly not 0x28; nor is 28 0x28; but 0x28 is 40 (decimal).
IMHO it was an unnecessary spec breakage, and a misplaced focus. The most expensive part of decoding PNG is zlib inflate, so any reduction in input data is more important than post-processing savings.
If Apple stored app launch images (the feature it's been invented for) as opaque RGB, then colorspace conversion would also be free, and they'd also be saving a quarter of the most expensive stage of decoding. Instead, they've kept the big expensive part big and expensive, and shaved off 3 instructions from the almost free part.