499 karma · joined August 11, 2016
I guess it’s hard to balance, because a company probably doesn’t want their employees uninstalling MDM profiles.
Using your opponents strength as weapon means deflecting their attack and using the force to throw them on the ground/defeat them.
Have a look at e.g. 5:58 https://youtu.be/-Qe_JKQjJTA It’s kata, so slow and meant for demonstration purposes.
The stuff you describe doesn’t have anything to do with the sport. It’s insane how people twist things to make them fit their ideas.
That’s actually the kind of spam I used to receive on a very short domain with a catch-all.
I guess they loop through short domain names and then try to brute-force the local part.
My confusion stemmed from the fact that the bug is supposed to affect pixel 6 devices, which aren’t listed in the QPR2 updates but were explicitly mentioned in the update to r37p0.
the most recent mention on their releases page is for the 2022120300 release:
> kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro): update Mali GPU driver to r37p0 (current release is r41p0 but there are substantial changes to the driver for the Tensor SoC on Pixels and it will take substantial work to upgrade all the way)
https://grapheneos.org/releases#2022120300
from the article:
> The Arm security team were very helpful throughout and released a public patch in version r40p0 of the driver on 2022-10-07 to address the issue [...]
And no, I never asked why we would need to verify the security researcher’s claims (but sure, you should).
1. Dma54rhs says Apple’s (!) claims supposedly can’t be verified and that you need to take Apple’s word for it
2. I ask why not, provide a link to a talk about iOS security by a renown security researcher as both an example of how to verify Apple’s claims (reverse engineer iOS) and to lend some credence to the point that they are likely to be true
3. You talk about the researcher and/or programmers being wrong by replying with an “orthogonal” comment containing “whataboutism”.
Edit: Could we please talk about the actual topic? Do you or someone else know about instances where Apple lied about mitigations like lockdown mode before? Maybe there’s a long history of it and I just don’t know. Or is there some other flaw in my logic?
There is always the argument about hidden bugdoors, backdoored compilers or whatnot. But that’s not practical, by then you might as well stop using technology.
If Apple can’t be trusted then why can you trust google? Or Qualcomm?
Could you please make concrete a point?
But it is possible to verify what it does, the same way you would for an android phone (I.e. not just look at the source code and hope that it matches what’s running on your device). https://youtu.be/8mQAYeozl5I At 26:42 he talks about lockdown mode. Would be a bit weird if he lied about the impact lockdown mode has.
“CHERI extends conventional hardware Instruction-Set Architectures (ISAs) with new architectural features to enable fine-grained memory protection and highly scalable software compartmentalization. The CHERI memory-protection features allow historically memory-unsafe programming languages such as C and C++ to be adapted to provide strong, compatible, and efficient protection against many currently widely exploited vulnerabilities.”
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
I forgot the details but iirc it’s not too much work to recompile programs for the architecture.
It was discussed on HN before, e.g. https://news.ycombinator.com/item?id=30007474
If it was open source that still wouldn’t prove much, see e.g. https://mobile.twitter.com/taviso/status/1263957627077226498 for a discussion on reproducible builds.
The recent OpenSSL vulnerabilities were in there for over a year before they were discovered. Theoretically Signal or an open source version of WhatsApp could have a bugdoor, which would not be found for as long or longer.
Sure, it’s way nicer when stuff is open source, but I’m not sure it’d change much in this regard.
(IMO there are many good reasons to dislike WhatsApp/meta. I just think your argument is flawed.)
The listed books should help with that! I think Practical Malware Analysis really is a good start, even for that. When looking at malware you also try to find important functionality and the book teaches you how to get there quickly.
> I'd also like to have a go at modifying firmware of embedded devices, eg a car head unit with a stupid splash screen on startup that I'd like to disable.
There are probably forums for that, where you can find some info. There's also a nostarch book on car hacking (https://nostarch.com/carhacking) and for embedded (https://nostarch.com/hardwarehacking). I haven't read either, but it might be worth to check out some reviews for it. Maybe they're good and can help you achieve your goals.
The difficulty probably depends on how new the car is. In case you need to actually find a vulnerability in the infotainment system to get proper access, something like Hacking: The Art of Exploitation (https://nostarch.com/hacking2.htm), which I heard many good things about, is probably a good read. But if it's too new it might be too time consuming (see e.g. https://www.youtube.com/watch?v=k_F4wHc4h6k)
> For example I have a camera with wifi functionality, and you can control it from a phone app. It would be cool if I could somehow control that from the command line, or create my own basic app for the PC to control it. On top of that it would be good if I could modify the firmware to make it automatically start up in that remote control mode.
I think getting at least a CLI client could be relatively easy. For that you probably don't even need to reverse a binary using IDA/Ghidra/Binary Ninja. You can try to get the .apk file of the app and decompile it using something like jadx (https://github.com/skylot/jadx/). You'll receive mostly readable Java code. It can try to deobfuscate names, if they're obfuscated. The code you're interested in is probably somewhere under "com.manufacturer...".
How easy it is to modify the firmware once again likely depends on how old or new the camera is. They could, for example, have some integrity checks that keep you from doing that. But I have absolutely zero experience here, so it might as well be really easy. I think there could be forums for this, too.
Also be warned that modifying the firmware of your car or camera can break (parts of) them if things go wrong. E.g. I accidentally (soft) bricked a device because I tried to flash it from within a VM. I don't know how big the risk in your cases is, maybe there isn't any. But it's a good idea to read lots before accidentally breaking something expensive!
Happy I could help you :)
> I really wish we had some way to protect ourselves until the patch is widely available.
I would hope/expect that the OpenSSL project has no indication that this vulnerability is used in the wild. And that is probably why they preferred announcing a patch date instead of releasing a fix right away. (But I don’t know their policies, so this is just speculation.)
That would mean that you don’t really need to do anything you shouldn’t have already been doing prior to this announcement to protect yourself until the patch is out.
Unless the vulnerability is easy to find — in which case we’d already hear about exploitation attempts, so I don’t think it is — worrying about this is as useful as worrying about the other critical yet-to-be-found vulnerabilities in the software you use (which most certainly exist).
Switching from one password/-key manager to another is going to be more of an issue.
But you should be able to add an additional passkey once logged in to an account, just like how you can have multiple hardware 2fa keys now. Then you could manually migrate accounts that way, which is painful, of course, but you wouldn’t be completely locked in.
That used to be the case. Since iOS 16 they are also synced via the iCloud Keychain: "Passkeys on iPhone require that you use iCloud Keychain. If you don’t have iCloud Keychain turned on when you try to save a passkey, you’ll be asked to turn it on. Passkeys also require that two-factor authentication is enabled for your Apple ID."
https://support.apple.com/guide/iphone/sign-in-with-passkeys...
Practical Malware Analysis is a really great book, even if you don’t intend to reverse malware. It has labs after every chapter, along with solutions. It teaches you about windows, how to approach reversing a program and what to focus on to not waste too much time.
Once you worked through that CTFs should be much more approachable.
Reverse Engineering: Secrets of Reverse Engineering and Practical Reverse Engineering are also often mentioned as good books, but I personally haven’t read them. Aside from that, the books from nostarch.com are great.
If you want to learn more about windows itself, there are the “windows internals” books.
It’s also a good idea to find a community with similar interests, learning together is often more fun. And when you ask for help try to properly state your problem and what approaches you already tried to solve it, along with their outcomes.
Good luck!
It was all over their release announcement and Twitter, iirc. From their website: “For the price of $365 / year” https://hex-rays.com/products/idahome/
But, like you said, IDA Home is additionally limited to one architecture, which is a bit annoying.
From the conclusion of the second post, which analyses the sandbox escape:
> Perhaps the most striking takeaway is the depth of the attack surface reachable from what would hopefully be a fairly constrained sandbox. [...] The expressive power of NSXPC just seems fundamentally ill-suited for use across sandbox boundaries, even though it was designed with exactly that in mind. [...]
(The above is severely cut down, reading at least the entire conclusion or even the whole post is worth it)
https://googleprojectzero.blogspot.com/2022/03/forcedentry-s...
It does, it just doesn't close all attack vectors used by APTs.
They say[0]:
> Turning on Lockdown Mode [...] further hardens device defenses and strictly limits certain functionalities, sharply reducing the attack surface that potentially could be exploited by highly targeted mercenary spyware.
They don't say "turn this on and you'll be unhackable". They go on to say:
> Apple will continue to strengthen Lockdown Mode and add new protections to it over time.
So what they released in the current beta is just the start. They decided that releasing Lockdown mode with only some additional protections would be worthwhile to at-risk users and I personally agree. It's both true that Lockdown likely helps at-risk users (see reply by _kbh_) and still has lots of room for improvement.
[0]: https://www.apple.com/newsroom/2022/07/apple-expands-commitm...
Here's a repo with lots of public reports by various consultancies, you could use that as a starting point: https://github.com/juliocesarfort/public-pentesting-reports
With newer Yubikeys you can also use ECC PGP keys:
> Support for Elliptic Curve Cryptographic Algorithms have been added to the YubiKey 5.2.3 and above firmware.
https://developers.yubico.com/PGP/YubiKey_5.2.3_Enhancements...
This is from November 2020, I’d expect them to use it even more by now:
> But we also use Rust to deliver services such as Amazon Simple Storage Service (Amazon S3), Amazon Elastic Compute Cloud (Amazon EC2), Amazon CloudFront, Amazon Route 53, and more. Recently we launched Bottlerocket, a Linux-based container operating system written in Rust. Our Amazon EC2 team uses Rust as the language of choice for new AWS Nitro System components, including sensitive applications such as Nitro Enclaves.
https://aws.amazon.com/blogs/opensource/why-aws-loves-rust-a...