小站

一、审计目标 在安卓手机通过无线 ADB 连接家庭服务器后，可以让自动化代理执行一次较为深入的非 Root 审计。 此次审计目标不是获取个人内容，也不是制作取证镜像，而是检查： 整个过程遵循： 二、非 Root ADB 能做到什么 通过 ADB，可以获取： 但它不能： 因此，这类任务应称为： 三、审计过程设计 审计分成两阶段。 第一阶段：只读采集 所有操作只读取，不修改： 所有证据保存到服务器独立目录，并生成结构化报告。 第二阶段：定向整改 审计结束后，仅处理用户明确选择的项目。 每项整改必须包含： 四、系统安全基线 审计确认了以下基础安全状态： 这些结果说明系统完整性基础正常。 未发现以下常见高风险迹象： 但“未发现”只能代表当前可见证据中没有，不能等同于绝对排除。 五、应用和权限审计 自动化代理逐个扫描了大量用户应用，并生成： 重点检查的能力包括： 审计发现的高权限应用，大部分都能与实际用途对应。 例如： 因此，高权限并不等于恶意。 风险判断必须结合： 六、一次重要的误判纠正 报告最初将某个远程桌面应用写成“无障碍已启用”。 但原始系统状态显示，它只是安装了无障碍组件，实际没有启用。 真正处于启用状态的无障碍服务只有两个用户明确使用的工具。 这说明自动化审计不能只依赖应用 Manifest 或已安装服务列表。 必须区分： 这四种状态完全不同。 七、共享存储中的残留 APK 共享存储检查发现一个文件名看起来像常见社交应用的 APK。 静态分析后发现： …

一、需求目标 安卓设备使用 Fcitx5 for Android，并安装了 Rime 插件。希望在现有拼音方案中加入动态日期和时间候选。 目标触发词包括： 要求保持原有输入习惯，不更换输入法框架，不影响用户词库和同步数据。 桌面版 Fcitx5-Rime 中，可以通过 Lua translator 实现类似功能。但安卓版本的目录结构、插件构建和部署方式与桌面 Linux 不完全相同，不能直接照搬。 二、最初的实现思路 最初方案采用三个核心文件： 目录结构类似： 基本逻辑是： 理论上，这一结构是合理的。 三、为什么第一次没有生效 配置文件写入后，实际输入没有出现动态候选。 最初并不能确定问题位于哪一层： 静态查看文件只能证明“配置存在”，不能证明运行时已经加载。 四、通过无线 ADB 获取运行时证据 无线 ADB 建立后，可以直接查看 Fcitx5 Android 的外部数据目录。 审计重点包括： 还可以检查： 这使排查从“根据备份猜测”变成“根据实时系统判断”。 五、关键时间线线索 实时目录中发现： 这说明新增配置写入后，部署产物没有同步更新。 这一现象通常对应几种可能： 其中，“配置文件存在，但 build 仍旧”是非常重要的诊断信号。 六、确认安卓 Rime 插件的 Lua 能力 …

一、需求背景 在家庭网络中运行了一台常驻服务器，并在服务器上部署自动化代理。希望代理能够连接安卓手机，检查系统状态、读取输入法配置、收集日志，并在明确授权的情况下完成部分设置调整。 最初容易想到的是 SSH，因为服务器管理通常都依赖 SSH。但安卓手机并不是普通 Linux 服务器，直接照搬桌面 Linux 的远程管理方式，会遇到权限、应用沙箱和后台限制等问题。 因此，首先需要区分三类工具： 这三者的用途完全不同。 二、SSH 客户端不能让服务器反向进入手机 手机上常见的 SSH 工具，多数只是 SSH 客户端。 它们适合以下方向： 例如在外出时，用手机登录家里的服务器，查看服务状态或执行维护命令。 但自动化代理连接手机需要的是反方向： SSH 客户端本身不会在手机上监听端口，因此不能让服务器主动登录手机。 如果确实希望通过 SSH 控制手机，需要在手机上另外安装能够提供 sshd 的环境，例如 Termux，并在其中安装 OpenSSH。 这种方式适合： 但它不能自动突破 Android 应用沙箱，也不能直接读取其他应用的内部私有目录。 三、Termux SSH 与无线 ADB 的区别 Termux SSH 的控制范围主要是： 无线 ADB 的控制范围则更偏向 Android 系统： 因此，如果目标是让自动化代理检查安卓系统和输入法，优先选择无线 ADB更合适。 Termux …

