ssh-keygen -t]]>
    
    
    2026-10-27T01:20:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      起因
一直挺得意那台轻量服务器——2 核 4G，跑着博客、图床、一个文件管理，两年没出过事。
10 月 26 号晚上翻图床的时候发现不对劲：桶里多了几个从来没上传过的文件，名字是 shell.php、.htaccess，还有一个叫 ahk_probe 的东西。第一反应是自己手滑，第二反应是——我根本没开过 PHP。
往下挖
先看的不是网站，是进程。
ps auxf | grep -v '\[' 
排在最上面的几个进程看着很正常，名字是系统自带的那种。但路径不对：
/dev/shm/.collector/collector.d
/dev/shm 是内存盘，重启就清空，正常服务不会往这儿放东西。collector.d 这个名字起得很「正经」，伪装成日志收集器——这种命名习惯不是随手写的，是有人专门研究过怎么不被人一眼看出来。
再看 /root/.ssh/，authorized_keys 里多了一把不属于我的公钥。也就是说：对方不需要密码也能随时回来。
溯源：入口在哪
翻 nginx 和 MinIO 的日志，链条很清楚：
图床的 9000 端口直接对着公网开着
MinIO 用的是默认凭据 minioadmin / minioadmin（建的时候图省事，一直没改）
对方扫到 9000，用默认口令直接进来了
通过 MinIO 的写入权限往桶里丢 web shell 和探测脚本
拿到执行权限后提权、装后门、留公钥
整个过程没有任何「高难度操作」。用的是出厂默认密码和不必要对外开放的端口。
顺带在 auth.log 里翻了 SSH 爆破记录，三个来源，都是同一批端口、同一套字典：
来源地址
归属
行为
51.222.47.156
境外（OVH 地址段）
单 IP 尝试登录 4466 次
106.53.117.97
中国·广东·广州（腾讯云）
扫描同一批端口
182.134.27.185
中国·四川·宜宾（电信）
扫描同一批端口
没什么好洗的，就是三个贱人：
51.222.47.156（境外 OVH 段）—— 一个 IP 硬试了 4466 次
106.53.117.97（广东广州，腾讯云）
182.134.27.185（四川宜宾，电信）
租台云主机来扫端口是贱人，拿别人的机器当跳板更是贱人。这三个地址我记在这儿了，哪天想起来了就翻出来看一眼。
骂完还得防。真正让它们无从下手的是「密码登录关掉」和「端口不对外」。
止损
发现后没做「清理」这种操作，直接按事故处理：
先关机，切断对方的操作通道——清理是在跟对手赛跑，没必要
关机后打快照，把现场固定下来（这台机器上的一切都可能是证据）
重启挂个临时环境，只对自己的 IP 开放，把数据捞出来
数据核对无误后，整机重装
这里有个判断很关键：不要试图「删掉后门」然后继续用。一个拿到过 root 的人，可以在任何地方留东西——内核模块、cron、systemd、甚至固件。你不可能穷举。
唯一可靠的处置是重装。
数据是怎么保住的
图床数据在对象存储的桶里，站点是纯静态文件，都落在数据盘上。把这两个目录打包：
tar czf backup.tar.gz /数据目录/minio/data /var/www
打完校验 SHA256，传到本地再核一遍。中间出过一次传输损坏，第二次才拿到一致的哈希——这一步千万不能省，一个坏包等于没备份。
教训
三条，按严重程度排：
问题
后果
默认密码（minioadmin/minioadmin）
等于没设密码，扫描器字典第一条就是它
端口对公网敞开（12 个端口）
每个端口都是一个入口，图床根本不需要公网直连
root 密码复用且偏弱
一旦进来，横向到系统层毫无阻力
还有一个隐性的：我从来没看过那台机器的日志。4466 次爆破，失败了 4466 次，没有一次触发告警，因为压根没装 fail2ban。
最后
这次没人身损失，数据也都回来了。但那种「自己的机器上跑着别人的进程」的感觉，比丢数据更让人不舒服。
后面几篇会写重装之后做了什么——SSH 换密钥、端口砍到 3 个、fail2ban、图床收回内网、评论系统搬回自己机器。都是很基础的东西，基础到出事之前我一直觉得「没必要」。
]]>
    
    https://cyk.pink/posts/7c2a91e4.html
    
    2026-10-26T14:40:00.000Z
    

      起因
一直挺得意那台轻量服务器——2 核 4G，跑着博客、图床、一个文件管理，两年没出过事。
10 月 26 号晚上翻图床的时候发现不对劲：桶里多了几个从来没上传过的文件，名字是 shell.php、.htaccess，还有一个叫 ahk_probe 的东西。第一反应是自己手滑，第二反应是——我根本没开过 PHP。
往下挖
先看的不是网站，是进程。
ps auxf | grep -v 
    
    
    2026-10-26T14:40:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      oh-my-posh 是个跨平台的终端提示符美化工具，支持 PowerShell、bash、zsh、fish、cmd。它用 JSON 配置文件定义提示符长什么样，可以显示当前目录、git 分支、执行时间、电池、天气、各种编程语言版本等。
安装
Windows 上最方便的是用 winget：
winget install JanDeDobbeleer.OhMyPosh
装完会多出一个 oh-my-posh.exe。macOS 和 Linux 可以用 Homebrew：
brew install jandedobbeleer/oh-my-posh/oh-my-posh
或者直接用官方安装脚本：
curl -s https://ohmyposh.dev/install.sh | bash
字体
oh-my-posh 的很多主题用到 Nerd Font 图标。如果看到方块或乱码，说明当前字体没有这些字形。
推荐装 MesloLGM Nerd Font 或 Cascadia Code PL。Windows Terminal 里在设置 → 外观 → 字体里选上。VS Code 终端同样要在 settings.json 里配 terminal.integrated.fontFamily。
初始化
根据你的 shell 加一句启动命令。
PowerShell（加到 $PROFILE）：
oh-my-posh init pwsh | Invoke-Expression
bash（加到 ~/.bashrc）：
eval "$(oh-my-posh init bash)"
zsh（加到 ~/.zshrc）：
eval "$(oh-my-posh init zsh)"
fish（加到 ~/.config/fish/config.fish）：
oh-my-posh init fish | source
换主题
初始化时可以直接指定主题：
oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\jandedobbeleer.omp.json" | Invoke-Expression
官方内置了很多主题，装完后主题文件一般在：
Windows：%LOCALAPPDATA%\Programs\oh-my-posh\themes\
macOS/Linux：~/.cache/oh-my-posh/themes/
想试效果可以临时运行：
oh-my-posh print primary --config "C:\path\to\theme.omp.json"
自己改配置
主题就是 JSON。一个最小结构长这样：
{
  "$schema": "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json",
  "version": 2,
  "blocks": [
    {
      "type": "prompt",
      "alignment": "left",
      "segments": [
        {
          "type": "path",
          "style": "plain",
          "foreground": "#26C6DA",
          "template": "{{ .Path }} "
        },
        {
          "type": "git",
          "style": "plain",
          "foreground": "#FFEB3B",
          "template": "({{ .HEAD }})"
        }
      ]
    }
  ]
}
segment 类型很多：path、git、executiontime、battery、node、python、go、kubectl……官方文档有完整列表。
多台机器同步
把主题文件放到 git 仓库或网盘里同步，初始化时指向固定路径。或者用环境变量 POSH_THEME 指向配置，这样换机器只需改一个变量。
$env:POSH_THEME = "C:\Users\codem\.config\oh-my-posh\mytheme.omp.json"
oh-my-posh init pwsh --config $env:POSH_THEME | Invoke-Expression
值不值得装
如果你每天大量时间在终端里，一个信息丰富、一眼能看清上下文状态的提示符确实能省不少事。oh-my-posh 配置一次，跨 shell 复用，维护成本不高。
]]>
    
    https://cyk.pink/posts/85891fe1.html
    
    2026-08-05T02:00:00.000Z
    

      oh-my-posh 是个跨平台的终端提示符美化工具，支持 PowerShell、bash、zsh、fish、cmd。它用 JSON 配置文件定义提示符长什么样，可以显示当前目录、git 分支、执行时间、电池、天气、各种编程语言版本等。

安装
Windows 上最方便的是用 winget：
winget install JanDeDobbeleer.OhMyPosh


装完会多出一个 oh-my-posh.exe。macOS 和 Linux 可以用 Homebrew：

    
    
    
    
    
    
      DOCX Pipeline 是个把 Markdown 转成中文 DOCX 的命令行工具。双后端：Pure Python 零外部依赖，Pandoc 质量更高。v1.2.0 补上了纯 Python 后端对 LaTeX 数学公式的支持，写论文、出报告时不用硬装 Pandoc。
下面先说怎么用，再简单提实现。
安装
Python 3.10 以上：
pip install git+https://github.com/redamancy231-create/docx-pipeline.git
核心依赖会一起装好：python-docx、PyYAML、click、Pillow。Pandoc 和 mermaid-cli 是可选的，后面按需安装。
一分钟上手
1. 初始化项目
docx-pipeline init --project-dir ./my-doc --template report --name "技术报告"
执行完会在 ./my-doc 下生成 project.yaml，里面包含页面、字体、路径、后端开关等所有配置。
四个内置模板：
模板
场景
默认后端
default
通用中文文档
Pure Python
academic
论文/学位论文
Pure Python
report
技术报告，带目录和 Mermaid
Pandoc
strategy
量化策略文档
Pure Python
2. 写 Markdown
模板会给你一个入口文件路径，默认在 ./md/main.md。直接写普通 Markdown 就行，公式用 $...$ 行内、$$...$$ 独立：
---
title: 示例报告
---

