In-place reskin of a sealed protein dispenser

The appliance is a Chinese-market coffee/protein dispenser rebadged for a fitness operator. There is no vendor source tree, no API documentation, no upstream security stream, and the recipe/calibration plane is safety-relevant. The only workable path was to treat the running appliance as the specification: acquire everything over ADB, rebuild the APK through apktool, move product behaviour into data wherever possible, and confine new code to an owned extension dex that reaches the vendor app only through reflection.

Before any change could be justified, the unit had to be identified precisely: which binary is installed, who signed it, under what UID it runs, and which entry point the kiosk boots into.

Table 1 — Specimen provenance. Certificate digest abbreviated.

Day-zero findings defined what “safe change” could mean for the rest of the engagement. Two of them — the EOL runtime and the frozen hardware plane — constrained every later decision.

Table 2 — Risk register as assessed on day 0 and its state at v1.0.

No vendor VPN, no Git history, no protocol book. Everything below had to be recovered from a running kiosk over a connection that dropped often enough to make each pull a discrete, verified step.

Table 3 — Acquisition ledger. Handling column records the policy, not just the action.

# the question: does an ordinary re-signed app still own the boards?
$ adb shell pidof com.ys.vending
4127
$ adb shell ls -l /proc/4127/fd | grep ttyS
lrwx------ 1 u0_a54 u0_a54 64 74 -> /dev/ttyS3   # drink board
lrwx------ 1 u0_a54 u0_a54 64 75 -> /dev/ttyS2   # MDB payment

Why this is the pivotal observation. The OEM narrative implied the app needed system privileges to reach the boards. Two file descriptors held by u0_a54 after a re-signed install disproved it, and that is what made the entire reskin legitimate rather than speculative.

The app is modern Kotlin MVVM compiled across four dex files. jadx recovers intent well enough to reason about; it does not round-trip, so every rebuild goes through apktool smali. The scale below is what any change had to be located inside.

Table 4 — Pinned toolchain. Versions are fixed because apktool output is not stable across releases.

A single process owns the UI, the catalog reads, and both serial links. The reskin operates entirely in the upper two planes; the kernel UART plane is frozen by policy and verified by fingerprint on every deploy.

Table 5 — Vendor component map with the reskin's relationship to each.

The single most valuable finding of the engagement is that most product behaviour is configuration, not code. Recovering the schema turned features that looked like app changes into SQL and protobuf edits.

Table 6 — Concern-to-store ownership, with the change vector actually used.

id, type, slot, layer, isCombinationSlot, slotType, name, capacity, stock, error,
error_at, price, discount_price, useDiscount, image, formula, spec, sku, enable,
cold, age_can_buy_enable, age_can_buy, sell_time, remark, create_at, update_at,
description, detail_image, video, with_hot_water_enable, hot_water_cost, sort,
translation_name, cabinet_index, sale_status, testStatus, showFormula,
showPrice, showDiscountPrice

-- indexes: index_product_sku, index_product_enable_type_sort
-- 22 rows total, 7 with enable = 1

Table 7 — Protobuf configuration files. Field numbers were recovered by decoding live bytes, not from a schema.

Why bytes and not an API. Jetpack DataStore serialises through generated classes that the reskin does not have. Appending a well-formed varint field is idempotent, verifiable by length, and reversible — the deploy script checks for the D0 01 tag first and leaves the file alone if the operator already enabled the grid.

The operator wanted a real dosing choice at 0, 5 and 10 g, priced independently. An earlier approach that remapped the vendor “half sugar” control was abandoned: it inherited sweetness semantics and could not carry its own price. The shipped design encodes the ladder as ordinary SKUs and stores the relationship in a field the vendor app ignores.

CREA|<sku of 5 g variant>|<sku of 10 g variant>

-- parsed by CreatineFlow.loadVariants():
--   remark.startsWith("CREA|")  →  split on \|  →  requires length >= 3
--   row 0 is the visible tile (0 g); parts[1] and parts[2] are hidden SKUs
--   variant rows stay enable = 0, so they never appear on the grid

VANILLA        CREA|VANILLA+CREA|VANILLA+CREA+CREA
PVL H20        CREA|PVL H20+CREA|PVL H20+CREA+CREA

Table 8 — Seven enabled tiles × three doses = 21 addressable SKUs, of which 14 are hidden rows. Prices in C$; stored as mils.