在 Linux 桌面环境中安装日语输入法并不困难，但真正需要迁移系统、重装发行版或更换电脑时，往往会遇到几个问题： 为回答这些问题，对一台运行 Arch Linux、KDE Plasma 和 Wayland 的工作站进行了一次只读审计。审计不修改配置、不卸载软件包，也不重启输入法，仅检查当前运行状态、配置文件、用户数据和可迁移性。 一、当前输入法环境 审计确认，当前活跃的输入法框架是： 桌面会话为 KDE Plasma Wayland，Fcitx5 进程和对应的用户服务均处于正常运行状态。 当前实际激活的输入法是： Rime 主要用于中文输入，并不是本次检查的日语输入法。 当前 Fcitx5 输入法列表中配置的日语输入法是： 系统中另外还安装了多个日语输入引擎： 这些引擎虽然已经安装，但并未全部加入当前日常使用的输入法切换列表。 因此，需要区分四种状态： 状态 含义 已安装 软件包存在于系统中 可用 Fcitx5 能够识别该输入法引擎 已配置 输入法已加入当前 Fcitx5 输入法组 当前激活 此刻正在用于输入的引擎 本机的实际情况是： 二、为什么选择 Mozc Mozc 是一个开源日语输入引擎，常用于 Linux 上的日语输入。它可以通过 Fcitx5、IBus 等不同输入法框架使用。 在当前系统中，Mozc 通过 …

在 Linux 桌面环境中，Rime 输入法具有很强的可定制能力。除了词库、快捷键和候选数量，也可以借助 Lua 动态生成当前日期、时间和星期。 目标效果如下： 这类功能看似只是增加几行配置，实际排查过程中却遇到了几个容易误判的问题： 本文整理完整过程，并总结一套更可靠的处理方法。 一、运行环境与需求 测试环境为： 用户原本已经将每页候选数量改为 9，但修改位置位于： build/ 是 Rime 的编译产物目录。这里的文件会在重新部署时被重新生成，因此不适合保存长期自定义配置。 正确做法是把自定义内容放在用户数据目录： 例如： 二、先确认 Lua 支持是否存在 动态日期和时间需要 librime-lua。 在 Arch Linux 中，新版 librime 软件包通常已经包含 Lua 插件，不一定需要额外安装独立软件包。 可以检查： 再确认插件文件： 如果能看到对应的 Lua 插件文件，并且该文件属于 librime 软件包，说明 Lua 支持已经安装。 三、不要继续修改 build 目录 候选数量应写入： 例如： 动态 Lua translator 也应通过同一个补丁挂载： …

在公司电脑、公共电脑或临时设备上访问自建 Nextcloud 时，传统的账号密码登录并不理想。 一方面，需要在陌生设备上输入密码；另一方面，即使使用浏览器隐私窗口，也仍然可能留下下载文件、剪贴板内容或系统级访问记录。 Passkey 提供了一种更方便的思路： 整个过程中，Nextcloud 密码不需要输入到陌生电脑上。 不过，这种登录方式有一个容易被忽视的前提：电脑通常需要具备蓝牙功能。 Nextcloud 是否支持 Passkey Nextcloud 支持基于 WebAuthn/FIDO2 的身份验证。 根据 Nextcloud 版本、管理员配置和已启用的应用，WebAuthn 可能以两种形式出现： 如果目标是在陌生电脑上不输入密码，应当使用无密码认证或 Passkey 登录，而不是只配置“密码加 WebAuthn 二次验证”。 通常可以在 Nextcloud 的个人安全设置中找到类似以下选项： 不同版本和语言环境下，名称可能略有差异。 注册 Passkey 时，可以将凭据保存在： 配置完成后，建议先使用另一台可信设备实际测试一次，确认二维码登录、用户名识别和二次验证流程都符合预期。 陌生电脑上的典型登录流程 在支持跨设备 Passkey 的浏览器中，登录流程通常如下： 这种模式的优势是，Passkey 私钥不会复制到临时电脑上，Nextcloud 密码也不需要在该设备中输入。 为什么扫码登录还需要蓝牙 很多人会自然地认为： 二维码已经把手机和电脑连接起来了，为什么还要蓝牙？ 原因是，二维码只能让手机知道“这次登录请求是什么”，却不能证明手机与发起登录的电脑确实处在同一地点。 跨设备 Passkey 通常采用一种被称为混合传输的机制。它会同时使用： 三者承担的职责并不相同。 第一步：电脑生成一次性二维码 电脑上的浏览器启动 …

