Reverse Engineering the DualShock 4 | Hacker News Reader

Reverse Engineering the DualShock 4

blog.the.al

173 pointsal_al65 comments

  the controller seems refusing to boot

that's when I realized that my idea of what is a controller is completely obsolete

How come? Ever since controllers used Bluetooth they would need to use some sort of programmable microcontroller or cpu. Both of these things need to 'boot' at some point. And yes even microcontrollers have bootloaders.

A traditional videogame controller is not much more than a few switches and perhaps a few potentiometers, see for instance the pinout for the Master System: https://www.smspower.org/Development/ControllerPort

That is, someone who started playing videogames in the SMS/NES days might have formed a mental model of the controller being mostly a passive device, with at most a few active chips to multiplex the pins in the interface, to allow for more buttons than there are pins.

Sure (I was there) but the same can kind of be said about mice and keyboards, too.

Ever since USB took off ~30 years ago and basically killed off raw I/O pins on the front of computers, human interface devices have required microcontrollers on board.

Edit: added timeline.

> but the same can kind of be said about mice and keyboards, too.

AFAIK, even old keyboards (AT and PS/2 connectors) already had a microcontroller, and the same was true of mice. The communication between the keyboard or mouse and the computer was through a serial protocol, instead of the computer directly reading the keyboard matrix or the mouse buttons and wheels. The exception might have been computers with built-in keyboards. But the joystick port (https://en.wikipedia.org/wiki/Game_port) directly exposed the buttons and potentiometers from the joystick, instead of talking to a microcontroller on it.

Yeah, that was what the "kind of" was meant to shadily cover. Thanks for clarifying.

it is obvious in hindsight, but I never put a thought on it before reading that sentence

I just read all 4 parts and I have thoroughly enjoyed them. I am curious to hear if the debug console (TEPPOU, or gun in Japanese) works. Please keep us posted!

That's what i don't get with linux...having all drivers inside the kernel is madness, no wait...it's pure stupidity. No other Universal OS makes that...crash my system with a USB-Controller...that's some Windows 98 reliability(-issues) right there.

I don't think Linux is exclusive here, there are plenty of examples of both macOS and Windows also crashing when plugging in various accessories.

- https://developer.apple.com/forums/thread/678644?page=5 - " Big Sur panic when connect/disconnect usb-c dock "

- https://forums.macrumors.com/threads/macbook-air-crashing-wh... - "MacBook air crashing when plugging a USB device"

- https://answers.microsoft.com/en-us/windows/forum/all/window... - " Windows freezing when I plug in a USB device"

Try searching for "$operating-system crash when connect usb" for various OSes and distributions and you'll see it's a problem everywhere, not just Linux.

I remember OpenBSD panicking over some USB hubs a few releases ago. USB is hell.

Yeah, crashes from hardware driver are fairly common on Windows. And without any surprise, USB is the most common one (I'd say network devices (Ethernet, Wifi, or BT) are a close second).

Linux uses modules, some other BSD not. A faulty USB driver (specially storage related ones) can panic your BSD kernel with ease.

With Linux you could blacklist lots of modules since forever easily, forbidding to load them.

Try that with Windows or MacOS.

Go buy some cheap WiFi adapter. Noth Atheros. Ralink, better. Often your favourite OS will panic/BSOD too.

Ah nice do we try to find excuses that monolithic kernel's are not so bad at all right?

And it's totally ok that those (any) "high-quality" driver can crash the system?

>Linux uses modules, some other BSD not.

Has nothing todo with modules, if it's loaded it's in kernel-space. Not others...OpenBSD is the ONE.

BTW: For those butt-hurt ones (that i blatantly attacked poor linux), it not just about linux but should we no create operating-systems where this is not possible? Just asking...

What you're asking for is a microkernel os, or at least a generic kernel shim to interface a user space driver.

Example of microkernel: QNX.

Example of userspace driver: fuse.

I'm not familiar with the architecture of OpenBSD, does it run it's drivers in userspace?

>I'm not familiar with the architecture of OpenBSD, does it run it's drivers in userspace?

No it's the BSD without modules.

>Example of microkernel: QNX.

Yes and minix, hurd and TrueUnix64 just some other examples.

Fun you say this, but I panicked a few OpenBSD releases before by just using a USB hub and some SD card adapters.

And I remind you I helped with some OpenBSD ports such as Mednafen, so I am not saying this as a bluff. The mail list is clear.

I am not talking about BSD vs Linux, i am talking about systems where no shitty driver can bring down the system....i say that as a FreeBSD user btw.

I had panics with FBSD too. It will happen to you at least once.

I have panics about your reading capability ;)

Maybe I should send him a Stadia controller? Maybe someone will get some utility out of it with Google completely killing Stadia off.

Does it have USB drivers?

While I've never tried it in that way, I understand it should function as a standard USB game controller when wired, but its real gem would be fully leveraging its wireless support.

The problem is that Stadia controllers use wireless in the sense of WIFI, not bluetooth. This means that in order to make them work not only is the RE work even harder, but you'd probably have to create a completely new driver since I'm unaware of any other device that can input commands from the internet; whereas with bluetooth we already have extensive tools to deal with it

Technically writing such a driver using ViGem should not be all that hard once you reverse the WiFi protocol this controller uses.

It's likely trying to talk HTTPS to Stadia servers, can't work with that without new firmware.

It seems the Stadia controller contains a Broadcom BCM43458 Bluetooth 4.2 chip.

https://www.reddit.com/r/Stadia/comments/xwcedv/i_spent_10_h...

Bonus: Windows Gamepad using phone USB as proxy: https://github.com/helloparthshah/StadiaWireless

You're not the first to think of this, they're disappointingly expensive on ebay.

If whoever submitted this is the author, this is good content :)

