It is much more likely imo, that they have zero day exploits for something that does not require the phone to be unlocked, eg wireless, 3g/4g, bluetooth, or via the lightning connector.
If they are not doing that one of the only other options i can see is if they can clone the phone and perform a offline brute force against the pin code but my understanding is that the secure enclave is meant to prevent attacks like that.
The radio interfaces do not have total access to the device but they have enough that it is feasible to compromise a device via a compromise of a radio component.
I do not think that a radio interface could have enough access to facilitate decryption of an encrypted volume. What I imagine it has enough access to do is to pivot to the OS running on the main CPU via a bug in the interface that is exposed for the radio to communicate with the main CPU.
From there they would likely have to exploit a number of other bugs to get into the position that they want to be in.
Saying you need to drop a file is a sad excuse. Especially when you don't need to. I see no reason why you couldn't use the suggested exploit. Changing the HKLM\SYSTEM\ControlSet001\Services\msiserver ImagePath to the path of cmd.exe should pop you up a system shell. With no files dropped.
If that is true, I am surprised that Boeing did not use that as a response to the researcher. Instead they responded that they have compiler mitigations in place and could not exploit the vulnerabilities themselves. That response makes me feel like the networks are not entirely seperate.
I feel like I am pretty security conscious and thought the same thing at first. but realistically isn't all this just data the government already has on us?.
Ghidra doesn't do a great job of decompiling Swift and ObjC which most most iOS apps would be written in now days. You are better off with something like Hopper. Hopper does a better job of decompiling Swift and ObjC but its decompiler output is no where near as good unfortunately.
He likely wouldn't be able to get past an unknown pass code with checkm8. Whilst it would jailbreak the device the flash is encrypted with a derived key thats stored in the secure enclave and can only be unlocked with the PIN.
The great thing about having these ultra fast SSDs and the associated software stacks is that you can get both faster load times and also more assets. One of the greatest benefits of these SSDs imo is that it tightens up how big your streaming pool has to be, freeing up a large amount of ram and allowing for on demand loading of assets just before they are needed.
Additionally the huge bandwidth means that the consoles can fill their entire ram in between 3ish and 6ish seconds, which should reduce max loading times by a lot.
The PSP is slightly different though as it not remotely accessible. It does sit in a similar position to the ME (can interact with the computer outside of the main x86 cores) but yes not listen on a external interface. Interestingly enough the PSP actually uses the ARM TrustZone extensions to implement some of its security.
DMTF DASH does look to be remote out of band management of AMD computers but I cannot find a connection to the PSP itself. I suspect it may run on the PSP but nothing I have seen so far has shown that the PSP is externally accessible or implements DMTF DASH functionality.
its actually more interesting imo if it _doesn't_ run on the PSP; because that means that there is another processor that runs at a lower level than the x86 cores that can interact with the host and listens externally.
After doing a bit of reading DMTF DASH appears to be implemented in the NIC from Broadcom or Realtek and uses the PCIE interface with the chipset from the NIC.
People are generally far less likely to give out credentials to their VPN or personal accounts than they are to give out passwords to a random application. Additionally requiring a VPN increases the barrier to entry to accessing the application as you could have additional requirements to a VPN (such as a 2FA and device certificate).
Memory encryption technologies such as AMD's Secure Encrypted Memory (SME). Would be your best bet to combat this, along with other anti-evil maid protections.
Secure Encrypted Virtualisation uses SEM, but it is not a newer version of it. SEV allows someone to run encrypted VMs that not even the host can read the memory, by leveraging per VMs keys in the AMD PSP that encrypt the VMs pages using SEM.
It would be interesting to leverage SEM to run a version of qubes where not only are the VMs isolated by the Xen hypervisor but are also separately encrypted using the PSP.
TRESOR is a great project but pretty seperate to SME imo. TESOR implements SME but its implemented effectively in software, making it less secure and a lot slower. The great thing about SME on AMD CPUs is that I believe (at least on the newer Zen cores) it effectively can run at the speed of the memory, so you have no performance loss.
I would argue that the out of band management provided by DMTF DASH is closer to what people consider then Intel backdoor then the AMD PSP. The PSP cannot be accessed remotely and is only available locally which removes most of the attack surface.
I honestly don't see why the CPUs couldn't from the factory contain a public key from AMD, and from there AMD issues certificates to firmware vendors to sign their firmware with. This would allow the CPU to 'verify' the certificate chain of the firmware that is being used without locking it to a specific vendor. This decreases security a little because the leakage of a single signing certificate means you can malicious firmware on any device but it seems like its much more consumer friendly.
I think its a bit of a wash personally, the PS5 runs faster and has proprietary storage. But the GPU only has 70% the CU's of the XSX meaning that the overall APU should be significantly smaller, assuming the CUs are similar in size. This would increase the number of usable APUs per wafer.
Due to the lower amount of INT32 in game loads as you stated, I don't think that separating INT32 and FP32 hardware makes a lot of sense, because you can share a substantial amount of the hardware between the two overall leading to space savings.
The patch available doesn’t patch the issue for non domain joined machines or Linux hosts the last time I checked. To do that you need to manually set a registry key.
But the GA102/GA104 doesn’t have seperate execution units for INT and FP32 because the INT also does FP32. So I don’t see how that shows that separating FP32 and INT hardware makes sense.
Couldn't agree more, imo game studios have all the downsides of a large software company with pretty much none of the benefits, the sooner they unionise and get treated like humans the better.
I believe with regards to TSO, it is actually a huge benefit performance wise. Without you would need to effectively have a barrier after every memory operation ARM, reducing performance drastically.
Isn't it a switch because the weak memory model, whilst providing less guarantees is more performant?. So they are trying to have both the x86 mode which isn't as performant, but works a lot faster in hardware than the software implementation and the faster weaker ARM model.
A nation-state actor likely already knows most of (if not all) of the techniques being used by FireEye. If they were really a nation-state actor then they were likely after the insight into sensitive networks rather then the tools imo.
The federalist itself has spread a lot fake news over the years so you may want a better source to debunk the republicans in the state who literally ran the election who are saying it wasn't fraudulent.
Yeah but there hasn't been the level of vertical integration that the M1 laptop has before. The same company is building the silicon, the laptop and the OS they can leverage whatever they feel like and don't have to account for processors that have differing features.
https://www.frida.re