Welcome to Richard's Blog

Author: applegater

Huge Thanks to EarthOnion – Vue-after-Free on My PS4 🎮
I want to give a huge thank you to EarthOnion for providing Vue-after-Free for the PS4. Because of this, I was able to restore the system backup on my PS4, open PS Vue, and successfully run the jailbreak exploit.

Everything worked perfectly — I truly appreciate the effort and contribution to the scene!

Non-Jailbroken PS4 System Backup Guide from his GitHub,

Official Repository

Full instructions and files are available here:

https://github.com/Vuemony/vue-after-free

⚠️ Important:
A network connection is required before running Vue. It does not need internet access — a local network is enough. Connect immediately after restoring the system backup.

If your network does have internet access, make sure you read the official connection instructions first.

Step 1 – Prepare Your USB Drive
1. Format your USB drive to exFAT.
⚠️ Warning:
Formatting will erase all data on the drive. Back up anything important first.

Step 2 – Download the System Backup
1. Download either:
  - VueSystemBackup.7z
  - VueLiteSystemBackup.7z
If you choose Lite Mode, the exploit will automatically launch when opening the app after the initial prompt.
1. Extract the contents of the archive onto your USB drive.
2. Plug the USB into your PS4.
Step 3 – Backup Your Data (Optional but Recommended)

If you have a real PSN account on the console:
- Go to:
  Settings > Application Saved Data Management > Saved Data in System Storage
- Back up your save data to the USB.
  (Make sure you have enough free space.)
If you cannot access saved data, your console likely does not have a real PSN account or is not activated. In that case, you cannot back up saves unless you jailbreak first.

Also back up captures:
- Go to:
  Settings > Storage > System Storage > Capture Gallery > All
- Back up your captures to USB.
Step 4 – Restore the System Backup
1. Go to:
  Settings > System > Back Up and Restore > Restore PS4
2. Select the system backup from your USB.
3. Restore it.
After reboot, you will have:
- A fake activated user account
- PS Vue installed
- Exploit data ready
Step 5 – Prepare the Payload
1. Place your payload (HEN or GoldHEN) on the root of your USB.
2. Rename it to:
```
payload.bin
```
After the first run, it will be loaded from /data/, so the USB will not be needed again.

Step 6 – Run the Exploit
1. Connect safely to any network (local is fine).
2. Open PS Vue.
3. You will see:
“This service requires you to sign in to PlayStation Network”

Press OK to continue.
1. Press the Jailbreak button to run the exploit
  OR configure:
  - Auto Loader
  - Auto Close
⚙️ Important for HEN Users

Before enabling Auto Close:
- Edit config.js
- Add 20 seconds to the close delay by setting:
```
20000
```
Then back up the current save file to USB via console settings.

Optional – Avoid PSN Pop-Up

After jailbreaking, you can run the np-fake-signin payload to avoid the PSN sign-in pop-up.

User Account Information
- Default User Account ID:
```
1111111111111111
```
This cannot be changed.

However, you can:
1. Create a new user.
2. Fake activate it.
3. While jailbroken, set up PS Vue under the newly activated account.
4. Resign an OnlineSave if exploit files become corrupted.
February 25, 2026
Fail2Ban + n8n Webhook SOP (SSH Permanent Ban)
Document Owner: IT / Network

Scope: Linux servers running OpenSSH where Fail2Ban enforces bans and notifies n8n via webhook.

Goal: Permanently ban brute-force SSH IPs locally (bantime = -1) and send events to n8n for enrichment/alerting.

Table of Contents
Architecture

This design keeps Fail2Ban as the local enforcement layer and uses n8n for centralized alerting/intel.
- sshd writes auth failures to /var/log/auth.log (or journald).
- Fail2Ban detects brute-force patterns and applies a local ban.
- n8n receives webhook events to enrich (IP intel), notify (Slack), and correlate across servers.
```
sshd logs → Fail2Ban jail → firewall ban (%(action_)s)
                         ↘︎ webhook notify → n8n workflow
```
Prerequisites
- Ubuntu/Debian server (or compatible)
- OpenSSH installed and running
- Log file exists: /var/log/auth.log
- Outbound HTTPS allowed to your n8n domain
- n8n webhook endpoint created (POST)
SOP 1 — Install Fail2Ban

