alcari
The README says it was tested on ZFS, but I doubt its utility in real-world deployments. I don't know of anyone who has significant data in a ZFS pool that isn't one or more of: raidz, compressed, encrypted, or embedded_data.
raidz implies that logical blocks aren't allocated as single physical blocks, but instead striped across multiple drives. Finding the SBX magic isn't enough to get you the rest of the block, but the checksum might (but, given that's it's CRC16, probably won't) let you try appending blocks from other disks to find the remainder of the block.
Transparent compression prevents you from identifying the magic header on each block, unless you decompress every disk sector that could have data (which is certainly feasible, but complicates recovery if you don't know which compression was in use, and zfs supports at least 3 kinds, and pools will generally have at least 1 in use whether compression is on or not).
Encryption (present in Oracle ZFS) means there's no plaintext data to recover.
embedded_data is a feature flag (and on by default in supporting versions of zfs) that packs blocks into block pointer structs when the amount of data is small. I can easily imagine the final block of an SBX, which may be mostly padding, getting compressed into one of those block pointers, which itself may be embedded in a larger structure which is part of an array that's compressed by default. That array is also probably long enough the compressed stream takes multiple blocks, and you may have lost some of the early ones, making the rest of it unrecoverable.
They could easily have implemented RFC 3091 [0], but instead they chose to create yet another proprietary API with vendor lock in, just as cloud service providers love to do.
[0]: https://tools.ietf.org/html/rfc3091
/s
That's the tech they already have on hand.
edit: or, in particularly terrible systems, if plaintext passwords were leaked.
Of course, that's only useful if it doesn't affect any other password security concerns, and it turns out that users who are forced to change their passwords frequently pick worse passwords, which is a bigger problem than the scenario this was supposed to protect against.
> Would you have any reference to specifics on this?
FBI using a Firefox js bug to unmask tor users a couple years ago:
http://arstechnica.com/security/2013/08/attackers-wield-fire... http://arstechnica.com/tech-policy/2013/09/fbi-admits-what-w...
All the timings are a little faster, the caches a little bigger, and the buses a little wider, but it's still basically the same stuff with different names.
Steam says I've played 15 hours.
Send hel--more microelectronics.
It's TIS-100, but with a native multiply! and unsynchronized broadcast! and digit get/set!
Still supremely difficult.
For commands, shell metacharacters like `, |, &, and $() are much more important.
Some people are also calling for every certificate they've ever issued to be added to the CT logs, but I doubt that'll happen.
(For the obvious issue) WoSign's recent certificates are in the CT logs and they're promising to put in all their 2015 certificates as well, so they could be whitelisted.
(Source: anecdotal experience from plugging a Rift into a computer that didn't have a real GPU; no idea if there are any other issues.)