Orbis OS - das Betriebssystem der PS4

crysmopompas

I am a bot ¯\_(ツ)_/¯
systems, systems, systems, systems, systems, systems, systems, systems, systems, systems, systems
Spielt gerade: GT7 | 60fps FTW
#41
Welches Interesse der Thread plötzlich hat. Vorher war das eher ~foreveralone~.


alle die hier ein offenes Scheunentor verteidigen, sind auch lustigerweise die Leute die jetzt nicht gerade die Mainstream-Titel online zocken.
Sind GT und FM Nischentitel ~hmm~. Deren Entwickler hatten jedenfalls keine großen Probleme Cheater auszusperren. In den Augen mancher Spieler hatten die sogar zu viel getan :ugly:, und auch eher harmlose Hacks gebannt (nicht erlaubte Felgen, mit Verkehrsautos in Horizon fahren,...). Ja, ist nicht automatisch auf andere Spiele übertragbar, und vielleicht ziehen die großen Shooter auch besonders viele "böse" Spieler an.


Um Cheater mach ich mir weniger Sorgen, ich fürchte eher Folgen wie noch mehr always-online Kacke, oder andere Einschränkungen auf den Konsolen als Vorsichtsmaßnahme :(. Ist ja bei PS4, PSV, XB1 bereits der Fall X(.
 
Zuletzt editiert:
systems, systems, systems, systems
PSN-Name: KING_DJ
#42
Weiß nicht mehr ob das auf der PS3 war oder einer anderen Plattform. Das krasseste gab es mal in GTA5, wo einer sogar Ingame-gescriptete Szenen eingebaut hatte und seine Gegner noch per Assfu**-Sequenz demütigen konnte. Hat damals sogar Schlagzeilen gemacht, vlt. erinnern sich noch einige. War glaub ich auch PS3, ebenfalls online. Und die Trophy-Hacks sollte man auch erwähnen, auf der PS4 sind sie ja "noch" nicht ercheatbar.

Je beliebter ein Game, desto eher die Wahrscheinlichkeit mit solchen Noobs in Kontakt zu kommen. Also BO3 ist iwann so gut wie sicher auf der PS3. :ugly: Wer den Port-Crap aber zockt, genießt nur ein Fünkchen Mitleid von mir. :p
 
systems, systems, systems, systems, systems, systems, systems, systems, systems, systems, systems, systems
PSN-Name: maxmontezuma
Spielt gerade: Hogwarts Legacy
#43
Bei den beliebten Ego-Shootern auf Konsole gehen mir schon die XIM4 Nutzer auf den Sack, das ist für mich nämlich auch nichts anderes als cheaten. Und sowas kann anscheinend nicht ausgesperrt werden.
 
systems, systems, systems, systems
PSN-Name: KING_DJ
#44
Bei den beliebten Ego-Shootern auf Konsole gehen mir schon die XIM4 Nutzer auf den Sack, das ist für mich nämlich auch nichts anderes als cheaten. Und sowas kann anscheinend nicht ausgesperrt werden.
Das hattest du glaub ich schonmal gepostet, man kann also ohne Probleme auf der PS4 mit Tastatur und Maus zocken. Das Teil wird auch noch unterstützt? :ugly: Dachte bisher das war nur für die PS3. Dann riskieren die Deppen ja nichtmal nen Bann, wenn sie einfach ohne Jailbreak iwas einstöpseln, was von der PS4 selbst supportet wird. :ugly: Game over.

Edit: Habter gewusst, dass man auf PS3 problemlos auch mit dem PS4-Controller zocken kann? Hab ich erst neulich erfahren, hätte man mir früher sagen können. ~lol~
 

crack-king

Administrator
Team-Mitglied
systems, systems, systems, systems, systems, systems
#45
Das wird nicht offiziell von der PS4 unterstützt. Aber das Teil versteckt sich als PS4 Controller, da kannste nix machen.

Und der PS4 Controller funktioniert nicht in allen Spielen auf der PS3 und es gehen auch nicht alle Tasten, wie die PS-Taste. Außer die haben das mittlerweile geändert.
 

crysmopompas

I am a bot ¯\_(ツ)_/¯
systems, systems, systems, systems, systems, systems, systems, systems, systems, systems, systems
Spielt gerade: GT7 | 60fps FTW
#47
Um wieder zum eigentlichen Thema zurückzukommen:

root FS dump, and list of PIDs
[+] Entered shellcode
[+] UID: 0, GID: 0
[DIR]: .
[DIR]: ..
[DIR]: adm
[DIR]: app_tmp
[DIR]: data
[DIR]: dev
[DIR]: eap_user
[DIR]: eap_vsh
[DIR]: hdd
[DIR]: host
[DIR]: hostapp
[FILE]: mini-syscore.elf
[DIR]: mnt
[DIR]: preinst
[DIR]: preinst2
[FILE]: safemode.elf
[FILE]: SceBootSplash.elf
[FILE]: SceSysAvControl.elf
[DIR]: system
[DIR]: system_data
[DIR]: system_ex
[DIR]: system_tmp
[DIR]: update
[DIR]: usb
[DIR]: user
[+] PID 0, name: kernel, thread: mca taskq
[+] PID 1, name: mini-syscore.elf, thread: SceRegSyncer
[+] PID 2, name: SceHidAuth, thread: SceHidAuth
[+] PID 3, name: hidMain, thread: hidMain
[+] PID 4, name: SceCameraDriverMain, thread: SceCameraDriverM
[+] PID 5, name: SceCameraSdma, thread: SceCameraSdma
[+] PID 6, name: hdmiEvent, thread: hdmiEvent
[+] PID 8, name: xpt_thrd, thread: xpt_thrd
[+] PID 9, name: iccnvs, thread: iccnvs
[+] PID 10, name: audit, thread: audit
[+] PID 11, name: idle, thread: idle: cpu0
[+] PID 12, name: intr, thread: irq273: xhci2
[+] PID 13, name: geom, thread: g_notification
[+] PID 14, name: yarrow, thread: yarrow
[+] PID 15, name: usb, thread: usbus2
[+] PID 16, name: md0, thread: md0
[+] PID 17, name: icc_thermal, thread: icc_thermal
[+] PID 18, name: sflash, thread: sflash
[+] PID 19, name: sbram, thread: sbram
[+] PID 20, name: trsw intr, thread: trsw intr
[+] PID 21, name: trsw ctrl, thread: trsw ctrl
[+] PID 22, name: SceBtDriver, thread: SceBtDriver
[+] PID 23, name: pagedaemon0, thread: pagedaemon0
[+] PID 24, name: pagedaemon1, thread: pagedaemon1
[+] PID 25, name: vmdaemon, thread: vmdaemon
[+] PID 26, name: bufdaemon, thread: bufdaemon
[+] PID 27, name: syncer, thread: syncer
[+] PID 28, name: vnlru, thread: vnlru
[+] PID 29, name: softdepflush, thread: softdepflush
[+] PID 31, name: SceSysAvControl.elf, thread: SceAvSettingPoll
[+] PID 33, name: SceSysCore.elf, thread: SysCoreAppmgrWat
[+] PID 34, name: orbis_audiod.elf, thread: AoutMonitorPid40
[+] PID 35, name: GnmCompositor.elf, thread: CameraThread
[+] PID 36, name: SceShellCore, thread: SceMsgMwSendMana
[+] PID 38, name: SceShellUI, thread: SceWebReceiveQue
[+] PID 39, name: MonoCompiler.elf, thread: MonoCompiler.elf
[+] PID 40, name: SceAvCapture, thread: SceAvCaptureIpc
[+] PID 41, name: SceGameLiveStreamin, thread: SceGlsStrmJobQue
[+] PID 42, name: ScePartyDaemon, thread: SceMbusEventPoll
[+] PID 43, name: SceVideoCoreServer, thread: SceVideoCoreServ
[+] PID 44, name: SceRemotePlay, thread: SceRp-Httpd
[+] PID 45, name: SceCloudClientDaemo, thread: SceCloudClientDa
[+] PID 46, name: SceVdecProxy.elf, thread: proxy_ipmi_serve
[+] PID 47, name: SceVencProxy.elf, thread: SceVencProxyIpmi
[+] PID 48, name: fs_cleaner.elf, thread: fs_cleaner.elf
[+] PID 49, name: SceSpkService, thread: SceSpkService
[+] PID 50, name: WebProcess.self, thread: selectThread
[+] PID 51, name: orbis-jsc-compiler., thread: SceFastMalloc
[+] Triggering second kernel payload
[+] Entered main payload
https://gist.github.com/CTurt/27fe7f3c241f69be19e5
 

crysmopompas

I am a bot ¯\_(ツ)_/¯
systems, systems, systems, systems, systems, systems, systems, systems, systems, systems, systems
Spielt gerade: GT7 | 60fps FTW
#52
Noch gar nicht mitbekommen.


https://fail0verflow.com/blog/2015/console-hacking-2015-liner-notes.html
Two years ago, I said that the PS4 was not a particularly interesting device, being a glorified PC. What happened?
Essentially, two things: First, we’re hackers, and hacking consoles is fun after all. Second, it turned out that the PS4 isn’t really a PC (which makes it a more interesting target), while being enough of a PC to have some serious advantages. It’s hard enough to be interesting, and easy enough to be practical.

Let’s recap the (very simplified) history of game console hacks that we have been involved with:

  • On the Wii, we basically drove the entire homebrew community, from exploits to libraries to infrastructure. The community ended up being very large and productive, with lots of interesting releases. However, the people interested in game piracy were always riding on the coattails of homebrew since relatively early on, and greatly benefited from it.
  • On the PS3, we tried releasing the exploits and letting others sort out the community. The result was that, for all practical purposes, the only users were those interested in piracy. AsbestOS allowed Linux to work again, but since there was no GPU driver, and the CPU was underpowered and annoying to work with, there wasn’t that much interest beyond those who were already running OtherOS.
  • On the Wii U, we tried to get the community to display interest and work on Linux support before releasing the exploits. Although there were certainly several interested people, nobody with the right experience stepped up to actually make it a reality. Eventually others released exploits, and quickly a piracy tool has become one of the primary use cases for them.
For the PS4, therefore, we’re yet again trying something new. It seems that the PS4 security architecture is rather straightforward and simple; the OS is based on FreeBSD, and the browser uses WebKit, both of which are open source. It is relatively easy to find exploits in both of them (all things considered), and that is all you need to chain into a Linux loader. However, as we found out, even though the hardware is certainly similar to a PC, it is not a PC, and Linux needs quite a bit of extra work to get running. Thus, we can add more value to the homebrew ecosystem by helping port Linux than by releasing exploits.

Of course, this also absolves us from responsibility for potentially enabling piracy (and online play hacking and other undesirable outcomes), but we think it might even have a net positive effect: if we can get people interested in running Linux on the PS4 over using the native OS, we can redirect efforts away from reverse engineering the original software infrastructure (which is what the piracy guys need, and they inevitably leech off of those efforts) to Linux (which is completely useless for piracy).

Linux on the PS4 actually makes a lot of sense, more than it ever did on any previous game console. It’s close enough to a PC that getting 3D acceleration working, while rather painful (as we’ve learned), seems entirely possible without undue amounts of effort (in a timeframe of months, not years), to the level needed for real indie games and even AAA titles, not just homebrew. And many thousands of indie and AAA games already run on Linux. Yes, SteamOS on the PS4 should “just work” once the driver issues are sorted out. We demoed a silly GBA emulator because all we had was a 2D framebuffer, but the real fun is getting 3D games to run just like they do on a PC (we’ve tried some commercial indie games already and they do work fine, just painfully slow as they are using software rendering right now, of course).

Although the exploits used in our demo were our own work (we in fact had Linux booting, albeit in a very broken state, well before any PS4 exploits were publicly announced - porting Linux takes time), the fact that other teams have also been able to get kernel code execution proves the point that you really don’t need to depend on us for that aspect. We also have no doubt that vulnerabilities in the latest firmware can be found without too much trouble. Incidentally, everything is pure software. Hardware stuff was only used for research. There is not much reason to resort to hardware-based exploits on an architecture like the PS4, with a very wide attack surface and mediocre isolation.

So, to the community: if you’re interested, we really think this is the way to go for the PS4. Write an exploit, point it to our loader, and you’ll get Linux (we’ll help you get it hooked up/debugged if needed). And if you want piracy, as usual, go away.

As for release timeframes: right now, the code is in a pretty ugly state, and some components are not releasable (e.g. they contain a bit of code that has been directly reverse engineered from Sony modifications to FreeBSD and needs to be rewritten/cleanroomed). Our goal is to eventually get the patches upstreamed in the Linux kernel, but in the meantime we will open up a work-in-progress repo as soon as is practical. If you’re interested, want to contribute, and have access to a PS4 kernel level exploit, feel free to get in contact with us so we know who wants to help out.

For those curious: the current status of 3D support is that we can get the kernel driver to enable acceleration (with some issues), but command buffer execution is currently broken because GPUVM is not working properly (page flipping works, but nothing is rendered, as the command buffer itself triggers a GPU page fault). We’re actively working on debugging this. If you happen to work on the Radeon DRI driver or are familiar with it, we could use a hand here ;).

TL;DR: We’re working on Linux kernel patches, and are looking to get them upstreamed. We’re not releasing exploits - we’re certain other people will. Don’t ask us. And if you want free games, go away.
https://youtu.be/PQFNnr6Ly9M
Instructions are posted soon by Team Fail0verflow. But for now you need a PS4 with firmware 1.76 or lower. This won't be possible on PS4's that are updated.
 
Zuletzt editiert:
systems, systems, systems, systems, systems, systems
PSN-Name: MORF-iUM
Spielt gerade: PS5
#53
Sowas ist halt richtig geil, bin gespannt was die da noch so alles raus holen werden.
Das es nicht bei Linux bleibt ist klar, aber grade OtherOS ist das spannendste, die Popularität wird dann aber wieder nur der bekommen, der zu erst ps4 spiele zum laufen bekommt:(
 

crysmopompas

I am a bot ¯\_(ツ)_/¯
systems, systems, systems, systems, systems, systems, systems, systems, systems, systems, systems
Spielt gerade: GT7 | 60fps FTW
#56
Ihr meint IBM-PC? Damit sind streng genommen nicht mal mehr aktuelle Intel-CPUs kompatibel :ugly:.

Bei der PS4 fehlen vermutlich viele "Legacy" Sachen (Timer, Interrupts, Tastaturcontroller, IO ...)



Edit:
marcan sagte:
Basically, it's a legacy-free x86 system, so it is missing many things (like interrupt controllers or timers) that are assumed to exist on a PC. On top of that, the southbridge does a lot of things in nonstandard ways and the way it is organized makes no sense. We'll probably have a talk in the future that goes into all the gory details of the porting process.
und noch ein paar andere Sachen:
The PS4 CPU has physical support for SVM, but it is fused off (disabled in hardware), so you can't run VMs. It may or may not be possible to work around that and enable SVM anyway.
Are you really sure about the internal HDD being connected with USB? From a business standpoint it sounds quite counter-productive, considering that there supposedly is SATA controller (Blu-Ray) and SATA -> USB converters aren't free.
Yes. We think it has something to do with the standby CPU in the southbridge, which has to be able to access the HDD to download updates/content while the APU is switched off. Maybe they didn't want to put an AHCI driver in there (no idea why - it runs FreeBSD too and already has one), or maybe the AHCI controller doesn't work while in standby for some reason.
Maybe it's just dumb design. Sony has a history of hilariously bad (and expensive) design decisions with their consoles. They're really bad at cost-optimizing and seem to value time to market, even with a ridiculous architecture, over producing a system that actually makes sense and is cheap to produce. The original PS3 was much worse than the PS4 though, so it seems they're learning a bit.
Hatte ich an anderer Stelle auch schon mal gelesen, daß die HDD per USB angebunden ist :ugly:. Evtl. bei der 1200er anders ~notsure~
It remains to be seen what kind of performance you can get. One important thing to note is that I'm pretty sure the CPU memory bus cannot exploit all the bandwidth of the GDDR5 memory - the bulk goes to the GPU. So it's nice from a unified memory standpoint, but from the CPU perspective only you probably won't get any kind of interesting performance out of it (and the cores are rather weak). OpenCL would be nice though.
 
Zuletzt editiert:

crysmopompas

I am a bot ¯\_(ツ)_/¯
systems, systems, systems, systems, systems, systems, systems, systems, systems, systems, systems
Spielt gerade: GT7 | 60fps FTW
#58
Mittlerweile hat CTurt Teil 3 veröffentlicht:





Über die USB Bibliothek, die Spieleentwickler nutzen können, z.B. für andere Joysticks:

When you insert a USB into the PS4, a new device is listed under /dev/: ugen0.4 for the first slot, and ugen0.5 for the second slot.

Unfortunately, we can't mount the device since the mount system call (and variations like nmount) always return 1, EPERM.

However, we can access USB flash drives using the libSceUsbd.sprx module; it is very similar to libusb, but with the Sony naming convention, and the removal of contexts.

For example, the following libusb code:

libusb_context *context;
libusb_init(&context);
libusb_exit(context);

Would translate to this libSceUsbd code:

sceUsbdInit();
sceUsbdExit();

This is a very low level library for sending direct commands to USB devices, so it isn't really ideal to use, but with the help of xerpi, I was able to port one of the libusb examples to PS4, and read the raw image of a USB flash drive.

Whilst it may be possible in the future to port a full FAT implementation based on direct USB commands, for now I am just writing my data as the raw image of a USB flash drive using Win32 Disk Imager (similar to dd for Linux).
Zu Keys:
Encryption

The most common questions I am asked pertain to encryption. It is a huge part of the PS4's security which prevents us from analysing firmware updates, games, saves and more.

The reason I didn't mention encryption in my last article is because trying to defeat it would be a complete waste of time. The PS4 probably uses AES (like the PS3 and PS Vita), which is the same type of encryption used by the U.S. government.

People also don't seem to realise that there are multiple encryption keys used within the PS4; even if we found a way to decrypt save data, we still wouldn't be able to decrypt PUP updates for example.

With the current level of access we have to the PS4 there is no way to get any keys: brute forcing them would take longer than the lifetime of the universe even under ideal conditions, and I doubt any of the few engineers at Sony trusted with them would want to lose their job by leaking them.

The only exception to this is would be for implementation mistakes such as the PS3's infamous use of the constant 4 instead of what should have been a random number.

Whilst it is unlikely that Sony has made another mistake like this in the core of the PS4's encryption, it is not uncommon for other companies to accidentally give us access to unencrypted content. If you snoop around various games' update servers, you might find some debug ELFs for example.
und Spielständen:
Saves

Save data is stored at the following location:

/user/home/[userID]/savedata/[titleID]/

For example:

/user/home/10000000/savedata/CUSA00455/FFXIVSYSTEM.bin

We can dump these files, but they are encrypted, and are identical to the files copied from using the PS4's official USB save export feature.

It is unlikely that developers directly deal with this encryption; I assume that the libSceSaveData module handles it all.

I was able to load and initialise this module successfully:

int libSave = sceKernelLoadStartModule("libSceSaveData.sprx", 0, NULL, 0, 0, 0);

int (*sceSaveDataInitialize)(void *);
RESOLVE(libSave, sceSaveDataInitialize);

sceSaveDataInitialize(NULL);

But I just received error codes when attempting to mount or read/write save data.
 
Zuletzt editiert:
Top