Release: Fully operational dlclose exploit + Linux for PS4, by kR105 | Hacker News Reader

Release: Fully operational dlclose exploit + Linux for PS4, by kR105

wololo.net

173 pointsalxsanchez51 comments

Open articleView on HN

The actual repo is here:

https://github.com/kR105/PS4-playground

And https://github.com/kR105/PS4-dlclose

So how long until Sony lawyers get the Github repo shut down?

On what grounds exactly? Sony can't forbid anyone installing other OSes on their hardware.

Isn't that what they sued George Hotz (aka GeoHot) for, and won an injunction preventing him from touching Sony hardware ever again?

They didn't win. They settled out of court. It can mean that Sony were afraid to lose (in court).

See https://en.wikipedia.org/wiki/Sony_Computer_Entertainment_Am...

Anyway, it's easy for such monster to intimidate an individual with little resources for legal battles. It doesn't mean that what they (Sony) do themselves is legal in any way.

I don't know the boot process on a PS4, but if loading Linux requires you to modify or bypass any access controls, then it may be a circumvention violation of the DMCA.

If loading an alternate OS is a EULA violation, they might brick users machines or at least stop them from using Sony services.

It might be, or it might be not. DMCA is a major mess and is itself quite unconstitutional to begin with.

But that's something the user is doing. This repo has the Linux distro, which is by itself neither a circumvention, gives instructions to circumvent, or performs a circumvention of the DRM to run, thereby passing DMCA muster.

It's somewhat similar to the situation XBMC was in back when the X still stood for Xbox -- the code itself is OK by the DMCA, but compiling it required use of unauthorized dev tools (if the user didn't have a license from MS, which they likely did not), distributing the binaries was a violation of the DMCA (due to statically linked, non-free MS libraries), and installation of said binaries was also a DMCA violation (as it required the user to circumvent the DRM on the console).

One github repo mentioned in the article is the exploit, and a basic functional webpage to "do stuff" with it.

See, https://github.com/kR105/PS4-playground/blob/gh-pages/js/exp... for example.

It is also illegal under the DMCA to traffic in circumvention technologies; ergo GitHub, by continuing to host this material, is breaking the law.

F* the DMCA! That's not my stupid law!

Signed - not a US citizen!

I wish more US citizens would demand the same: http://www.fixthedmca.org

That said, similar garbage laws exist in many countries: https://en.wikipedia.org/wiki/Anti-circumvention

Cloned and ready to rock.

Remember 09 F9?

After Xbox dev mode, I think Sony needs to be more open about their console development.

This might just be stepping stone in the right direction.

Before announcing the PS4, I was hoping Sony would adopt Linux, mainly because I think it would've done a great service to the Linux community by having games that run well on Linux, but I think it would've also helped Sony in the long run. Microsoft is already banking on "DirectX gaming" for both Windows and Xbox. Sony should've had a similar strategy. They should go all-in with Linux and Vulkan with future consoles.

I was really hopeful when they switched to x86 architecture. But it has been over 2.5 years. Nothing yet.

They have lowered the price of dev kit, they approach more indie developers then every before, they even have a indie fund. But they would have more games if they try the other way around - if they could somehow lower the barrier for game developers to approach them.

I understand that these PS4s use a BSD, so I think Sony has adopted "unix" in technology but not the Linux philosophy. It's totally closed off.

What advantage would any of that have over FreeBSD? They've already got a kernel that gets them all of that, so why change that that isn't broken?

It would be easier for developers to port their Linux games to the PS4.

FreeBSD has a Linux compatibility module that works for most binaries, and source should be just a recompile in almost all cases.

How? A console is a very specialized device. The GPU access is vastly different from what you get when you use accelerated drivers on Linux/FreeBSD, for example.

If you can compile it on Linux, you can probably compile it on FreeBSD. Sorting out the rest is not OS specific, it's a completely different beast.

> The GPU access is vastly different from what you get when you use accelerated drivers on Linux/FreeBSD, for example.

Can you elaborate on this one. How are they different?

You don't use OpenGL etc, you use their proprietary graphics API.

Looks like Sony is far far away from developing something like XBox dev mode.

You're pushing raw data to the GPU which is directly executed. I've heard there's a ~15% performance increase doing it this way, but you could never do this with a general purpose OS due to the huge security problems it creates.

Sony had their flirts with Indies and Linux and walked away from it.

The Playstation had Net Yaroze, which was almost comparable the usual devkit. A collector's item nowadays.

The PS2 had PS2 Linux, which required special RGB monitors with sync on green, but it provided almost the same access to the hardware as the devkits. The main difference was the amount of available RAM, only PS2GL and the higher level PS2 official graphics API were available. The low level one wasn't accessible.

The PS3 provided a very limited support for Linux. The graphics hardware was exposed as a plain framebuffer. Then came the firmware update that wiped Linux out of the PS3.

