I didn’t learn this until later, but this iMac was from 2011 and was running OSX 10.7 Lion. What I could tell pretty quickly though is that this wasn’t a recent iMac at all. That was a good sign, because I figured that would make it unlikely that there would be any disk encryption or extra security that would make it difficult to extract the data or crack the password.

I was able to get to a boot menu with a little bit of trial and error. Turns out it only comes up if you hold the option key during boot from fully powered off, not after triggering a restart from the login screen! I plugged in a live Fedora USB and had Linux running soon after.

Now if all we cared about was getting the files off the internal drive, I could have stopped here. The Gnome file browser had no trouble browsing the drive, but I wanted to see if we could do one better by getting into OSX. This grandfather was really into photography, and there would be something neat about seeing the computer running as he had kept it, tools and all.

A quick search showed that this version of OSX stores user password hashes in plist files located at /var/db/dslocal/nodes/Default/users/{username}.plist. From Linux I was able to send a copy of this file over to my main computer to work on it.

I found a pretty simple Python script online for extracting password hashes on OSX 10.15 Catalina. Lion uses the simpler SALTED-SHA512 format instead of the PBKDF2-SHA512 that was introduced in 10.8 Mountain Lion. After a few small changes I was able to come up with a modified script that would work for 10.7 Lion.

With the hash extracted, I installed hashcat to start cracking. The command I used is:

hashcat -m 1722 -a 0 hash.txt rockyou.txt

• The m flag specifies the hash type, which you can find in the hashcat documentation.
• The a flag specifies an attack mode. 0 corresponds to a straight dictionary attack, which is what I wanted since I suspected the password would be something simple.
• I used the popular rockyou wordlist for the same reason. If it failed, I could always try again with a custom wordlist.

After about two seconds (yes the password was that simple) I had the password! Embarrassingly, it was something we easily could have and should have guessed. But we didn’t, so my effort was for something at least.

When we logged in, all of Grandpa’s windows reopened as he had last had them which was a neat sight. We had a great time going through all the old photos the rest of the night.

— JP

Control’s issue is that after only a couple minutes the game stops loading high quality versions of textures for things like characters and important world details, reducing everything to about PS2 level quality.

It seems to be a problem with the game engine itself. Knocking the graphics settings down works temporarily but the blurry textures come back after only a few minutes. I’m running on an RX 6700 XT, a 12 GB card, so I’m pretty certain I’m not hitting a VRAM limit. Even if I was, I’d expect lowering the settings to be a permanent fix.

What worked for me

I downloaded and installed these two mods from Nexus Mods. Installation is simple, you just extract the zip contents to Control’s root directory.

• Loose Files Loader
• Tweakables

Next, paste this XML into Control\data\globaldb\tweakables.xml.

<tweakables>
	<tweakable type="float1" name="Texture Streaming:Max texture load time per update (ms)" value="100.000000"/>
	<tweakable type="float1" name="Texture Streaming:Max texture request time per update (ms)" value="10.000000"/>
	<tweakable type="int" name="Texture Streaming:Update Slices" value="1"/>
	<tweakable type="float1" name="Texture Streaming:Distance scale" value="0.250000"/>
	<tweakable type="float1" name="Texture Streaming:Mip target bias" value="0.500000"/>
	<tweakable type="int" name="Texture Streaming:Min Pool Size MB" value="2048"/>
	<tweakable type="int" name="Texture Streaming:Target texture pool size MB" value="4096"/>
	<tweakable type="int" name="Texture Streaming:Max Dropped Mips (Characters)" value="0"/>
	<tweakable type="int" name="Texture Streaming:Max Dropped Mips (Player)" value="0"/>
	<tweakable type="bool" name="LOD: Use ObjectScaleOverride" value="1"/>
	<tweakable type="float1" name="LOD: ObjectScaleOverride" value="3.000000"/>
	<tweakable type="float1" name="Hierarchy LOD:Distance scale" value="3.000000"/>
</tweakables>

No, I haven’t got a clue what these settings are doing. I found them in a Reddit comment that I can’t for the life of me track down again, and you see now why I’m writing this post.

That should be all you need to do to apply the fix. If you’ve made it to the point in the game where you’ve cleansed your first control point (roughly 30-45 minutes in), a good quick way to test the fix is to go to the control point and switch between the different outfits. The new outfit textures should load in pretty quickly every time you switch. After applying the fix myself, I played for over an hour and never saw a blurry texture.

What didn’t work for me

I’m including these here because they may still be options to explore if you want to avoid modding the game for some reason.

It’s worth noting that my system has an Intel i5-13600K and an AMD Radeon RX 6700 XT.

Switching to DX11 mode

Control, at least on my system, defaults to using DX12. If you add -showlauncher to the game’s launch options, you’ll be shown a menu that allows you to run in DX11 mode when you start the game.

