Would it be possible to achieve the opposite in some way?, I mean, dump the kernel and build it on a pc on top of a compatible hardware?
Let me know what you think
As consoles get more and more powerful and introduce abstractions between the game developer and the hardware (kernels, syscalls, platform runtime libraries), I've figured it would only be a matter of time before we stop trying to emulate the way that console works, and instead begin to virtualize the console by writing API-compatible wrapper libraries.
Presuming developers just treat the PS4 as somewhat like we treat PCs: a generic processor that can do "math stuff", and some black-box libraries for {threading, graphics, audio, HID support, networking, ...}, then it becomes far easier to statically recompile a PS4 binary into a native PC binary: just recompile the "math stuff" for your target architecture, and then replace the linkages to libraries provided by the PS4 SDK, to libraries provided by your virtualization wrapper.
In other words, basically do the equivalent of what Emscripten does to C programs that expect to use OpenGL: compile the C to asm.js, and compile the calls OpenGL into calls to WebGL.
Man, this is the fourth time today that someone's suggested that maybe I should talk to a real game developer about something. I am a game developer. Just not a (modern) console game developer. But I did develop SNES games, way back when!
My point was not that this might be possible now; but that, as console CPU+GPU power approaches a certain threshold of "good enough; why would we need more?", console makers will eventually decide to spend some of the console's power not on fancier graphics, but on making development easier and more portable by introducing at least one full black-box abstraction layer above the hardware. When this happens, that layer can then be considered the "source ABI" for transpilation.
Now, I haven't played with the XBO or PS4 SDKs, but I have played with the Wii U SDK—and it's exactly what I'm talking about. There's no hardware to think about in the Cafe toolchain—no IO ports to peek and poke, no MSRs to read off. There's just library APIs. It's nearly as abstract as Apple's tvOS SDK.
There had been library API on PS1, PS2 had been an exception with the DMA chains and VU code exposed to developers but Xbox 1 and all later consoles come with libraries and no poking into registers business. So you can already try your idea by writing an Xbox 1 emulator (which is as much a PC as PS4 or Xbone). Spoiler alert: these libraries are statically linked on top of developers going around them all the time. Ultra High Level emulation seems to work only on Nintendo consoles, see https://en.wikipedia.org/wiki/UltraHLEhttps://en.wikipedia.org/wiki/Dolphin_%28emulator%29
> There's no hardware to think about in the Cafe toolchain—no IO ports to peek and poke, no MSRs to read off. There's just library APIs. It's nearly as abstract as Apple's tvOS SDK.
Sorry, I was going to compare-and-contrast with HLE; forgot. HLE is effectively a JIT, whereas I'm talking about something more like a static recompiler, like jamulator (http://andrewkelley.me/post/jamulator.html).
Also, the "libraries" in HLE, that the JITed code calls into, are wrappers built into the emulator software, and therefore can "think in terms of" the source console (see, for example, the texture upscaling in Dolphin)—whereas with transpilation, you have to make direct use of the transpilation-target's platform libraries as-is, with the only extra platform-specific logic existing as shim-code compiled into the transpiled binary at the call-site.
Besides Emscripten, the only other good comparison I can think of is ARC (https://developer.chrome.com/apps/getstarted_arc): a transpiler that takes Android Java bytecode (with Android SDK calls) and spits out PNaCl bytecode (with PPAPI calls.)
Wine is faster than Emscripten because asm.js is a slow target, not because HLE produces fundamentally better results than transpilation.
Wine has a variant, libwine, that can linked into a Windows binary at compile-time, replacing that Windows binary's linkages to Windows libraries with linkages to Wine. If you have the opportunity, this is always the more processor-efficient way to go (and I'm surprised so many companies choose to "port" their software to Linux using Cider rather than taking their source and compiling in libwine.)
If you didn't have the source of a Windows binary, you could create a Linux transpiler that replaces already-generated Windows symbols with Wine symbols statically while also potentially rewriting the ISA and calling conventions. The only reason one doesn't exist is that the overhead of running a very similar platform via HLE (i.e. one with the same ISA) is negligible. If OSX was still on PPC, for example, running Wine-on-PPC-OSX would work much better via transpilation than via HLE.
Speaking of PowerPC, a better candidate for "transpilation for performance purposes" would have been the PPC apps run under the Rosetta HLE emulator built into OSX. These apps could have been chewed-through once to produce a Carbon-linked x86 binary, that binary cached in the PPC binary's resource fork, and then executed immediately from then on. But Apple themselves had little reason to do this—they didn't want to give anyone an extra incentive to continue using PPC software instead of moving to x86/x64 software.
I wouldn't say that whether the shim libraries are built into the emulator or statically linked into the transformed output is very important. There are really two mostly orthogonal axes here:
- Instruction set: JIT (emulators, Rosetta) vs. static recompilation (only niche projects when the source is a machine ISA, but arguably Java AOT compilers, OdinMonkey, etc. count) vs. doing nothing because the source and target have the same ISA (Wine, VM software for the most part).
- APIs: HLE (emulate semantics) vs. LLE (emulate hardware). The more abstract the API, the better the former works, and vice versa. If you are not emulating things like interrupts and register pokes, that is HLE by definition.
In some cases you can /directly/ translate source API usage into target API usage without any shims, but only for relatively simple APIs. For anything complicated, the semantics are likely different enough that transforming calls to it would require complicated global analysis, which would be quite pointless from a performance perspective unless the API is called ridiculously often.
It's feasible, but to make firmware useful outside of device encryption keys must be extracted or firmware need to be heavily patched. Both tasks are complex and there not many people that going to work on it because groups like fail0verflow don't support piracy.
Also video does show privilege escalation that start via webkit exploit, but that doesn't mean that they worked towards breaking of content encryption and / or dumping games.
Since the PS4 OS is based on FreeBSD, you could conceivably match up parts of the compiled PS4 kernel with FreeBSD source code. However, I bet there's some sort of obfuscation that their compiler performs to make it difficult to decompile.
Apparently there are very little changes in the Sony PS4 kernel compared to FreeBSD 9. Sony changed some of the parameters to syscalls and added a bunch of their own syscalls.