# 正文

考虑正弦信号的采样定理：

$$f_s \geq 2 f_{\max}$$

若采样率 $f_s = 100\,\text{Hz}$，则奈奎斯特频率为 $f_N = f_s/2 = 50\,\text{Hz}$。

## 表格

| 参数 | 值 |
|------|-----|
| 采样间隔 | 0.01 s |
| 窗长 | 21 |
3. 转换
cd ./my-doc
docx-pipeline convert --config ./project.yaml
输出路径由 project.yaml 里的 paths.docx_output 决定，默认 ./output/doc.docx。
想换输出文件：
docx-pipeline convert --config ./project.yaml --output ./out/报告.docx
只想看会不会报错，不生成文件：
docx-pipeline convert --config ./project.yaml --dry-run
常用命令
# 查看配置摘要
docx-pipeline info --config ./project.yaml

# 校验配置合法性
docx-pipeline validate --config ./project.yaml

# 强制用 Pure Python 后端
docx-pipeline convert --config ./project.yaml --method pure

# 强制用 Pandoc 后端
docx-pipeline convert --config ./project.yaml --method pandoc

# 传额外参数给 pandoc
docx-pipeline convert --config ./project.yaml --pandoc-args "--number-sections"
init 和 convert 是日常使用最多的两个命令。
配置重点
project.yaml 是全部行为的入口。几个常见调整：
改输入输出路径
paths:
  md_source: "./chapters/main.md"
  docx_output: "./output/报告.docx"
改字体
fonts:
  east_asian: "微软雅黑"
  latin: "Times New Roman"
字体必须在系统里已安装，否则 Word 会回退默认字体。
页面和缩进
page:
  size: "A4"
  orientation: "portrait"
  margins:
    top: 2.54
    bottom: 2.54
    left: 3.18
    right: 3.18

styles:
  paragraph:
    line_spacing: 1.15
    first_line_indent: 0.0   # cm，学术论文可设 0.74 左右
后端开关
pandoc:
  enabled: false          # true 启用 Pandoc
  extra_args: []
  reference_docx: ""      # Pandoc 参考文档路径
enabled: false 时走 Pure Python，LaTeX 公式由 v1.2.0 新增的 latex2mathml → MathML → OMML 桥转换。enabled: true 时走 Pandoc，公式渲染质量更好，但需要系统里有 pandoc。
后端怎么选
不想装 pandoc → Pure Python，一个 Python 环境就够了，公式也能转。
要代码语法高亮、复杂表格、章节自动编号 → Pandoc。
想精确控制中文字体、缩进、行距 → Pure Python 更直接。
Auto 模式（默认）会先看 pandoc.enabled，再看 pandoc 是否在 PATH 里，能 pandoc 就 pandoc，不能就自动降级到 Pure Python。
Mermaid 图表
report 模板默认开启 Mermaid。需要 Node.js 和 mermaid-cli：
npm install -g @mermaid-js/mermaid-cli
Markdown 里写：
```mermaid
flowchart LR
    A[输入] --> B[处理] --> C[输出]
```
转换时会自动渲染成 PNG 嵌入 DOCX。渲染失败的代码块会保留原文并加警告注释。
v1.2.0 公式实现简说
纯 Python 后端新增了一条 LaTeX → Word 原生公式的路径：
扫描 Markdown，把 $...$ 和 $$...$$ 抠出来，替换成占位符。
用 latex2mathml 把 LaTeX 转成 MathML。
用 lxml 遍历 MathML 树，生成 Word 的 m:oMath / m:oMathPara。
行内公式挂到段落里，独立公式包成居中段落。
转换失败就回退成原始 LaTeX 文本，不会让整个文档崩掉。
覆盖分数、根号、上下标、极限、n 元运算符、重音、矩阵、括号、围栏等 14 种结构，有 21 个自动化用例校验。
不过说实话，Pure Python 的 OMML 渲染在分式、根号、大型运算符等复杂式子上还是有缺陷；Pandoc 后端十五年打磨的 TeX 引擎更稳。所以能装 pandoc 的话，复杂公式建议优先 Pandoc 后端。
两个容易踩的坑
Windows 乱码
中文输出在 Windows 下可能乱码，加环境变量：
export PYTHONIOENCODING=utf-8
PowerShell：
$env:PYTHONIOENCODING = "utf-8"
目录重复
如果 Markdown 里已经手写了一个”目录”章节，pipeline 又会自动插入 Word 的 TOC 域，结果出现双目录。要么在 Markdown 里删掉手工目录，要么在 project.yaml 里设 styles.toc.enabled: false。
一句话总结
DOCX Pipeline 让 Markdown → Word 这件事可以一条命令跑完；v1.2.0 之后，公式也不需要 Pandoc 了。写报告、论文、技术文档时，它能省下大量调格式的时间。
]]>
    
    https://cyk.pink/posts/23eb6558.html
    
    2026-07-22T08:00:00.000Z
    

      DOCX Pipeline 是个把 Markdown 转成中文 DOCX 的命令行工具。双后端：Pure Python 零外部依赖，Pandoc 质量更高。v1.2.0 补上了纯 Python 后端对 LaTeX 数学公式的支持，写论文、出报告时不用硬装 Pandoc。

下面先说怎么用，再简单提实现。
安装
Python 3.10 以上：
pip install]]>
    
    
    2026-07-22T08:00:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      增益把深部放大后，一些横向窄的条纹、绕射尾、振铃尾也跟着被放大，在 B-scan 上冒成一片斜纹或竖条毛刺。横向平滑就是沿测线方向做均值替换，把这些窄东西糊掉，横向连续的层位则保留。
和背景去除的区别
背景去除是「减均值」：删掉横向共有的成分，留下横向局部的点目标。
横向平滑是「替换为均值」：把每道替换成左右几道的平均，抹掉横向局部的窄条纹，留下横向共有的连续层位。
两者保留的东西正好相反：
操作
去掉
保留
背景去除
减均值
横向共有（直达波、水平横条）
横向局部（钢筋双曲线）
横向平滑
替换为均值
横向局部（绕射尾、条纹）
横向共有（连续层位）
单级盒式的问题
最简单的做法是用一个矩形窗做一级滑动平均。但它的频率响应是 sinc 函数，旁瓣大——阻带里的纹波压不干净，条纹会留残影。
两级盒式更干净
做两级串联：第一级用较大窗做主要平滑，第二级用小窗磨掉第一级留下的边缘台阶。两个矩形核卷积后等效成一个梯形核，频响近似 sinc²，旁瓣比单级小得多。
实测对比（window=10）：
归一化频率
单级响应
两级响应
两级压到
0.05（通带）
0.577
0.558
97%
0.15
0.177
0.128
72%
0.25
0.091
0.030
33%
0.30
0.091
0.012
13%
通带内两者差不多，不伤层位；阻带内两级把残余压到单级的 1/3~1/8。
梯形核怎么来的
以 window=10 为例：第一级半窗 5（11 点核），第二级半窗 1（3 点核）。算中心点输出时，每个位置被几个第二级抽头「看到」：
中心位置：3 个抽头都看到，权重最大；
边缘位置：只有 1 个抽头看到，权重最小。
把「被看到的次数」画出来就是梯形：1, 2, 3, 3, …, 3, 2, 1。
窗长怎么选
只有一个参数 window：平滑跨度，单位是道数。
斜条纹还在：window 调大；
横向层位被抹糊了：window 调小，或关掉本步；
window 的物理含义 ≈ 想抹掉的横向窄目标的宽度，一般 8~20。
副作用
会抹掉横向窄的真实目标：小孤腔、细裂隙、单根细钢筋都会被糊掉。
破坏幅值定量：每个值被换成邻域均值，原始振幅信息没了。
必须放在流水线最后：它破坏幅值，所有需要真实幅值的步骤都要在它之前。
边界处理
图的两端窗会超出范围。我的做法是截断边界，只用地道内真实数据，除以实际参与平均的道数。不补零、不镜像，避免引入假象。
]]>
    
    https://cyk.pink/posts/bd00ef30.html
    
    2026-07-22T02:00:00.000Z
    

      增益把深部放大后，一些横向窄的条纹、绕射尾、振铃尾也跟着被放大，在 B-scan 上冒成一片斜纹或竖条毛刺。横向平滑就是沿测线方向做均值替换，把这些窄东西糊掉，横向连续的层位则保留。


    

    
    2026-07-22T02:00:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      处理一批灰度图，深部信号弱、看不清，就加了道增益（gain）把深部的幅值往上提。调完增益打开图一看，奇怪了——本来是想让深部亮起来，结果观感是浅部反而变灰了，深部也没见亮多少。第一反应是增益写错了，查了半天代码没问题。