Some people report that switching to DX11 mode solves the blurry texture issue. I tried it for myself and DX11 mode ran significantly worse than DX12 on my system. There was lots of noticeable micro-stuttering and the game just felt a lot worse to play because of it, but your mileage may vary.

Disabling resizeable BAR

This is another option that people report some success with. You’ll have to look up the specific steps of how to do this depending on your GPU. On AMD, you need to change a couple of options in the BIOS to disable resizeable BAR.

I don’t know about you, but I wasn’t about to go changing BIOS settings to workaround an issue for one specific game so I didn’t even bother with this. Still, it might be something to try if you’ve exhausted other options and are bent on getting it to work.

A dumb closing thought

Why is gaming like this? This isn’t even close to my worst example. There’s one (not very old!) game whose executable I had to manually patch just to get launching on newer CPUs.

— JP

It turns out that it is! It may even be slightly more straightforward than you’d guess, but I still ran into enough snags during the setup that I figured it’d be useful to document.

What you’ll need

• Termux
• Markor (or any other text editor that will let you easily edit markdown files)

Setup Termux

If you haven’t used Termux before, one of the first things you’ll want to do is run termux-setup-storage. This will grant Termux access to your phone’s storage, which we’ll need later in order to clone our site somewhere where our text editor will be able to get to it.

You’ll also need to install git with pkg install git and Hugo with pkg install hugo.

Setup git

There’s one option that you’ll need to add to your git config in Termux, otherwise you’ll probably run into errors later on about an “unsafe repository”. From what I can tell, this has something to do with how Android or Termux is handling file ownership, though much more than that I don’t know.

You can get around this error by running git config --global --add safe.directory '*'. If you want to read up on why this safe directory check is in place, you can check the git documentation and this commit for more information. As long as you trust the files on your phone’s storage (I can’t think of a good reason why you wouldn’t), you should be safe adding this config option to bypass the safety check.

Clone your site

This step will obviously vary slightly depending on where you host your site’s repository. In my case, the git repository for my site is hosted on GitHub, and my preferred way of accessing it is through GitHub’s command line tool. Fortunately this is easy to install in Termux with pkg install gh. Once it’s installed, you should be able to authenticate normally with gh auth login.

Termux normally starts in its own internal directory which other apps can’t access, so you’ll need to navigate to somewhere in Android’s “external” storage where Markor or your chosen text editor will be able to make edits. On my Google Pixel, this is located at /storage/emulated/0/. Termux will only be able to access this if you’ve run the termux-setup-storage command from earlier.

You can clone your site anywhere under that directory that makes sense to you. For me, that was in the Documents directory.

Get ready to write

If you’re used to creating a new post with the hugo new command, you might notice that it fails with an error about being unable to obtain a build lock. This is because some commands cause Hugo to try to obtain an OS-level write lock on the .hugo_build.lock file, which here it’s unable to do either because of Android or Termux. My workaround is to create the new file manually and copy the frontmatter metadata from an existing post.

The hugo server and hugo build commands will also fail for the same reason, but these allow the build lock to be skipped by adding the --noBuildLock flag.

There’s a decent explanation of why this build lock exists on the Hugo support forum if you’d like to learn more about it. As long as you’re not running multiple instances of Hugo at the same time, I don’t believe you’ll run into issues disabling it.

Write and publish

Everything past this point should work as you’d expect it to. Just edit your post in Markor or whichever text editor you’ve chosen and publish it when you’re ready. You can even preview your site with hugo build (you may need the --noBuildLock flag mentioned earlier) and it works just as you’d expect it to.

My site gets built and deployed by Vercel automatically when I push to the main branch, so to publish all I have to do is create a new commit and push it. If your publishing process involves building locally then copying the files somewhere, I assume that would also work as expected since common tools like scp are available in Termux.

Final thoughts

Everything here is based on my experience with my Google Pixel running Android 15. The process should be identical or at least extremely similar on other Android phones. If you try this and find that it isn’t, feel free to reach out to me with the details and I’ll try to get them added!

— JP

There’s been quite a few posts going around from people sharing their self hosting setups. Here’s my setup, but since I’m still somewhat new to self hosting I’ll also add a few of my recommendations for those interested in joining in on the fun.

Purely Self Hosted Services

These are services I run from home on a Dell Optiplex (office PC) that was a lucky $5 find at a thrift store. With a Core 2 Duo, 8 GBs RAM, and my own 1 TB HDD, it’s plenty beefy and surely draws too much power for what I use it for.

Nextcloud

Nextcloud is a self hostable cloud storage solution, but it’s also a lot more than that. Sort of how Google has Drive, but also Photos, Calendar, Meet, etc. I use Nextcloud for backups, file sharing, and video calls with family.

Jellyfin

