Zhuowei Zhang on Nostr: I think I understand why the USB exploit analyzed by Amnesty International uses both ...

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.