天空软件工作室的博客 — 全部文章

Astro 混合渲染怎么做？SSG 与 SSR 按页面级切换的完整实践

Mon, 28 Sep 2026 00:00:00 GMT

Astro 的混合渲染只需要两个动作：全局设 output: 'server'，再在静态页面顶部加一行 export const prerender = true。这样构建期就把首页、列表页打成静态 HTML，只有真正需要读 Cookie 的付费文章页走 Node 服务端按请求渲染，性能与权限门控两全。

为什么内容站需要混合渲染？

纯静态最快，但付费墙必须在服务端读会话并截断正文；纯 SSR 灵活，却把首页、归档这类"内容永不变"的页面也变成了每请求计算。混合渲染的本质是：按页面分配渲染时机——内容在构建期已确定的页面在构建期渲染，内容依赖请求上下文的页面在请求期渲染。

怎么配置 Astro 5 的混合渲染？

先装 Node 适配器，然后在 astro.config.mjs 里声明 server 输出：

// astro.config.mjs
import { defineConfig } from 'astro/config';
import node from '@astrojs/node';

export default defineConfig({
  output: 'server',                 // 默认 SSR
  adapter: node({ mode: 'standalone' })
});

静态页面在文件顶部声明预渲染：

---
// src/pages/index.astro
export const prerender = true;      // 这一行让该页在构建期生成静态 HTML
---

prerender 是页面级开关，不影响其他路由。需要按请求读 Cookie 的页面保持默认（SSR）即可。

付费文章页为什么要 SSR？

判断"当前用户能不能看全文"只能发生在服务端：读会话 Cookie → 查会员身份/单篇授权 → 决定输出全文还是截断版。这个流程发生在每一条请求上，因此文章详情页整体走 SSR 是最简单可靠的做法。

// src/pages/posts/[...slug].astro（示意）
export const prerender = false;     // SSR：每请求判定权限

const { slug } = Astro.params;
const entry = await getEntry('posts', slug);
const decision = resolvePostAccess(Astro.locals.user, entry);
// decision.full ? 输出全文 : 输出服务端截断后的墙前内容

两个必须守住的底线：

截断在服务端完成——绝不能把全文发给浏览器再用 CSS/JS 藏起来，查看源码即泄露；
墙前内容进初始 HTML——标题、目录、摘要、FAQ 必须是服务端渲染的静态标签，AI 爬虫多数不执行 JS。

上线前怎么验证效果？

三步：npm run build 检查构建日志中各页面的渲染方式；用 curl 匿名请求一篇付费文章，确认返回的 HTML 里没有付费段正文；跑一次 Lighthouse 确认静态页性能达标。更完整的权限判定实现可参考本站源码 src/lib/access.js，页面级切换的思路也适用于 Node.js 流式处理等服务端场景。

常见坑

中间件在构建期也会执行：混合输出下，prerender 页面在 build 时会跑一遍中间件，因此中间件里不要做"必须有请求上下文"的强假设（读 Cookie 返回空是正常的）。
适配器与托管平台绑定：@astrojs/node 用于自有服务器/Nginx 反代，上 Vercel/Netlify 则换对应适配器。
sitemap 要自己补 SSR 页面：@astrojs/sitemap 只收录预渲染页，付费文章页需要手工加入站点地图。

逆向工程的方法论是什么？从入口定位到算法还原的通用路径

Sat, 05 Sep 2026 00:00:00 GMT

逆向分析的通用方法论只有五步：明确目标 → 定位入口 → 追踪数据流 → 还原逻辑 → 闭环验证。所有具体技巧都挂在这条链上。这篇文章把这五步展开，让你在拿到任何陌生目标时有一张确定性的地图。

为什么逆向需要方法论而不是技巧？

技巧（某个 Hook 点位、某条 IDA 快捷键）会随目标与工具版本过期，但"从现象反推实现"的路径是稳定的。方法论的另一个作用是控制范围：明确这次分析只回答什么问题，防止在百万行的反编译代码里漫无目的地漂移。

第一步：明确目标与边界

动手前写下三行字：要还原什么（例：请求头里 X-Sign 的生成算法）、验收标准是什么（例：本地能对任意输入复现出一致的签名）、合法边界在哪（例：自建靶场/授权项目）。这一步看似形式主义，实际决定了后面每一步的取舍。

第二步：怎么找入口？

按性价比从高到低试这些锚点：

字符串与字段名：参数名、URL 片段、错误文案在反编译产物里全局搜索，命中率最高；
网络层回溯：Hook 收发函数（如 XMLHttpRequest、OkHttp 拦截点），对请求体下断点，沿调用栈向上找；
算法指纹：魔数（0x67452301 等）、S-box、固定表名——直接暴露标准算法的存在。

