I don't know if the splat is exactly the same, but the playcanvas engine has no false transparency on this one: https://superspl.at/scene/7e4e9bcb that splat is actually of fairly high quality, so unless this is a materially different splat (with some of the gaussians dropped out maybe?) I'm inclined to blame the engine.
If you turn off performance mode this is way higher quality than either of the other two versions of this model linked by bhouston in this thread, although with a much lower frame rate on my phone of course:
Looks neat! I'd love for it to feed the MIDI notes back into my player piano instead of playing out of my iPhone's (comparatively tinny) speakers though.
I managed to make an ESP32-controlled RC car move by sending it commands from a webapp running on my Android phone last year. I don't believe I have telekinesis magic power, so I'd rather believe that this is not in-fact iOS only.
For modern systems, stack buffer overflow bugs haven't been great to exploit for a while. You need at least a stack cookie leak and on Apple Silicon the return addresses are MACed so overwriting them is a fools errand (2^-16 chance of success).
Most exploitable memory corruption bugs are heap buffer overflows.
I do vulnerability research. Those things would do the exact opposite of what you're aiming for. They'd be received with glee by mercenary spyware companies, _especially_ being able to load things into higher levels of privilege.
that wouldn't be a problem, apple signs extensions. In windows land for example, there are ELAM drivers for security software, they don't just hand them out, you basically have to convince people at Microsoft you're one of the good guys, in person.
It means more surface (both from extensions themselves and the loader code), relaxation of things like KTRR/CTRR (you now need to add executable EL1 pages at runtime), plus the potential for signing keys to leak (Finding enterprise signing keys even for iOS is fairly easy).
Yeah, loldrivers are a thing because any signed driver can load, vuln drivers with ELAM .. I don't know of any, I believe they're quite rare.
You have a good point with attack surface, but apple has a pretty robust system already for ensuring boot and lock security that doesn't rely on EL0/El1 security. I'm sure you know more than me about higher EL's like EL3 and secure world code that can take care of all that. I'm pretty sure they don't have to issue new signing keys either, matter of fact, why let even 3rd parties do this, apple themselves could expose a memory and file system dumping api without involving third parties. That way, they could sanitize away anything they consider sensitive as well. They can also require that the commands be issued over a physical/authorized usb connection.
Point is, there are very legitimate are critical cases where memory and file system forensics could be critical. From what little chatter I've heard, forensic software today is resorting to exploitation of the devices and those exploits tend to be abused for other reasons too.
Do you know of any reports where macos system extensions being abused this way? I've heard about windows drivers, but my impression was apple is doing this well enough to be a non-issue mostly?
That's a good one. To be clear, I'm not saying vulnerabilities don't or can't exist in system-extensions. I'm just saying that apple can publish and/or sign iphone extensions for a very limited use case like this, or publish an api/system service to do the same thing, if the concern is 3rd parties. The use case here is reading some memory and exposing that to authorized applications. I concede on the system extension part, but apple can still expose the capability without one.
You're confusing your opinion of the company with the perception by the general public. Apple's definitely not perceived as 'an office appliance company' by your average person. It's considered a high-end luxury brand by many[1].
reply