本文中的设备型号、硬件 ID、主机名、用户目录、映射参数、日志时间和规则文件名均为虚构示例，仅用于展示排查方法与配置结构，不可直接复制到真实环境。 一、环境与目标 测试环境如下： 目标是让绘图板在两种连接方式下保持一致的行为： 期望映射参数如下： 其中 X 和 Y 表示区域中心，而不是左上角坐标。 对应的屏幕区域边界为： 二、USB 模式：使用 OpenTabletDriver 1. 启动用户级服务 安装驱动后启用用户服务： 确认状态： 插入 USB 后检查日志： 成功识别时可能出现： 还应确认原生内核驱动没有同时接管： 如果第三方驱动与原生驱动同时处理同一设备，可能出现： 2. 配置 USB 映射 启动图形界面： 在 Display 区域填写： 在 Tablet 区域填写： 操作顺序： 保存后，USB 再次插入时应自动恢复该配置。 三、断开 USB 时图形界面崩溃 某些 OpenTabletDriver GTK 界面在设备断开时，可能因为设备列表刷新而异常退出。 典型提示类似： 这不一定意味着后台 daemon 也已停止。 …

随着 AI Agent 使用时间增长，工作区中的规则、主机信息、操作手册、故障记录和长期记忆往往会不断积累。 一开始，所有内容可能只有几个 Markdown 文件。为了让 Agent 每次启动时都能理解环境，这些文件通常会被自动注入上下文。然而，当内容逐渐增加后，一个新的问题随之出现： Agent 每处理一次普通任务，都要重新读取大量与当前任务无关的技术资料。 例如，处理一个简单文件操作时，模型可能同时接收到： 这些资料都很重要，不能删除，但也没有必要在每轮对话中全部注入。 解决这个问题的一种有效方法，是在工作区中建立一个独立的、按需读取的 context/ 资料库。 一、问题不只是某个文件太长 不少 Agent 工作区会包含类似文件： 这些文件通常承担不同职责： 问题在于，详细技术资料往往会逐渐混入这些启动文件。 例如，一个网络问题可能在排查后留下几千字内容，其中包括： 这些内容确实值得长期保存。如果全部留在 TOOLS.md 或 MEMORY.md 中，每次启动都会重复占用上下文。 仅仅把内容从 MEMORY.md 移到 TOOLS.md，并没有真正解决问题。它只是把负担从一个自动注入文件转移到了另一个自动注入文件。 真正需要优化的是： 所有启动文件的总注入量，而不是某一个文件的长度。 二、三层知识结构 更适合长期维护的结构，可以分为三个层级。 1. 启动层 每轮对话都应知道的内容，继续保存在自动注入文件中： 这一层只保存： 启动层应当短、小、稳定。 2. 按需资料层 详细技术资料进入： 这一层保存： 这些文件不应每轮自动注入，而应在任务需要时由 Agent 主动读取。 3. 历史与证据层 …

在 Linux 桌面环境中使用 RustDesk 远程连接 Windows 时，遇到了一个比较特殊的剪贴板问题： 这种“单向正常、反向失败”的现象，容易被误认为是 Windows 剪贴板服务异常，或者 RustDesk 的剪贴板权限没有打开。但进一步排查后发现，真正的问题位于 Linux 客户端一侧，并且与 KDE Plasma Wayland 环境及 RustDesk 版本有关。 一、问题环境 发生问题的本地系统为 Arch Linux，桌面环境使用 KDE Plasma，当前会话类型为 Wayland。 远程端是一台 Windows 系统，通过 RustDesk 进行远程控制。 首先检查 Linux 当前的图形会话类型和 RustDesk 安装情况： 输出结果显示： 这说明当前使用的是系统软件包方式安装的 RustDesk 1.4.7，并不是 Flatpak 版本。 二、为什么问题只发生在一个方向 远程桌面的剪贴板同步并不是一个完全对称的过程。 当从 Windows 复制文字到 Linux 时，RustDesk …

在远程维护 Windows 主机时，常见方案包括 RustDesk、AnyDesk、直接暴露 RDP、VPN，以及通过 SSH 隧道转发 RDP。 其中一种兼顾安全性、清晰度和使用便利性的方案是： 这种结构不需要把 Windows 的 RDP 端口直接暴露到公网，同时仍然可以获得原生 RDP 较高的画质、较低的带宽占用和良好的剪贴板体验。 一、整体结构 假设存在三台设备： 远程 Windows 位于内网，没有公网 IP。Windows 上运行 FRP 客户端，主动连接公网中转服务器上的 FRP 服务端。 FRP 已经建立了一条 SSH 映射： 因此，在 Linux 上可以通过下面的方式登录远程 Windows： 这里连接的虽然是公网中转服务器的地址和端口，但最终进入的是远程 Windows 的 OpenSSH 服务。 在此基础上，再增加一层 SSH 本地端口转发： 最终链路如下： 需要特别注意： FRP 映射的仍然只是 SSH，并没有把 RDP 直接暴露到公网。 …