// 示例：用 Frida 快速确认某函数是否是目标入口
Interceptor.attach(Module.getBaseAddress('libtarget.so').add(0x1A2B3C), {
  onEnter(args) {
    console.log('arg0:', args[0].readUtf8String());  // 观察输入
  },
  onLeave(ret) {
    console.log('ret :', ret.readUtf8String());      // 观察输出
  }
});

第三步：追踪数据流

拿到入口后，问三个问题：输入从哪来、经过哪些变换、输出去了哪。把中间变量按顺序 dump 出来，对相邻两次调用做差分——值变了但逻辑没变的字段是盐/时间戳，值不变的往往是密钥或设备指纹。

第四步：还原逻辑

先判断是标准算法还是自研变体：

特征: MD5 常量 0x67452301 / AES S-box / SHA-256 K 表 → 标准算法，直接套库验证
异常: 常量被替换、轮数改变、多一轮异或 → 魔改，逐段 diff 定位改动点

用 python 快速验证假设，输入输出对不上就回到第三步补 dump。常见的哈希与编码特征对照可以把识别时间从小时级压到分钟级。

第五步：闭环验证

把还原的算法封装成独立函数，用目标在真实运行中产生的多组输入输出对做回归验证：10 组全对才算还原成功。只对一组样例"碰巧一致"是最常见的假阳性。

工具链建议

静态：IDA / Ghidra / jadx（Android）/ 浏览器 DevTools（JS）。动态：Frida 通用性最好，入门见 Frida Hook 的三个层次。所有分析在授权范围内进行——本文与后续实战篇只覆盖方法论与自建靶场演示，不涉及任何具体商业产品的绕过。

Node.js 流为什么能省内存？背压机制详解与实战代码

Sun, 30 Aug 2026 00:00:00 GMT

Node.js 流省内存的关键不是"分块读"本身，而是背压（backpressure）：当下游消费不过来时，write() 返回 false，上游暂停生产，直到 drain 事件通知缓冲已排空再继续。这让内存占用与文件大小无关，始终保持在常数级。

用 Buffer 一次性读文件会发生什么？

// 反例：整个文件进内存
import { readFileSync } from 'node:fs';
const buf = readFileSync('access-10gb.log'); // 10GB 日志 → OOM 或换页抖动

处理 10GB 文件时，这段代码至少需要 10GB 堆内存，V8 默认堆上限内直接崩溃。而同样的任务用流只需几十 MB：

// 正例：常数级内存
import { createReadStream, createWriteStream } from 'node:fs';
import { pipeline } from 'node:stream/promises';
import { createGzip } from 'node:zlib';

await pipeline(
  createReadStream('access-10gb.log'),   // 按块读
  createGzip(),                          // 边读边压
  createWriteStream('access-10gb.log.gz')
);

背压到底是怎么工作的？

writable.write(chunk) 把数据放进内部缓冲区（上限由 highWaterMark 控制，默认 64KB）。当缓冲超过上限，write() 返回 false——这不是报错，而是协议信号：请暂停写入。缓冲被消费完之后触发 drain 事件，上游恢复写入。手写这个协议长这样：

// 手动背压协作（理解原理用，生产推荐 pipeline）
const readable = createReadStream('in.log');
const writable = createWriteStream('out.log');

readable.on('data', (chunk) => {
  if (!writable.write(chunk)) {
    readable.pause();                  // 缓冲已满，暂停生产
    writable.once('drain', () => readable.resume()); // 排空后恢复
  }
});
readable.on('end', () => writable.end());

pipe() 和 pipeline() 做的就是这件事的健壮版本——包括错误传播与资源清理，因此生产代码永远优先 pipeline。

实战：逐行处理 10GB 日志并统计

结合 readline（基于流的行解析）与批量写库，是日志分析最常用的模式：

import { createReadStream } from 'node:fs';
import { createInterface } from 'node:readline';
import { pipeline } from 'node:stream/promises';

const stats = new Map(); // url -> count

await pipeline(
  createReadStream('access-10gb.log', { encoding: 'utf8' }),
  async function* (source) {
    for await (const line of source) {
      const url = line.split(' ')[6];
      stats.set(url, (stats.get(url) || 0) + 1);
    }
  }
);
// stats 里就是全量统计结果，峰值内存 < 100MB

async generator 也是流：它天然遵守背压协议，上游快了会自动暂停迭代。

三个常见误区

忽略 write() 的返回值又不用 pipe——缓冲无限增长，流等于白用；
在 pipe 链里忘了错误处理——某一段崩了，其他段不会自动销毁，用 pipeline 一并解决；
对流做 JSON.parse 整体操作——流的价值在"逐块、无需全量"的场景，需要全量数据时应改用聚合策略。

把这套思路放到 Web 服务里同样成立：本站的付费文章页就是用服务端截断输出控制响应体大小的，底层思想与 Astro 混合渲染实践一脉相承——按需生产，不做无用功。