Yes, thank you!

Neat find. What could cause the calibration offset to be zero? Certainly it did not come this way from the factory. Any abuse/misuse of the controller would not cause it either.

Ah, I suspect this was a firmware update that got borked somehow. Maybe the cable was disconnected before the update could complete.

> What could cause the calibration offset to be zero?

A possible explanation can be found on part 4 of this post:

> [...] if the checksum is not valid, there is a loop that clears out the flash [...] I suspect (but haven’t tried yet) that if the battery of the controller dies while it’s writing on the flash, at the next startup the checksum does not match and the DS4 gets totally messed up like this one.

That is, according to that theory, it was trying to write something to the flash (perhaps while pairing?), and part of the write failed because the battery died. On the next boot, it detected a wrong checksum, and erased everything.

Thanks for that, I missed it in TFA. But ouch, that feels like an extreme design choice. What's the logic here to erasing the flash on a failed checksum, or requiring a checksum in the first place? Is there a non-obvious security threat?

The issue is probably a missing A/B firmware update for the config section.

If a firmware update needs to alter the calibration data or other rather static config, and that update process is interrupted by an empty battery then it can't recover. It should of course be more conservative in killing all of the config section... Or could reset to some sane default. Or have a copy of the old known good data around and restart the procedure

A properly made device would at least keep a spare copy just in case, there's more than enough space in flash for that, but no, Sony wants to sell more controllers.

I'd wager a bad/worn NAND block, 'cosmic ray' or other electrical glitch was more likely to cause a checksum issue than anything else. It might be sudden battery disconnect caused due to the controller being dropped (per the first page), but there should be local capacitance on the NAND supply voltage size to last a page write cycle as sudden power loss is going to happen in a lot of situations.

I would generally critique the use of a checksum on this config data without a backup or ping-pong writing system specifically because in the case of a 1 bit failure on something critical like cal or configuration data, really you want the data anyway and just hope that the 1 bit wasn't that important and also be ok if the bit flips back again on the next go around.

> I wrote a fix for this bug in the linux driver and sent to the linux-kernel mailing list (linux-input), so that a DS4 with a broken calibration does not cause a kernel panic.

I really admire people, who contribute their random findings to improve an open source software on their own time and resources. This is so wholesome.

I love “fell down so hard” as a polite way to avoid saying, “someone got pwned and threw this baby at a wall.”

>And then, suddenly.. Caps Lock is blinking and the system is totally frozen :anguished:.

So plugging in a brand-name joystick caused a kernel panic. Gross.

so... gross because sony should have better firmware or gross because linux should have a better usb stack, that is, it should never panic the kernel.

If you stepped into a dog turd and it leaked into your socks do you blame your open source shoe designer or your lazy dog?

I don't get the analogy. Why is the dog supposed to be lazy? A dog turding on the street is by design. Maybe blaming the lazy dogs owner would be more appropriate.

It's not a good analogy but at the end of the day it's a bad Linux issue. Sony has no obligation to make sure it's driver will never halt a system. Linux does.

So... are you saying the dog's owner has no obligation to pick up their dog's poo?

You're right, it's not a good analogy. It's barely one at all.

On their own land, no the owner can let them shit all around the house.

In what world do you step in your own dog’s shit and blame the dog for being lazy?

Haha get a lazy dog and you'll know what I'm talking about

IYKYK!

And lazy dogs don't come with bags & shovels, accessories are sold separately.

On the plus side, you might attract a Quick Brown Fox!

Both, surely? The hardware shouldn't give bad input, and the kernel should tolerate it if it does.

Edit: Sorry, I take it back: That data is weird, but not malformed; the hardware isn't out of line and I think the driver is fully at fault.

Yeah, it would be the hardware's fault if it delivered 1000 volts. Delivering any sequence of 1s and 0s should maybe cause the driver to give up, but not to panic the kernel.

USB sucks everywhere. OpenBSD can panic over USB too. It happened to me. Hubs, faulty USB drives, Chinese gamepads, noname ElCheapo USB Ralink WiFi dongles with dubious designs...

I think the only truly secure OS for this would be Hurd or SeL4+Genode.

Reply on news.ycombinator.com