A simple but feature-rich media server. If you’ve heard of Plex, it’s the same thing but much faster and without all the nonsense.

VPS Services

These are services I run through a couple of rented VPSs. I’ve been using DigitalOcean for a couple of years and have been pretty happy with them. A VPS can offer a lot of the advantages of self hosting while also offloading some of the responsibility. If reliability is high-priority then a VPS can be a great option.

Gemini capsule

I use the static Agate gemini server – my top recommendation for anyone wanting to set up their own home on gemini.

RocketCaster

RocketCaster is a simple gemini service I wrote that brings podcastindex.org’s searchable podcast database to gemini.

See: gemini://rocketcaster.xyz

Snikket

An easy to setup server for the XMPP chat protocol. I’m the only user on it right now but it’s served me well in talking to folks on other servers.

Where to Get Started?

If you want to start playing around with self hosting, I would strongly recommend Nextcloud. It’s surprisingly easy to set up and maintain on Ubuntu with Snap. For as much crap as Snap gets in the desktop space it makes a lot of sense in cases like this. It’ll even take care of auto-updating for you by default – something that’s seriously helpful in the context of self hosting.

Nextcloud like I said is extremely versatile thanks to a wide range of installable extensions called apps. The one that I use the most is Talk which adds chat and video conferencing features. There are apps for almost anything you can think of like news readers, maps, calendars, contacts, forms, notes, mail, and more. There are few things you can self host that will give you as much utility as Nextcloud.

Gemini servers would also be a great place to start self hosting since they’re public, low-stakes, and can be comfortably run on the tiniest of computers.

Above all, just find something that you’ll find useful. The fun in self hosting for me is not building something or maintaining it but getting good use out of it. It’s the feeling of technological independence.

See this list on GitHub for ideas of services to self host

At the bottom of this post I’ll link to the XML files for the tasks I created in case anybody wants to import them.

Create a login task

Before anything else, you need to create a task that logs in to the Kasa API and gets a token. This token should be saved as a global variable so other tasks can make use of it.

You’ll need to create a few global variables:

• %TPLUSER - the email address used for your Kasa account
• %TPLPASS - the password for your Kasa account
• %TPLTERM - a version 4 UUID, you can generate one to use with an online tool or with the uuidgen command in Linux
• %TPLTOKEN - where the login token will be stored

With that done, you can start creating the login task.

Start with a Variable Set action. Name the variable %payload and set it to the following:

{ "method" :"login",
"params" : {
  "appType" :"Kasa_Android",
  "cloudPassword" :"%TPLPASS",
  "cloudUserName" :"%TPLUSER",
  "terminalUUID" :"%TPLTERM" } }

Next, create an HTTP Request action. Set the method to POST, the URL to https://wap.tplinkcloud.com, and the body to “%payload”.

Create a JavaScriptlet action next and give it the following code. This will extract the login token from the response and save it as a local variable.

var mtoken = JSON.parse(http_data).result.token;

The last thing to do is to use another Variable Set action to set the global %TPLTOKEN variable to %mtoken.

I don’t know how often this token expires, but you may want to create a profile that runs the login task on some sort of regular interval just in case.

Find your device IDs

To control a device you first need to know its ID. You can get a list of all of your devices by sending a POST request to https://wap.tplinkcloud.com?token={your-token-here} with the following data:

{ "method": "getDeviceList" }

Here is an example curl command that’ll do the trick. You may want to pipe it to jq to make the response more readable.

curl -X POST -H "Content-type: application/json" -d '{ "method": "getDeviceList" }' 'https://wap.tplinkcloud.com?token={your-token-here}'

Find whichever devices you want to control in Tasker in the response and make note of their device IDs. Save each device ID as a Tasker variable and call it something descriptive like %TPLLAMPID.

Create a device control task

Create a new task and add a Variable Set action. Call the variable %payload and set it to the following:

{"method":"passthrough", "params": {"deviceId": "%TPLDEVICEID", "requestData": "{\"system\":{\"set_relay_state\":{\"state\":0}}}" }}

Be sure to change %TPLDEVICEID to whatever you called the variable that contains your device ID. Also be sure to set the state to either 0 for off or 1 for on.

Next create an HTTP Request action and set its method to POST and its URL to https://wap.tplinkcloud.com?token=%TPLTOKEN. Set its body to %payload.

That should be it! If you run the task, you should see your device turn off or on depending on what you set the state in the payload to. If you need to debug, you can create a popup action with the text %http_data to see the response from the API.

Resources Used

• https://www.reddit.com/r/tasker/comments/czt93u/integrate_kasa_app_with_tasker/
• https://itnerd.space/2017/06/19/how-to-authenticate-to-tp-link-cloud-api-with-tasker/
• https://itnerd.space/2017/01/22/how-to-control-your-tp-link-hs100-smartplug-from-internet/