Procedure
1. Install packages:
```
sudo apt update
sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
```
Validation
```
systemctl is-active fail2ban
sudo fail2ban-client ping
```
SOP 2 — Create n8n Webhook Action

Create a custom Fail2Ban action that calls n8n when an IP is banned or unbanned.

Procedure
1. Create the action definition:
```
sudo nano /etc/fail2ban/action.d/n8n-webhook.conf
```
Paste the following:
```
[Definition]

# NOTE:
# - actionban/actionunban are all we need for webhook notifications.
# - actionstart/actionstop/actioncheck are intentionally omitted.

actionban = curl -sS -m 8 -X POST "<n8n_url>" \
  -H "Content-Type: application/json" \
  -d '{"event":"fail2ban_ban","jail":"<name>","ip":"<ip>","fq_hostname":"<fq_hostname>","failures":"<failures>","time":"<time>","token":"<token>"}' \
  >/dev/null 2>&1 || true

actionunban = curl -sS -m 8 -X POST "<n8n_url>" \
  -H "Content-Type: application/json" \
  -d '{"event":"fail2ban_unban","jail":"<name>","ip":"<ip>","fq_hostname":"<fq_hostname>","time":"<time>","token":"<token>"}' \
  >/dev/null 2>&1 || true

[Init]
n8n_url =
token =
fq_hostname =
```
Notes
- Why no actionstart/stop/check? Webhooks don’t require lifecycle setup; only ban/unban events matter.
- Timeout: -m 8 prevents Fail2Ban from hanging on slow networks.
- Reliability: || true prevents webhook failures from breaking Fail2Ban operations.
SOP 3 — Configure SSH Jail (Permanent Ban + Multi-Action)

Procedure
1. Edit the jail configuration:
```
sudo nano /etc/fail2ban/jail.local
```
Add/replace the SSH jail:
```
[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
backend = auto

maxretry = 5
findtime = 600
bantime = -1

# Multi-action:
# 1) %(action_)s = default firewall ban action
# 2) n8n-webhook = notify n8n
action = %(action_)s
         n8n-webhook[n8n_url="https://YOUR_N8N_DOMAIN/webhook/fail2ban", token="YOUR_TOKEN", fq_hostname="YOURSERVER.example.com"]
```
Critical Token Warning

Avoid tokens containing # unless you escape it, because # can be treated as a comment delimiter.
- Good: SecureToken_ABC123
- If you must keep #: escape it like \# (example: abc\#123)
Apply
```
sudo systemctl restart fail2ban
```
SOP 4 — Validate & Test

Check SSH jail status
```
sudo fail2ban-client status sshd
```
Tail Fail2Ban logs
```
sudo tail -n 200 /var/log/fail2ban.log
```
Test a ban safely
- Use a separate source IP (not your admin IP)
- Attempt several failed SSH logins to trigger maxretry
Verify n8n
- Confirm the webhook executed in n8n
- Confirm payload includes event, ip, fq_hostname, and jail
SOP 5 — Operations (Monitoring & Health Checks)

Daily quick checks
```
systemctl is-active fail2ban
sudo fail2ban-client status sshd
```
Investigate suspicious spikes
```
sudo tail -n 200 /var/log/fail2ban.log
sudo grep "Ban" /var/log/fail2ban.log | tail -n 50
```
Expected behavior
- Fail2Ban stays active
- Banned IPs accumulate gradually
- No repeated webhook/curl failures in logs
SOP 6 — Manual Unban