后来才反应过来，这不是增益的 bug，是显示的色阶在捣乱。
全局百分位定色阶，会被放大后的极值撑大
显示这种动态范围很大的灰度数据，一般不会直接用最小最大值定 vmin/vmax——少数极大值（比如直达波那种）会把范围撑得太大，绝大多数数据挤在一头，图就「非黑即白」。常见的做法是用百分位，比如取第 1 和第 99 百分位作为显示的上下限，把长尾削掉，层次就出来了。
问题在于，这个百分位是整张图算的。增益一上去，深部那些本来不强、但被放大了的反射，幅值被抬得很高，整张图的 p99 跟着水涨船高（实测能从不到一万飙到二十多万）。色阶的上限一拉高，那些没被增益放大的浅部数据，在新的色阶里就全被挤向中灰了。
所以调大增益参数，看到的不是「深部变亮」，而是「浅部变灰」——因为色阶被深部的极值撑宽了，浅部在更宽的尺度里自然显得更暗。本质是灰度级被重新分配了，不是数据本身变暗。
想看增益的真实效果，得把色阶锁住
要判断增益到底有没有把深部提亮，得让前后两幅图用同一把尺子量。具体就是把「加增益前」那张图的百分位 [1,99] 记下来，加增益后显示的时候还用这同一组 vmin/vmax，不让它重新算：
vmin, vmax = np.percentile(raw, [1, 99])   # 用原始图定一次色阶

ax[0].imshow(raw,    vmin=vmin, vmax=vmax, cmap='gray')   # 原图
ax[1].imshow(gained, vmin=vmin, vmax=vmax, cmap='gray')   # 增益后，共用同一色阶
这样色阶锁死了，增益放大的深部目标是真的「冒出来」变亮，浅部因为没动还是原来的灰度，对比一目了然。配套加个「锁定色阶」的开关，勾上两图共用原始百分位，不勾就各自算各自的——平时看绝对层次用各自的，调增益判效果一定得锁。
这事给我的一个教训：调一个看起来「没生效」的处理参数，先别急着怀疑算法，想想显示环节是不是也跟着动了。增益改的是数据，百分位色阶也跟着数据重新算，两者一叠加，呈现出来的变化就不是单纯增益的效果了。判断一个处理到底有没有用，得把它放在固定的显示基准下看，不然你调的是参数，被糊弄的其实是色阶。
]]>
    
    https://cyk.pink/posts/e4b2a96c.html
    
    2026-07-15T02:30:00.000Z
    

      处理一批灰度图，深部信号弱、看不清，就加了道增益（gain）把深部的幅值往上提。调完增益打开图一看，奇怪了——本来是想让深部亮起来，结果观感是浅部反而变灰了，深部也没见亮多少。第一反应是增益写错了，查了半天代码没问题。

后来才反应过来，这不是增益的 bug，是显示的色阶在捣乱。
全局百分位定色阶，会被放大后的极值撑大
显示这种动态范围很大的灰度数据，一般不会直接用最小最大值定 vmin/vmax——少数极大值（比如直达波那种）会把范围撑得太大，绝大多数数据挤在一头，图就「非黑即白」。常见的做法是用百分位，比如取第 1 和第 99]]>
    
    
    2026-07-15T02:30:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      手电筒照得越远越暗，雷达波也一样。深部反射回波比浅部弱很多，不补一下，剖面深处就是一片黑。
深部为什么衰减
电磁波往下传，能量衰减来自两方面：
球面扩散：能量摊开，随距离平方变弱（∝ 1/r²）；
介电吸收：介质吸能，随距离指数衰减（∝ e^(−αz)）。
深部反射体回波可能比浅部弱 40~60dB。
时间增益：按时间乘一条固定曲线
造一条随时间单调增长的曲线 $G(t)$，每道信号逐样点乘上去。浅处乘得小，深处乘得大。
三种常见形状：
$$G(t)=\begin{cases}1+p,t & \text{linear}\ e^{,p,t} & \text{exp}\ t^{,p}\text{ 归一化} & \text{power}\end{cases}$$
指数型最贴合指数吸收的物理。设 p=0.051，dt=0.054ns，512 个样点：
位置
时间
增益
相当于
浅
0 ns
1.00
+0 dB
中
10 ns
1.66
+4.4 dB
深
27.6 ns
4.09
+12.2 dB
最深处放大约 4 倍，原本看不见的弱反射被拉到可看的亮度。
不过别搞错：时间增益不是真正的反衰减，真实吸收系数未知。它只是显示补偿，不是物理还原。
AGC：自动音量
AGC 像耳机自动音量：强处压小、弱处放大，让每个深度看起来差不多强。
对每个样点，取前后小窗口算局部 RMS 能量，然后该样点除以这个 RMS：
$$\text{rms}[n]=\sqrt{\frac{1}{W}\sum_{k=-W/2}^{W/2}x[n+k]^2+\varepsilon},\qquad \text{out}[n]=\frac{x[n]}{\text{rms}[n]}$$
强段除以大数变小，弱段除以小数变大，每小段能量都被归一到约 1。
两者差别
时间增益
AGC
曲线
固定预设
看数据自适应算
依据
时间位置
邻域实际能量
效果
温和补深部
强行抹平强弱差
副作用
改变幅值
彻底破坏幅值
gain 后会重新引入直流
即使 gain 前每道已经是零均值，gain 之后均值又可能不等于 0。增益曲线恒正递增，深部样点被放大更多，会把整道均值往深部拽偏。
举个例子，dewow 后零均值的道：
x        = [ 1, -1,  1, -1]     均值 = 0
G        = [ 1,  2,  3,  4]     (浅→深递增)
x·G      = [ 1, -2,  3, -4]     均值 = -0.5
减均值后  = [1.5,-1.5,3.5,-4.5]  均值 = 0
所以有些流程在 gain 后再减一次每道均值，称为 post_gain_dc。它跟 dewow 不是一回事：dewow 是去低频漂移，post_gain_dc 是清 gain 新引入的直流。
注意事项
增益/AGC 会放大噪声，调太大深部就全是雪花。
改变幅值关系，不能定量。「反射越强 = 病害越重」必须回原始数据。
AGC 比固定增益更激进，仅用于显示和目标识别，绝不能用于定量。
AGC 窗长一般取目标回波持续长度的 2~3 倍；固定增益的 p 调到深部看得见、但噪声还没明显冒出来就行。
]]>
    
    https://cyk.pink/posts/5c056d5b.html
    
    2026-07-15T02:00:00.000Z
    

      手电筒照得越远越暗，雷达波也一样。深部反射回波比浅部弱很多，不补一下，剖面深处就是一片黑。

深部为什么衰减
电磁波往下传，能量衰减来自两方面：

球面扩散：能量摊开，随距离平方变弱（∝ 1/r²）；
介电吸收：介质吸能，随距离指数衰减（∝ e^(−αz)）。

深部反射体回波可能比浅部弱 40~60dB。
时间增益：按时间乘一条固定曲线
造一条随时间单调增长的曲线]]>
    
    
    2026-07-15T02:00:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      把一批 16 位采样的数据读进来做了点预处理（去直流、去背景这种减法操作），再写回原来的二进制文件给别的专业软件打开。读进来处理的时候一切正常，写回去打开一看，有的文件好好的，有的直接满屏噪点、糊成一团。同样的代码、同样的处理，结果天差地别，卡了好一阵。
根子是 16 位整数到底按有符号还是无符号解读，不是统一的，取决于文件格式。
同样 16 位，有的围绕 0 有的围绕 32768
这批数据两种格式：一种是无符号 16 位（unsigned），数据的载波零点在 32768，数值在 065535 之间抖；另一种是有符号 16 位（signed），围绕 0 抖，范围是 −3276832767。同样是两个字节 00 80，按无符号读是 32768，按有符号读（小端）是 −32768，完全是两码事。
读的时候按各自格式来，没问题。问题出在写回。
减法预处理之后有了负值
去直流、去背景这类操作本质是减法：估一个背景再从原数据里减掉。减完之后，数据就从「围绕 32768」或者「围绕 0」变成了「围绕 0」，而且必然出现负值（原来低于背景的地方）。
写回有符号格式（围绕 0）的那种文件，很直接——数据本来就围绕 0，减完还是围绕 0，按有符号 clamp 到 [−32768, 32767] 写进去就行，啥额外操作都不用加。
但写回无符号格式（围绕 32768）的那种文件就出事了：减法之后围绕 0、带负值，直接当无符号写回去，那些负值会被解释成 65536 附近的超大数，落在一个本该是中灰的位置上全是亮点，整张图就满屏噪点了。
写回无符号得先平移回它的基准
所以写回无符号格式之前，得先把数据从「围绕 0」平移回「围绕 32768」——加一个全图统一的直流基准（大概就是整图的均值，约等于 32768），把负值整体抬进 0~65535 的范围，再 clamp：
if target_unsigned:
    dc_base = int(round(data.mean()))     # 全图统一的基准，约 32768
    out = data + dc_base                   # 平移回无符号范围
    out = np.clip(out, 0, 65535).astype('<u2')
else:
    out = np.clip(data, -32768, 32767).astype('<i2')   # 有符号直接 clamp，不加基准
