
A thousand years ago these poems were meant to be *seen* on paper and *heard* aloud, not scrolled past as plain text. Tyokiie's new Chinese poetry feature tries to give them back some of that — every poem sits on its own ink-wash painting, you can find any poet or dynasty in a tap, and the most loved verses become quiet, ambient videos.

## An ink-wash reader for every poem

Open any poem and it appears on a misty landscape painted in the classical 水墨 (ink-wash) style — a different scene for each poem, drawn to match its mood. The verse is set large in a reading serif; the poet, dynasty and anthology sit under the title; the poem's themes hang as small chips at the foot of the page.

![The Tyokiie poem reader — a Tang poem on an AI-painted ink-wash backdrop](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/09/chinese-classical-poetry-reimagined-in-tyokiie/reader.png)

The whole corpus of the 唐诗三百首 (Three Hundred Tang Poems) is here, with thousands more Tang and Song poems available as small downloadable packs. Once a pack is on the phone it reads fully offline.

## Search by poet, title, or dynasty

The corpus is large, so search is built to match how people actually look for a poem — by who wrote it, by its title, or within a single dynasty. A field selector switches between **All / Author / Title**, and a dynasty filter narrows the search to one era.

![Faceted poetry search — filter by field and dynasty](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/09/chinese-classical-poetry-reimagined-in-tyokiie/search.png)

Under the hood it is a full-text index over every poem's title, body and poet. It also understands **both Simplified and Traditional characters** — type 靜夜思 or 静夜思 and you land on the same poem — and the whole interface is localized into 16 languages, so a reader anywhere can navigate it in their own.

## Ambient poetry videos

The most famous poems also become short, meditative videos: the ink painting drifts with a slow camera, the verse is brushed on column by column, snow or leaves fall, and a solo *guqin* plays underneath. They are made for the vertical screen — good for a quiet minute, or to fall asleep to.

<YouTube id="pX9fT85UT8A" />

## Painted by a small GPU in the next room

None of the artwork is stock. Each backdrop is generated locally with FLUX on a single RTX 3060 in the classical ink-wash style — the same on-prem pipeline we wrote about in [Now it paints Chinese ink landscapes on the same RTX 3060](/blog/2026/09/09-now-it-paints-chinese-ink-landscapes-on-the-same-rtx-3060/). The music is original, composed for each mood; the poems themselves are public-domain classics.

## Try it

The Chinese poetry feature is live now in Tyokiie on Google Play. Open **Explore → Poetry**, pick a dynasty, and start reading.

