用淀粉自制葡萄糖：糖苷键的三种断法与产率
网上关于自制糖浆的做法不少，大致都是淀粉加水调开，加一点白醋，小火煮一两个小时，煮到挂勺。做出来的东西是甜的，粘度也上来了，看起来像是成功了，但那个甜味主要不是葡萄糖。 醋的酸度太弱，煮的温度也不够，淀粉只有一小部分被切断，断出来的东西主要是糊精和麦芽糖。这两样都有甜味，所以尝起来是甜的，成分和葡萄糖却不是一回事。要拿到葡萄糖，需要让糖苷键在特定的位置断开，这跟酸的强弱、温度的高低、用哪种酶都有关系。 淀粉是葡萄糖串起来的链，串法有两种淀粉的分子式写作 (C₆H₁₀O₅)ₙ。这个式子只能看出元素比例，看不出连接方式。它的实际结构是几百到几千个葡萄糖分子连成的链，连接的地方叫糖苷键。 连接有两种。一种是一个葡萄糖的第 1 位碳连着下一个的第 4 位碳，叫 α-1,4 键，这样连出来是一条直链。另一种是一个葡萄糖的第 1 位碳连着链上另一个葡萄糖的第 6 位碳，叫 α-1,6 键，这样连出来是分叉。 玉米淀粉里，直链部分大约占 27%，剩下的 73% 是带分支的支链淀粉，平均每 20 到 25 个残基分一次叉。 水解就是把这两种键一个一个加进水分子拆开。 \mathrm{(C_6H...
社会工程学：人性的漏洞
在网络安全领域，我们习惯于寻找漏洞。 一个开放的端口、一段存在缺陷的代码、一个配置错误的服务，都可能成为入口。我们通过扫描、审计、测试和修复，不断缩小技术系统中那些可以被利用的薄弱环节。 但如果一个系统没有明显的技术漏洞呢？ 服务器经过加固，身份认证已经启用，安全设备持续运行，日志也在被实时监控。此时，一个人收到了一封看似正常的工作邮件，接到了一个自称来自管理部门的电话，或者面对一项要求立即完成的任务。 他没有破解密码，没有绕过防火墙，也没有执行任何看起来明显危险的操作。他只是相信了某个身份，接受了一个解释，并按照自己认为合理的方式完成了工作。 问题可能就从这里开始。 把这类事件归结为安全意识不足是最省事的做法，也是最没有用的一种。它的潜台词是：只要员工足够谨慎、足够专业，就能避免。但现实中的人不是始终保持高度警觉的分析仪器。我们依赖经验理解世界，依赖信任维持协作，也会在时间压力和信息不完整的情况下作出判断。这些能力让日常生活得以正常运转，却不意味着每一次判断都能得到正确的结果。 社会工程学研究的，就是人与信息、信任和行为之间的关系。它提醒我们，安全风险不只存在于代码和配置之中，...
社会工程学：人为什么会忽略安全警告
公司今年做了两次安全意识培训。第二次的考试，小李考了 96 分，还剩 4 分扣在一道关于附件的多选题上。 同一个月的某天上午，他在会议室里听汇报，手机上收到一条提醒，说他的身份验证令牌今天到期，需要重新绑定一下。他点开了。 事后他自己也说不清为什么。他知道这类提醒可能是伪造的，考试里那道类似的题他做对了，培训上讲过的案例他还记得。 这就是本文要回答的问题：知道风险存在，为什么仍然可能做出不安全的选择？ 知道和做到之间隔着四步把这件事拆开看，从「知道有风险」到「做出动作」，中间有四个环节。 第一步是知道这个风险。这一步是培训能覆盖的部分，也是唯一能被考试测出来的部分。 后面三步都是条件问题。当时的场景里有没有想起来；想起来了会不会被别的东西压住；判断的时候依据对不对；判断本身有没有足够的注意力支撑。 四个断点里，第二个最容易在事后被当成道德问题。「他明知道还这么做」，听起来像不在乎。实际上更常见的情况是，在当时那几秒钟里，另一个东西的分量更大：客户在等答复、领导站在旁边、手上三件事同时到期。 四个断点合起来可以写成一句话： \text{是否做出不安全的选择} = f(\text{...
社会工程学：信任是如何被建立的
一个人站在机房门口。工牌是对的，制服是对的，说辞也对得上流程，还顺口提了一句 8 月中旬来装过空调。保安登记了一下，前后 4 分钟，放他进去了。 事后查出来，工牌是印的，制服是网上买的，流程是他自己打听来的。 这类事情里，最容易被忽略的地方在于：那个请求从头到尾都很合理。他没有提任何奇怪的要求，没有催，没有吓人，也没有说错话。他做的只是让自己看起来像那么个人，然后提了一个在这个场景下本来就该被提出来的请求。 所以核心问题是这样的：为什么一个看起来合理的请求，不一定是一个可信的请求？ 合理不等于可信要回答这个问题，得先看清一个请求里其实有两层信息。 业务层回答的是：这件事本身说得通吗。资产盘点、系统升级、合同归档、设备巡检，这些都是真实存在的流程，一个外部的人只要稍微了解这行的常识，就能把话说得像模像样。 身份层回答的是另外两个问题：提这件事的人，是他说的那个人吗；这件事情，该不该由他提。 这两层可以写成一句话： \text{一个请求} = \text{事情（说得通吗）} + \text{来源（是他吗、有资格提吗）} 说人话：一件事合不合理，和提这件事的人是谁，是两套互不相干的判...
社会工程学：提问的艺术
下面这段对话一共 6 轮，从头到尾没出现过任何敏感词。 对方：您好，我是集团 IT 服务中心的，最近在做一次网络设备清点。您这边是行政前台吧？前台：对，是我。对方：麻烦帮我确认一下，你们 3 号楼机柜上的路由器是什么型号？上面应该贴了标签。前台：这个我不清楚，得问我们网管。对方：没关系。那您能把网管的联系方式给我吗？我们系统里登记的那个好像过期了。前台：他姓王，电话我找一下…… 从头到尾，没人问密码，没人问内网地址，没人问系统名称。前台也没有被威胁、被催促，甚至觉得帮了个小忙。 但对方拿到了 2 样东西：网管的姓氏和电话。再叠上前面那句「办公区机柜上有路由器、上面贴了标签」，一个外部的人就已经知道该找谁、怎么开口了。 这就是社会工程学里提问的基本形态：用问题引导，让对方自己说。 图里右边那一列，是每一轮对话之后对方手上多了什么。可以看到信息是分三轮给出的，每一轮比上一轮更靠近他真正想拿的东西。 信息是怎么在对话里流动的要理解这件事，得先接受一个事实：对话里双方都在补充信息，只是目的不同。 接电话的前台想的是「帮他把事情办完」，提问题的人想的是「这段对话能换来什么」。两个人都...
飞秋（FeiQ）3.0.0.2 远程拒绝服务漏洞审计
飞秋 3.0.0.2 在处理图片和文件的分片接收时，会用三个取自网络报文的数值做内存操作：分配大小、目的偏移、拷贝长度。这三项都没有边界校验。任意一台与目标网络可达的主机发送一个构造报文，就能造成堆越界写，进程随后以 0xC0000374（STATUS_HEAP_CORRUPTION）终止。 审计在受控实验网络内完成，目标是自己搭建的同一版本样本，没有涉及第三方资产。 项目 结论 漏洞类型 堆缓冲区溢出（CWE-787 / CWE-122） 触发前提 无。不需要认证、不需要交互、不需要目标侧任何操作 网络条件 与目标网段可达即可，走 UDP 2425 打击面 4 个 UDP 报文，合计约 32 KB 失效耗时 远程实测 2.9 秒 崩溃表现 0xC0000374，目标机事件日志可查 恢复方式 只能人工重启，飞秋没有自愈或自动重启机制 可否持续压制 可以，目标恢复后 8 秒内可再次打掉 样本 项 值 文件名 FeiQ.3.0.0.2.exe 格式 PE32（x86），GUI 子系统 编译器 MSVC 10.0...
飞秋（FeiQ）3.0.0.2 协议缺陷分析：设备名册伪造与消息缓冲残留
飞秋（FeiQ）是一款局域网即时通讯工具，在机房、教室和不少单位的内部办公网里还在使用。它装完即可使用，不需要服务器和账号，同一网段内的机器会自动出现在好友列表里，通信走 UDP 2425。 我最近对它的协议做了分析，并写了一个内网设备探测工具。分析过程中发现两个问题，一个在协议设计层面，一个在内存安全层面。本文记录协议还原的结果、两个问题的原理、实测数据和修复建议。 报文格式飞秋的协议没有公开文档，但与 IPMSG（IP Messenger）同源。抓取 3.0.0.2 广播的报文可以看到，一条报文就是一段可读字符串，字段之间用 # 和 : 分隔： 11_lbt6_0#128#001122334455#0#0#0#4001#9:1792156361:USER:PC-NAME:0:<消息>\0 报文分两段。# 之前是第一段，最多八个字段；: 之后是第二段，格式与 IPMSG 一致。字段含义见图一。 有两个字段需要单独说明。 f5 声明这条消息的字节数，第二个缺陷与它直接相关。 命令字必须填 32（IPMSG 中的 SENDMSG）。填 32 时对端会把你登记进名册并回...
用 Python 从零实现一个 SSH 蜜罐
把一台机器的 SSH 端口放到公网上，过不了多久日志里就会开始有东西。半夜的登录失败、来自好几个国家的地址、每隔十几秒试一次。你不需要去惹谁，扫描器本来就在全网扫这个端口。 这些尝试绝大多数是无差别的，但里面有信息。它们猜哪些用户名、用什么口令、进去以后第一件事做什么。把这些记下来，比一条条翻 sshd 日志有意思得多。 这篇文章写一个能记这些东西的蜜罐。功能本身不复杂，值得花时间想清楚的是另外两件事：怎么保证它什么都不会真的执行，以及经过转发之后怎么把来源 IP 拿回来。 先定清楚要拿到什么三样是基本盘：用户名、口令、来源 IP。再加两样进阶的：登录成功后执行的命令、客户端的版本串。版本串能认出对方用的是什么工具，有时候比口令本身更能说明问题。 整个数据流是这样： 图一 蜜罐的组成与数据流。攻击流量进到容器里，能走的最远一步就是被记录。 一个反直觉的决定：口令一律放行正常的服务遇到错口令要拒绝，蜜罐反过来，全部接受。 原因在 SSH 的认证机制：一次连接只提交一组凭证。爆破工具的做法是连一次、试一组、断开、再连。所以两种策略拿到的数据完全不同。 一律拒绝的话，每次连接只能记下...
高并发 API 服务的瓶颈究竟在哪里：连接池、线程池、事件循环与背压
一个 API 服务在低负载下跑得好好的。请求量涨上来，吞吐量跟着涨；再涨，吞吐量不动了，P99 开始往上爬。继续加压，超时、连接池耗尽、503 接连出现。 这时候最自然的反应是去调参数：线程数加一点，连接池开大一点，事件循环换个更快的实现。这些调整有时候确实管用，有时候只是把问题挪了个位置，还有时候会让情况更糟。 本文要回答的是一个前置问题：在动手之前，怎么知道瓶颈在哪一层。至于「参数该设多少」，那是找到瓶颈之后的事。为了让结论可检验，我在一台 4 核虚拟机上搭了一个模拟下游处理时间的服务，把连接池、并发度、worker 数、队列容量逐个拉出来单独改，记录每一次的吞吐量、延迟分位数、队列深度和错误码。文中所有数字都是这台机器上跑出来的，环境和复现脚本放在文末。 先说一个贯穿全文的结论，它由后面的实验支撑： 系统的容量由「能并行执行多少工作」乘以「每份工作多快」决定，这个数在你改代码之前就定死了。超过它的那些请求不会让系统做更多事，只会去某个队列里排队。而排队这件事，在平均响应时间这个指标上是看不出来的。 一、问题的本质：并发增加，为什么延迟反而越来越高？先看一组实测数字。服务端配...
对 Dataman 的代码审计分析
Dataman 是一个开源的数据管理系统，README 里写得很克制：轻量、现代设计风格、移动端。功能清单列了二十来项，从配置管理到广告位，看得出是认真做的项目。技术栈是 Laravel 8 加 Dcat-Admin，代码量不大，一百五十个 PHP 文件、九千行左右。 我把它拉到本地跑起来审了一遍。结论不太好看：从打开登录页，到在服务器上执行系统命令，全程不需要任何已有的账号。 这篇文章记录审计过程。漏洞本身在报告里有逐条列出，这里更想讲的是怎么找到的、怎么判断的，以及中途两次差点把洞放过去的地方。 一、先摸清攻击面拿到一个 Web 项目，第一步不是搜 eval，是先搞清楚它长什么样：用什么框架、路由怎么组织、哪些入口不需要登录。 Dataman 的框架信息在 composer.json 里： 123456"require": { "dcat/laravel-admin": "2.*", "laravel/framework": "^8.12", &qu...