Good question: regardless of the recording instrument (our lab has many microphones of varying degrees from low > high fidelity), a live person vs. recordings that are played back carry a unique signature.
"Crack the hash"? Does this mean you were employing some novel hashing algorithm and relying on its secrecy? If so your employer were never serious about security in the first place. Hardware attestation is more or less a solved problem, and that solution does not involve secret algorithms.
Eh. It was some kind of hash of the image. I was not involved in that project, so can't tell you exactly how it worked, but the images were "signed," and someone figured out how to "re-sign" an altered image.
Sure but conceptually no one should've been able to crack any hashing scheme anyone half-way decent at their job could come up. SHA256 is the default and it's unbroken. Even SHA1 has scant few known collisions. So like...what the heck were they hashing and how that anyone was able to crack it?
Most likely is either extracting the private key from the camera or getting the camera to sign arbitrary data. If the signing isn't part of the sensor die itself there's a bus where the image data gets transferred from sensor to signer, so an attacker can inject arbitrary data onto that bus to get it signed, even though they never actually extract the signing key.
C programmers aren't complaining about the "magic" being tens of thousands of lines of code. They're complaining about the magic including bizarre side effects that brazenly violate the principle of least astonishment.
In C++, you can overload the comma operator to do shit. I've seen it done. There's no reason to do it, and no reasonable person would ever expect it in a code base they're unfamiliar with. To find bug in that ultimately roots back to that implementation, you have to go eliminate every other whack-job possibility before it even occurs to you that maybe the weirdo who wrote this code chose to overload the comma operator.
I'm not going to argue with anyone who wants to use C++ in their own projects, you do you. But let's be real about what C programmers are complaining about. It's not line count. It's syntactic obfuscation. I don't just level this criticism at C++ either. Basically every major new language has its own byzantine syntactic constructs to some degree.
God Plex sucks now. The mobile Photos app is basically abandonware that threw out 80% of the functionality from when photos were handled in the main app. Still glad I snatched up the lifetime pass when it was $150, but they're doing their best to make it money wasted.
I can't take anyone seriously who equates "six figure income" with "upper-middle class". That was true in the 80s. But the median household income in the US is about $80,000/yr. That extra $20,000 doesn't push you into upper-middle class.
If there's a trap for the upper-middle class, it's for the W2 earners. The federal tax code essentially disqualifies high-income W2 earners from virtually every deduction. Both parties wind up soaking these taxpayers because they
- make a lot of money,
- don't own a business, and
- don't have an organization like the Chamber of Commerce to lobby on their behalf
When Republicans get into power, these people are likely to vote Democratic and are therefore okay to stick with the bill after cutting taxes for dentists, lawyers, and corporations. When Democrats are in power, these people are (as ever) not "paying their fair share", so they need their taxes hiked to pay for free stuff for people who don't vote for Democrats. And then they'll also be disqualified from taking advantage of those new benefits/entitlements.
This is a tragically misguided view. There are tons of code bases that aren't going to be rewritten in safe languages for various reasons, be it political or technical. You may or may not agree with those reasons, and you may or may not like that these code bases are important, but the fact remains that these projects exist. Giving them a toolset to adopt a broad set of bounds-safe behavior can only be a good thing.
I just haven't tried it on a BSD. No reason it wouldn't work though. Might require a couple of fixes here and there, but generally the library sticks to standard C stuff and uncontroversial POSIX (in the POSIX target).
Microsoft supports memory safety. Rust is 100% the direction for new projects. But there are existing C codebases that are unlikely to be entirely rewritten in a memory-safe language for various reasons. Such projects can significantly benefit from incremental improvements in memory safety.
reply