New blog post (about an old exploit): tachy0n.
For iOS 13.0-13.5, dropped as an 0day at the time.
Boris Larin
Reverse engineer / 0-days hunter at Kaspersky GReAT
In Thailand, or more precisely in Patang in Phuket, a very crazy tourist place, on the way to the hospital with a suspected bone fracture, I realized what I hate the most - Songkran
Boris Larin boosted:
I think I understand why the USB exploit analyzed by Amnesty International uses both a virtual Extigy sound card and a FastTrackPro sound card.
https://securitylab.amnesty.org/latest/2025/02/cellebrite-zero-day-exploit-used-to-target-phone-of-serbian-student-activist/
It took me 6 weeks to notice: in the logs, the Extigy and the FastTrackPro sound cards are not two virtual devices.
They're one device with two interfaces.
Which explains why the device "morphs":
- it first returns Extigy as the USB VID/PID in its device descriptor
- the Extigy quirk causes Linux to re-fetch the device descriptor
- the Amnesty analysis points out that you can return a bigger bNumConfigurations in the new device descriptor to cause an out-of-bound read+free on disconnect
- but you can also return a different VID/PID - say, the FastTrackPro VID/PID
- and Linux will use that VID/PID to probe the next audio interface:
https://cs.android.com/android/kernel/superproject/+/common-android-mainline:common/sound/usb/card.c;l=773;drc=bc9dca02d645353bd4ff789c5a3a20064923889b
Now you have a device with both a corrupted bNumConfigurations - and with VID/PID set to FastTrackPro, which now triggers FastTrackPro quirks.
The original writeup identifies that, like the Extigy, the FastTrackPro has quirks that are only run for that VID/PID.
Amnesty speculates that the attacker uses the FastTrackPro "to confirm that the memory corruption primitive CVE-2024-53197 is functional".
The writeup looks at the skip_setting quirk:
https://cs.android.com/android/kernel/superproject/+/common-android-mainline:common/sound/usb/quirks.c;l=1598;drc=bc9dca02d645353bd4ff789c5a3a20064923889b
but there's also this boot quirk, which switches the device's configuration:
https://cs.android.com/android/kernel/superproject/+/common-android-mainline:common/sound/usb/quirks.c;l=1652;drc=bc9dca02d645353bd4ff789c5a3a20064923889b
This calls to usb_set_configuration(dev, 2), which reads bNumConfigurations and looks for configuration #2.
https://cs.android.com/android/kernel/superproject/+/common-android-mainline:common/drivers/usb/core/message.c;l=2007;drc=9f2a3933beeaeead53829d3a7be53770e41e7869
So if you wanted to confirm that your heap manipulation worked, in your fake `struct usb_host_config`, set 2 as your bConfigurationValue.
usb_set_configuration will read the corrupted bNumConfigurations and start reading `struct usb_host_config`s out of bounds.
If it finds configuration #2, it means your fake is located in the right place, right after the Extigy/FastTrackPro's own `struct usb_host_config`s.
And since the search doesn't dereference anything, you can't crash.
https://securitylab.amnesty.org/latest/2025/02/cellebrite-zero-day-exploit-used-to-target-phone-of-serbian-student-activist/
It took me 6 weeks to notice: in the logs, the Extigy and the FastTrackPro sound cards are not two virtual devices.
They're one device with two interfaces.
Which explains why the device "morphs":
- it first returns Extigy as the USB VID/PID in its device descriptor
- the Extigy quirk causes Linux to re-fetch the device descriptor
- the Amnesty analysis points out that you can return a bigger bNumConfigurations in the new device descriptor to cause an out-of-bound read+free on disconnect
- but you can also return a different VID/PID - say, the FastTrackPro VID/PID
- and Linux will use that VID/PID to probe the next audio interface:
https://cs.android.com/android/kernel/superproject/+/common-android-mainline:common/sound/usb/card.c;l=773;drc=bc9dca02d645353bd4ff789c5a3a20064923889b
Now you have a device with both a corrupted bNumConfigurations - and with VID/PID set to FastTrackPro, which now triggers FastTrackPro quirks.
The original writeup identifies that, like the Extigy, the FastTrackPro has quirks that are only run for that VID/PID.
Amnesty speculates that the attacker uses the FastTrackPro "to confirm that the memory corruption primitive CVE-2024-53197 is functional".
The writeup looks at the skip_setting quirk:
https://cs.android.com/android/kernel/superproject/+/common-android-mainline:common/sound/usb/quirks.c;l=1598;drc=bc9dca02d645353bd4ff789c5a3a20064923889b
but there's also this boot quirk, which switches the device's configuration:
https://cs.android.com/android/kernel/superproject/+/common-android-mainline:common/sound/usb/quirks.c;l=1652;drc=bc9dca02d645353bd4ff789c5a3a20064923889b
This calls to usb_set_configuration(dev, 2), which reads bNumConfigurations and looks for configuration #2.
https://cs.android.com/android/kernel/superproject/+/common-android-mainline:common/drivers/usb/core/message.c;l=2007;drc=9f2a3933beeaeead53829d3a7be53770e41e7869
So if you wanted to confirm that your heap manipulation worked, in your fake `struct usb_host_config`, set 2 as your bConfigurationValue.
usb_set_configuration will read the corrupted bNumConfigurations and start reading `struct usb_host_config`s out of bounds.
If it finds configuration #2, it means your fake is located in the right place, right after the Extigy/FastTrackPro's own `struct usb_host_config`s.
And since the search doesn't dereference anything, you can't crash.
@opa334 sounds like dirty lightning port / broken usb host port / broken cable
I don't know what I feel more: amazement at how good these AI-generated images look, or disgust at the ethics and behavior of the people behind this technology.
Boris Larin boosted:
OpenAI is using Studio Ghibli-style memes as an ad hoc promotional campaign for its new image generator—despite Ghibli founder Hayao Miyazaki's famous hatred of AI. Sam Altman even made his X avatar a 'Ghiblified' portrait.
Disgracing Miyazaki is part of the point: It's more proof to the industry's biggest boosters that they have won—that they're free to use, appropriate, and commoditize art however they see fit.
https://www.bloodinthemachine.com/p/openais-studio-ghibli-meme-factory
The root cause of the Chrome 0-day logical vulnerability CVE-2025-2783, which we discovered used in attacks with sophisticated malware, also affects the Firefox! New CVE-2025-2857 has just been fixed in Firefox 136.0.4 https://www.mozilla.org/en-US/security/advisories/mfsa2025-19/
We have discovered a new Google Chrome 0-day that is being used in targeted attacks to deliver sophisticated spyware 🔥🔥🔥. It was just fixed as CVE-2025-2783 and we are revealing the first details about it and “Operation ForumTroll” https://securelist.com/operation-forumtroll/115989/
Boris Larin boosted:
IOS Hacking in 2024 - An Overview | Lars Fröder https://youtu.be/prj6g0QsBGI
Boris Larin boosted:
Microsoft recall is fucking insane.
Recall snapshots are kept on Copilot+ PCs themselves, on the local hard disk, and are protected using data encryption on your device and (if you have Windows 11 Pro or an enterprise Windows 11 SKU) BitLocker.
Your doing what? Microsoft wh-
Recall uses Copilot+ PC advanced processing capabilities to take images of your active screen every few seconds. [...]
[...] The default allocation for Recall on a device with 256 GB will be 25 GB, which can store approximately 3 months of snapshots. [...]
WHAT WHY NO ST-
Note that Recall does not perform content moderation. It will not hide information such as passwords or financial account numbers. That data may be in snapshots that are stored on your device, especially when sites do not follow standard internet protocols like cloaking password entry.
Microsoft please... th-the tech support scams... think about what happens if this gets bre-
Recall also does not take snapshots of certain kinds of content, including InPrivate web browsing sessions...
Oh, okay I guess that's san-
...in Microsoft Edge.
AAAAAAAAAAAAAAAAAAAAAAAA
It treats material protected with digital rights management (DRM) similarly; like other Windows apps such as the Snipping Tool, Recall will not store DRM content.
Ah, but of course. The DRM is protected...
We managed to find this 0-day twice! First as a description of a vulnerability, then as a real exploit used by attackers. https://securelist.com/cve-2024-30051/112618/
Boris Larin boosted:
It's been ten years, so a short story about the "gotofail" bug.
Someone came to me about a catastrophic vulnerability in Apple's TLS implementation.
I shit you not, they'd overheard someone at a bar drunkenly bragging about how they were going to sell it to a FVEY intelligence agency for six figures.
They didn't know exactly what it was, just some vague details and the key point that it allowed use of the real certificate.
This was enough for me to find the bug (yay open source), which would go on to be known as "gotofail", and produce a working exploit in less than a day.
The details were anonymously back channelled to Apple, who released a fix.
@matthew_d_green posted on Twitter about it, concerned by Apple's vague release notes.
I used a burner phone to share the details with him anonymously.
Then everyone forgot about the whole thing because heartbleed.
¯\_(ツ)_/¯
We've posted an update on what's currently known and unknown about this obscure debugging feature. https://securelist.com/operation-triangulation-the-last-hardware-mystery/111669/
@marcan@treehouse.systems @joxean @stf This is a debug feature 100%. The main mystery for me is whether it was possible to find and use it without “hints”. The fact that this “hash” is ECC increases the likelihood that this feature could have been found by playing with the hardware. To solve this mystery, it would be nice to come up with a working recipe to find such feature(s) and find something similar in other places.
Thanks to @marcan@treehouse.systems (https://social.treehouse.systems/@marcan/111655847458820583) and @zhuowei (https://notnow.dev/objects/90b471bd-b375-43ef-b6d4-46fba6723fd8) now we know the original purpose for this unknown hardware feature. Its MMIO debug registers for GPU L2 cache. I am really excited that we are very close to solving this mystery!
Client Info
Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst