> A lot of phone manufacturers "save on memory" and use the same memory chips for the baseband processor and the central cpu. Which means that it's a little bit cheaper ... and the baseband has access to all the phone memory and all peripherals connected through the memory bus (which is all of them in any recent phone).

This can be mitigated e.g. via an IOMMU: https://grapheneos.org/faq#baseband-isolation

> It may even be the case that these chips are integrated in the cpu (which I believe is the case for recent Apple chips).

I don't know whether it's true or not that they use the same RAM chips. But either way it doesn't change the fact that they can still be properly segregated via the IOMMU.

> [...] The baseband implements other functionality such as Wi-Fi and GPS functionality [...] https://grapheneos.org/faq

It doesn't need to ask the OS, it can just get the coordinates and send them off.

This is true but there's automatic restart which will automatically restart the phone to get it back into BFU state:

> Automatic Restart is a security mechanism in iOS 18.1 iPadOS 18.1 and or later that leverages the Secure Enclave to monitor device unlock events. If a device remains locked for a prolonged period, it automatically restarts, transitioning from an After First Unlock state to a Before First Unlock state. During the restart, the device purges sensitive security keys and transient data from memory.

https://help.apple.com/pdf/security/en_US/apple-platform-sec...

> [...] inactivity reboot triggers exactly after 3 days (72 hours). [...]

https://naehrdine.blogspot.com/2024/11/reverse-engineering-i...

GrapheneOS also has this (https://grapheneos.org/features#auto-reboot) with a default of 18 hours.

Maybe one could try to force restart (https://support.apple.com/en-gb/guide/iphone/iph8903c3ee6/io...) to quickly get to BFU. But I could imagine that it'd be hard to remember and then execute the right steps in a stressful situation.

Yes, afaik macOS apps could theoretically be sandboxed as well (or close to) as iOS apps are. You can find the policies for many first-party apps and deamons in /System/Library/Sandbox/Profiles. But in practice most third-party apps aren't.

https://bdash.net.nz/posts/tcc-and-the-platform-sandbox-poli... and https://bdash.net.nz/posts/sandboxing-on-macos/ are good introductory articles.

Not without approval, see https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_A... or https://web.dev/articles/async-clipboard#security_and_permis.... But that is not relevant here.

Instead of the .torrent files, the compromised website served a .zip file, which contained a .exe. When opened, it shows a GUI to select a Xubuntu version and a button to generate the link. When that button was clicked, the malware showed a download link to the user and, in the background, deployed a second stage to %APPDATA%\osn10963\elzvcf.exe and executed it.

The second stage monitors the clipboard for cryptocurrency addresses which it will replace with attacker-controlled ones. The second stage is also added to HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ to ensure it is run whenever the user logs in.

Both stages have some limited anti-debugging and anti-VM functionality.