有个反着的坑得强调一下：写回有符号格式绝对不能也傻乎乎加个 +32768 的基准。因为数据本来围绕 0，加完 32768 之后落到 32768 附近，再被 (short) 强转，超过 32767 的部分直接溢回 −32768，数据当场写坏。也就是说 clamp 方式必须按目标格式二选一，不能图省事统一一套。
还有一个细节：那个直流基准必须是全图统一的一个值，不能用每一道各自的均值。用各道均值的话，等于把每道都单独拉回自己的 32768，结果是保留了各道之间的直流差——这恰恰是去直流、去背景想抹掉的东西，效果会差很远。这一条是走过弯路之后才纠正过来的：一开始图精确用了各道均值，结果处理完的图还不如不平移干净，换成全图统一直流基准才对。
说到底，这事的核心就一句：16 位数据的有符号、无符号不是读的时候定死就完了，写回的时候还得按目标格式再判一次。同样是「减完带负值」的中间结果，写回有符号和无符号要走的 clamp 路径完全不同，搞混了就是满屏噪点和数据写坏的区别。
]]>
    
    https://cyk.pink/posts/d6c7a14b.html
    
    2026-07-14T05:25:00.000Z
    

      把一批 16 位采样的数据读进来做了点预处理（去直流、去背景这种减法操作），再写回原来的二进制文件给别的专业软件打开。读进来处理的时候一切正常，写回去打开一看，有的文件好好的，有的直接满屏噪点、糊成一团。同样的代码、同样的处理，结果天差地别，卡了好一阵。

根子是 16 位整数到底按有符号还是无符号解读，不是统一的，取决于文件格式。
同样 16 位，有的围绕 0 有的围绕 32768
这批数据两种格式：一种是无符号 16 位（unsigned），数据的载波零点在 32768，数值在 065535 之间抖；另一种是有符号 16 位（signed），围绕 0 抖，范围是 −3276832767。同样是两个字节 00 80，按无符号读是]]>
    
    
    2026-07-14T05:25:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      手上有一批设备采集下来的二进制数据，没文档，只有几组不同后缀的文件，要把它们读出来画图。全程靠 hex 编辑器一点点猜，记一下逆向这种私有二进制格式的大概路数，顺便记一个踩得很疼的 off-by-one。
先把头和样点数摸清楚
这种采集文件，基本结构都是「一个文件头 + 后面一大片采样数据」。第一步是估文件头多大。把文件丢进 hex 编辑器，前面一段往往是固定模式、跟后面的「数据区」长得不一样，头一般是个整数（512、1024、2048 这种）。这批文件摸下来头是 1024 字节。
样点数通常藏在文件头的某个偏移里。怎么找——算一道简单除法：(文件总大小 - 头) / 每道字节数 = 道数，而 每道字节数 = 样点数 × 每个样点的字节。如果数据是 16 位（2 字节）存的，那去文件头里找一个值，使得「头之后的字节数 / 2 / 这个值」是个整数、而且这个值本身是合理的样点数（比如 512）。这批文件样点数在头偏移 4 的位置，值是 512。
到这里，最朴素的读法就有了：跳过 1024 头，后面按 int16 一道一道读：
nsamp = 512           # 头里偏移4读出来的样点数
header = 1024         # 头大小
raw = np.frombuffer(data[header:], dtype='<i2')   # 小端 int16
ntrace = raw.size // nsamp
traces = raw[:ntrace * nsamp].reshape(ntrace, nsamp)
用 magic 字节区分格式
事情没这么简单，因为这批数据有四种后缀、对应四种格式，得知道手里这份是哪种。靠后缀判断不可靠（后缀能随便改），靠谱的是文件头里的「魔数」——每个格式在固定位置有一段独特的字节，相当于这个格式的身份证。
实测下来这批文件：一种开头是 00 07，一种是 56 04 00 00 04 04 00 00，另两种是 01 00 或 00 00。读的时候先嗅探（sniff）一下这几个字节，命中哪种就走哪种的解析器，后缀只当兜底：
def read_auto(path):
    head = open(path, 'rb').read(8)
    if head[:2] == b'\x00\x07':          return read_kind_a(path)
    if head[:4] == b'\x56\x04\x00\x00':  return read_kind_b(path)
    # 剩下的退回看后缀
    ...
有意思的是，其中三种格式摸到最后发现是同一个套路——都是 [1024 头][int16 数据]，只是 magic 不一样，连样点数偏移都一样（纯属不同厂家巧合撞了布局）。所以这三个的解析逻辑抽到了一个公共函数，各自只是薄薄包一层填自己的 magic。
一个 off-by-one，数据道数多算一条
真正折腾人的是第四种。一开始按老套路把它当「[1024 头][int16]」来读，画出来的图第一道总是一根奇怪的直线、后面整体对不齐，怎么调参数都不对。
后来把它的字节流摊开一格一格看，才发现它根本不是「全局头 + 数据」那种结构，而是定长记录流：整个文件就是一条条固定 1028 字节的记录首尾拼接，没有独立的全局头。而且记录还分类型：
第 0 条是「头记录」，前 4 字节是类型码 1110，后面基本是 0；
后面才是数据道记录，每条开头是类型码 82，再跟 512 个 int16 样点。
之前的读法把第 0 条头记录也当成了数据道，所以道数多算了一条、第一道里混进了那条头记录的残值，图自然对不齐。改完之后，先检测开头是不是 1110、是的话跳过这条头记录，真实道数从第 1 条开始数，图一下就正了。
def read_record_stream(data):
    rec = 1028
    nrec = len(data) // rec
    first = np.frombuffer(data[:4], dtype='<i4')[0]
    start = 1 if first == 1110 else 0      # 头记录(type=1110)不算数据道
    traces = []
    for i in range(start, nrec):
        seg = data[i*rec + 4 : i*rec + 4 + 512*2]   # 跳过 type 码读 512 样点
        traces.append(np.frombuffer(seg, dtype='<i2'))
    return np.array(traces)
逆向这种没文档的二进制格式，路数其实挺固定：先估头大小、再从文件大小反推样点数偏移、用 magic 区分同源的几种格式、剩下就是格格里看字节把记录结构猜出来。最后那个 off-by-one 也提醒一件事——别想当然觉得同一批数据都是一种结构，哪怕是同一个采集软件出的，不同后缀可能用的是完全不同的文件模型，按老套路硬套就会多算一条少算一条。
]]>
    
    https://cyk.pink/posts/8b2c5e91.html
    
    2026-07-13T01:40:00.000Z
    

      手上有一批设备采集下来的二进制数据，没文档，只有几组不同后缀的文件，要把它们读出来画图。全程靠 hex 编辑器一点点猜，记一下逆向这种私有二进制格式的大概路数，顺便记一个踩得很疼的 off-by-one。

先把头和样点数摸清楚
这种采集文件，基本结构都是「一个文件头 + 后面一大片采样数据」。第一步是估文件头多大。把文件丢进 hex 编辑器，前面一段往往是固定模式、跟后面的「数据区」长得不一样，头一般是个整数（512、1024、2048 这种）。这批文件摸下来头是 1024 字节。
样点数通常藏在文件头的某个偏移里。怎么找——算一道简单除法：(文件总大小 - 头) / 每道字节数 = 道数，而 每道字节数 = 样点数 × 每个样点的字节。如果数据是 16 位（2 字节）存的，那去文件头里找一个值，使得「头之后的字节数]]>
    
    
    2026-07-13T01:40:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      雷达数据做完前面的清洗，最后一步往往是加增益（gain）。深部反射看不见、一团黑，加完增益深部就亮起来了。但增益到底在补什么、补多少有讲究，不是无脑把深部拉亮就行。另外有篇单独讲做完增益之后显示色阶的坑，这篇只讲增益算法本身。