Frida 入门：Hook 函数的三个层次与调试技巧

Wed, 12 Aug 2026 00:00:00 GMT

Frida 的 Hook 能力分三个层次：Java 层方法拦截 → Native 函数拦截 → 内存级读写。从上往下难度递增、能力递增。本文按层次给出可运行的最小脚本与排错思路，帮你把"注入成功"到"拿到数据"的距离缩到最短。

环境怎么搭？

# PC 端（以 Python 环境为例）
pip install frida-tools
frida --version

# Android 设备端：下载对应架构的 frida-server 推送并运行
adb push frida-server-android-arm64 /data/local/tmp/fs
adb shell "chmod +x /data/local/tmp/fs && /data/local/tmp/fs &"

# 验证连接
frida-ps -U

测试目标建议使用 OWASP UnCrackable 或自写的 demo app——不要拿线上商业产品练手。

层次一：Java 层 Hook

目标在 jadx 里能看到的方法，用 Java.perform 拦截：

// hook_java.js — 拦截某类的静态方法并打印参数与返回值
Java.perform(() => {
  const Cls = Java.use('com.demo.app.CryptoUtil');
  Cls.sign.overload('java.lang.String').implementation = function (input) {
    const ret = this.sign(input);
    console.log('[sign] in :', input);
    console.log('[sign] out:', ret);
    return ret;
  };
});

frida -U -l hook_java.js -f com.demo.app   # spawn 模式，覆盖 attach 抓不到早期调用的场景

常见坑：方法重载时必须用 overload() 指定签名；类名被混淆就用脚本枚举当前内存里的类。

层次二：Native 层 Hook

目标在 so 库里，先用偏移量定位，再 Interceptor.attach：

// hook_native.js — 拦截 so 中的未导出函数（偏移 0x1A2B3C）
const base = Module.getBaseAddress('libnative.so');
Interceptor.attach(base.add(0x1A2B3C), {
  onEnter(args) {
    // 按函数约定读参数：指针按字节读，整型按位读
    console.log('[n] arg0 ptr:', args[0].readCString());
  },
  onLeave(ret) {
    console.log('[n] ret:', ret.toInt32());
  }
});

定位偏移的方法：IDA 打开 so → 找到目标函数 → 记录函数起始地址减去模块基址。导出函数可以直接 Module.getExportByName(null, 'symbol')。

层次三：内存级操作

前两层都不奏效时（函数被内联、逻辑写在宏里），退到内存层：Memory.scan 搜特征字节、Memory.readByteArray 直接读数据区、Memory.protect 改页属性。这是"最后手段"，脚本可移植性差，每次版本更新都要重新定位。

调试心法

三个技巧贯穿三层次：

差分观察：同一操作重复两次，对比 dump 结果，找"变的"和"不变的"字段；
从调用栈反推：console.log(Java.use('android.util.Log').getStackTraceString(Java.use('java.lang.Exception').$new())) 打印 Java 调用栈，定位是谁在调目标函数；
最小化注入：一次只 Hook 一个函数，确认生效再加下一个——批量 Hook 出错时几乎无法定位。

Frida 在完整分析流程中的位置，见逆向方法论五步；拿到关键数据后如何还原算法，将在会员篇签名算法分析实战中以自建靶场为例完整演示。

Prompt 工程有哪些被验证有效的模式？附可复用模板

Wed, 22 Jul 2026 00:00:00 GMT

Prompt 工程被验证有效的模式并不多：角色与边界、结构化输出、少示例、思维链、自检回路、上下文分区、失败降级、版本化评测。这 8 个模式覆盖了生产环境 90% 的场景，本文逐一给出模板与反例。

为什么大多数 Prompt 失败？

失败 Prompt 有个共同点：把模型当搜索引擎用——一句话需求丢进去，指望它理解你没有说出口的约束。有效 Prompt 的本质是工程约定：输入是什么、输出长什么样、边界在哪、错了怎么办。下面按模式展开。

模式一：角色与边界（Role + Boundary）

你是一名资深代码评审员。职责：只评审给出代码的正确性与安全问题。
边界：不讨论代码风格，不重写整个文件；发现的问题按 [严重度][位置][原因][建议] 四段输出。
如果代码无法评审（信息不足），直接回复"需要补充上下文"并列出缺失项。

要点：边界句和职责句同样重要。没有边界，模型会用"热心"填补空白——重写你的代码、解释基础概念，输出不可控。

模式二：结构化输出（Schema First）

用示例把格式"钉死"，而不是用形容词描述格式：

输出必须严格是 JSON 数组，不要任何额外文字：
[{"issue": "问题描述", "severity": "high|medium|low", "line": 12}]
示例：
[{"issue": "未校验空指针", "severity": "high", "line": 42}]