attract        ad_full_attract_{en|fr}.jpg          // language-filtered by hook
  → shop      2-up grid, half banner _{en|fr}, 7 tiles
      → CreatineFlow chooser
             · 0 / 5 / 10 g          // when remark starts with CREA|
             · own-mug option        // when device_setting.selfCupOption
          → detail   hero + creatine badge + nutrition card
              → payment  // vendor MDB path, untouched
                  → shipment  hero + progress arc

All new behaviour lives in one owned class compiled against android.jar alone — zero vendor classpath. Every integration point is reflection, and every entry point catches Throwable and falls back to vendor behaviour. A failure in the reskin degrades to the original app rather than crashing the kiosk.

Table 9 — Extension entry points. The failure-mode column is the design contract, not a disclaimer.

Vendor smali edits are recorded individually because each one is a liability at the next vendor update. The ratio is the point: six files rewritten out of 28,317, and five of those six insert a single static call.

Table 10 — Every vendor smali file modified, with intent. Vendor package spelling tanslation is reproduced as found.

Update strategy. New views carry an af_ prefix and are appended rather than replacing vendor ids, so a future vendor APK can be re-decoded and the same six patches reapplied mechanically instead of merged by hand.

Two independent chains converge: the owned Java compiles to a dex that is dropped into the apktool tree as an additional multi-dex member, then the whole app is rebuilt, aligned and signed under a project key.

Deployment is a single scripted transaction, not a sequence of ad-hoc adb commands. It refuses to run against the wrong target, takes a restorable backup first, fingerprints the hardware plane on both sides of the change, and ends by proving the app is alive and still holding both serial ports.

1. Preflight

   Enumerate devices, require exactly one target or an explicit serial, and refuse any emulator-* target outright. Require the staged catalog and the signed APK to exist.

2. Backup

   Pull catalog plus its WAL and SHM sidecars, operational_config.pb, and the entire ads tree into backups/v2-<timestamp>/.

3. Fingerprint — before

   md5 of YS_CONFIG.db (and its WAL), catalog, serial config, calibration, operational and device settings. This is the reference the deploy is judged against.

4. Quiesce

   am force-stop com.ys.vending, then wait for the process to release its database handles.

5. Replace attract and banner art

   Clear ads/local/full and ads/local/half, then push language-suffixed artwork routed by filename prefix.

6. Push product renders

   Local hero PNGs into /sdcard/coffee/productImage/.

7. Invalidate image cache

   Remove the Glide ad_image_cache directory — without this, replaced artwork keeps rendering from cache.

8. Push catalog

   Copy the staged coffee_db.db over the live file and delete stale WAL/SHM so SQLite cannot resurrect the previous content.

9. Apply translations

   Pull language_db.db, apply the creatine label and language-support SQL locally, push it back, drop sidecars, and archive a copy into the backup folder.

10. Conditional protobuf patch

    Append D0 01 01 to operational_config.pb only when field 26 is absent; otherwise leave the operator's setting untouched.

11. Install

    adb install -g -r of the aligned, signed APK.

12. Launcher handoff

    Hand the HOME role back to the device's own Launcher3 so a failed kiosk app cannot lock the unit into an unusable state.

13. Cold start

    Launch SplashActivity explicitly and allow 30 s for first-run initialisation and board handshake.

14. Fingerprint — after, and verify

    Re-hash all six files, classify each as unchanged / expected / unexpected, confirm focus, PID and both tty descriptors, grep logcat for fatals, and capture a screenshot as evidence.

Table 11 — Fingerprint verdicts. Both directions are failures: unexpected change and unexpected sameness.

A deploy is only accepted when the appliance proves four things about itself. Anything less is treated as a failed deploy and rolled back from the backup taken minutes earlier.

ClassNotFoundException: org.apache.logging.log4j.spi.ExtendedLoggerWrapper
  // Netty probing for an optional log4j backend that this build does not ship.
  // Present on the untouched vendor APK as well - documented so it is never
  // mistaken for reskin damage during a live deploy.

Control experiment. A rebuild of the untouched vendor APK through the same apktool version produced no com/ys/ smali differences attributable to the toolchain. That baseline is what allows the six-file ledger in §09 to be stated as complete rather than approximate.

The working loop was: pull the current truth, form a hypothesis about which store or class owns a behaviour, patch, deploy to the board, screenshot, compare. Relative effort by workstream:

Table 12 — Controls introduced, and the boundary of each.