Peripage A40 Bluetooth protocol: analysis of a real HCI trace from the official app

Date: 2026-07-14/15
Method: adb shell settings put secure bluetooth_hci_log 1 → restart the Bluetooth stack →
print through the official com.ileadtek.peripage Android app on a tablet → adb bugreport →
extract FS/data/misc/bluetooth/logs/btsnoop_hci.log → analyze with tshark (no root needed on
the device — adb bugreport exposes these logs through a separate system service; /data/misc
itself isn't accessible without root).

Printer: a real Peripage A40 (PPG_A40_34C4, firmware V1.4.5_SD).

How to read this: every claim is tagged with a confidence level — confirmed (seen
directly in the bytes/stats, or confirmed by decompiling the app's code), likely (consistent
with the data but not proven), or unknown (recorded as fact, meaning not deciphered).

Later (2026-07-15) the app itself (com.ileadtek.peripage, versions 312 and 319, the latter
pulled directly off a real device) was decompiled with jadx, and its native libraries
disassembled (capstone/pyelftools) — including a security review first (no backdoor found:
no dynamic code loading, no Runtime.exec/ProcessBuilder, no JS bridges, no hardcoded
IPs, permissions requested match what's actually used). That upgraded most of this document's
findings from "guessed from trace timing" to "confirmed by decompiled code" — noted inline
below wherever it applies.

1. Capture overview

• Duration: 754.6 seconds, 3 separate print actions inside it (the same test image printed
  twice, plus one more distinct action in between).

• Protocol hierarchy (tshark -q -z io,phs):

  bluetooth: 1158 frames
    hci_h4
      bthci_cmd: 258   (HCI controller commands, not part of the application protocol)
      bthci_evt: 579   (HCI controller events)
      bthci_acl: 321
        btl2cap: 321
          btsdp: 4       (Service Discovery — finding the SPP service)
          btrfcomm: 277
            btspp: 135   (the actual application-layer data — what we care about)
  

• Of the 135 SPP frames: 116 → to the printer (15183 bytes), 19 ← from the printer
  (242 bytes).

• Of the 116 frames to the printer: 41 short control frames (≤100 bytes) and 75 large
  frames (>100 bytes, forming 3 continuous bursts — the actual image data).

2. Per-print-action command sequence

Reconstructed from all 3 print actions — byte-identical across all three except where noted as
variable.

The library's own image opcode (1d763000) never appears anywhere in the trace — the official
app prints images through a completely different protocol for this printer.

3. Image data transfer (opcode 0x1f)

Update 2026-07-15: this section originally came from the live trace alone and had three
"unknown"/"likely" items. After decompiling the official app (method w(Bitmap, int) in the
protocol controller class) every preamble field is now decoded exactly, and — most
importantly — a real data-compression mechanism was discovered (§3.2). The original
observations below are kept as-is, with confidence levels updated; numbers that previously
"didn't add up" now do.

3.1. Preamble — now fully decoded

First bytes of the first frame of each burst:

Session 0 (t=34.538):  1f 00 00 d0 01 16 00 00 10 54 ed 92 4f 6c e4 46 ...
Session 1 (t=740.561): 1f 00 00 d0 08 61 00 00 19 b4 ed d2 7d 8c 5c d7 ...
Session 2 (t=774.124): 1f 00 00 d0 01 16 00 00 10 54 ed 92 4f 6c e4 46 ...

(Sessions 0 and 2 print the exact same test image twice, hence identical bytes in both the
preamble and the start of the data.)

Preamble format, byte-exact per the decompiled code (all multi-byte fields are big-endian —
important, see §7.4 on how this differs from the legacy protocol):

3.2. Payload compression — it's plain zlib deflate

The main new finding (2026-07-15). Method w(Bitmap, int) builds the raster with the same
function as the legacy protocol (see §7.4 — 1 bit per pixel, MSB-first, black = 1 when average
RGB < 190), then runs the result through a native call Code.code(byte[]). The library backing
this call, libCode.so, was disassembled (capstone/pyelftools, see §7.1) — it retains debug
symbols and copyright strings unambiguously identifying it as plain zlib 1.2.3 ("deflate 1.2.3 Copyright 1995-2005 Jean-loup Gailly", "inflate 1.2.3 Copyright 1995-2005 Mark Adler",
symbols deflate, inflateInit2_, compress2, adler32, crc32, zcfree, paths
.../jni/zlib/{deflate,inflate}.c).

Code.code() is a thin JNI wrapper around zlib's standard compress2() (or equivalent). The
Java code afterward explicitly strips the first 2 bytes of the result before sending
(System.arraycopy(bArrCode, 2, bArr2, 10, bArrCode.length - 2)) — exactly the 2-byte zlib
wrapper header (CMF+FLG, typically 78 9C/78 01/78 DA depending on compression level).
So what goes over the wire is not a full zlib stream, just its deflate body plus the
trailing 4-byte Adler-32 (the trailer itself is not stripped).

Practical takeaway for implementing this (details and code in
printer-protocol-implementation-plan.md): the stdlib zlib module is enough to replicate this
in Python:

raw = pack_1bpp_msb_first(bitmap)   # same packing already used for the legacy protocol
compressed = zlib.compress(raw, level)   # compression level doesn't affect decodability
payload = compressed[2:]                 # strip the 2-byte zlib header, as the app does

⚠️ Real-hardware update, added after posting this analysis: we implemented this and tested
it against a real Peripage A40. The printer hung/powered off on receipt of a payload
produced by Python's own zlib.compress() (fully recovered after a manual restart, no lasting
damage — confirmed via an immediate working print through the legacy 1d7630 path right
after). So this protocol is not simply "any standard deflate stream" as compatible as the
matching zlib version might suggest — something about our compressed byte stream specifically
isn't accepted by this firmware's decompressor, even though the algorithm is nominally the
same. Not root-caused; our leading guess is a deflate window-size mismatch (zlib.compress()
defaults to a 32KB window, wbits=15; an embedded decompressor may expect much less and not
fail gracefully on a larger one). If anyone picks this up: try zlib.compressobj(wbits=...)
with an explicitly smaller window, or capture another live trace of the official app on the
exact same input and byte-diff its compressed output against a Python-produced one rather than
assuming "same algorithm" implies "same accepted bytes."

3.3. Timing — the headline finding

Confirmed: the official app inserts no manual delay whatsoever between
rows/frames — the observed gaps (2.5-4.4ms) are purely the natural pace of the Bluetooth
transport (bounded by the negotiated RFCOMM MTU), not a deliberate delay in the app's code. The
entire image goes out as one continuous stream in 49-140 milliseconds.

That's 15-30x faster than the delay=0.05 a downstream project (PeriPrint) had been using
before finding this trace (this library inserts time.sleep(delay) between every raster row
inside printRowBytesList()). This single finding was the fix that resolved silent data loss
on longer prints for that project — slow, evenly-paced delivery was desynchronizing the
printer's receive state, not protecting it.

Caveat: the 200-byte frame size is very likely just the negotiated RFCOMM/L2CAP packet size
(a transport-layer artifact), not a guarantee that "one frame = one raster row." Don't
confuse transport-level fragmentation with the protocol's logical structure — the timing
conclusion (no manual per-row delay) holds regardless, but "1 row = 208 bytes = 1 frame" does
not.

3.4. End of burst — another finding

The last frame of each of the 3 bursts ends identically:

Session 0: ...981b4a1010fffe45
Session 1: ...9a1b4a1010fffe45
Session 2: ...981b4a1010fffe45

Breaking down the trailing bytes: 1b 4a 10 + 10 ff fe 45.

• 1b4a10 — confirmed: this is this library's already-known printBreak opcode
  (1b4a + a size byte), here with size 0x10=16. The official app genuinely uses the exact
  same printBreak as this library — byte-for-byte identical.
• 10fffe45 — confirmed by code (see §2 step 7, §7): method Y(). Appears both before and
  after the image data — not phase-specific, more like a general "finalize/rearm state," called
  from several unrelated places in the app's code.

This confirms the image data and trailing commands are one continuous Python/Java-level
write() that the OS simply cut into RFCOMM packets wherever convenient, with no regard for
logical command boundaries.

4. Unsolicited (unrequested) messages from the printer

During an idle gap between print session 1 and session 3 (~t=750-753s, no preceding app command
in this window at all):

t=750.67 ← fd01
t=751.29 ← aa
t=753.28 ← fd02

Decoded by code (2026-07-15) — the single most important finding of this update. These are
asynchronous control messages from the printer, and this library doesn't listen for them at
all. The official app's incoming-packet parser tags the first byte 0xFD (-3) and dispatches on
the second byte (b11) like this: b11==3 and b11==4 go to two empty handlers (no-ops in
the decompiled code — the app receives them but does nothing); every other value of b11
(including 1 and 2 — exactly what's seen in the trace) goes to onStartOrStopSend, where:

• b11 == 1 → logs "终止命令" ("terminate/abort command") → the app stops the current print
  (clears its "keep sending" flag, hides the progress bar) and publishes an event with code
  0x01.
• b11 == 2 → logs "继续开始命令" ("continue/start again command") → publishes an event with
  code 0x02 (the decompiled handling stops there — what exactly "starts again" at the app
  level wasn't traced further).

In other words: fd 01 = the printer itself is asking to abort the print, fd 02 = the
printer is allowing it to resume/restart. This isn't directly battery/button-related (though
the physical cause behind such a signal could be any of cover-open/overheat/button — those are
already covered by their own separate tags, see §7.3); specifically the 0xFD family is a
print-level flow-control protocol. This library and any client built on it currently don't
listen for incoming bytes at all during printImage() — meaning if the printer sends fd 01
mid-print (e.g. the user opened the cover), a naive client just keeps writing into a socket the
printer may have already stopped processing.

(Update: a downstream project implemented a listener for this and confirmed it live — printing
a real job and physically opening the printer's cover mid-job produced a cover_open status
(0xFF 0x02, see §7.3 below) that was caught and correctly paused the print, with the physical
printer stopping at the exact same instant. Two distinct real triggers — abort_print/fd01
from this trace and cover_open/ff02 from that live test — both land in the same
"stop, something needs attention" bucket, worth knowing they're not the same event under two
names.)

5. Opcode summary: known vs. found in the trace

Updated 2026-07-15 from the decompiled code — see §7.2 for the full opcode-by-opcode table of
controller-class methods, including commands never seen in this particular trace.

6. Practical implications

1. A downstream project (PeriPrint) already applied: removed the manual per-row delay
   (0.05s → 0.001s) and stopped artificially chunking short documents — both follow directly
   from the timing in §3.3, confirmed by printing on a real printer.
2. Previously a workaround, now backed by an exact formula: a 1664px "safe content width"
   for this A40 (vs. this library's hardcoded 1728px) used to rest on a single observed byte
   (d0=208), just assumed to be row_bytes. Now confirmed by the decompiled code: row_bytes = ceil(width/8), formula and byte positions read directly from w(). The number 1664 stays
   correct, it's just no longer "a guess from one byte."
3. Not applied, needs hardware verification: concentration 04 (§2 step 6, §5) — this
   library artificially clamps to 0-2; the app's code has no such clamp (a 0-3 clamp exists only
   in the separate, legacy image-header path C()). Worth explicitly sending 10ff1000 +
   03/04 past the clamp and checking whether print density actually improves.
   (Update: tried on a real A40 — accepted without error at 3/4, but no visible density
   difference on that specific unit.)
4. Now implementable, previously wasn't: the entire 0x1f opcode is fully decoded (§3),
   including discovering the zlib compression — that was the only reason the numbers didn't add
   up before. (Update: implemented and tested — see the real-hardware warning in §3.2. Do not
   use as-is.)
5. Decoded, needs immediate attention: the incoming fd01/fd02 (§4) isn't random
   telemetry, it's print-flow-control (abort/resume). No client built on this library currently
   listens for it at all — this is the single most actionable functional gap found in this
   document. (Update: implemented and confirmed live via a real cover-open test — see the note
   at the end of §4.)
6. Partially decoded, reliably reproducible: 10ff20ee, 10ff70, 10ff1003, 10fffe45,
   1fb210, 10ff8001, 10ff8150 — all now tied to specific decompiled-code methods (see §7.2
   for the full table and §7.3 for the status-response semantics: low battery, cover open/
   closed, wrong paper type, overheat, cartridge/head "insufficient mileage").

7. Cross-reference with the official app's decompiled code (2026-07-15)

7.1. Method

Two instances of the official com.ileadtek.peripage Android app were analyzed:

1. com.ileadtek.peripage-312.xapk — version 6.10.6 (build 312).
2. peripage-base.apk + peripage-split_config.arm64_v8a.apk — version 6.10.9 (build 319),
   pulled directly off a real device (a more authoritative source than an arbitrarily-downloaded
   .xapk).

Both were decompiled with jadx 1.5.6 (Java/Kotlin from classes*.dex); native libraries
(.so, arm64-v8a) via readelf/nm/strings and a manual disassembler built on capstone +
pyelftools. Full methodology, including a security check for malicious behavior (none found),
is available on request.

Important methodological note: between builds 312 and 319, obfuscation (ProGuard/R8)
renames classes and fields (e.g. the protocol-command class was v0.h in build 312 and
became u0.h in build 319; a byte-level comparison confirmed identical logic, only the
generated names changed). String literals (log tags like "BluetoothPortPrint",
"choosePaperType", Chinese messages like "onOutPaper", "onOverHeat") survive obfuscation
and are more reliable to search by than class/package names if this needs to be repeated
against a future app version.

7.2. Full command table from the protocol controller class

The controller class (u0.h/v0.h depending on build) is the single point all low-level
commands go out from, over the same Bluetooth SPP transport (UUID
00001101-0000-1000-8000-00805F9B34FB — the same one this library uses). Below is every
command found in this class, not just the ones seen in the live trace. The "In trace?" column
distinguishes what was confirmed by a live capture from what's confirmed by code only.

Decompilation note: jadx substituted numeric byte literals with static constant names from
unrelated libraries (org.apache.poi, org.apache.commons.compress) that happen to share
the same value — e.g. UnionPtg.sid happens to equal 0x10, BoolPtg.sid = 0x1D,
NumberPtg.sid = 0x1F, UnaryPlusPtg.sid = 0x12, TarConstants.LF_NORMAL/LF_LINK = ASCII
'0'/'1' (0x30/0x31), Ptg.CLASS_ARRAY = 0x40. This is purely a decompiler artifact
(the substitution has nothing to do with Excel formulas or tar archives) — worth knowing if
anyone reopens these classes in jadx and finds these "random" imports confusing.

7.3. Printer status responses — full semantics

The status-message handler (interface implemented in the print-orchestration class) gives exact
semantics to every tag mentioned in §2/§4:

7.4. Differences between the legacy (0x1d7630) and new (0x1f) image protocols

Not just a different opcode — the header formats also differ structurally in ways that are
easy to miss when porting:

• Different byte order. The new (0x1f) protocol encodes row_bytes/height as
  big-endian (§3.1). The legacy (0x1d7630) protocol (method C()) encodes the same values
  as little-endian ((byte)(i11%256), (byte)(i11/256) — low byte first).
• The legacy header has a concentration byte this library doesn't use. This library's own
  printRow()/printRowBytesList() always writes 0x00 at that header position (1d763000 —
  the fourth byte is always zero). The official app instead writes a
  concentration/mode parameter there, clamped to 0..3 — meaning the protocol itself has an
  unused-by-this-library field: "density for this specific image."
• The 255-row chunk limit is artificial, not protocol-level. This library encodes height
  as one byte (hence its own comment, "chunked... height limit of 0xff") — which is why
  printRowBytesList() has to slice any image taller than 255 rows into chunks. But in both the
  legacy and new app protocols, the height field is a genuine 16 bits. This means the
  255-row chunk limit in this library isn't a firmware limitation — it's a consequence of how
  this library encodes the header bytes; the firmware potentially accepts heights up to 65535
  rows in one command.
• This library's reset() appends 13 zero bytes to 10fffe01; in the app's code, reset
  (U()) is exactly 4 bytes, with no zero bytes following (§2 step 5, §7.2 M()).

This writeup, and a companion implementation plan with concrete code for each of these
findings, came out of building an open-source printing app
(perripage-ferrum) on top of this library.
Posted here in case any of it is useful upstream — happy to answer questions about the
methodology or dig further into any of the still-undecoded opcodes.