反例："请结构化地输出你的分析结果"——"结构化"是人类的想象，模型需要的是具体 schema。

模式三：少示例（Few-shot）

2–5 个精选示例的效果稳定优于零示例，也优于 20 个冗余示例。选示例的标准：覆盖边界情况，尤其要包含一个"应拒绝/判空"的示例，否则模型对模糊输入会强行编造答案。

模式四：思维链（按任务类型启用）

推理类任务（数学、多条件判断、根因分析）在要求"先列出推理步骤，再给最终答案"后有可测量提升；简单分类与抽取任务不要加，纯属浪费 token 与延迟。经验法则：答案需要组合两个以上事实的任务，才值得思维链。

模式五：自检回路（Self-check）

完成草稿后，先按以下清单自检并修正，再输出最终答案：
1. 输出格式是否符合 schema
2. 每个事实性断言是否有材料支撑
3. 是否存在未处理的空值/异常分支

实测能拦截大部分格式错误与编造断言，代价是一轮额外推理。对质量敏感、对延迟不敏感的管线值得开启。

模式六：上下文分区

长上下文 prompt 按固定顺序组织：角色与规则 → 材料（带编号） → 任务指令 → 输出格式。检索增强场景下，把最强证据放在材料的开头与结尾（模型对中间内容注意力弱），这一条在 RAG 系统搭建实践里有详细展开。

模式七：失败降级

预定义三档输出：正常答案 / "资料未覆盖" / "需要人工"。让模型有台阶下，是压住幻觉最便宜的手段——大量幻觉来自模型不敢说"不知道"。

模式八：版本化与评测

Prompt 进 Git、变更写说明、每次修改跑同一套评测集（哪怕只有 30 条）。没有回归评测的 Prompt 迭代等于裸奔。把这些模式组合进工程管线的方法，可参考逆向分析里的提示词驱动辅助分析思路——方法论是通用的。

如何快速识别一个哈希或编码算法？特征长度对照表

Wed, 01 Jul 2026 00:00:00 GMT

逆向分析中，识别"这段数据是什么算法的产物"是第一块拼图。方法就三招：看长度、看字符集、用已知输入验证。本文给一张速查表加一段验证代码，把识别时间压到分钟级。

第一步：看长度与字符集

输出特征	候选算法	备注
32 hex	MD5	空串结果 `d41d8cd9...8427e`
40 hex	SHA-1	空串 `da39a3ee5e6b4b0d3255bfef95601890afd80709`
64 hex	SHA-256	空串 `e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855`
128 hex	SHA-512	空串 `cf83e135...`
`A-Za-z0-9+/=`	Base64	末尾 `=` 是填充标志
`A-Za-z0-9`（无 `+/=`，无 `0OlI`）	Base58	比特币地址常用
纯数字	纯数字编码/自研	常见于业务混淆 ID
高熵二进制	加密/压缩	需结合代码特征判断

第二步：用已知输入验证

记住四个"指纹值"，验证标准哈希只需一行：

import hashlib

known = {
    "md5":    "d41d8cd98f00b204e9800998ecf8427e",
    "sha1":   "da39a3ee5e6b4b0d3255bfef95601890afd80709",
    "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
}

def identify(digest: str) -> str | None:
    d = digest.lower()
    for name, empty in known.items():
        if hashlib.new(name, b"").hexdigest() == empty and len(d) == len(empty):
            return name
    return "unknown（可能加盐/魔改/截断）"

对不上指纹值不一定是"不是这个算法"——加盐或魔改会让空串指纹失效，这时转入第三步。

第三步：进代码找结构特征

数据层面区分不了加密算法，要进代码看常量：

AES   : S-box 以 0x63, 0x7c, 0x77, 0x7b... 开头；轮常量 0x01, 0x02, 0x04...
DES   : 初始置换表 IP[58, 50, 42, ...]；16 轮迭代
RC4   : 256 长度状态盒 + KSA/PRGA 双循环，无魔数常量
RSA   : 大数运算 + e 常见取值 0x10001 (65537)
CRC32 : 查表法 0xEDB88320（反射）或 0x04C11DB7（正向）

IDA/Ghidra 里全局搜索这些字节序列，命中即有答案。Standard Hash 的魔数（MD5 的 0x67452301、SHA-1 的 0x5A827999）也适用于定位哈希函数位置。

常见陷阱

长度对上就下结论——32 hex 也可能是两次 MD5 套接或加盐 MD5，必须动态验证；
忽略编码嵌套——Base64(Hex(MD5(x))) 三层嵌套很常见，逐层解到指纹值为止；
把压缩当加密——zlib/gzip 头分别是 78 9C 和 1F 8B，先解压再分析。

识别只是起点，数据流追踪与算法还原的完整路径见逆向方法论；Frida 动态验证手段见 Frida Hook 三个层次。