为什么要补：深部比浅部弱太多
电磁波往地下走，越深衰减越厉害，所以深处的反射回到天线时已经弱了一大截。一道信号画出来，浅部反射很强、深部几乎贴着噪声底，深部想看的目标（比如衬砌后面的脱空）就淹没在里面。增益的作用就是把这个随深度掉下去的幅度，人为往上提一提，让深浅在图上都能看见。
衰减有两种，数学形式不一样
深部变弱这件事，根上有两个来源，得分开看。一个是几何扩散——波往外是球面扩散的，能量摊到越来越大的球面上，幅度按幂律（大约 1/距离）往下掉。另一个是介电吸收——介质本身把电磁能吃掉一部分，这个是按指数 e^(−α·深度) 掉的。
关键在于这俩数学形式不同：一个是幂律、一个是指数。所以想补偿，也得用对应的形式去补，硬拿一个套另一个补不齐。
两种增益对应两种衰减
增益常见的两种类型正好对应上：power 型按幂律补，对应几何扩散；exp 型按指数补，对应介电吸收。要补哪种衰减就选哪种类型。实际数据里两种衰减同时存在，单用 exp 其实只补了吸收那部分，几何扩散那块没单独补——这正是后面会看到的「补不满」的根因。
exp 的参数 p 不是拍脑袋
exp 增益的形式是逐点乘一条指数曲线，关键参数是 p。这里有个容易踩的坑：p 的单位是 1/ns，物理上等于 α·v——α 是介质的吸收系数（每米吸收多少），v 是波速（每纳秒走多少米）。所以 p 不是随便给的数，是能从数据反推的：算一下能量随时间的衰减斜率（对数能量随时间的斜率），那基本就是 α·v，也就是该用的 p。实测下来一批数据这个斜率大概在 -0.045/ns 附近，用 0.05/ns 左右就接近数据本身反推出来的值。
故意不补满
这里有个反直觉的点：实测深部相对浅部衰减了大约 18.5dB，但用 exp(0.05) 只补回来约 12dB，还留着约 6dB 没补。这不算错，是故意的。补得太狠，深浅都被拉平，深部强反射和浅部一样亮，反而看不出深浅层次了。判厚度、判脱空这些是要靠相对强弱判断的，全拉平了反倒没法判。所以温和地补、留一点层次，是刻意的。真要完全补平，p 得往 0.077 那边走。
换句话说，增益是个显示补偿，不是物理反演。它把每道逐点乘同一条 G(t) 曲线（所有道乘同一条），目的是让人眼看得见深部，但不会把衰减掉的能量真的还原回来。增益后的幅值不能拿来当真实幅值定量算。
保幅就别用 AGC
还有个 AGC（自动增益控制），它不分深浅物理机制，直接把局部能量拉平归一——原来局部能量跨深度抖得很厉害（标准差好几千），AGC 一压，各处都归到差不多 1，标准差能压到零点零几。看图特别爽，深浅都清楚。但代价是幅值信息全没了：哪里本来强、哪里本来弱，AGC 之后全都拉平，相对强弱看不出来了。
所以选 exp 还是 AGC，看目的。要保幅、要做定量判读（靠幅值判厚度、判脱空含水），就用 exp，别用 AGC。AGC 只适合纯粹看个图、不在乎幅值大小的场景。
切类型要重定参数
最后说个具体的坑：exp 的 p 单位是 1/ns，power 的 p 是个无量纲的幂指数，这俩「p」名字一样但含义完全不同。从 exp 切到 power（或反过来），参数不能直接照搬，得按新类型的含义重新定，不然补出来的曲线完全不是想要的那条。
增益这一步看着简单（就是逐点乘一条曲线），真正要拿捏的是补什么、补多少。补的是随深度掉的幅度，形式得匹配衰减机制（幂律对几何、指数对吸收），力度上故意留一点层次别拉平，保幅用 exp、纯看图才用 AGC。把它当显示补偿、不当物理反演，就不会指望它把深部能量真的还原回来。
]]>
    
    https://cyk.pink/posts/9c4e8a2f.html
    
    2026-07-12T01:30:00.000Z
    

      雷达数据做完前面的清洗，最后一步往往是加增益（gain）。深部反射看不见、一团黑，加完增益深部就亮起来了。但增益到底在补什么、补多少有讲究，不是无脑把深部拉亮就行。另外有篇单独讲做完增益之后显示色阶的坑，这篇只讲增益算法本身。

为什么要补：深部比浅部弱太多
电磁波往地下走，越深衰减越厉害，所以深处的反射回到天线时已经弱了一大截。一道信号画出来，浅部反射很强、深部几乎贴着噪声底，深部想看的目标（比如衬砌后面的脱空）就淹没在里面。增益的作用就是把这个随深度掉下去的幅度，人为往上提一提，让深浅在图上都能看见。

    

    
    2026-07-12T01:30:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      给桌面软件接了一套登录许可证，启动的时候要过一串校验，任一条不过就直接锁应用。licence 防破解的一些具体坑（时间回拨、指纹漂移）之前写过，这里不重复，主要想理一下：一张许可证启动时到底该查哪些项，以及其中几个不那么直观的、容易漏掉的检查。
整体是个串行链条，前面是许可证本身合不合法，后面是运行环境对不对，最后才是用户名密码。哪一环断了都锁，不是「前面过了后面就随便」。
许可证本体这几项
先是把许可证解析出来，格式不对、签名解析失败，直接锁。然后是有效期，过期了锁——但有效期的判断会被改系统时间绕掉，这块得配合本地单调时间记录来防回拨，之前那篇说过的思路，这里不展开。接着是硬件指纹比对，确认现在这台机器就是许可证绑的那台，防一份 licence 拷来拷去到处用。
这几项是基础，大多数做 licence 的人都会想到。
版本号得跟软件版本对上
这条我觉得容易被忽略。许可证里带一个版本号字段，校验的时候不能只看它「有没有」，得看它是不是等于当前软件的版本。
为什么重要——因为软件会迭代。一份在 v2 时代签发的 licence，里面版本号写的是 2，用户拿着它去跑 v3，如果不校验版本，v3 照样认这份老 licence。这就留下一个口子：买了旧版的人拿着旧 licence 一直白嫖新版本。绑死版本号之后，大版本升级要么重新签发、要么 licence 里显式声明向前兼容哪些版本，主动权在签发方手里。
注册目录得是当初注册的那个
这条更隐蔽。注册成功的时候，把「当时所在的安装目录」记进许可证或者本地凭证里。下次启动，拿当前程序的运行目录（user.dir）跟记下来的那个比一下，不一致就锁。
防的是这种操作：用户在一台机器上注册成功了，然后把整个安装目录连着注册凭证一起打包，拷到另一台机器上跑。光靠硬件指纹的话，如果两台机器硬件凑巧接近、或者指纹本身不够强，可能蒙混过去。但目录是物理路径，拷到别的机器上基本不可能还在同一个绝对路径下，这条等于多加了一层「这确实是当初那台机器、那个位置」的绑定。
配置校核防的是改配置
还有个配置校核（proofread）：启动时把关键的本地配置重新算一遍校验和，跟之前存的比对。防的是破解者不去动 licence 本体（那个有签名，动不了），转而去改本地的配置文件——比如把「已激活」标志、剩余时长这些写死成有利值。配置一旦被改，校验和对不上，锁。
这条的逻辑是：licence 本体有签名护着改不动，那攻击者最可能下手的就是没有签名保护的本地配置，得给这部分也上个完整性校验。
最后才是用户名密码
所有上面的环境校验都过了，才走到用户名密码这一步。它放在最后是有讲究的：用户名密码防的是「会操作电脑但不会逆向」的人，真正能破前面那些链路的人，根本不需要猜密码。所以把它放最前面没意义，先确认环境和许可证没问题，最后再用密码挡一道普通使用者层面的越权。
这一串串起来，思路其实就是「licence 本体靠签名、运行环境靠多维度绑定」。签名保证许可证没被改，版本号、目录、配置校核把「拿合法 licence 换个环境用」这条路一层层堵上，最后用密码挡住普通越权。哪条单独拎出来都不绝对，但叠成一个链条之后，想绕过去得同时把好几处都对上，门槛就上去了。
]]>
    
    https://cyk.pink/posts/3f7d9c2b.html
    
    2026-07-11T07:55:00.000Z
    

      给桌面软件接了一套登录许可证，启动的时候要过一串校验，任一条不过就直接锁应用。licence 防破解的一些具体坑（时间回拨、指纹漂移）之前写过，这里不重复，主要想理一下：一张许可证启动时到底该查哪些项，以及其中几个不那么直观的、容易漏掉的检查。

整体是个串行链条，前面是许可证本身合不合法，后面是运行环境对不对，最后才是用户名密码。哪一环断了都锁，不是「前面过了后面就随便」。
许可证本体这几项
先是把许可证解析出来，格式不对、签名解析失败，直接锁。然后是有效期，过期了锁——但有效期的判断会被改系统时间绕掉，这块得配合本地单调时间记录来防回拨，之前那篇说过的思路，这里不展开。接着是硬件指纹比对，确认现在这台机器就是许可证绑的那台，防一份 licence 拷来拷去到处用。
这几项是基础，大多数做 licence 的人都会想到。

    
    
    2026-07-11T07:55:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      做了个注册机给桌面软件签发许可证，注册机本身有个管理员解锁密码——不是最终用户的密码，是防止谁都能进来乱签 license 的那道门。一开始图省事，密码明文写在 gradle.properties 里，程序运行的时候读出来比对。能用是能用，但越想越不对劲。