List current bans
```
sudo fail2ban-client status sshd
```
Unban a specific IP
```
sudo fail2ban-client set sshd unbanip 1.2.3.4
```
SOP 7 — Incident Recovery (Accidental Self-Ban)

Recovery steps
1. Use console access (cloud console / physical / out-of-band)
2. Unban your public IP:
```
sudo fail2ban-client set sshd unbanip YOUR.PUBLIC.IP.ADDRESS
```
Optional: protect stable admin IP

If your admin IP is stable, add it to ignoreip:
```
[sshd]
ignoreip = 127.0.0.1/8 YOUR.PUBLIC.IP.ADDRESS
```
SOP 8 — Secure the Webhook (Production Standard)
- Validate token in n8n as the first step
- Return 401/403 on invalid token
- Rate-limit the webhook at reverse proxy (Nginx/Traefik/Cloudflare)
- Optionally restrict source IPs to only your servers
SOP 9 — Change Control

Backup config before changes
```
sudo cp -a /etc/fail2ban /etc/fail2ban.bak.$(date +%F)
```
After changes
```
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd
sudo tail -n 100 /var/log/fail2ban.log
```
Document changes: date/time, what changed, why, and expected impact.

End of SOP.
February 23, 2026
Anthem Coffee – Guest Wi‑Fi Terms of Service (Washington, USA)

By accessing and using Anthem Coffee’s Guest Wi‑Fi (“Service”), you agree to these Terms of Service and Acceptable Use rules.

1) Acceptance and Eligibility

This Service is provided for customers and guests of Anthem Coffee.

By connecting, you confirm you are authorized to use the device you connect and you agree to these Terms.

2) Service Provided “As Is”

The Service is provided “as is” and “as available.”

Anthem Coffee does not guarantee availability, speed, coverage, or compatibility with your device.

The Service may be limited, filtered, or blocked to protect the network and users.

3) Your Responsibility

You are responsible for:

Keeping your device secure (updates, antivirus, firewall).

Any activity conducted from your device while connected.

Protecting your own data. Public Wi‑Fi is not secure; use HTTPS and/or a VPN for sensitive activity.

4) Prohibited Uses

You may not use the Service to:

Violate any law or regulation.

Attempt unauthorized access to any system, account, or network.

Run port scans, exploit tools, phishing, spam, or other abusive activity.

Distribute malware, viruses, or malicious code.

Infringe copyrights or distribute illegal/pirated content.

Access, create, or distribute unlawful, harmful, or exploitative content (including child sexual abuse material).

Interfere with the network or other users (excessive bandwidth use, denial-of-service behavior).

Operate public servers/hosting, or run continuous high-volume traffic not typical of guest use.

5) Logging, Privacy, and Security

For security, troubleshooting, and acceptable-use enforcement, Anthem Coffee may collect and store limited data such as: device identifiers (e.g., MAC address), assigned IP address, connection timestamps/duration, and basic network traffic metadata.

Anthem Coffee does not guarantee confidentiality of data transmitted over the Service.

Information may be disclosed to service providers or law enforcement if required by law or to protect the business, customers, or network.

6) No Unlawful Use / Cooperation with Law Enforcement

You agree not to use the Service for unlawful purposes.

Anthem Coffee may cooperate with law enforcement investigations as required by applicable law.

7) Suspension or Termination

Anthem Coffee may suspend or terminate your access at any time, without notice, if your use is suspected to be unsafe, unlawful, disruptive, or in violation of these Terms.

8) Limitation of Liability

To the maximum extent permitted by law:

Anthem Coffee is not liable for any damages, losses, or claims arising from use of the Service, including data loss, device compromise, security incidents, or service interruptions.

9) Changes to These Terms

Anthem Coffee may update these Terms at any time. Continued use of the Service after changes means you accept the updated Terms.

Select “I Agree” to connect to Anthem Coffee Guest Wi‑Fi.

February 21, 2026
How I Prevented My Ubuntu Server from Crashing by Moving Docker to a Separate Drive
Every Linux server failure I’ve seen from disk issues starts the same way:

