Pi doesn't turn off automatically.

[krakenbites]

I discussed this briefly here, so I decided to update the script to the latest version.

The Pi is not turning off automatically after successful PPPwn, despite the fact I chose it to do so during setup:

Check my Y/N commands above.

Is the web server supposed to load if the Pi is turned off?

[krakenbites]

There's definitely something wrong, Pi is not shutting off automatically after PPPwn.

[krakenbites]

On top of that, if you put the console on rest mode and then wake up the console the Pi will try to PPPwn the PS4 even though the console is already PPPwnd.

[krakenbites]

This is what I am suggesting:

1) Pi shuts down after successful PPPwn;

2) Pi DOES NOT turn on if the console turns on from rest mode.

3) Pi DOES turn on if the console turn on from power off state.

[Kyhze]

I'm getting the same behavior as you. I also noticed mine keeps trying to jailbreak the console even when it's in rest mode. PPPwn just keeps running forever sometimes, it would seem. But it's unclear as to how to reproduce it in order to pin point the cause.

Something else I also noticed: It's good that we have a timer to restart PPPwn in case it hangs, but would it be possible to forcefully trigger a "LAN cable not connected" (i.e. by putting the eth0 interface down and then up again) upon restarting PPPwn? This way, the exploit and the console are better in sync. Not sure if this would actually help tho?

Additionnally, I feel like an option to simply stop PPPwn from the Web UI and/or as an option on successful jailbreak would be a good idea.

[DrYenyen]

Yes an option to stop PPPwn would be good

[ImAlwaysInFaMouS]

It's worth just letting it run tho tbh and if you're using the internet via the pi it's no big deal,l.

Coming from rest mode: if you are not using the usb power of the PS4, yes it might be good to have a stop button, but you can enable the usb to stay powered while in rest mode, keeping the pi on?

[DrYenyen]

It's good to have in general

[krakenbites]

It's worth just letting it run tho tbh and if you're using the internet via the pi it's no big deal,l.

Not it is not worth it to let it run, it heats up and keeps operating without a reason to do so.

Lots of people don't use internet through Pi. We just want the Pi to turn ON and jailbreak the PS4 every time the PS4 turns ON from a powered OFF (not rest mode) state, and then the Pi should turn itself OFF automatically (after a successful PPPwn).

This would be an amazing automation functionality that many people have been asking.

[stooged]

ok there are three things going on here i have found in my tests with rest mode...

the first issue is when saving config settings through the web page the shutdown flag was being set to false which i will fix when set to shutdown the pi does shutdown as expected.

the following issues are with rest mode...

if you watch the pi console output when you enter rest mode the console cuts power to the usb ports for about 2 seconds and then restores it which reboots the pi because the power is being cut and restored. the pi then restarts and tries to pwn the console while it is in rest mode. the only way around this is to disable the power to the usb ports in rest mode.

the third issue is the pppwn exploit does not seem to be persistent through rest mode, after booting back in from rest mode goldhen is unloaded and elevated permissions are lost. it also seems to be unstable after this as it causes my slim test console to panic after the restart from rest mode when running pppwn again, this could just be my console too.

[krakenbites]

the third issue is the pppwn exploit does not seem to be persistent through rest mode, after booting back in from rest mode goldhen is unloaded and elevated permissions are lost. it also seems to be unstable after this as it causes my slim test console to panic after the restart from rest mode when running pppwn again, this could just be my console too.