Explanation

I first took a look at Nextcloud a few months ago and decided it was a little much for what I needed. But needs change and since early last month I’ve been self-hosting my own Nextcloud instance on an old office computer.

Making my Nextcloud available from outside my network was less than straightforward due to the situation with my apartment internet. Basically, there’s another device between my router and the internet doing network address translation. This makes it either impossible or at least a big hassle for me to get my own public IP.

The way I chose to work around this was by setting up a VPS with a provider I’ve used before (DigitalOcean), configuring a Wireguard VPN server on it, and connecting to it from my machine hosting Nextcloud. My Wireguard server is configured to route all incoming web traffic to my Nextcloud server and my Nextcloud server is configured to route all outgoing traffic through my Wireguard server. The end result is that I’m now able to talk to my VPS and it’s as if I’m talking to my Nextcloud server.

Getting Started

There are a few guides on how to do this out there already, but there’s a few things I didn’t like about each one I looked at. I borrowed from a few different ones to come up with my current config which I’ve written about here.

The instructions below were written with Ubuntu in mind but they should be pretty general and work on most other Linux flavors. A lot of what’s in this guide will also need sudo privileges.

First thing you’ll want to do is of course get a VPS started. DigitalOcean and Linode are both popular providers that offer fairly cheap basic plans, though for this purpose you might be able to find an even cheaper option elsewhere. From now on I’m going to be referring to the VPS as the server and the machine you’re self-hosting from as the client.

Next you’ll want to install Wireguard, which most likely should be in your OS’s package repositories. Go ahead and do this on both the server and the client.

Generate Keys

Navigate to /etc/wireguard (or any other directory you would like to save your keys in) and run the following commands on both the server and the client to generate your public and private keys.

wg genkey | tee privatekey | wg pubkey > publickey

Server Configuration

Here’s my server config which I’ve saved as /etc/wireguard/wg0.conf.

[Interface]
PrivateKey = <server's private key>
Address = 10.10.92.2/32
ListenPort = <port you want to listen on>

PreUp = iptables -t nat -A PREROUTING -d <server's public ip> -p tcp --dport 80 -j DNAT --to-destination 10.10.92.1
PreUp = iptables -t nat -A PREROUTING -d <server's public ip> -p tcp --dport 443 -j DNAT --to-destination 10.10.92.1
PreUp = iptables -t nat -A POSTROUTING -o <your network interface, ex. eth0> -j MASQUERADE
PostDown = iptables -t nat -D PREROUTING -d <server's public ip> -p tcp --dport 80 -j DNAT --to-destination 10.10.92.1
PostDown = iptables -t nat -D PREROUTING -d <server's public ip> -p tcp --dport 443 -j DNAT --to-destination 10.10.92.1
PostDown = iptables -t nat -D POSTROUTING -o <your network interface, ex. eth0> -j MASQUERADE

[Peer]
PublicKey = <client's public key>
AllowedIPs = 10.10.92.1/32

Notice the PreUp and PostDown rules. These modify iptable rules when the wireguard connection goes up or down in order to forward incoming traffic to the client. Some guides I’ve seen online have these rules set up to forward ALL incoming traffic to the client, but I would strongly discourage that. Instead, you can use the rules that I have in this config to forward only the ports you intend to use. I have rules for ports 80 and 443 for http and https. You can modify these rules, remove them, or add more for your needs.

Next you’ll need to enable IP forwarding with the following command. You may also need to edit /etc/sysctl.conf to make the setting persistent.

sysctl net.ipv4.ip_forward=1

Client Configuration

The config file for the client is a bit simpler than the server. Save it as /etc/wireguard/wg0.conf.

[Interface]
PrivateKey = <client's private key>
Address = 10.10.92.1/32

[Peer]
PublicKey = <server's public key>
Endpoint = <server's ip address>:<ListenPort from server config>
AllowedIPs = 0.0.0.0/0
PersistentKeepAlive = 25  # necessary to keep the connection alive

You’ll need to add two iptable rules. Run the following commands and also add them to /etc/rc.local to make them permanent across reboots.

iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o <your network interface, ex. eth0> -j MASQUERADE

Like the server, you’ll also need to enable IP forwarding. Run the following command to do that. You might also need to edit your /etc/sysctl.conf to make it persist after a reboot.

sysctl net.ipv4.ip_forward=1

Testing It All Out

You can enable, start, and check the status of Wireguard with these commands on both the client and the server:

systemctl enable --now wg-quick@wg0
systemctl status wg-quick@wg0
wg show

If everything’s worked out you should be able to tell that the connection is active when you see a “latest handshake” and “transfer” in the output for “wg show”.

References

• https://www.kmr.me/posts/wireguard/
• https://hacdias.com/articles/2020/11/access-network-behind-cgnat/