Home on virusdefender's blog ʕ•ᴥ•ʔ

POCSAG 协议考古 - 硬件实现

Sun, 10 May 2026 00:00:01 +0000

上一篇文章梳理了 POCSAG 的协议格式，这一篇来看看硬件的实际选型。POCSAG 是运行在 2-FSK 调制之上的应用层协议，硬件层面只需要两个核心能力：一个支持 FSK 调制解调的射频前端，一个能跑协议解析的 MCU。看上去选择很多，但真要做的时候，射频芯片的寄存器配置、FSK 极性的匹配、频率稳定度、开发门槛都是坑。

好在 GitHub 上有几个开源项目，各走了一条路，拿来当硬件选型的参考很合适。

硬件选型

Warning

无线电设备的研发必须严格遵守相关法律法规：禁止在非民用频段进行信号发射；严禁违规接收非授权频段信号；严禁将非公开的信号与数据上传至互联网。

	MCU	射频前端	板卡方案	简介
GoRail_Pager	STM32F103C8T6	TI CC1101	自己画 PCB	纯 FSK 芯片；外挂 ESP8266 走 MQTT。
SX1276_Receive_LBJ	ESP32	SX1276	现成开发板	TTGO LoRa 32 v1.6.1，约 18 美元到手即用。SX1276 支持 LoRa/FSK 双模。
RP2040-Based	RP2040	SX1276	自己画 PCB	同样基于 SX1276，MCU 换成树莓派 RP2040，有完整的 PCB 和外壳文件。

TTGO LoRa 32 价格不算低，但完全不用 DIY——一块板子到手即用，代码现成，不需要画 PCB。缺点是板子形态固定，体积、功耗、接口都没法自己调整。

POCSAG 协议考古 - 协议基本格式

Fri, 01 May 2026 00:00:01 +0000

在智能手机普及之前，有一个时代的移动通信是靠 BP 机（Pager/寻呼机）撑起来的。POCSAG 就是那个时代最成功的寻呼协议之一。虽然 BP 机早已淡出大众视野，但 POCSAG 在今天并没有完全消失——一些医院的老式内部呼叫系统、工厂的报警通知、铁路列车接近预警（800MHz 机车电台 LBJ）等场景中，仍然能看到它的身影。

今天让我们翻开这份来自上世纪的技术文档，看看它是如何在极其有限的带宽和功耗约束下，设计出一套完整的一对多消息广播系统的。

什么是 POCSAG

POCSAG 全称是 Post Office Code Standardization Advisory Group（邮政总局编码标准化咨询组），由当时掌管全英电信的英国邮政总局制定。它是一种无线数据传输的协议，用于向"寻呼机"（Pager）单向发送消息。

POCSAG 定义了三种标准数据速率：512 bps、1200 bps、2400 bps。512 bps 的通信距离最远，而 1200 和 2400 bps 允许每秒传的寻呼消息数量更多。

物理层：调制方式

POCSAG 采用 Frequency Shift Keying（FSK，频移键控）调制。FSK 是一种数字调制技术，用载波频率的变化来表示数字信号——不同的频率对应不同的 bit 值，接收端通过检测频率来判断发过来的是 0 还是 1。

具体到 POCSAG：在射频载波上使用 ±4500Hz 的频偏，高频代表数字 0，低频代表数字 1。同一个传输频道上可以混合不同速率的数据块。

CAP Code：寻呼机的"身份证"

CAP Code（Channel Access Protocol code，频道接入协议码）是每台寻呼机独一无二的地址标识，总共 21 位，这意味着一个频道理论上可以分配 2097152 个不同的地址。

这 21 位实际上被拆成了两部分：

字段	位数	位置
地址位（Address bits）	18 bit	高位（MSB）
帧位置位（Frame location bits）	3 bit	低位（LSB）

拆出 3 个帧位置位的设计非常精巧——它允许寻呼机只在"属于自己"的那几帧时间里打开接收器，其他帧时间直接断电休眠，显著延长电池寿命。后文会详细展开。

体验 LetsEncrypt 的短期证书

Thu, 27 Nov 2025 00:00:01 +0000

在今年 2 月份的时候，LetsEncrypt 就发布了一篇文章称要推出六天的短期证书，而目前 LetsEncrypt 的默认证书还是 90 天的。

为何要使用有效期更短的证书呢，这个主要有两个重要的原因：

证书吊销机制不可靠

证书吊销一直是依赖 OCSP 或 CRL 机制，但是都需要是客户端主动的去检查，否则对证书有效性没有任何的影响。

CRL（证书吊销列表）

CA 定期生成一个签名的列表，其中包含所有已被吊销但尚未过期的证书序列号。客户端在验证证书时，会下载这个列表，并检查目标证书的序列号是否在其中。如果在，则说明该证书已被吊销，不应信任。

缺点包括

体积大：随着吊销证书增多，CRL 文件会变得很大，影响性能。
存在时效性问题：两次更新之间的窗口期内吊销的证书无法被及时发现。

OCSP（在线证书状态协议）

客户端向 CA 指定的 OCSP 响应服务器发送一个查询请求，包含目标证书的序列号等信息，OCSP 服务器实时返回该证书的状态。

缺点包括

每次查询都会暴露用户正在访问哪个网站
依赖网络和服务器可用性：如果 OCSP 服务器宕机或响应慢，可能导致连接延迟甚至失败。某些客户端可能会忽略 OCSP 错误继续连接。

其改进版为 OCSP Stapling，即服务器主动从 CA 获取 OCSP 响应，并在 TLS 握手时一并发送给客户端。避免了客户端直接连接 OCSP 服务器，提升性能和隐私。