What I can confirm is that the PPPwn exploit is indeed persistent through rest mode, at least on my Slim (and other people's Slims as well). Based on what I've seen, most people are leaving their consoles on rest mode after PPPwn to avoid boot + PPPwn every time they want to use the PS4.

Nevertheless we look forward to the next updates, let us know if you need more help and thanks a lot for everything you do Stooged!

[krakenbites]

if you watch the pi console output when you enter rest mode the console cuts power to the usb ports for about 2 seconds and then restores it which reboots the pi because the power is being cut and restored. the pi then restarts and tries to pwn the console while it is in rest mode. the only way around this is to disable the power to the usb ports in rest mode.

I also want to make a comment on this.

If you think about it, even if you "disable power to the USB in rest mode" to prevent the Pi from waking up again 2 seconds later, the Pi will try to PPPwn the PS4 as soon as the PS4 wakes up from rest mode, because power will be restored to the USB ports once the console is operating again. Which means your suggestion for this problem doesn't really work.

Do you think there's any way to fix that with your code?

[DrYenyen]

Losing goldhen after rest mode is weird i'm going to test it out really quick but i think this is the only time I've seen this. I have been testing on the pi since the day you released your script for the best success method i have found that toggling connect to the internet and then test internet connection manually gives a much better success rate on my ps4 pro whereas if i just let the pi run at the home menu it has to do it 10 or more times. I will test tonight and see because i know some people get kernel panics in rest mode and have to re exploit.

[krakenbites]

Do you think there's any way to fix that with your code?

Stooged, I think this could perhaps help you fix the issue:

The very first thing that has to happen once the Pi turns on and interacts with the PS4 is to check if console is PPPwnd.

• if true (PS4 is PPPwnd) = shut down the Pi immediately
• if false (PS4 is not PPPwnd) = proceed with the schedules and turn off once PPPwnd occurs

because its unpractical to alter how the PS4 power delivery works on a hardware level. I think the solution has to come via the Pi and PPPwn sequence of steps.

[stooged]

the third issue is the pppwn exploit does not seem to be persistent through rest mode, after booting back in from rest mode goldhen is unloaded and elevated permissions are lost. it also seems to be unstable after this as it causes my slim test console to panic after the restart from rest mode when running pppwn again, this could just be my console too.

What I can confirm is that the PPPwn exploit is indeed persistent through rest mode, at least on my Slim (and other people's Slims as well). Based on what I've seen, most people are leaving their consoles on rest mode after PPPwn to avoid boot + PPPwn every time they want to use the PS4.

Nevertheless we look forward to the next updates, let us know if you need more help and thanks a lot for everything you do Stooged!

i just realized my goldhen settings were wiped out and rest mode support was disabled.

so that solves that last issue but the power to usb ports issue is the main problem here.

I also want to make a comment on this.

If you think about it, even if you "disable power to the USB in rest mode" to prevent the Pi from waking up again 2 seconds later, the Pi will try to PPPwn the PS4 as soon as the PS4 wakes up from rest mode, because power will be restored to the USB ports once the console is operating again. Which means your suggestion for this problem doesn't really work.

Do you think there's any way to fix that with your code?

if you can suggest a way for when the pi gets powered on it can detect whether the console has started from rest mode or cold boot then i am all ears.

the console is restarting the pi when it hits rest mode so it is no different to you unplugging the power to the pi and plugging it back in.

[krakenbites]

if you can suggest a way for when the pi gets powered on it can detect whether the console has started from rest mode or cold boot then i am all ears.

Is this suggestion below possible?

The very first thing that has to happen once the Pi turns on and interacts with the PS4 is to check if console is PPPwnd.

• if true (PS4 is PPPwnd) = shut down the Pi immediately
• if false (PS4 is not PPPwnd) = proceed with the schedules until PPPwn

[DrYenyen]

lol i've been sitting here putting my console in and out of rest mode to try and see if i can get it to do it.

[stooged]

The very first thing that has to happen once the Pi turns on and interacts with the PS4 is to check if console is PPPwnd.

how though?

[krakenbites]

For example checking if the Goldhen payload is present?

[stooged]

and how do you do that through the ethernet connection that is not connected. even if it was connected you have no access to the consoles memory space to tell if a module is loaded.

the only possible way i could see is if you created an elaborate routine to wait until the console boots then setup the pppoe connection then try and communicate with the binload server or ftp to see if it is present.

the main problem with that is goldhen drops the servers when it finds no connection so the is a fair chance that ftp/binload wont work with the newly established connection.

[krakenbites]

the only possible way i could see is if you created an elaborate routine to wait until the console boots then setup the pppoe connection then try and communicate with the binload server or ftp to see if it is present.

That's what I was thinking as well, and I agree it is a problem but I don't have an answer for... At least in my case the ethernet cable is always connected and the PPPoE connection is always turned on (despite the fact that on Putty I chose to NOT have the PS4 connect to the internet via the Pi).

[stooged]

despite the fact that on Putty I chose to NOT have the PS4 connect to the internet via the Pi).

if you set the internet connection to disabled it does not link the ps4 to the pi, the pppoe-server is not started by the pi.

the pi still has internet in that state but it cant communicate with the ps4 and the ps4 cant communicate with the pi

[krakenbites]

That's true, I am out of ideas for now, then...

[stooged]

i will try and see if there is any way to run a check on the boot of the pi

obviously if enabled it will slow the execution time on boot down but i will see if i can find a way.

[stooged]

i have something sort of working but it does require rest mode settings to disable power to the usb.

in rest mode goldhen is suspended and there is no way to tell it is loaded through the ethernet, even with the "stay connected to the internet" option on.

so putting the console into rest mode kills the power to the pi. when you wake the console the pi boots then checks goldhen and reacts according to the settings of pi-pwn.

if goldhen is found... if you have shutdown set then the pi will just shut down if you have internet enabled for the console the pi will stay running and the pppoe-server will run

if goldhen is not found then pppwn will continue as normal and run pppwn

[stooged]

i also forgot to mention that the console PPPOE user and pass must match the user and pass set for the console internet connection option in pi pwn. if you never set those then the default is ppp for both user and pass.

i will probably need to add an option to change those on the web page.

[krakenbites]

Awesome, I'm gonna try it now (I always use ppp / ppp for username and password on PPPoE anyways).

[krakenbites]

Stooged, in order to update to your latest release should I run all the Putty commands or just sudo bash install.sh is enough?

[Kyhze]

Stooged, in order to update to your latest release should I run all the Putty commands or just sudo bash install.sh is enough?

Regarding this, perhaps an updater button on the webUI would be nice to have too, if possible! ;)