问题在于，这个密码随包一起发出去了。gradle.properties 里的值，打包完之后会以某种形式落到产物里，最差就是直接生成一个 register.properties 跟着 exe 走。破解者拿到发版包，翻一翻配置文件，明文密码就在那儿躺着，这道门等于没上锁。
后来改成这样：密码在打包阶段就转成 MD5，然后通过 exe4j 的 VM 参数固化进 exe，运行时直接从系统属性里读 MD5 来比对，全程不落外部配置文件。
打包脚本里大致是：
// 打包时把明文密码算成 MD5，塞进 exe4j 的 VM 参数
def pwdMd5 = md5(project.property('registerPassword'))
def vmArgs = "-Dregister.password.md5=${pwdMd5}"
// 这段 vmArgs 写进 exe4j 配置，随 exe 一起固化
运行时校验这边，按优先级找这个 MD5：
private String resolveExpectedPasswordMd5() {
    // 1. 打包时通过 -Dregister.password.md5 注入的（生产）
    String md5 = System.getProperty("register.password.md5");
    if (StringUtils.isNotEmpty(md5)) {
        return md5;
    }
    // 2. 开发态 IDEA 直接跑，读 properties 里的明文现算（仅本机）
    String pwd = loadDevProperties().getProperty("registerPassword");
    if (StringUtils.isNotEmpty(pwd)) {
        return md5(pwd);
    }
    // 3. 兜底
    return md5(FALLBACK_PASSWORD);
}
用户输入密码，同样 md5 一遍，跟期望值比，对得上才放行。全程只存和比 MD5，明文密码不进运行态、不落盘。
这么改之后几个好处。一是发版包里翻不到明文密码了，最起码「翻配置文件」这条路堵死了，想拿原值得反 exe。二是 VM 参数 -D 是打进 exe4j 配置、随 exe 固化的，不是旁边带个文件，没那么容易被一眼发现和替换。三是开发态不受影响——IDEA 里直接跑 main 的时候没有那个 VM 参数，就走第二条读 properties 现算，本机调试照样方便。
当然这不是什么高强度的防护，MD5 本身早不该直接用来存密码（正经得加盐、用慢哈希），注册机这个场景门槛要求没那么高，这么搞够用。真要紧的是别把明文密码跟包一起发出去——那不叫加密，那叫附赠钥匙。
]]>
    
    https://cyk.pink/posts/c4e2b81a.html
    
    2026-07-10T03:08:00.000Z
    

      做了个注册机给桌面软件签发许可证，注册机本身有个管理员解锁密码——不是最终用户的密码，是防止谁都能进来乱签 license 的那道门。一开始图省事，密码明文写在 gradle.properties 里，程序运行的时候读出来比对。能用是能用，但越想越不对劲。

问题在于，这个密码随包一起发出去了。gradle.properties 里的值，打包完之后会以某种形式落到产物里，最差就是直接生成一个 register.properties 跟着 exe 走。破解者拿到发版包，翻一翻配置文件，明文密码就在那儿躺着，这道门等于没上锁。
后来改成这样：密码在打包阶段就转成 MD5，然后通过 exe4j 的 VM 参数固化进 exe，运行时直接从系统属性里读 MD5 来比对，全程不落外部配置文件。
打包脚本里大致是：

    
    
    2026-07-10T03:08:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      用 exe4j 把一个 JavaFX 桌面程序打成 exe，自带 JRE 一起发出去，结果双击 exe 直接弹「找不到 jvm」之类的错。机器上明明装了 Java，自带的 JRE 目录也都在，就是起不来。
折腾一圈发现是 exe4j 找 JRE 的路径没配对。
exe4j 打出来的 exe 本质是个启动器，它自己不包含 JVM，运行的时候要先在机器上找一个可用的 JRE 再拉起真正的程序。它找 JRE 是按一个「搜索顺序」来的，默认会先去找系统注册的 Java、JAVA_HOME 之类，找不到才往下走。问题就出在这：开发机上系统 Java 是高版本的，能蒙混过去；到了用户那台干净机器上，啥系统 Java 都没有，它又没被告诉「去我自带的那个 ./jre 里找」，自然就报找不到。
修法是在 exe4j 的配置里显式给一个搜索路径，优先指向打包进去的那个 JRE 目录。exe4j 的配置是份 xml，对应的是 <searchSequence> 这一段：
<searchSequence>
  <directory location="./jre" />
</searchSequence>
就是把「相对于 exe 所在目录的 ./jre」放到搜索序列的最前面。打包的时候把精简过的 JRE（我用 jlink 裁了一份只含要用的模块的）整个放到发版目录的 jre/ 下，exe 起来就先从这儿找，稳稳命中自带的那份，跟用户机器上装没装 Java 彻底脱钩。
有个坑顺带说一下：这个 JRE 目录名得和配置里写的对得上，打包脚本挪文件的时候别把 jre 改名或者放到别的层级，否则 ./jre 这个相对路径就指空了，又是同样找不到的报错。我用 Gradle task 自动生成这份 exe4j 配置 + 拷 JRE，两步用同一个目录变量串起来，省得手抖对不上。
其实这类「在我这好好的、到你那不行」的问题，根子基本都是把开发机上的环境当成了默认环境。启动器找 JRE 这种事，别指望它自己去猜，显式把自带 JRE 的路径塞到搜索序列最前面，一份自包含的 exe 才算真的能到处跑。
]]>
    
    https://cyk.pink/posts/9f3a7c2e.html
    
    2026-07-09T08:20:00.000Z
    

      用 exe4j 把一个 JavaFX 桌面程序打成 exe，自带 JRE 一起发出去，结果双击 exe 直接弹「找不到 jvm」之类的错。机器上明明装了 Java，自带的 JRE 目录也都在，就是起不来。

折腾一圈发现是 exe4j 找 JRE 的路径没配对。
exe4j 打出来的 exe 本质是个启动器，它自己不包含 JVM，运行的时候要先在机器上找一个可用的 JRE 再拉起真正的程序。它找 JRE 是按一个「搜索顺序」来的，默认会先去找系统注册的 Java、JAVA_HOME 之类，找不到才往下走。问题就出在这：开发机上系统 Java 是高版本的，能蒙混过去；到了用户那台干净机器上，啥系统 Java 都没有，它又没被告诉「去我自带的那个 ./jre 里找」，自然就报找不到。
修法是在 exe4j 的配置里显式给一个搜索路径，优先指向打包进去的那个 JRE 目录。exe4j 的配置是份 xml，对应的是 <searchSequence>]]>
    
    
    2026-07-09T08:20:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      整张 GPR 剖面上常有一层「每道都长一样」的横向条带，像照片蒙了灰雾。擦掉它，局部目标才显出来。
从哪来
有些成分在全测线每一道都几乎相同：
直达波：发射天线直接窜到接收天线，每道开头都有；
地表或天线面的反射、耦合响应；
大范围的均匀层状反射。
它们在每个位置出现的时间和强度都差不多，画出来就是水平横条，盖住局部异常。
平均道就是背景
对每个时间样点，把所有道的值求平均，得到一条「平均道」。水平背景在每道都一样，在平均里相干保留；局部目标位置相位不同，互相抵消。
从每道减去这条平均道，背景没了，局部目标活下来。
统一公式：
$$D_{out}[t,x]=D[t,x]-\alpha\cdot\hat B[t,x],\qquad \alpha\in[0,1]$$
$\alpha=1$ 全减；$\alpha<1$ 部分减，适合既看点目标又想看连续界面的情况。
背景估计的几种方法
全局 mean/median：所有道一起求均值或中位数。
滑窗 mean/median：只取当前道附近窗口内的道求平均，适合背景沿测线缓慢变化。
SVD：取数据矩阵前几个奇异图，背景通常低秩。
f-k 滤波：在二维频谱里把低空间波数成分当背景去掉。
mean 还是 median？
一个 3×4 的迷你 B-scan：第 0 行是直达波（每道都是 50），第 1 行第 3 道有一根钢筋（30）：
            道1  道2  道3  道4
行0(直达波)  50   50   50   50
行1(有钢筋)   2   30    3    1
用 mean：行 1 平均被钢筋拉到 9，减完后其他道出现 −7/−8 的凹坑。
用 median：行 1 中位数是 2.5，减完后钢筋 +27.5，其他道几乎不受影响。
有孤立强目标时，优先用 median。
最大的陷阱
如果你要找的目标本身就是连续水平界面，比如层间脱空、连续裂隙，它在每道都出现，也会被当成背景减掉。
找钢筋、管线这种点目标：背景去除是好工具；
找脱空、连续裂隙这种面目标：关掉背景去除，或者把窗调得很大。
判读要点：顶部直达波亮纹变淡、局部双曲线更清楚，就对了。同时要警惕横向连续反射有没有莫名消失。
]]>
    
    https://cyk.pink/posts/3440ab25.html
    
    2026-07-08T02:00:00.000Z
    

      整张 GPR 剖面上常有一层「每道都长一样」的横向条带，像照片蒙了灰雾。擦掉它，局部目标才显出来。

从哪来
有些成分在全测线每一道都几乎相同：

直达波：发射天线直接窜到接收天线，每道开头都有；
地表或天线面的反射、耦合响应；
大范围的均匀层状反射。

它们在每个位置出现的时间和强度都差不多，画出来就是水平横条，盖住局部异常。

    

    
    2026-07-08T02:00:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      探地雷达的剖面图（B-scan）上，经常有一些横向几乎不变的条带或底色——直达波、天线环回响、系统本底。它们跟具体的地下反射没关系，却往往占了大头，把真正想看的弱反射压在下面看不清。背景去除就是想办法把这些共模背景估出来再减掉。