Root slowly fills up.

No alarms. No drama. Just creeping usage.

On this Ubuntu server, / was sitting at a safe percentage — but something wasn’t right. A quick disk usage scan showed the real issue:
```
/opt 141G
```
Large directories on root are a warning sign. And on Docker hosts, the usual culprit is container storage.

Rather than wait for the root filesystem to fill and crash services, I made a structural fix:

I moved Docker completely off the root disk.

Here’s how.

Why Moving Docker Matters

By default, Docker stores everything under:
```
/var/lib/docker
```
That includes:
- Images
- Containers
- Volumes
- Build cache
- Overlay filesystem layers
On active systems, this can grow into hundreds of gigabytes.

When root fills:
- Docker stops
- systemd fails
- Logs stop writing
- SSH may fail
- The server can become unstable
Best practice: separate OS storage from container storage.

The Proper Fix: Move Docker’s Data Root

Instead of deleting images repeatedly, the right solution is to move Docker’s data directory to a secondary disk.

In this case, the secondary drive was mounted at:
```
/mnt/1TB
```
The new Docker path:
```
/mnt/1TB/docker-data
```
Step-by-Step: Move Docker to Another Drive (Ubuntu)

Step 1 — Confirm the Secondary Drive Is Mounted

Verify mount:
```
df -h
```
Ensure your secondary disk appears mounted at your intended path.

Also confirm UUID-based mount in /etc/fstab:
```
cat /etc/fstab
```
This prevents mount issues after reboot.

Step 2 — Stop Docker
```
sudo systemctl stop docker
sudo systemctl stop docker.socket
```
Step 3 — Create the New Docker Directory
```
sudo mkdir -p /mnt/1TB/docker-data
sudo chown root:root /mnt/1TB/docker-data
sudo chmod 711 /mnt/1TB/docker-data
```
Step 4 — Copy Existing Docker Data

Preserve permissions and metadata:
```
sudo rsync -aP /var/lib/docker/ /mnt/1TB/docker-data/
```
Important: the trailing slash matters.

Step 5 — Configure Docker

Edit:
```
sudo nano /etc/docker/daemon.json
```
Add:
```
{
  "data-root": "/mnt/1TB/docker-data"
}
```
If you use GPU runtime, include those runtime settings as needed — but the only required change for relocation is "data-root".

Save the file.

Step 6 — Backup the Old Docker Directory
```
sudo mv /var/lib/docker /var/lib/docker.bak
```
This gives you rollback protection.

Step 7 — Start Docker
```
sudo systemctl start docker
```
Step 8 — Verify the New Location
```
docker info | grep "Docker Root Dir"
```
Expected:
```
Docker Root Dir: /mnt/1TB/docker-data
```
Step 9 — Clean Up After Verification

Once confirmed working:
```
sudo rm -rf /var/lib/docker.bak
```
Production-Safe Boot Protection

One critical issue many guides miss:

If Docker starts before the secondary drive mounts at boot, it may recreate /mnt/1TB/docker-data on root.

To prevent this, create a systemd override:
```
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo nano /etc/systemd/system/docker.service.d/override.conf
```
Add:
```
[Unit]
RequiresMountsFor=/mnt/1TB
```
Reload:
```
sudo systemctl daemon-reload
```
Now Docker will not start unless the drive is mounted.

Final Result

After this change:
- Root remains stable
- Docker storage is isolated
- Disk growth is predictable
- Server stability improves significantly
This is not a cleanup tactic — it’s structural infrastructure design.

Takeaway

If you run Docker on Ubuntu and care about uptime:
- Do not let /var/lib/docker live on root.
- Use a separate mounted volume.
- Enforce mount dependency.
- Protect your OS partition.
Disk space issues don’t explode suddenly.

They accumulate quietly.

Separating Docker storage is one of the simplest and most effective ways to prevent a future outage.
February 19, 2026