[krakenbites]

I'm also wondering what the answer for this question would be, due to the latest (rest mode compatibility) update:

EDIT: I answered with N and also answered with N when it asked about connecting to internet via Pi.

EDIT 2: Although the rest mode functionality seemed to have worked well, upon turning off the PS4 the PS4 is now frozen into shutdown state (white LED blinking) which literally never happened before.

EDIT 3: It was just a kernel panic, however I noticed that upon boot the Pi didn't attempt to PPPwn the console, possibly because I chose N to the very question I screenshotted here. Let me run the last sudo again and change that to Y to see if it fixes the problem.

EDIT 4: You need to run the whole command list, which I did, and I replied with Y to the question regarding "Pi and console shutdown detection" but still no good. I turned the PS4 on and although the Pi turned on as well the Pi didn't automatically tried to PPPwn the PS4.

EDIT 5: I clicked on "Reboot Pi" on the web server and although the Pi turned off it is not turning on again. It eventually turned back on but still no automatic PPPwn attempt being made.

[krakenbites]

Yeah something broke for sure because the Pi doesn't try to PPPwn anymore not even if you tell it to Restart PPPwn on the web server.

Possibly because it lost the interface?

[krakenbites]

Upon unchecking Enable Rest Mode Support the Pi PPPwnd the PS4 automatically (a reboot wasn't even needed), which means the current iteration doesn't work.

[krakenbites]

The Pi stopped trying to PPPwn the PS4 automatically during a boot entirely (and even manually).

[stooged]

mine is working. i am trying to disable things to find the issue but each time it just runs as expected.

[krakenbites]

mine is working. i am trying to disable things to find the issue but each time it just runs as expected.

Can you tell me what answers you replied to the Y/N questions so I can replicate?

[stooged]

at this stage everything false except rest mode

it does not really matter what settings are chosen as the first thing it does is check for the link and then check for goldhen so the only settings that matter are the restmode flag and the lan interface eth0 to the console

[stooged]

if it is hanging after the link is found then nmap is returning nothing and i cant seem to get it to do that unless i pull the lan cable out

[krakenbites]

Do you know what could have possibly triggered the Pi from having No Options on the interface list?

[stooged]

i have even set the wrong info in the consoles pppoe settings so it cant connect

all attempts result in it not finding goldhen and running pppwn

[stooged]

no options would be that it did not find a lan interface

[stooged]

what is in your /boot/firmware/PPPwn/config.sh file

[krakenbites]

How can I give you that information, by opening this file in notepad?

[stooged]

yes its just the stored config settings in text

[krakenbites]

By the time you asked I was already running:

sudo apt update

sudo apt install git -y

sudo rm -f -r PI-Pwn

sudo systemctl stop pipwn

git clone https://github.com/stooged/PI-Pwn

sudo mkdir /boot/firmware/

cd PI-Pwn

sudo cp -r PPPwn /boot/firmware/

cd /boot/firmware/PPPwn

sudo chmod 777 *

sudo bash install.sh

to see if it would fix the problem, let me see what happens now that I ran all of the commands again with the following answers:

[krakenbites]

Very first rest mode I had a kernel panic, just like before.

[stooged]

the only way i can get it to hang is by having the wrong interface value

[stooged]

INTERFACE="eth0" FIRMWAREVERSION="11.00" SHUTDOWN=false USBETHERNET=false PPPOECONN=false VMUSB=false DTLINK=false PPDBG=false TIMEOUT="3m" RESTMODE=true

thats how the config.sh should look

[krakenbites]

Okay I booted but as you can see it is not trying to PPPwn:

[stooged]

you would be better off plugging the pi into a screen to see what it is printing.

that web viewer only shows the output from the pppwn binary

[krakenbites]

INTERFACE="eth0" FIRMWAREVERSION="11.00" SHUTDOWN=false USBETHERNET=false PPPOECONN=false VMUSB=false DTLINK=false PPDBG=false TIMEOUT="3m" RESTMODE=true

thats how the config.sh should look

This is what mine looks like:

!/bin/bash

INTERFACE="eth0" FIRMWAREVERSION="11.00" SHUTDOWN=false USBETHERNET=false PPPOECONN=false VMUSB=false DTLINK=true PPDBG=true TIMEOUT="1m" RESTMODE=true

[stooged]

i have done about 40 boots of this thing now and it works in every config, cold boot/rest boot and it works every time.

i am unable to replicate what is happening.

i am going to try a complete os reinstall and see if that changes anything