先跟 dewow 划清界限：dewow 沿时间轴（每道内部）去道自己的低频漂移；背景去除沿空间轴（道与道之间）去横向的共模背景。两者方向正交。统一写成一个公式就是 D − α·B̂——估一个背景 B̂，乘个强度系数 α 再减掉，alpha 默认 1.0 就是全减。
难点不在「减」，在「背景 B̂ 怎么估才估得准」。试下来几种路子各有擅长的场景。
mean / median：沿线平均，最朴素
最直接的是沿空间方向（跨道）求平均当背景。直达波这种几乎每道都一样的东西，一平均就冒出来了，减掉很干净。把均值换成中位数（median）就是 median 法，好处是抗异常——少数几道的强反射不会把整体背景带偏。
这一类对「横向基本恒定」的背景效果好。但雷达数据里的背景不总是规规矩矩水平的，有时候是斜的（剖面沿线有倾角）、有时候是周期性振铃（ringing），mean 沿线一平均，倾斜的条带平均不掉、振铃也对付不了，这时候就得换家伙。
SVD 低秩：背景本质是低秩的
换一个角度看：一条横向恒定的背景，在「道×时间」这个矩阵里其实就是秩为 1 的成分（每一道都差一个常数）。倾斜的条带也一样，本质还是秩 1，只是均值法没顺着它的斜路去减。
SVD 法就是利用这个——对数据矩阵做奇异值分解，最大那几个奇异值对应的，往往就是这些占大头的背景结构。砍掉前 k 个主分量（比如 k=1），用剩下的奇异值重构，背景就没了：
def _svd_background(data, k=1):
    U, S, Vt = np.linalg.svd(data, full_matrices=False)
    S[:k] = 0                      # 砍掉前 k 个最大奇异值
    return (U * S) @ Vt            # 重构 = 背景
它的好处是数据驱动，不假设背景水平——倾斜条带、振铃这种 mean 减不动的，SVD 砍掉对应的秩就干净了。代价是要算一次 SVD，数据大的时候比 mean 慢，工程上可以降到 float32 省时间。
f-k 频域：压掉低空间波数
还有一招是变换到频率-波数域（f-k 域）处理。思路是：横向缓变的背景，在空间频率（波数 kx）上表现为低波数成分——波长很长、变化很慢。反过来，局部反射是高波数。所以在 f-k 域把低空间波数（|kx| 小于某个截止 fk_kcut）的成分抠出来当背景减掉，留下的就是局部变化：
截止 fk_kcut 的单位是「每道多少个周期」，默认取 0.02 左右，大致意思是波长超过 50 道的才算背景。这招对横向恒定的背景特别彻底，残差能压到很小，同时局部凸起（真正的反射）原样留下。它跟 SVD 都是「空间低通当背景、减完得空间高通」的思路，f-k 是频域的砖墙低通，更锐利。
alpha：留一手护住连续界面
有个旋钮 alpha 得单独说，它控制减多少。默认 1.0 是全减，但有时候不能减这么狠。雷达里有一类东西是「连续的水平界面」——层间脱空、连续裂隙，它们本身就是横向延展的，长得跟背景很像。背景去除开满，会把这种连续界面也当背景一起抹掉，该看到的病害反而没了。
碰到这种情况就把 alpha 调小（部分减除），或者把窗开大、甚至关掉这一步。经验上是：要同时看钢筋点状反射和脱空这种连续界面，alpha 不能给到 1，得留一部分背景护住连续界面。这也是背景去除最容易翻车的地方——减得太干净，连该留下的东西一起干净了。
怎么选
水平静态背景（直达波最典型）→ mean 就够，又快又简单；剖面有倾角、有振铃 → 上 SVD；横向强缓变背景、想干净留局部凸起 → f-k；碰到连续水平界面型病害 → alpha 调小或跳过这一步。位置上，背景去除放在 dewow 和带通之后、增益之前。
背景去除的核心其实就一句话：背景和反射在「空间方向上的变化快慢」上不一样，背景慢、反射快，想方设法把慢的估出来减掉就行。mean 是最朴素的估法，SVD 和 f-k 是更聪明的估法，alpha 是防误伤的保险——选哪个，看背景长什么样、有没有不能误伤的连续界面。
]]>
    
    https://cyk.pink/posts/1e9f4c6b.html
    
    2026-07-07T06:00:00.000Z
    

      探地雷达的剖面图（B-scan）上，经常有一些横向几乎不变的条带或底色——直达波、天线环回响、系统本底。它们跟具体的地下反射没关系，却往往占了大头，把真正想看的弱反射压在下面看不清。背景去除就是想办法把这些共模背景估出来再减掉。

先跟 dewow 划清界限：dewow 沿时间轴（每道内部）去道自己的低频漂移；背景去除沿空间轴（道与道之间）去横向的共模背景。两者方向正交。统一写成一个公式就是 D − α·B̂——估一个背景 B̂，乘个强度系数 α 再减掉，alpha 默认 1.0 就是全减。
难点不在「减」，在「背景 B̂ 怎么估才估得准」。试下来几种路子各有擅长的场景。
mean /]]>
    
    
    2026-07-07T06:00:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      前面写过一版防时间回拨，思路是本地存一个「上次见过的时间」，下次启动发现现在比它还早，就判定时间被调过。那招够用但比较朴素，只能挡住随手调表的人。后来又琢磨了一圈，离线环境里想认真防「改系统时间续命」，其实有几条不同路数的思路，单独哪一条都有破法，得叠着用。
先说个大前提：完全离线、又不能联网对时的环境下，这是软件防破解里的经典难题，没有银弹。下面这些都是抬门槛，不是绝对防住。
别看「现在几点」，看「过去留的痕」
第一类思路是文件时间戳审计。软件运行的时候，往系统各处（日志、临时目录、配置文件深处、注册表角落）偷偷写一些文件。每次启动去读这些文件的最后修改时间，只要发现当前系统时间比某个历史文件的修改时间还早——说明时间被往回调了，直接锁死。逻辑是：正常情况下，现在不可能比过去还早。
这招成本最低，但文件能被删，删干净了就重置，所以只能当一道初筛。
时间能倒退，运行时长不能
第二类是单向计数器，我觉得是更靠谱的方向。墙上的时钟能调，但「软件实际跑了多久」这件事，用户没法自然地把它调回去。
具体两种做法。一种是限制使用次数：许可证带一个最大次数，每次启动在本地加密文件里扣一次，用完就锁。另一种是累计运行时间：后台开个线程，软件每跑一段时间，就在本地累计一下。然后拿这个累计时长去跟系统时间流逝的量对账——系统时间说只过了一小时，可我记着的累计运行时长涨了十小时，那中间一定被调过表。
对账用的「实际跑了多久」不能用 System.currentTimeMillis()，那个跟着系统时钟走，一调表就废。得用单调时钟，Java 里就是 System.nanoTime()。它不受墙上调时间影响，只反映真实流逝的纳秒：
// 后台线程周期性累计真实运行时长（nanoTime 单调，不受改系统时间影响）
private volatile long accumulatedNanos;
private long segmentStart = System.nanoTime();
while (running) {
    long elapsed = System.nanoTime() - segmentStart;
    accumulatedNanos += elapsed;
    persistAccumulated(accumulatedNanos);   // 加密落盘
    segmentStart = System.nanoTime();
    Thread.sleep(INTERVAL);
}
启动时把「系统时间流逝」和「nanoTime 累计」一对，差得离谱（比如系统时间几乎没走、累计时长却涨了一大截，或者反过来系统时间大跳而累计没动）就认定被动了手脚，锁应用。这比单纯记墙上时间硬，因为它不依赖「时间只往前走」这个假设，而是直接量「真实运行量」。
借别人频繁更新的时钟对账
第三类是跨应用对账，专门对付那种「运行时间很短、关了再开」的工具。你的软件可能就跑几秒，累计时长根本攒不起来，用户大可以「跑五秒、关掉、调表、再跑五秒」地白嫖。
这种就别指望自己的运行时长了，借系统里那些天天在跑的东西：Windows 读系统事件日志里最近一条事件的时间，Linux/macOS 看 ~/.bash_history、/var/log 下最新文件的时间。这些都是别的程序留下的时间脚印，你启动的时候如果发现系统时间比这些脚印还早，那系统时间肯定被倒拨了。
硬件单调时钟和加密狗
再往上还有硬件层的招。就算改了墙上时间，有些底层时钟是调不回去的：Windows 的 GetTickCount64、Linux 的 clock_gettime(CLOCK_MONOTONIC)，表示本次开机以来流逝的毫秒，跟系统时钟脱钩。每次退出前把这次的 monotonic 时间累加存下来，能挡「开机时长」被作弊。再往上就是带独立时钟芯片的 USB 加密狗了，软件只向狗要时间，改系统时间完全没用，那是高价值软件才上得起的配置。
计数器存哪儿才不被删
上面这些都绕不开一个问题：计数器、累计时长存在哪，才不会被用户直接删掉重置。删了文件、软件以为是第一次运行，前面全白干。实务里是散着存：一部分放应用自己的数据目录（放正经的签名许可证文件），一部分加密后伪装成系统文件丢到临时目录的角落，Windows 还可以塞注册表深处。不指望哪一处绝对安全，而是让用户没法一眼找全、删干净。
兜底还有个体验问题：主板电池没电、跨时区出差、系统自动对时，都可能让时间无意中跳一下，一刀切锁死会招来客诉。所以一般都留个宽限期，差得小的当时区抖动记下来警告但不锁，差得大的才真锁。
这几条叠下来，核心其实就是把信任从「系统能不能给个准时间」换成了「用户改不了的那些量」——真实运行时长、别人的时间脚印、硬件单调时钟。单拎一个都有破法，叠在一起，普通用户基本没那个耐心去一个个找全删干净。
]]>
    
    https://cyk.pink/posts/2e8c4d61.html
    
    2026-07-06T06:30:00.000Z
    

      前面写过一版防时间回拨，思路是本地存一个「上次见过的时间」，下次启动发现现在比它还早，就判定时间被调过。那招够用但比较朴素，只能挡住随手调表的人。后来又琢磨了一圈，离线环境里想认真防「改系统时间续命」，其实有几条不同路数的思路，单独哪一条都有破法，得叠着用。