The PS Vita did offer a Mono based SDK, but after the initial release, they went silent. You can still access the web site, though.

The PS4 already exposes two graphics APIs much more powerful than Vulkan, with the developers being quite experienced on them.

If you search SCEE and GDC Vault web sites there are plentiful documents and sessions, NDA free, how the console market works.

I have not used PS2 Linux but I am curious how was it possible to limit the low level graphics API? Did they not let you run VU1 code? The retail games were just writing registers on GS from VU1 (and few smart ones were also streaming textures directly to GS). There was no API involved other than kicking DMA chains to feed VU1 (and that was just writing a pointer into a user register anyway).

You didn't have direct hardware access from Linux, the access was exposed via an abstraction library which was a bit higher level than what the devkit allowed for.

Then there was PS2GL which was built on top of that, also not quite like the GL version on the devkit. But both shared the same fate of not being used that much.

So you could not write VU code? Sounds pretty useless if true.

On the contrary, the goal was to give enthusiasts a taste of what programming a games console might look like, not offer devkits for free.

In any case, it seems my memory was playing tricks on me.

The higher level APIs I am talking about was SPS2 and then there was Libps2dev as well.

The VU were actually available, I completely forgot about it.

You can delve into the old site, some guys did manage to mirror it, before Sony pulled the plug.

http://ps2linux.no-ip.info/playstation2-linux.com/coding-on-...

Personally I think the main reason for Sony's delusion with the community was that instead of trying to make games, many were using their PS2Linux kits to turn the PS2 into routers, cheap GPUs or cheap PCs.

The community was never as vibrant as the XNA one in terms of game coding.

Well, if you could program VU1 you had as much low level API as anybody else, that's my point.

As for the whole Linux support - I remember Kutaragi pushing the PS2 to become a home computer. Even its devkits (T10000s) were looking like PCs and had a "workstation" mode. PS3's "other OS" seems to be a vestige of this policy.

Hi, This is not true - PS2 Linux provided full hardware access to the graphics hardware via the SPS2 library, which just mapped a bunch of hardware registers into your userland address space.

The IOP chip was restricted but that wasn't really a big deal for most purposes, as it was generally only used for I/O.

Hi, maybe you could have bothered to read the other post from me?

https://news.ycombinator.com/item?id=11433163

There was also the PS2 version of Yabasic, which was included on the demo disc that came with the console.

If I recall correctly, this was done to avoid some kind of tax on "entertainment devices" in Europe; Sony argued that the ability to write BASIC programs made it a "computer", rather than an entertainment device.

Text could be entered using either a pad or a USB keyboard, and programs could be saved to memory cards. Some magazines even included user-submitted games on their cover disc, and the official UK magazine included a page or two of code each month which eventually built up to a playable game.

There were a few differences from the original Yabasic - gradient triangles were added, audio functionality was removed, etc. I'm told that the source code is available online somewhere, since the original Yabasic was GPL-licensed, but a quick Google search didn't turn up anything useful.

For those who are interested, a friend of mine has re-implemented the PS2 version in Javascript: http://www.mrdictionary.net/yabasic/

Yeah, I didn't pay much attention to it beside the day I bought the PS2.

Eventually I got hold of the PS2 Linux package, but getting monitors with sync on green wasn't that easy.

So can it now run Witcher 2?

I doubt it has accelerated graphics drivers.

They said it was already working in the past: https://twitter.com/fail0verflow/status/684079550943354880

UPDATE: just found this: https://twitter.com/fail0verflow/status/705304480888156161

I wonder if this could be used to decrypt/unpack/dump/whatever the contents of games?

I know the Dark Souls community are gasping to see the cut content which may or may not live inside the Bloodborne game files.

Why would that be any easier than just ripping the content off the disc directly?

Pretty sure the game files are encrypted and all the consoles have a secure chip which decrypts them. Getting files from the game disc is easy, reading them isn't.

> all the consoles have a secure chip which decrypts them.

I assume Steam Machines shouldn't do that and therefore they should be more mod friendly.

That has to be true for Steam Machines since you can build your own.

Especially considering they run Linux, so... I'm decently sure that Steam could easily use some form of binary protection.

True for Steam Machines, but it wouldn't help in this specific case, as Bloodborne is a PS4 exclusive.

Yea. I think that's called the NOR chip.

As iLoch said, the disks are encrypted.

Just because the PS4 can run Linux doesn't mean you get free access to data on arbitrary discs. If this is anything like the PS2 and PS3 incarnations you're locked out from a lot of that.

This isn't an officially sanctioned sandboxed Linux mode like on PS2-3. It's an exploit for (an old version of) the customized FreeBSD kernel that all games on the PS4 run under; in this case the exploit is used to throw away the kernel in memory and chainload Linux, but it could also be used to just install some kind of hook that dumps decrypted game data.

Url changed from http://www.theregister.co.uk/2016/04/04/full_linuxonps4_hits..., which points to this.

Reply on news.ycombinator.com