Reverse Engineering the PlayStation App - Nonchalant Guidance
Nonchalant Guidance
About Me·RSS·My Projects·LinkedIn
Search
Added on: Thursday, 28 May, 2026 | Updated on: -<br>Reverse Engineering the<br>PlayStation App
I like gaming. I’ve historically played a lot of PlayStation<br>exclusives, so I prefer sticking with the PlayStation consoles. With the<br>PS4 onwards, Sony created an app called the PlayStation app that allows<br>you to (among other things):
Message friends over PSN
Interact with the PlayStation Store
Manage your console’s storage and/or start downloading games to the<br>console from the app
Look at your trophy progression
View game screenshots and video (if you enable the auto upload)
The app itself is somewhat decent, although I wished it was a bit<br>faster. Also, the screenshots and videos are a bit of a pain to share<br>over other mediums, and they disappear from the server in 14 days.<br>That’s not a huge problem, except for the fact that even the stuff<br>you’ve viewed in the app disappears. The only way to save it is to<br>“truly” download it, ie download to the Android gallery. This is kind of<br>annoying.
This pain point would lead me to reverse engineer enough of the app<br>so I could build my own that would cache stuff inside the app and allow<br>viewing, sharing and saving to gallery even after the content was<br>deleted from Sony’s servers. Here’s how I did it.
The Setup
My previous phone, which was still modern enough to run the<br>latest LineageOS and was also rooted. After I got my new (and current<br>phone), I reset the old one, and rooted it, out of curiosity. I kept it<br>around idly, with no real purpose, but my “foresight” rewarded me when I<br>needed a test device for reverse engineering.
I installed PCAPDroid, with the<br>root certificate it created also installed as a user cert.
The root certificate is installed so that HTTPS connections can be<br>intercepted, decrypted, stored and forwarded. However, on Android apps<br>can also pin their preferred certificates, so they don’t necessarily<br>have to trust the user installed certificates. While this practice is discouraged,<br>many apps still do this to prevent reverse engineering. The PlayStation<br>app is no different.
Frida setup following this<br>guide. Frida is basically a framework that allows you to inject<br>certain behavior into Android apps by hooking into system API calls<br>those apps make. In this case, by using specific scripts with specific<br>behaviors that hook into networking APIs, we can tell the PlayStation<br>app to use the PCAPDroid certificate rather than whatever it has<br>pinned.
This consists of two steps:
Running the frida server binary as root on the Android device.<br>This will actually do the injection, and launch the app with the scripts<br>we provide it.
Launching the Frida scripts from our desktop to hook into native<br>TLS, unpin certs, and configure our own certficate, and launching the<br>PlayStation app under these circumstances.
Note: I initially used HTTPToolkit’s Frida scripts as highlighted in<br>the article, however I had to use this<br>fork for the unpinning to work, as it correctly hooked into<br>com.android.org.conscrypt.TrustManagerImpl where the<br>upstream repo did not. As of writing this article I first started<br>looking into this a few months ago, so it is quite possible they have<br>already fixed it. In case they haven’t, you can save yourself some time<br>and try using this fork.
I used the command
frida -U -l ./config.js \<br>-l ./native-tls-hook.js \<br>-l ./android/android-certificate-unpinning.js \<br>-l ./android/android-certificate-unpinning-fallback.js \<br>-f com.scee.psxandroid<br>(where com.scee.psxandroid is the package name of the<br>PlayStation app)
to launch the app under these circumstances after I had followed the<br>instructions and edited the config.js accordingly.
As a precautionary/necessary measure, I forget at this point, I also<br>used the cert-fixer<br>Magisk module. This copies all the certs from the user-installed CA cert<br>list into the system store, since some apps can refuse to trust the user<br>CA certs and instead stick only to the system store. However, I’d say my<br>usage of the forked Frida scripts probably negated the need for this.<br>Still, if even after all that the certificate is still untrusted, try<br>this step out.
First Steps
With all of these pieces in place, I ran the app, starting with<br>logging in …. and that did not work!
The PlayStation app redirects you to what I believe is a WebView<br>process that loads in the login page. This login page, once successful,<br>generates a token called an “NPSSO”. This token is what will ultimately<br>identify a user in the subsequent API calls.
However, due to the way that this WebView process is spawned, and the<br>way the Frida scripts work, if we have Frida scripts active, the WebView<br>is never able to load in the login page. Thus, we have to log in with no<br>interception (ie, we can’t capture the login page URL, or what data it<br>returns on successful login to the app through Frida).
After we’re logged in though, we’re firmly...