[Get Tyokiie on Google Play](https://play.google.com/store/apps/details?id=au.com.tyo.wiki.android)


4dc204d349828d72c7eb97c4beaddac076f659fee60145e253ca830ff2f80660

Tyokiie's new Chinese poetry feature: an ink-wash poem reader, search by poet, title or dynasty, and ambient guqin poetry videos.

Tyokiie now brings 唐诗三百首 and thousands more classical Chinese poems to your phone — each on an AI-painted ink-wash backdrop, searchable by poet, title, or dynasty, with ambient guqin poetry videos.

Chinese Classical Poetry, Reimagined in Tyokiie

{/* banner prompt: A soft matte clay-render 3D illustration, 16:9, of a parallel history timeline: rounded clay lanes flowing left to right with small clay portrait medallions and rounded bars marking reigns and lifetimes, a swirling terracotta Big-Bang burst with a small planet and moon on the left, classical columns and a pyramid through the middle, and a clean cream modern city silhouette on the right; palette of matte sage green, warm cream and terracotta orange with muted blue accents, soft studio shadows, gentle rim lighting, simple pale background, tactile plasticine texture, clean minimal composition, no text. */}

Reading an encyclopedia article tells you *what* happened. It rarely tells you what
was happening **everywhere else at the same time**. While Catherine the Great ruled
Russia, who sat on the throne in China, in Japan, in France? When did the first
pharaoh appear, and how long *after* the dinosaurs was that, really?

That question, *what else was happening then?*, is the whole idea behind the
**Parallel Timeline**, the flagship feature of
[Tyokiie](https://play.google.com/store/apps/details?id=au.com.tyo.wiki.android),
our offline-first reference app. It lays history out as a set of horizontal lanes so
you can read across cultures and across time at a glance.

## History, side by side

Open the timeline and you get a living chart of the past. Each **lane** is a region
or a theme: Europe, East Asia, the Middle East, plus Scientists, Composers, Rulers,
and more. Each **bar** is a reign or a life, drawn to scale on a shared year axis,
with a portrait pulled from Wikimedia Commons. Scroll left and right through the
centuries; pinch to zoom; drag with two fingers to make the lanes taller when you
want more detail.

![The Parallel Timeline in History view: reigns across Europe, East Asia and the Middle East, side by side around 1770.](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/08/introducing-the-parallel-timeline/parallel-timeline-history.png?height=520)

Suddenly the connections jump out. In 1770, Catherine II of Russia, George III of
Great Britain, Louis XV of France, the Qianlong Emperor of China and Yeongjo of
Joseon were **all reigning at once**, a fact that is obvious on a parallel timeline
and nearly invisible in a stack of separate articles.

Tap any bar and a summary card slides up: a portrait, the dates, a one-line
description, and a button to **read the full article** right there in the app.

![Tapping an entry opens a summary card, here Catherine II of Russia (1762 to 1796), with a portrait and a link to the full article.](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/08/introducing-the-parallel-timeline/parallel-timeline-card.png?height=520)

## Two ways to look at time

History has a scale problem. If you draw the last 400 years and the Big Bang on the
*same* ruler, one of them becomes an invisible sliver. So the Parallel Timeline gives
you **two modes**, and a single tap switches between them:

- **History view** — a normal, evenly-spaced year axis, now stretching all the way
  back to **3400 BC**, the dawn of the written record. Egyptian dynasties,
  Mesopotamian city-states, medieval rulers and the modern era, all on one line.
- **Cosmic view** — a **logarithmic** axis that plots *years before present*, so the
  whole of time fits on one screen: the **Big Bang (~13.8 billion years ago)**, the
  formation of the Earth and Moon, the Cambrian explosion, the age of dinosaurs, the
  rise of mammals, and the emergence of *Homo sapiens*, right up to the present day.

![Cosmic view: a logarithmic deep-time axis. The Moon forms 4.5 billion years ago, primates 60 million years ago, agriculture around 10000 BC, all above recorded history.](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/08/introducing-the-parallel-timeline/parallel-timeline-cosmic.png?height=520)

In Cosmic view the deep-time lanes — **Cosmos, Life on Earth, Human Evolution,
Religions** — rise to the top, and dates read the way you actually think about them:
*"4.5 billion years ago," "66 million years ago," "300,000 years ago."* It is the
"cosmic calendar," but interactive, and in your pocket.

## Built the way we build everything

The Parallel Timeline reflects the principles behind the whole app:

- **Offline-first.** The timeline data — hundreds of entries across dozens of lanes,
  curated from **Wikidata** and illustrated from **Wikimedia Commons** — is bundled
  right into the app. No account, no cloud, no waiting.
- **Straight to the source.** Every entry links to its full **Wikipedia** article, so
  a moment of curiosity is one tap from the real thing. (The same offline article
  engine we wrote about in
  [Using Tyokiie for Offline Wikipedia Searching and Viewing](/blog/using-tyokiie-for-offline-wikipedia-viewing/).)
- **Speaks your language.** Lane names, entity titles and descriptions are localized
  into **15 languages** — read the timeline in English, 中文, Español, Français, 日本語
  and more, and jump to the matching-language article.
- **Yours to shape.** A filter lets you choose exactly which lanes and which countries
  appear, so you can focus on the Roman world, or East Asian dynasties, or just the
  composers — whatever you are exploring today.

## Try it

History isn't a list, it's a landscape. The Parallel Timeline lets you stand back and
see the shape of it, then dive into any moment that catches your eye.

You can install Tyokiie from the
[Google Play Store](https://play.google.com/store/apps/details?id=au.com.tyo.wiki.android).
Then tap **Explore → Parallel Timeline**, and switch on **Cosmic view** to travel from
the Big Bang to this morning. We would love to hear which unexpected "they were alive
at the same time?!" moment you find first.

*— The TYO Lab team*


ec2b2398b23c9b85fb9f6aac7d5bd7036ef6b08309d7fb984955844c4c13d5b8

The Parallel Timeline in Tyokiie, our offline-first reference app, charts history as side-by-side lanes with two modes: a linear view back to 3400 BC and a logarithmic cosmic view stretching from the Big Bang to the present day.

Tyokiie's flagship feature lays history out as parallel horizontal lanes, so you can see who ruled where at the same moment, from the Big Bang all the way to today, entirely offline.

Introducing the Parallel Timeline: See History Side by Side, from the Big Bang to Today

{/* banner prompt: Clean isometric diorama of a miniature factory on a white background, where a stylized Go gopher guides a block representing a Go binary through a series of gates labeled 'Linker', 'Alignment', and 'Package' into a sleek Android phone model, minimalist, crisp shadows, material design color palette, 16:9. */}

We're building an Android VPN app that needs a Go binary — a packet-forwarding proxy that runs as a subprocess, owns the TUN file descriptor, and handles all the network I/O. Simple enough in theory: cross-compile Go for arm64, pack it into the APK, exec it at runtime.

In practice we hit three separate problems, each invisible until it wasn't. This post documents all three: what the failure looked like, why it happens, and exactly what to change.

## Trap 1: `GOOS=linux` produces a binary Android can't run

The first sign of trouble is a logcat line that reads something like:

```
java.io.IOException: Cannot run program "/path/to/binary": error=2, No such file or directory
```

The binary is *there*. The path is correct. The file exists. Android still says it doesn't.

The reason is the ELF interpreter line. Every dynamically-linked ELF binary on Linux carries a `PT_INTERP` segment that names the dynamic linker the OS should use to start the program. On a Linux server or desktop, that path is typically:

```
/lib/ld-linux-aarch64.so.1
```

That path doesn't exist on Android. Android ships its own linker at:

```
/system/bin/linker64
```

When the OS tries to exec your binary, it reads the interpreter path from the ELF header. If that path doesn't resolve, execve returns `ENOENT` — "no such file or directory" — even though the binary itself is sitting right there. The error is about the *linker*, not the binary.

**The fix:** use `GOOS=android`, not `GOOS=linux`, when cross-compiling for arm64.

```sh
CGO_ENABLED=0 GOOS=android GOARCH=arm64 \
  go build -trimpath -buildmode=pie \
  -ldflags="-s -w" \
  -o libreachproxy.so .
```

With `GOOS=android`, Go produces an ELF with `/system/bin/linker64` in the interpreter slot. Android finds it, loads it, and your binary starts.

You can verify before deploying:

```sh
readelf -l your_binary | grep interpreter
# Good:  [Requesting program interpreter: /system/bin/linker64]
# Bad:   [Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
```

### What about x86_64?

`GOOS=android GOARCH=amd64` doesn't work without CGO external linking — which requires the Android NDK. If you don't have the NDK in your build environment, you're stuck. For x86_64 (emulators only; no real Android phone ships x86_64), `GOOS=linux` is acceptable — the emulator kernel is lenient enough. Just don't use it for arm64 on real devices.

## Trap 2: Android 16 requires 16 KB page alignment

Android 16 — shipping on Samsung Galaxy S25 and other devices with newer Arm chips — increased the memory page size from 4 KB to 16 KB. If your native binary isn't aligned to 16 KB page boundaries, Android 16 won't load it.

Google Play enforces this at upload time too. You'll see a warning (soon an error) in the Play Console if any `.so` in your APK or AAB fails the alignment check.

**For arm64:** Go's PIE binaries built with `GOOS=android GOARCH=arm64` default to 64 KB alignment, which already satisfies the 16 KB requirement. No extra flag needed.

**For x86_64:** Go's default alignment is 4 KB. You need to force 64 KB (which also satisfies 16 KB) via the linker flag `-R 0x10000`:

```sh
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
  go build -trimpath -buildmode=pie \
  -ldflags="-s -w -R 0x10000" \
  -o libreachproxy_x86_64.so .
```

The `-R 0x10000` flag sets the ELF segment alignment to 65536 bytes (64 KB). Play Store's checker accepts anything ≥ 16 KB.

### Why `-buildmode=pie`?

Android requires all natively-executed code to be position-independent. Without `-buildmode=pie`, Go produces an `ET_EXEC` (fixed-address) binary, which Android won't exec. With `-buildmode=pie`, you get an `ET_DYN` (position-independent) executable that Android's linker is happy to load anywhere in the address space.

## Trap 3: Play Store AAB delivery may not extract your `.so` to disk

Here's the sneaky one.

The standard approach for shipping a native binary in an APK is to put it in `jniLibs/<abi>/`, rename it with a `.so` extension (so the build system includes it), and read its path from `applicationInfo.nativeLibraryDir` at runtime.

```kotlin
val binary = "${applicationInfo.nativeLibraryDir}/libreachproxy.so"
ProcessBuilder(binary, ...).start()
```

This works fine when you sideload the APK directly. On older Android versions it also works for Play Store installs — the system extracts `.so` files to `nativeLibraryDir` during installation.

On Android 16 with Play Store's AAB (App Bundle) delivery, the system may skip that extraction entirely. The `.so` is never written to `nativeLibraryDir`. Your `File(binary).exists()` check passes the sanity check but the file is empty, or the path simply doesn't exist at all. The exec fails silently.

**First fix: `useLegacyPackaging = true`** in your `build.gradle.kts`. This tells the build system to store the `.so` uncompressed in the APK, so Android can extract it on install:

```kotlin
packaging {
    jniLibs {
        useLegacyPackaging = true
    }
}
```

This restores the old extraction behaviour for direct APK installs.

**Second fix: `memfd_create` fallback** for Play Store AAB installs where extraction is still skipped. Bundle the arm64 binary in `assets/` and load it into an anonymous memory file using `Os.memfd_create`. Execute it via `/proc/self/fd/<n>`:

```kotlin
private fun ensureBinary(): String {
    val nativePath = "${applicationInfo.nativeLibraryDir}/libreachproxy.so"
    if (File(nativePath).exists()) return nativePath

    // Play Store AAB on Android 16: nativeLibraryDir wasn't populated.
    // Load from assets into a memfd and exec via /proc/self/fd/<n>.
    val bytes = assets.open("libreachproxy").use { it.readBytes() }
    val fd = Os.memfd_create("libreachproxy", 0)
    var offset = 0
    while (offset < bytes.size) {
        offset += Os.write(fd, bytes, offset, bytes.size - offset)
    }
    val fdInt = FileDescriptor::class.java
        .getDeclaredField("descriptor")
        .apply { isAccessible = true }
        .getInt(fd)
    return "/proc/${Os.getpid()}/fd/$fdInt"
}
```

`memfd_create` creates an anonymous file in memory — no filesystem, no SELinux exec restriction. The `/proc/self/fd/<n>` path is a valid executable path that the kernel accepts for `execve`. The `fd` reference is kept alive for the lifetime of the service so the kernel doesn't reclaim the memory.

`Os.memfd_create` requires API level 30 (Android 11). If you still support API 26–29, you'll need a fallback for that too (writing to `codeCacheDir` and calling `chmod 700`, accepting that Samsung SELinux may still block it on some devices).

## Putting it together

A minimal build script that avoids all three traps:

```sh
#!/usr/bin/env bash
set -euo pipefail

OUT="app/src/main/jniLibs"
mkdir -p "$OUT/arm64-v8a" "$OUT/x86_64"

# arm64: GOOS=android for the correct ELF interpreter.
# 64KB alignment is the default — satisfies Android 16's 16KB requirement.
CGO_ENABLED=0 GOOS=android GOARCH=arm64 \
  go build -trimpath -buildmode=pie -ldflags="-s -w" \
  -o "$OUT/arm64-v8a/libreachproxy.so" .

# x86_64: GOOS=linux (android/amd64 requires CGO external linking without NDK).
# -R 0x10000 forces 64KB alignment to satisfy Play Store's 16KB check.
# x86_64 is emulator-only — no real device uses it.
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
  go build -trimpath -buildmode=pie -ldflags="-s -w -R 0x10000" \
  -o "$OUT/x86_64/libreachproxy.so" .

# Also copy arm64 binary to assets/ for the memfd fallback path.
cp "$OUT/arm64-v8a/libreachproxy.so" app/src/main/assets/libreachproxy
```

And in `build.gradle.kts`:

```kotlin
packaging {
    jniLibs {
        useLegacyPackaging = true
    }
}
```

## Quick reference

<Table data={
    {
        headers: ['Problem', 'Symptom', 'Fix'],
        rows: [
            ['Wrong GOOS for arm64', 'error=2 ENOENT on exec even though the file exists', 'GOOS=android GOARCH=arm64'],
            ['4 KB page alignment', 'Play Store upload warning; crash on Android 16', '-buildmode=pie (arm64 default is fine); -R 0x10000 for x86_64'],
            ['AAB delivery skips extraction', 'nativeLibraryDir is empty after Play Store install', 'useLegacyPackaging=true + memfd_create fallback'],
        ]
    }
} />

None of these are obvious until you've hit them. The `GOOS=linux` trap is particularly nasty because the binary runs perfectly in your CI and on the emulator — it only fails on a real device with a strict kernel, which is usually the last place you test.


5f6ebea443bb89c3641ee31d52cb3ce97211e0c406c6070d6e92207477385e66

What we learned cross-compiling Go for Android: the ELF linker trap, 16KB page alignment for Android 16, and the memfd fallback for Play Store AAB delivery.

Building an Android VPN app that bundles a Go binary exposes you to three traps in quick succession: compiling for Linux instead of Android, Android 16's 16 KB page-alignment requirement, and Play Store delivery no longer extracting native libraries to disk. Here's what each one looks like and how to fix it.

Shipping a native Go binary inside an Android APK: ELF linkers, 16 KB pages, and the memfd trick

{/* banner prompt: Of course! Here are a few creative and engaging prompts for a banner image, designed to capture the essence of the blog post.

### Main Prompt (Cinematic & Evocative)

This prompt focuses on the "resurrection" theme of bringing old hardware back to life with modern, efficient software.

**Prompt:**
> A cinematic, dramatic shot of a dusty, forgotten 90s-era beige PC tower sitting on a workbench in a dimly lit workshop. A brilliant, glowing blue USB cable connects a modern Android smartphone to the PC's front port, acting as a lifeline. Ethereal, glowing data streams, shaped subtly like the Alpine Linux mountain logo, emanate from the PC's vents, illuminating the scene and casting long shadows. The old machine hums with new purpose, transformed into a powerful network gateway. Moody, high-contrast lighting, tech noir aesthetic, hyper-realistic, 8k. --ar 16:9

---

### Alternative Prompts

Here are two other options with different artistic styles.

#### Option 2 (Technical & Stylized)

This prompt emphasizes the technical, blueprint-like nature of the project.

**Prompt:**
> A stylized, futuristic blueprint schematic on a dark grid background, illustrating the post's network topology. At the top, a sleek icon of an Android phone connects via a glowing USB data line to a central, semi-transparent block representing an old computer. The iconic Alpine Linux mountain logo glows brightly from within this central block. From the block, a solid ethernet data stream flows out to a home router icon. The entire image has a clean, technical, and cyberpunk feel, with digital annotations and connection labels. Widescreen, vector illustration style, highly detailed. --ar 16:9

#### Option 3 (Minimalist & Symbolic)

This prompt focuses on the core components in a clean, modern, and symbolic way.

**Prompt:**
> A minimalist composition on a clean, dark grey background. In the center, a simple, iconic representation of an old PC case is given new life. A single, vibrant cyan USB cable plugs into it from one side, originating from an abstract smartphone shape. From the other side, a stable, glowing ethernet cable extends outwards. The Alpine Linux mountain symbol is subtly but clearly etched onto the side of the PC case, glowing with a soft white light. The image conveys elegance, efficiency, and the concept of "powerful simplicity." Professional product shot style, soft studio lighting. --ar 16:9 */}

# Building a 4G/5G Backup Mobile Gateway with Alpine Linux on Old Hardware

*How to repurpose an outdated PC into a reliable backup internet gateway using Android USB tethering*

---

## The Problem

Internet goes down. It always does at the worst possible time. However, even though that only happens a couple of times a year, an always-on 4G/5G backup isn't strictly necessary. It would be nice to have a plug-and-play solution—like using your phone (which probably has plenty of data) as a rescue for those few hours of downtime.

If you have a spare Android phone and an old PC gathering dust, you can build a proper backup gateway that kicks in when your main connection fails — no expensive hardware required.

This guide walks through the entire process, including the real-world gotchas encountered along the way.


## Hardware Requirements

- An old/low-powered PC (sub 1GHz, even under 512MB RAM is workable)
- One or two ethernet NICs (two is ideal, one works fine)
- A USB port for the Android phone
- An Android phone with a mobile data plan
- A USB stick (2GB+ is plenty) to install from

For this project, I used a rugged industrial PC made by **Advantech Australia**. It's equipped with an **Intel Atom D510 CPU** and **2GB of memory**. Its industrial build and dual NIC cards make it a perfect "warhorse" for a dedicated gateway role. 

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/04/repurpose-your-old-pcs-how-to-install-alpine-linux-on-them/2026-04-20-19-42-33.png)

The machine used in this guide had two onboard NICs, an 8GB internal flash module (DOM — Disk on Module), and a larger hard drive set aside for backups. Very modest specs, perfectly adequate for a router role. Please execute me for the dust collected on this machine.


## Why Alpine Linux?

For low-powered hardware doing a single job, Alpine Linux is the right tool:

- Boots in under 5 seconds
- Idles at ~30–50MB RAM
- Tiny base install (~130MB on disk)
- Uses OpenRC (no systemd overhead)
- The `rndis_host` kernel module handles Android USB tethering natively — no extra drivers needed
- Actively maintained, security-focused

Other options like Debian minimal or OpenWrt on x86 are also viable, but Alpine wins on resource footprint for truly constrained hardware.


## Network Topology

With two NICs the setup is clean — no double-NAT:

```
Android Phone (USB tethering)
        |
        | usb0
  [Alpine Linux PC]
   eth0  |  eth1
    |         |
Your Router  (spare / unused)
 (WAN port)
```

With a single NIC, the same approach works — `eth0` connects to your router's WAN port, `usb0` is the phone. Your router handles the LAN side as normal. The Alpine box just NATs between `usb0` and `eth0`.

> **Note on double-NAT:** With a single NIC and a typical home router, you'll have three layers of NAT (phone → Alpine → router). For general internet use this is completely fine. Port forwarding gets complicated, but for a backup scenario it's a non-issue.


## Step 1: Creating the Install USB

Download the Alpine Linux "standard" x86 ISO from [alpinelinux.org](https://alpinelinux.org/downloads/).

Write it to a USB stick using `dd`:

```bash
dd if=alpine-standard-x.x.x-x86.iso of=/dev/sdX bs=4M status=progress
```

Replace `/dev/sdX` with your USB stick's device. **Double-check this** — `dd` will happily wipe whatever you point it at.

> **Important:** Use `dd` directly, or Rufus in **DD mode** if on Windows. Do not let Rufus create a FAT32 partition layout — old BIOSes can choke on it. Alpine ISOs are hybrid MBR images and work correctly when written raw.


## Step 2: BIOS Boot Gotchas (American Megatrends)

Old AMI BIOS boards have a few quirks that can stop USB boot from working even when USB is set as first priority:

- **Plug the USB in before powering on.** USB drives often only appear in the boot device list if they're present at POST time.
- **Check for two separate boot priority menus.** AMI BIOS often has a top-level device-type priority (Removable → HDD → CD) *and* a separate submenu for ordering within each type. The USB stick needs to be first in *both* places.
- **Enable Legacy USB Support** — usually found under Advanced or Integrated Peripherals.
- **Use a rear USB 2.0 port.** Front panel ports and USB 3.0 ports are often ignored by old BIOSes during boot enumeration.
- **Use a USB 2.0 flash drive** if possible. USB 3.0 sticks can fail to enumerate on old BIOSes.
- **Try the one-time boot menu first** — on most AMI boards, hit **F8** or **F11** at POST. This bypasses the boot order entirely and lets you pick the USB stick directly, which is useful for confirming the stick itself is bootable before adjusting BIOS settings.

In my case, I was finally able to have it boot into the Alpine Linux installation interface after plugging the USB drive into the back (rear) of the machine.

---

## Step 3: Identifying Your Disks

Once booted into the Alpine live environment, identify your drives before installing:

```sh
cat /proc/partitions
```

Example output:

```
8    0  312571224  sda     ← ~150GB (Windows drive)
8   16    7880544  sdb     ← ~7.5GB (target install drive)
8   32    3910656  sdc     ← ~3.7GB (Alpine USB stick)
```

To confirm the nature of a drive — particularly whether it's a USB device or an internal flash module:

```sh
dmesg | grep sdb
```

If the output references `sd X:X:X:X` (SCSI enumeration) rather than `usb-storage`, the drive is connected internally — likely a DOM (Disk on Module), common on older appliance-grade hardware. These are perfectly fine for Alpine and handle the low write workload of a router OS well.

> **Tip:** A drive formatted as FAT32 with write cache disabled and a single partition spanning the whole disk is a typical signature of a factory-installed DOM or embedded flash device.

---

## Step 4: Installing Alpine

Run the setup script:

```sh
setup-alpine
```

Work through the prompts:

- **Keyboard layout:** your preference
- **Hostname:** something useful, e.g. `mobile-gateway`
- **Network interface:** configure `eth0` for DHCP during install; skip `eth1` for now
- **Root password:** set something strong
- **Timezone:** your local timezone
- **NTP client:** choose **chrony** (see note below)
- **Mirror:** pick a geographically close one or `r` for auto-detect
- **SSH:** `openssh` is fine
- **Disk mode:** type `sys` — this is a standard permanent install to disk
- **Which disk:** type the device name of your target drive (e.g. `sdb`)

The installer will wipe the selected disk and install Alpine. When finished, remove the USB stick and reboot.

### Why chrony for NTP?

For a machine that's offline frequently or has intermittent connectivity — exactly the backup router use case — chrony is the best choice. It handles time jumps gracefully when connectivity comes and goes, and compensates for clock drift between connections. `busybox-ntpd` is too basic for this, and `openntpd` handles irregular connectivity less gracefully than chrony.

---

## Step 5: Post-Install — Making It Boot

If the machine boots back into another OS after install, the BIOS is still preferring the wrong drive. Go back into BIOS and find the **Hard Disk Drive Priority** submenu — set your Alpine drive (the 8GB/DOM one) as first in that list.

Use the one-time boot menu (F8/F11) to test first — select your Alpine drive directly to confirm it boots before making the BIOS change permanent.

---

## Step 6: Configuring USB Tethering

Plug in the Android phone and enable **USB Tethering** from the phone's settings (usually under Settings → Network → Hotspot & Tethering).

The Alpine kernel will load `rndis_host` automatically and a new interface will appear — typically `usb0`:

```sh
ip link show
```

Bring it up and get an IP via DHCP from the phone:

```sh
udhcpc -i usb0
```

Test connectivity:

```sh
ping -c 3 1.1.1.1 -I usb0
```

---

## Step 7: NAT and IP Forwarding

Install iptables if not already present:

```sh
apk add iptables
```

Enable IP forwarding:

```sh
echo 1 > /proc/sys/net/ipv4/ip_forward
```

Set up NAT (assuming `usb0` = WAN, `eth0` = LAN out to router):

```sh
iptables -t nat -A POSTROUTING -o usb0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o usb0 -j ACCEPT
iptables -A FORWARD -i usb0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
```

Make IP forwarding persistent — add to `/etc/sysctl.conf`:

```
net.ipv4.ip_forward = 1
```

Save and persist iptables rules across reboots:

```sh
rc-update add iptables
/etc/init.d/iptables save
```

---

## Step 8: Hotplug Script (Plug In and It Just Works)

Rather than running commands manually every time, Alpine's `mdev` can detect when the phone is plugged in via USB and automatically bring up the tethering interface and routing.

Create `/etc/mdev/usb-tether.sh`:

```sh
#!/bin/sh
# Called by mdev when a USB network interface appears

IFACE="usb0"

if [ "$ACTION" = "add" ] && ip link show "$IFACE" > /dev/null 2>&1; then
    udhcpc -i "$IFACE" -q
    iptables -t nat -A POSTROUTING -o "$IFACE" -j MASQUERADE
    iptables -A FORWARD -i eth0 -o "$IFACE" -j ACCEPT
    iptables -A FORWARD -i "$IFACE" -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
fi
```

Make it executable:

```sh
chmod +x /etc/mdev/usb-tether.sh
```

This gives you plug-in activation — connect the phone, USB tethering enables on the phone, and the gateway comes up automatically. Unplug to deactivate.

---

## Second NIC — What to Do With It

If your machine has two NICs, you have more flexibility:

- **eth0** — connect to your router's WAN port (LAN out)
- **eth1** — leave unconfigured unless you need a second downstream device connected directly

There's no need to bridge or assign an IP to `eth1` for a basic single-router setup. Leave it unconfigured and use it later if needed.

---

## Summary

{/* | Component | Choice | Reason |
|-----------|--------|--------|
| OS | Alpine Linux | Minimal footprint, fast boot, good hardware support |
| NTP | chrony | Handles intermittent connectivity gracefully |
| Tethering | Android USB (rndis_host) | Native kernel support, no extra drivers |
| Install mode | sys | Standard permanent disk install |
| Activation | mdev hotplug | Plug-in and it just works | */}

The end result is a machine that sits quietly on the shelf, draws minimal power, and becomes a functional mobile gateway the moment you plug a phone into it — no GUI, no fuss, no expensive hardware.

---

*Built and tested on an old low-powered PC with AMI BIOS, dual onboard NICs, and an internal DOM flash drive. Alpine Linux 3.x.*

2c3a46c60c6e9cc4ef710506425dabc985899f2bfc048c9968ed99cf2fe490db

A step-by-step guide to installing Alpine Linux on old, low-powered hardware and configuring it as a mobile backup gateway using Android USB tethering. Covers BIOS quirks, disk identification, NAT/iptables setup, and hotplug automation with mdev.

Turn an old, dusty PC into a reliable 4G/5G backup internet gateway using Alpine Linux and Android USB tethering — no expensive hardware required.

Repurpose Your Old PCs: How To Install Alpine Linux on Them

{/* banner prompt: Of course! Based on the blog post, here are three creative and engaging banner image prompts, each with a different artistic direction. They all capture the core idea of using a phone as a clever, cost-effective backup internet solution.

---

### Option 1: The Digital Lifeline (Conceptual & Dynamic)

**Prompt:**

A dynamic, conceptual illustration of network failover. In the center, a large, futuristic fiber-optic data highway is visibly broken and dark, representing a failed primary internet connection. From the side, a glowing green USB cable connects a modern Android smartphone to a small, sleek mini-PC. This connection creates a vibrant, glowing data bridge that bypasses the broken highway, seamlessly redirecting streams of light (data packets) to a small office network. The scene is set in a dark, tech-themed environment with blue and green neon accents. Style: digital art, high detail, cinematic lighting. **--ar 16:9**

**Why it works:** This prompt visualizes the core concept of a "backup bridge" in a dramatic and futuristic way. The contrast between the broken primary path and the active mobile lifeline makes the solution's purpose instantly clear.

### Option 2: The Smart Switch (Infographic & Clean)

**Prompt:**

A sleek, futuristic infographic-style artwork. Visualize two incoming data streams: a massive, primary blue stream labeled "WAN" that is flickering and disrupted, and a secondary, vibrant green stream originating from an Android phone, labeled "Mobile Backup". Both streams converge on a central, intelligent cube-like gateway device featuring a subtle Alpine Linux penguin logo. The gateway is actively routing the green stream forward, while the blue stream is blocked. The background is a clean, dark gray with a digital grid pattern. The entire image has a clean, high-tech aesthetic with glowing lines and crisp vectors. **--ar 16:9**

**Why it works:** This prompt focuses on the "intelligence" of the solution. It presents the Alpine Linux box as the central brain making a smart decision, which aligns perfectly with the technical, how-to nature of the blog post.

### Option 3: The DIY Hero (Photorealistic & Relatable)

**Prompt:**

A photorealistic shot of a modern tech enthusiast's desk. In the foreground, a compact mini-PC (like an Intel NUC) is the hero, with a subtle Alpine Linux logo visible on a tiny monitor next to it. A braided USB-C cable connects the PC to an Android smartphone, its screen showing the 'USB Tethering Active' notification. Glowing ethernet ports show data flowing out. In the soft-focus background, a primary internet router is clearly visible with a blinking red warning light, indicating an outage. The mood is resourceful and clever, with warm, focused lighting on the foreground setup. **--ar 16:9**

**Why it works:** This prompt grounds the concept in reality, showing the actual components described in the article. It creates a relatable, "I can build that" feeling and highlights the cost-effective, DIY spirit of the solution.

Additional instructions: a flying angel holding a mobile phone */}

## The Problem

For small businesses and home offices, internet downtime is painful. When your primary NBN connection goes down — whether it's a cable fault, an ISP outage, or a modem failure — everything grinds to a halt. Emails stop, video calls drop, cloud tools become unreachable.

The obvious fix is a backup WAN connection, but most solutions involve:
- A dedicated 4G/5G router (~$200–$500)
- A second SIM card with a separate data plan (~$20–$50/month)

That's recurring cost for something you only need occasionally.

## The Better Solution: Use Your Existing Phone

Here's the insight: you almost certainly already have a mobile phone on a plan that includes data. When NBN goes down, that phone in your pocket already *is* a backup internet connection — you just need a way to share it with your whole network instead of just your phone.

Android's **USB tethering** feature turns your phone into a USB network adapter. Plug it into a Linux box and it appears as a regular ethernet interface (`usb0`). From there, you can route your entire network's traffic through it.

**What this costs you:**
- An old PC, mini PC, or single-board computer (even a Raspberry Pi works) — something you may already have spare
- A USB cable
- Your existing phone and mobile plan
- No extra SIM, no extra monthly bill

## Architecture

The setup uses a dedicated Alpine Linux box (we'll call it `mg`) sitting on your LAN alongside your primary NBN router.

```
Normal (NBN up):
  Clients → mg (192.168.8.99) → NBN router (192.168.8.1) → Internet

Failover (NBN down):
  Clients → mg (192.168.8.99) → usb0 (Android phone) → Mobile Internet
```

Clients point their default gateway to `mg`. When NBN is up, `mg` transparently forwards traffic to the NBN router. When NBN fails, you run one command on `mg` and it switches to routing via the phone. Clients don't change anything.

## Requirements

- A PC or mini box with at least one ethernet port, running **Alpine Linux**
- An **Android phone** with USB tethering capability (virtually all modern Android phones)
- A USB cable (USB-A to USB-C or Micro-USB depending on your phone)
- SSH access to the Alpine box

## Step 1: Install iptables

Alpine Linux is minimal by default. Install `iptables` for NAT:

```bash
sudo apk add iptables
```

## Step 2: Enable IP Forwarding

The box needs to forward packets between interfaces like a router:

```bash
echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.d/99-forwarding.conf
sudo sysctl -w net.ipv4.ip_forward=1
```

## Step 3: Add USB Interface to Network Config

When Android USB tethering is active, it appears as `usb0`. Tell Alpine to obtain a DHCP address from the phone on that interface:

```bash
sudo tee -a /etc/network/interfaces > /dev/null << 'EOF'

# USB tethering (Android backup WAN)
iface usb0 inet dhcp
EOF
```

The kernel modules `rndis_host` and `cdc_ether` handle Android USB tethering. On a standard Alpine install with a reasonably modern kernel, these are already present and loaded automatically when the phone is plugged in with tethering enabled.

## Step 4: iptables Rules at Boot

Create a startup script that sets up NAT and forwarding rules every time the machine boots:

```bash
sudo tee /etc/local.d/wan-setup.start > /dev/null << 'EOF'
#!/bin/sh
# WAN gateway iptables setup

sysctl -w net.ipv4.ip_forward=1

# FORWARD chain — drop by default, allow LAN traffic out via either WAN
iptables -P FORWARD DROP
iptables -F FORWARD
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o usb0 -j ACCEPT

# NAT — masquerade outbound on both WAN paths
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -o eth0 ! -d 192.168.8.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o usb0 -j MASQUERADE
EOF

sudo chmod +x /etc/local.d/wan-setup.start
sudo rc-update add local default
```

Apply the rules immediately without rebooting:

```bash
sudo sh /etc/local.d/wan-setup.start
```

**Why MASQUERADE on `eth0`?** When `mg` forwards a client's packet to the NBN router, without masquerading the source IP is the client's (e.g. `192.168.8.50`). The NBN router sends the reply directly back to that client, bypassing `mg` — breaking the connection tracking. MASQUERADE rewrites the source to `mg`'s own IP (`192.168.8.99`), so all return traffic flows back through `mg` correctly.

## Step 5: The Failover Script

This script handles detecting whether the primary WAN is up and switching routes accordingly. Save it to `/usr/local/bin/wan-failover.sh`:

```bash
sudo tee /usr/local/bin/wan-failover.sh > /dev/null << 'EOF'
#!/bin/sh
# wan-failover.sh — WAN failover between NBN (eth0) and USB tethering (usb0)
# Usage: wan-failover.sh [auto|primary|backup|status|check]

PRIMARY_GW="192.168.8.1"
LAN_IFACE="eth0"
USB_IFACE="usb0"
CHECK_HOST="8.8.8.8"
CHECK_HOST2="1.1.1.1"
STATE_FILE="/var/run/wan-mode"
LOG="/var/log/wan-failover.log"

log() {
    printf '%s %s\n' "$(date '+%Y-%m-%d %H:%M:%S')" "$1" | tee -a "$LOG"
}

get_mode() {
    cat "$STATE_FILE" 2>/dev/null || echo "primary"
}

check_primary_wan() {
    # Force the check through the primary gateway by adding temporary host routes.
    # This ensures the test uses eth0 even if the current default route is via usb0.
    ip route replace "${CHECK_HOST}/32" via "$PRIMARY_GW" dev "$LAN_IFACE" 2>/dev/null
    ping -c 3 -W 2 "$CHECK_HOST" > /dev/null 2>&1
    result=$?
    ip route del "${CHECK_HOST}/32" 2>/dev/null

    if [ $result -ne 0 ]; then
        ip route replace "${CHECK_HOST2}/32" via "$PRIMARY_GW" dev "$LAN_IFACE" 2>/dev/null
        ping -c 3 -W 2 "$CHECK_HOST2" > /dev/null 2>&1
        result=$?
        ip route del "${CHECK_HOST2}/32" 2>/dev/null
    fi
    return $result
}

bring_up_usb() {
    if ! ip link show "$USB_IFACE" > /dev/null 2>&1; then
        log "ERROR: $USB_IFACE not found — enable USB tethering on the phone first"
        return 1
    fi
    ip link set "$USB_IFACE" up
    udhcpc -i "$USB_IFACE" -q -n -t 5 > /dev/null 2>&1
    ip addr show "$USB_IFACE" | grep -q 'inet ' && return 0
    log "ERROR: Failed to get DHCP lease on $USB_IFACE"
    return 1
}

clear_default_routes() {
    # Remove all current default routes to start clean
    while ip route del default 2>/dev/null; do :; done
}

switch_to_backup() {
    log "Primary WAN DOWN — switching to USB backup..."
    bring_up_usb || return 1

    USB_GW=$(ip route show dev "$USB_IFACE" | awk '/^default/{print $3}' | head -1)
    if [ -z "$USB_GW" ]; then
        log "ERROR: Could not determine USB gateway IP"
        return 1
    fi

    clear_default_routes
    ip route add default via "$USB_GW" dev "$USB_IFACE" metric 10
    echo "backup" > "$STATE_FILE"
    log "Routing via USB ($USB_GW). Mode: BACKUP"
}

switch_to_primary() {
    log "Primary WAN UP — switching back to NBN..."
    clear_default_routes
    ip route add default via "$PRIMARY_GW" dev "$LAN_IFACE" metric 1
    echo "primary" > "$STATE_FILE"
    log "Routing via $PRIMARY_GW. Mode: PRIMARY"
}

status() {
    printf 'Mode:     %s\n' "$(get_mode)"
    printf 'Default:  '; ip route show default
    printf 'eth0:     '; ip addr show "$LAN_IFACE" | awk '/inet /{print $2}'
    if ip link show "$USB_IFACE" > /dev/null 2>&1; then
        printf 'usb0:     '; ip addr show "$USB_IFACE" | awk '/inet /{print $2}'
    else
        printf 'usb0:     not present\n'
    fi
}

case "${1:-auto}" in
    auto)
        mode=$(get_mode)
        if check_primary_wan; then
            if [ "$mode" = "backup" ]; then
                switch_to_primary
            else
                log "Primary WAN OK"
            fi
        else
            if [ "$mode" = "primary" ]; then
                switch_to_backup
            else
                log "Primary WAN still DOWN, staying on backup"
            fi
        fi
        ;;
    primary)  switch_to_primary ;;
    backup)   switch_to_backup ;;
    status)   status ;;
    check)
        if check_primary_wan; then echo "Primary WAN: UP"
        else echo "Primary WAN: DOWN"; fi
        ;;
    *)
        echo "Usage: $0 [auto|primary|backup|status|check]"
        exit 1
        ;;
esac
EOF

sudo chmod +x /usr/local/bin/wan-failover.sh
```

## Step 6: Point Clients to mg

For each machine on your network that you want covered by the failover, change its default gateway from the NBN router's IP to `mg`'s IP (`192.168.8.99`).

- **Windows:** Network adapter settings → IPv4 → Default gateway
- **macOS:** System Settings → Network → Details → TCP/IP → Router
- **Linux:** See below

Alternatively, do it centrally: log into your NBN router's admin page and change the **DHCP gateway option** to `192.168.8.99`. All clients pick this up on their next DHCP renewal with no per-machine changes required.

### Linux: Gateway Switcher Scripts

On Linux, DHCP may leave behind its own default route when you try to change the gateway, resulting in two conflicting defaults. The safest approach is to flush all default routes first, then add the one you want.

Create two convenience scripts in `~/bin/`:

**`~/bin/gw-backup`** — switch to mg (backup WAN):

```bash
#!/bin/bash
while sudo ip route del default 2>/dev/null; do :; done
sudo ip route add default via 192.168.8.99 dev enp2s0 metric 100
echo "Gateway → mg (192.168.8.99) [backup WAN]"
ip route show default
```

**`~/bin/gw-primary`** — switch back to NBN router:

```bash
#!/bin/bash
while sudo ip route del default 2>/dev/null; do :; done
sudo ip route add default via 192.168.8.1 dev enp2s0 metric 100
echo "Gateway → NBN router (192.168.8.1) [primary WAN]"
ip route show default
```

Make them executable:

```bash
chmod +x ~/bin/gw-backup ~/bin/gw-primary
```

Then switching is just:

```bash
gw-backup    # route via mg when NBN is down
gw-primary   # route via NBN router when NBN is back
```

> **Note:** Replace `enp2s0` with your actual interface name (`ip link show` to check). These changes are not persistent across reboots or DHCP renewals — run the script again if needed.

## Using the Failover Script

```bash
wan-failover.sh            # auto: check primary WAN, switch if needed
wan-failover.sh check      # test if primary WAN is up (without switching)
wan-failover.sh status     # show current mode and interface IPs
wan-failover.sh backup     # manually force switch to phone
wan-failover.sh primary    # manually force switch back to NBN
```

## When NBN Goes Down: Step by Step

**1. Enable USB tethering on your Android phone**

On your phone: *Settings → Network & Internet → Hotspot & Tethering → USB Tethering* (on)

Plug the phone into `mg` via USB.

**2. SSH into mg and switch to backup**

```bash
ssh mg
sudo wan-failover.sh backup
```

**3. Verify**

```bash
sudo wan-failover.sh status
ping 8.8.8.8
```

You should see `usb0` with an IP address and pings going through. Clients on the network are now using mobile data transparently — no changes needed on their end.

**4. When NBN comes back**

```bash
sudo wan-failover.sh primary
```

Clients resume using NBN automatically.

## How It Works Under the Hood

When you run `wan-failover.sh backup`, the script:

1. Checks `usb0` exists (phone is plugged in with tethering on)
2. Brings the interface up and runs `udhcpc` to get a DHCP lease from the phone
3. Reads the gateway IP assigned by the phone (typically `192.168.42.129`)
4. Flushes all existing default routes, then adds a single clean one: `ip route add default via 192.168.42.129 dev usb0`

The flush step matters. When `udhcpc` gets a lease it automatically injects its own default route. Without clearing first, you end up with two default routes — the old primary and the new backup — and the kernel picks whichever has the lower metric, which may not be what you want. The `clear_default_routes` loop removes all of them before adding the correct one.

Android's USB tethering uses the RNDIS protocol, which the `rndis_host` kernel module handles. The phone acts as both a DHCP server and a NAT gateway to the mobile network. From the kernel's perspective, `usb0` is just another ethernet interface.

The `check_primary_wan` function tests internet reachability *through* the primary gateway specifically — even if the default route is already pointing at `usb0`. It does this by temporarily injecting a host-specific route (`8.8.8.8/32 via 192.168.8.1`), pinging, then removing it. This prevents the check from falsely succeeding via the backup connection while testing the primary.

## Keeping Costs at Zero

The entire ongoing cost of this solution is **zero**. Your phone's existing mobile plan absorbs the data usage during outages. Most modern plans include more than enough data for light business use — email, web browsing, cloud tools for a small team — for the duration of a typical NBN outage.

Contrast this with a dedicated 4G router plus a SIM plan that costs money every single month regardless of whether your NBN ever goes down.

## Conclusion

A spare computer, Alpine Linux, a USB cable, and a phone you already own is all it takes to give your home or small business network a solid backup WAN. The setup is straightforward, the failover is a single command, and the ongoing cost is nothing.

For the occasional outage — which is exactly the scenario most small businesses and home offices face — this is hard to beat.

<ContactFooter />


57ae585892c55092a1811e25a229f03d24e86b9b9f6fe0cd022c43794f3059dc

A step-by-step guide to setting up an Alpine Linux box as a backup WAN gateway for your home or small business network, using Android USB tethering as the mobile data source. Includes a failover script and full network configuration.

Turn an old PC or mini box running Alpine Linux into a backup WAN gateway using your existing Android phone's USB tethering — no extra SIM, no extra plan, no extra cost.

Create a Backup Mobile Data WAN for Your Small Business / Home Network


# Safeguard Your Secret and Hide It in Plain Sight  

In today’s world, smartphones have become indispensable. They hold our personal details, contacts, emails, photos, text messages, social media posts, and a host of other data, making them a treasure trove for anyone interested in accessing our information. This makes protecting our data, privacy and secret information a critical priority.  

While most smartphones are secured with a PIN or similar methods, this alone is not foolproof. Phones can be hacked using various sophisticated techniques [1]. Additionally, there are situations where you might have to unlock your phone—willingly or under pressure—and hand it over to someone else.  

To mitigate the risk of exposing sensitive information, you can either encrypt your data or hide it. Encryption acts like a safe: it’s visible, and everyone knows there’s something valuable inside. With enough time or pressure, however, safes can be cracked—or unlocked by the owner involuntarily. Data hiding, on the other hand, offers a more subtle approach. For instance, you could rename a file and store it in an inconspicuous folder. However, among all hiding methods, steganography stands out as an art form that has been practiced for thousands of years.  

A good example of hiding is from the movie *The Shawshank Redemption*, where a hole behind a poster helps Andy Dufresne escape his cell. Without knowing the hole exists, the poster remains a simple decoration. Similarly, steganography conceals data in such a way that its very existence is hidden, adding an extra layer of protection. By combining both encryption and hiding techniques, your data security can be significantly enhanced.  

Steganography is not just about protecting sensitive data; it can also help bypass surveillance or censorship. For instance, whistleblowers can securely pass information about injustice or corruption to journalists, and undercover agents can communicate discreetly without raising suspicion. History offers many examples of steganography in action. During the fifth century B.C., a Greek plotting a revolt against the Persian king shaved a messenger’s head, inscribed the message on his scalp, and waited for the hair to grow back. The messenger safely passed checkpoints and delivered the hidden message [2].  

If you’re an Android user, consider using the **“Hide Like a Pro”** app to achieve your goals of securing your data. The app provides tools for encrypting and decrypting secret messages. Demonstration videos are available on YouTube at the following links:  
- [Encrypting a secret message](https://www.youtube.com/watch?v=2CsG5tZnuF4)  
- [Decrypting a secret message](https://www.youtube.com/watch?v=AoeHtssJ2fc)  

You can download the app here:  
[Download Hide Like a Pro](https://play.google.com/store/apps/details?id=au.com.tyo.steghide)  

## References  
1. Chris Smith. “This Israeli company can hack into any Apple or Android phone.” *NY Post*, 2016. [Link](https://nypost.com/2016/09/27/this-israeli-company-can-hack-into-any-apple-or-android-phone/) (Accessed May 14, 2019).  
2. Gregory Kipper. *Investigator’s Guide to Steganography.* Auerbach Publications, 2004.  


9e907b0678589be0e2cff7bc6c052e71e95900d131b56b09e70177012116a618

This article explores the importance of safeguarding your secret with a way of hiding it in plain sight.

This post discusses the importance of safeguarding your secret with a way of hiding it in plain sight.

Safeguard Your Secret and Hide it in Plain Sight


## Overview

[Tyokiie]((https://play.google.com/store/apps/details?id=au.com.tyo.wiki.android)) is a very handy tool for offline Wikipedia article searching and viewing with lots of other features helping you make knowledge discovery easy and efficient. Comparing with other offline Wikipedia viewer, Tyokiie is fast, and it supports full-text search. For each supported language, it has large database(s) coming with tens of thousands of articles. 

## Usage

### Offline Wikipedia Viewing

You can only see the download if your primary language matches the avaliable database language. 

For example, at the moment, only the follow databases are avaiable:
- Chinese
- Arabic
- Limburgish
- Old English
- Malagasy

Say your primary / main Wikipedia language is set to Malagasy, as shown below:

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/apps/tyokiie/2022-03-22-12-42-45.png)

The availability is now "yes (Malagasy)", and you can view the database information by clicking on "Yes".

You will then be taken to a download page:
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/apps/tyokiie/2022-03-22-12-53-01.png)

You can see the size of the database, and how many articles are contained in the database.

To download the database, you can just simply click on the red cloud download button: ![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/apps/tyokiie/2022-03-22-12-54-30.png). 

Once the download is finished, the status of the database availability is now "installed", as shown below:

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/apps/tyokiie/2022-03-22-12-27-12.png)

Also, after the download is done, the Wikipedia article viewing mode is automatically turned on. You can turn it off easily by clicking on the switch button of "offline mode".

When the Tyokiie is in offline mode, the toolbar color will be changed, as it can be seen as follows:
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/apps/tyokiie/2022-03-22-12-26-21.png)


### Online Wikipedia Viewing 

Even Tyokiie right now has a main function for view Wikipedia artciles offline, it still can check out the online version of the article by switching off the "offline mode".

- Option one is to go to the "Setting" page and switch off the offline mode.

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/apps/tyokiie/settings-offline1.png)

- Option two is to open the drawer on the left side by sliding to the right:

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/apps/tyokiie/settings-offline-drawer.png)

## Download

You can install Tyokiie via [Google Play Store](https://play.google.com/store/apps/details?id=au.com.tyo.wiki.android).

As some users may not be able to access Google Play Store due to various of reasons, you can download the APK [here](/download/tyokiie/tyokiie-latest.apk) and sideload it.


## Support and Contact

If you have any suggestions on helping improve this app, we can be contacted via email: [dev@tyo.com.au](mail:dev@tyo.com.au).

Or you can contact the developer directly:

- X (formally twitter): [Eric Tang](https://x.com/_e_tang)
- email: [eric@tyo.com.au](mailto:eric@tyo.com.au) 

## Credits
- Photo: [Temple of Hathor, Dendera](https://unsplash.com/photos/wpxr-qSDQJM) by Jeremy Bezanger.






7f2a0490dc9dc998eaf7432675f714a9a1f5ca3623eb273802cb933d29406463

A simple tutorial to show you how to use 'Tyokiie' to search and view offline Wikipedia articles on your phone

Tag: Android