短期证书的主要优势在于，它们能显著缩短潜在的风险暴露时间，因为这类证书会相对较快地过期。这降低了对证书吊销机制的依赖。因为上述吊销机制一直不够可靠，所以短期证书将不包含 CRL 或者 OCSP 的配置信息。

此外，短期证书实际上要求必须实现自动化管理，实现证书签发的自动化也对于安全性至关重要。

支持 IP 证书

虽然说 IP 和域名的 SSL 的验证和签发本质都是一样的，但是过去只有少数几家 CA 小规模提供此类服务。

IP 证书很少见最重要的原因是 IP 地址的所有权的变动比域名频繁多了，比如你在某个云厂商创建了一个新的虚拟机，分配了一个 IP 地址，在释放虚拟机的时候，如果你同时选择了释放 IP 的话，这个 IP 可能随时就被其他人所占用。这时候已经签发的长期有效的 IP 地址的证书可能就存在安全隐患了，而使用短期证书即可以匹配 IP 生命周期也可能比较短的场景。

迁移到 Hugo

Thu, 04 Sep 2025 00:00:01 +0000

从本站的文章发布日期来看，写博客也已经有 10 多年的历史了。回想了一下本站使用的博客系统，大概分为下面三个阶段，它们让我切换的动力都是简洁轻量的部署与贴合个人审美的模板。

Typecho

印象中当年将 Typecho 在多家不同的虚拟主机上都部署过，也是当年初入技术圈的时候，各种胡乱探索的过程。

相对于 WordPress，差别是 Typecho 更加简洁易用，共同点是 10 多年过去了，我翻了下 Typecho 的 GitHub 发现还是和 WordPress 一样天天在修复安全漏洞。

这个截图来自官方博客，我当年用的主题似乎和这个有点差别，但是整体布局和色调是接近的。

Jekyll

后面静态博客生成器快速流行起来，无意中发现有人分享了一个主题 jekyll-theme-H2O，也是一眼就看中了。

因为不想更换为 Jekyll 之后让之前 Typecho 生成的文件链接失效，所以一个静态网站的 url 也不得不变成 /index.php/archives/100/ 这样的格式了。

Hugo

逛 GitHub 的时候发现了一个名为 ʕ•ᴥ•ʔ Bear Blog 的博客系统，其小熊的 logo 非常的呆萌可爱。

不过这个博客系统很遗憾是 Django 开发的，不是静态网站，但是我又一眼就喜欢上了这个网站的模板风格，就打算自己扒一下网站的源码改造一些，调研过程中就发现了原来已经有好心人给弄了 Hugo 版本，所以自然就切换到了 Hugo 上。整体来看，这个版本的风格和 Typecho 还是比较接近的。

折腾这个没花太多的时间，借助 AI 工具，一些明显的问题和数据格式的简单迁移很快就搞定了，主要遇到的一个卡点是这个博客区分 Dark 和 Light 模式，并借助 css 自动切换，但是 Markdown 中代码块的高亮却是固定的模式，导致不管选择哪个高亮的主题在另外一个模式下总是看上去比较奇怪。后来搜索了一些资料，最终是导出了两个主题的语法高亮 css 然后插入自定义的 css 进行选择，感觉 Hugo 自带这个功能的话会更好一些。

1<style type="text/css" media="screen">
2@media (prefers-color-scheme: dark) { 
3 /* Generated using: hugo gen chromastyles --style=github-dark */
4 /* github-dark css 内容 */
5}
6@media (prefers-color-scheme: light) { 
7 /* Generated using: hugo gen chromastyles --style=friendly */
8 /* friendly css 内容 */
9}

寻找不太一样的 Webshell 检测绕过方法

Mon, 21 Aug 2023 00:00:01 +0000

这其实是一篇写于 2022 年初的老文，不过鉴于很久没发过文章了，就来凑个数。

本文不再赘述编码、替换等通用绕过技术，也不太多的深入检测的核心原理，而是列举一些检测周边的 bug，这些 bug 基本原理都不复杂，但也确确实实的在影响检测效果，而且可能也是横跨多个引擎的通用绕过技术。

PHP Server 模式和 Cli 模式行为不同

正常情况下，我们运行 PHP 网站都是 PHP Server 的模式，但是在一些 Webshell 检测中，是使用的 Cli 模式，简单来说就是 php sample.php 这样来模拟执行和检测的。这样做的原因可能是：

避免检测过程中出现 bug 导致整个进程崩溃，影响其他检测。Cli 模式下，每个检测都对应一个单独的进程；
方便给不同的检测样本添加不同的时间和内存限制。

这两种模式下，PHP 运行的行为基本是一样的，但是也存在细微的差别，这就可以用于来绕过 Webshell 检测。

shebang line

为了方便和其他脚本解释器一样，直接使用 ./x.php 的形式运行 PHP 脚本，PHP 解释器也提供了 shebang line 的支持，但是 PHP 对 shebang line 的支持和 Bash、Python 等比还有些不一样。

shebang line 是 #!/usr/bin/php、#!/bin/bash、#!/usr/bin/python 的形式，对于 Bash 和 Python 来说，语言的注释符就是 #，所以这一行自然就忽略掉了，不需要特殊的处理。而对于 PHP 来说，# 不是注释符，需要进行特殊的处理，否则就会出现语法错误。所以 Cli 模式下，会特殊的判断和跳过，而 Server 模式下面不会去处理。

1#! <?php echo 100*100;
2
3<?php
4echo 200*200;

Server 模式下的输出是