Why is it foolish? Are drivers really well hardened now?

No, and juice jacking is entirely possible right now. It's just more difficult to do than many other types of hw attack & too costly to deploy in random indiscriminate public ports, making it less than viable for most cases outside of nation-state targeted attacks.

Generally speaking any documented cases of juice jacking happening are just red teams doing PoCs.

Stop repeating unsubstantiated rumors as facts.

BadUSB-C[0] builds upon the original 2014 BadUSB's HID emulation approach but takes advantage of USB 3.x DisplayPort to process video stream to make decisions & validate the success of the HID emulation steps.

It's too esoteric & expensive to be viable at any scale, but it's definitely functional.

[0] https://ieeexplore.ieee.org/document/9474274

If you bother to read more than the abstract, you’d realize this isn’t an attack. It’s a framework for possibly creating new attacks, which after extensive research yielded precisely zero code execution bugs. Gotta print something after wasting a whole semester I suppose.

When I say unsubstantiated rumor, this is what I’m talking about.

> this isn’t an attack

I'm aware. As I said above:

> any documented cases of juice jacking happening are [...] PoCs

Then you should learn what a PoC is. This is not a PoC. It’s a “we tried this and failed”. It’s a disproof(by exhaustion)-of-concept.

I'm curious about what you think they "tried and failed", and what exactly success looks like for you.

You mentioned "code execution bugs" - what is that exactly to you? I presume you don't count HID emulation, so I'd be interested in what exactly does count.

Code refers to computer code, sometimes called “shell code”. Execution refers to getting that code to run.

They didn’t get anything unexpected to happen on the device. You really should read the paper, it’s a masterclass in making nothing sound like something.

In a word, yes. The code execution CVEs, especially for iOS which is the subject here, all start with <=2014. There has been a huge amount of work since then (accelerated by the research device program).

It’s a favorite boogeyman of the “nation state actors are under your bed” crowd. Which is stupid because they all recommend avoiding public charging and would they be doing that if they were siting on high-quality exploits?

There’s a reason NSO doesn’t target USB, and it’s not because they enjoy creating VMs in the image decoder.

Juice jacking tends to use HID emulation - that's feature abuse, not CVE exploitation.

The point is it isn't viable at any scale - nation states advise avoiding public charging because employees of companies they subcontract have been individually targetted. They're not going to be doing any indiscriminate mass exploitation of the general public with it though.

That’s absurd, no it doesn’t. It refers to a combination of the 2011 defcon demo of eliciting a device to sync data by default and a fever-dream of getting code execution by abusing the USB stack.

You’re thinking of BadUSB or OMGCable.

1) which is a totally different attack 2) not especially applicable to smartphones 3) very much a thing that happens in real life (I have responded to incidents where one was used)

Lastly, there are plenty of CVEs issued for “feature abuse”, that’s a meaningless distinction.

> Which is stupid because they all recommend avoiding public charging and would they be doing that if they were siting on high-quality exploits?

Umm. Yes? I think this supports the opposite point than the one you’re trying to make. Apparently you’re too ignorant to grasp that.

Is that even possible with USB-C, though?

I believe at least the CC connection needs to be intact for a conformant power adapter or device to even output any voltage for charging for a C-to-C cable.

It might be possible to omit the D+ and D- wires, but that disqualifies many legacy charging protocols as well.

Yes.