先说个大前提：完全离线、又不能联网对时的环境下，这是软件防破解里的经典难题，没有银弹。下面这些都是抬门槛，不是绝对防住。

    

    
    2026-07-06T06:30:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      处理探地雷达（GPR）数据，拿来第一步基本都先做 dewow。刚接触的时候光看名字不知道它在去什么，后来弄明白了，记一下。
先说两个词。雷达每次发射接收，得到的是一条沿时间方向的采样序列，叫一道（A-scan）；把很多道沿测线方向排开，就成了二维的剖面图（B-scan）。dewow 处理的是「一道」内部的事。
一道信号本来该围绕 0，实际常常整体漂
理论上，去掉直达波以后，一道雷达信号应该围绕 0 这条基线上下抖动——有反射的地方抖一下，没反射的地方贴着 0。实际拿到的数据不是这样，整条信号会慢慢往上拱一段、又往下沉一段，整体不贴着 0，像是在一个缓慢起伏的包络上叠加了高频反射。这个慢漂就叫 wow。
wow 这个词是早期音响那边的行话，本来指唱片转速不稳导致的声音低频飘忽，借过来形容信号的低频基线漂移。它的来源一般是天线跟地面的耦合、仪器本底、线缆感应这些，跟真正的地下反射没关系，但它占着基线、带着整道信号跑偏。
为什么要先去掉它——基线不归零，后面一堆处理都受拖累。算能量、判反射强度的时候，慢漂会垫一层虚假的底；显示的时候，整道压在直流偏置上，弱反射更看不清。
沿时间方向算个滑动平均，再减掉
做法很直白：沿时间方向（每道内部）做一个滑动平均，得到那条慢漂的包络线，然后从原信号里把它减掉：
def dewow(data, window=101):
    trend = boxcar_mean(data, window, axis=0)   # 沿时间轴(axis=0)的滑动平均
    return data - trend
滑动平均是个低通，原信号减掉低通剩下的就是高频——所以 dewow 本质上是个高通滤波，把低频漂移滤掉，留下相对高频的反射。这一步的代码其实就一行减法，真正要拿捏的是那个 window（窗长）。
窗长就是截止频率，太小会把真信号也削了
窗长直接决定去多「低」的频。窗越长，滑动平均越平滑、跟得上的漂移越慢，等于截止频率越低，只去更低的频；窗越短，截止频率越高，连稍微低一点的有用反射都当漂移给减了。
这是个要小心的地方：窗太小，会把真实的低频目标（比如深部的大块反射）当成 wow 削掉，深部信息受损；低频天线、探测深部大目标的数据，dewow 不能开太狠。默认一百出头个样点是个常用起点，具体得看数据的时间窗和天线主频调。
这一步是沿时间轴，跟背景去除别搞混
有个特别容易混的点：dewow 是沿时间轴（每道内部，axis=0）去每道自己的低频漂移。而后面要做的「背景去除」是沿空间轴（道与道之间，axis=1）去横向的共模背景。两个方向正交，处理的东西完全不同——一个是道内的慢漂，一个是跨道的条带。光看「都是减一个平均」容易以为是一回事，实际上轴不一样，减出来的效果差很远。
位置在最前面
dewow 在整条处理流水线里是第一步，在带通、背景去除、增益之前。先把每道拉回 0 基线，后面才有干净的数据接着处理。顺带一个坑：dewow 减完会出负值，写回文件的时候有符号、无符号格式要分开 clamp，这个之前单独写过，不展开了。
dewow 说穿了就一件事：沿每道时间方向，减掉那条不贴 0 的慢漂，让信号回到围绕 0 的状态。它不解决反射弱、背景条带那些问题，但作为流水线的第一道清洗，基线不归零后面啥都谈不上。
]]>
    
    https://cyk.pink/posts/5b8c3e91.html
    
    2026-07-05T02:15:00.000Z
    

      处理探地雷达（GPR）数据，拿来第一步基本都先做 dewow。刚接触的时候光看名字不知道它在去什么，后来弄明白了，记一下。

先说两个词。雷达每次发射接收，得到的是一条沿时间方向的采样序列，叫一道（A-scan）；把很多道沿测线方向排开，就成了二维的剖面图（B-scan）。dewow 处理的是「一道」内部的事。
一道信号本来该围绕 0，实际常常整体漂
理论上，去掉直达波以后，一道雷达信号应该围绕 0 这条基线上下抖动——有反射的地方抖一下，没反射的地方贴着 0。实际拿到的数据不是这样，整条信号会慢慢往上拱一段、又往下沉一段，整体不贴着 0，像是在一个缓慢起伏的包络上叠加了高频反射。这个慢漂就叫 wow。
wow]]>
    
    
    2026-07-05T02:15:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      之前研究了一下 keygen（GitHub 上 keygen-sh/keygen-api，一个开源的软件许可服务），想搞清楚工业级的软件授权到底是怎么组织的。看完最大的感受是，它早就不是那种「写个算法、算出一串序列号、客户端拿同样算法校验」的老路子了——那种算法只要被逆出来就全军覆没。keygen 把授权拆成了一套类似图模型的东西在服务端动态管。
整个体系围绕三个东西转：策略（Policy）、许可证（License）、设备（Machine）。策略是规则模板，比如「能激活 3 台机器、有效期一年、每 30 天必须联网一次」；许可证是卖给用户的实体，绑在某个策略上；设备是许可证真正消耗的额度，每激活一台就建一个 Machine 节点、扣一个名额。这套拆法把「卖了多少份」「每份能绑几台」「谁在用」分得很干净，加规则改策略就行，不用动许可证本身。
离线验签靠非对称加密
我觉得这是它最核心的一手。光靠联网请求校验有个致命问题：破解者本地起一个假服务器（mock），把你客户端的请求全拦下来返回「合法」，校验就形同虚设。keygen 的做法是服务端用非对称加密（Ed25519）的私钥给许可证数据签名，客户端只内置公钥。这样它支持完全离线校验——只要签名验得过、数据没被改过，就认。私钥一直在服务端，客户端 mock 再像也没用，因为它签不出合法的签名。
这点其实跟自己做 JWT 授权是一个思路：私钥签、公钥验，把信任根钉在密钥上而不是网络上。
在线激活是把设备和许可证绑死
用户拿到 key 之后在软件里填，客户端带着 key 和本机的硬件指纹去调 validate 接口。服务端查这个 key 合不合法、过没过期，没问题而且是新设备的话，就在后台给它建一个 Machine 节点、扣名额，然后返回一个短期有效的 token。指纹这东西是用来防「一码多绑」的——同一份 key 想在第十台机器上激活，名额不够就拒掉。
运行期间还有心跳：隔几天客户端回来打一次卡，策略里配了心跳的话，超时没报到，这台设备在服务端就被标记失效，下次得重新联网。这条主要是防退款之后继续用、以及及时回收已经不用的授权。
断网环境走文件换码
真正麻烦的是机房、内网这种完全连不上外网的场景。keygen 给的是一套「文件换码」流程：断网机器上软件导出一个带本机指纹的请求文件；用户把它拷到能上网的机器、传到官网；服务端校验后用私钥签一个许可证凭证文件；用户再把它拷回断网机器导入，客户端拿内置公钥验签、比对指纹，过了就离线解锁。
绕了一圈，离线模式下信任还是落在「私钥签名 + 公钥验签 + 设备指纹」这三件套上，联网只是换个地方做这件事。
研究下来其实就一条主线：keygen 把密码学、设备指纹、并发名额、过期控制这些东西，解耦成了一套干净的 RESTful API。开发者不用自己在数据库里写一堆授权判断，客户端要么调它的接口、要么本地拿公钥验签，就能搭出一套还算像样的授权体系。它当然不是无敌的——私钥泄露、客户端被深入逆向都一样会破，但作为「许可即服务」的基础设施，这套抽象确实把脏活都收走了。
]]>
    
    https://cyk.pink/posts/6c1e8a3f.html
    
    2026-07-04T01:12:00.000Z
    

      之前研究了一下 keygen（GitHub 上 keygen-sh/keygen-api，一个开源的软件许可服务），想搞清楚工业级的软件授权到底是怎么组织的。看完最大的感受是，它早就不是那种「写个算法、算出一串序列号、客户端拿同样算法校验」的老路子了——那种算法只要被逆出来就全军覆没。keygen 把授权拆成了一套类似图模型的东西在服务端动态管。

整个体系围绕三个东西转：策略（Policy）、许可证（License）、设备（Machine）。策略是规则模板，比如「能激活 3 台机器、有效期一年、每 30 天必须联网一次」；许可证是卖给用户的实体，绑在某个策略上；设备是许可证真正消耗的额度，每激活一台就建一个 Machine 节点、扣一个名额。这套拆法把「卖了多少份」「每份能绑几台」「谁在用」分得很干净，加规则改策略就行，不用动许可证本身。

    

    
    2026-07-04T01:12:00.000Z