企业官网建设流程全解析

把代码藏进图片，这事我第一次见到是在CTF比赛的隐写题里，后来才发现，真实工作中这个需求远不止“炫技”。运维想传一份服务器配置文件又不想让聊天记录里的关键词被识别，开发想给教程配一张图、顺便把可复现的代码连同图片一起发给同事，甚至有人把一段脚本伪装成产品截图放进项目管理平台——本质上都是同一件事：让图片变成载体，把代码悄悄捎过去。

这篇文章想聊的，是几种真正把代码写进图片文件、能随时提取的“隐藏代码到图片”的实用技巧。从最直观的Notepad++手工拼接，到Windows命令行里的copy /b，再到Linux下的一条cat命令，最后还有带密码保护的steghide和完全可定制的Python脚本。前两种适合零基础快速上手，后三种适合追求隐蔽性、可玩性和自动化的人。五种方法我都实际跑过，会尽量把原理、命令、坑位都讲透，你照着做就行。

1. 先摸清5种隐藏方案的底层逻辑

很多人一听“把代码藏进图片”就觉得高深，其实拆开来看，底层思路只有三类：字符追加、文件拼接、像素替换。后面具体方法再多，都跳不出这三板斧。

1.1 字符追加：最直白的“藏尾”玩法

字符追加的思路非常简单：图片文件对阅读器来说，并不是每个字节都会被解析。JPEG文件以FF D8开头，以FF D9标记图像数据结束；解码器读到FF D9就认为图片已经读完了，后面再跟什么内容都会被忽略。PNG文件则是靠“块”结构组织，解码器处理完IEND块后，同样不再关心后续字节。

这就给“藏尾”留出了空间：把代码文本直接追加到图片文件末尾，图片查看器依然能正常打开，但用文本编辑器打开文件时，能看到图片二进制内容的尾部跟着一段可读代码。日常开发里这种方法最常见，动手门槛最低，唯一的要求是图片格式选JPEG最稳——PNG的块结构带CRC校验，部分严格解码器发现尾部多出数据会报警甚至拒绝打开。

1.2 文件拼接：在二进制层把两个文件粘在一起

字符追加是给人看的玩法，文件拼接则是把这个过程交给命令行：把图片文件的二进制数据流和代码文件的二进制数据流按顺序串联，输出成一个新文件。因为图片解码器会在自己的结束标记处停止读取，所以多出来的文件数据不会干扰图片展示。

这个方式的最大好处是“可脚本化”——一条命令就能处理大量文件，而且拼接后的文件不管用什么工具打开，数据都是完整的。它的最大弱点也很明显：文件体积是两者之和，代码稍微大一点，图片文件大小就会露出马脚。隐蔽性靠的是“看起来正常”，不是真正的抗检测。

1.3 专业隐写：把数据写进图片的“像素缝隙”

第三种思路就有点技术含量了：不是把代码追加到文件尾部，而是把代码的二进制比特流拆散，嵌入到图片像素的颜色通道里。最常用的叫LSB（Least Significant Bit，最低有效位）替换——每个像素的颜色值最后一位改动，人眼根本分辨不出颜色变化，但这一位却可以代表一个比特的数据。

这类方案的代表工具就是steghide，也可以用Python自己实现。它的隐蔽性远高于前两种：图片能正常打开，文件大小基本不变化，而且没有明显的“尾部多余数据”。代价是嵌入容量有限，并且部分专业工具可以通过统计分析方法发现LSB隐写的痕迹。简单说，它适合“藏给特定接收方看”，不适合对抗专业取证。

1.4 5种方法怎么选？先问自己三个问题

动手之前，先对照自己的真实需求选方法，能省不少时间。我的建议是看三件事：第一，你的接收方用什么平台？如果对方是Windows + 微信，那Notepad++或copy /b的方法最方便；如果两边都是Linux服务器，直接上cat或steghide。第二，代码有多长？几十行的配置文件用字符追加完全没问题，几百KB的代码包建议先压缩再藏，数据量太大时就该认真考虑LSB容量问题了。第三，是否需要防别人提取？如果只是同事之间传文件，前四种方法都够用；如果希望别人即使拿到图片也提取不出代码，必须用带密码的steghide或者自己在Python脚本里加加密逻辑。

把这几个问题想清楚，再往下看具体操作，就不会觉得方法多而无从下手。

2. 方法一：Notepad++ 快速拼接，把代码“粘”进图片末尾

如果你现在用的是Windows，桌面上已经装了Notepad++，那这是最快能跑通的一种方式，全程不需要敲命令。整个过程一句话总结：用Notepad++打开图片，把图片的二进制内容当作普通文本，把代码粘贴到文件最末尾，保存。

2.1 为什么选Notepad++而不是系统记事本

我知道很多人第一反应是用Windows自带的记事本打开图片。试一下就知道了：记事本打开大一点的图片会直接卡到无响应，因为它在加载时会尝试对整个文件做编码检测和文本渲染。Notepad++对大文件的支持好很多，而且默认以UTF-8编码处理文本，粘贴中文代码注释不容易出现乱码。

另外，Notepad++有一个很关键的能力：它不会像IDE那样对文件类型做严格限制，打开二进制文件虽然显示出来是一堆乱码，但文件内容会被完整加载，末尾追加文本保存后，原文件字节不会被破坏。如果用某些“二进制安全”较差的编辑器，保存时可能会帮你做换行符转换甚至截断意外字节，那图片就废了。想省心，就用Notepad++。

2.2 操作步骤：30秒实现“代码藏进图片”

整个流程可以分成四步，实际操作下来不超过一分钟：

第一步，准备一张JPEG格式的图片，文件尺寸不用太大，几百KB的风景图、截图都行。第二步，用Notepad++直接打开这张图片，你会看到满屏的乱码，这是正常的，不要慌，按Ctrl + End跳到文件最末尾。第三步，在末尾先输入一行容易识别的标记，比如BEGIN_CODE，然后换行粘贴你的代码。注意，代码前后都留一行分隔标记，提取的时候就知道该从哪里开始、到哪里结束。第四步，按Ctrl + S保存，文件的扩展名保持.jpg不变。

保存后再用图片查看器打开，图片显示完全正常，看不出任何改动。但你用Notepad++再次打开这个文件、跳到末尾，就能看到那行标记和代码仍然躺在图片二进制内容的尾部。

2.3 提取代码与反查验证

提取代码有两种方式。轻度使用者：直接用Notepad++重新打开这个图片文件，Ctrl + End跳到末尾，从BEGIN_CODE的下一行开始复制内容到新文件，把标记行删掉，保存为.txt或原代码扩展名即可。重度使用者：如果图片文件很大、代码很长，用编辑器拖动定位太累，更好用的是命令行检索。

Windows下打开CMD，进入图片所在目录，执行一行命令就能把尾部文本导出来：

findstr /C:"BEGIN_CODE" output.jpg > extracted.txt

这条命令会把包含BEGIN_CODE的行及其后所有内容写入extracted.txt，虽然二进制部分也会被读进去，但你从BEGIN_CODE之后开始引用就好了。需要精细处理的话，推荐用HxD这类十六进制编辑器打开图片，定位到末尾文本位置，直接选中复制，比在Notepad++里拖滚动条舒服得多。

2.4 这个方法的短板，你心里要有数

优缺点都得说清楚。它最大的优点是真零门槛，普通人也能三分钟学会；缺点是隐蔽性很差，文件大小会明显增加，任何人都能用文本编辑器打开图片看到末尾的明文代码。如果你的使用场景只是“把代码和图放一起方便传”，那没问题；但如果希望代码不被人一眼看出来，那就要考虑后面的方法了。另外强烈建议图片格式用JPEG，PNG在一些严格解码器下可能会因为CRC报错打不开。

3. 方法二：Windows 命令行 copy /b，一条命令完成二进制拼接

Notepad++方法是给人看的，命令行方法则是给脚本和批处理用的。Windows下最经典的文件拼接命令是copy /b，/? 参数少，但效果好。

3.1 为什么copy /b在Windows下最稳

copy命令默认工作在文本模式，会把文件当作文本流处理，遇到特殊字节可能做换行符转换，这会导致二进制数据被破坏。加上/b参数后，命令强制进入二进制模式，原样复制文件里的每一个字节，不做任何转换。这就是为什么网上所有图片藏文件的教程都会强调这个/b，漏了它，拼接出来的图片大概率打不开。

拼接之后的文件结构是：图片的完整二进制数据 + 代码文本的完整二进制数据。图片解码器读到JPEG的FF D9结束标记就不再向后读取，所以尾部代码不会影响图片展示。这也是为什么我把方法二和方法一归为同一类底层原理，但方法二更适合批量操作和脚本化。

3.2 实际操作：从拼接命令到大小校验

先在CMD里准备两个文件：一张cover.jpg和一份code.txt，然后执行：

copy /b cover.jpg + code.txt output.jpg

执行完成后，系统会提示“已复制 1 个文件”。这行命令的意思是：把cover.jpg和code.txt按字节顺序合并，输出到output.jpg。顺序不能反，一定先图片后文本，文本放前面的话，很多图片解码器会在文件头部一开始就找不到JPEG的SOI标记FF D8，直接报格式错误。

拼接完后做两步验证。第一步，看文件大小，用dir命令查看：

dir output.jpg

正常情况下output.jpg的大小应该等于cover.jpg和code.txt两者大小之和，大小不对基本就是文本模式搞的鬼。第二步，直接用图片查看器打开，能正常显示就没问题。

如果文件名或路径里带空格，记得用双引号包起来，这是命令行最容易被忽略的细节。

3.3 读取数据时的两个小坑

坑一，很多人在PowerShell里执行copy /b发现不生效。这是因为PowerShell把copy解释成自身的Copy-Item别名，参数语法对不上。解决方式是在前面加cmd /c，强制走CMD解释器：

cmd /c copy /b cover.jpg + code.txt output.jpg

坑二，代码文本本身如果比较大，建议在代码末尾多留两个空行，避免后面如果再拼接其他数据时，两段内容边界不清。读取时，找代码起始位置可以用findstr /N，也可以直接用CFF Explorer这类十六进制工具定位到文件尾部，从文本可读的地方开始提取。

4. 方法三：Linux cat 命令，一劳永逸的隐写组合拳

如果你日常工作在Linux服务器上，那方法三才是真正的主力方案。Linux下没有花哨的工具也能完成同样的拼接，而且配合管道和重定向，可以玩出比Windows命令行更舒服的流程。

4.1 cat拼接的基础版

方法很简单，就是利用cat把多个文件按顺序输出，再用重定向写进新文件：

cat cover.jpg code.txt > output.jpg

这里有个细节要强调：>重定向会把cat输出的所有内容写到output.jpg，顺序完全取决于命令行里文件的排列顺序。确保图片在前、文本在后，和Windows的copy /b是一样的原理。

拼接完同样用两个命令验证。一个是file，用来确认图片格式是否仍然正常：

file output.jpg

正常输出类似JPEG image data, baseline, precision 8, 600x400，如果显示data或ASCII text，说明拼接顺序出了问题。另一个是binwalk，它可以扫描文件里嵌入的其他文件结构，能直观看到图片尾部是否藏了文本或归档文件：

binwalk output.jpg

4.2 玩法升级：代码先压缩再藏

直接在图片尾巴上贴明文代码，代码不长还好，代码一长就特别引人注目，而且关键词检索能直接扫出来。我的习惯是先把代码打包压缩，再往图片里拼。比如准备一个project目录，里面有多个代码文件：

tar czf code.tgz project/ cat cover.jpg code.tgz > output.jpg

接收方拿到图片后，用binwalk就能看到尾部多了一个gzip压缩包，提取时把文件从尾部切出来再解压就行。如果想更准确定位，可以在压缩包前面加一个文本标记，比如：

(echo "BEGIN_CODE"; tar czf - project/) > payload.tmp cat cover.jpg payload.tmp > output.jpg

这条命令先把标记和压缩包合成一个临时文件，再拼到图片后面。提取的时候直接搜索BEGIN_CODE，从标记位置开始就是完整的压缩数据流。

4.3 验证与“反侦察”

很多人在Linux下用cat拼接图片和代码后，会忽略文件校检。如果图片本身被人用看图软件重新保存过一次（比如从JPEG转存成PNG），再拼接上去的代码就可能因为格式变化而无法稳定提取。所以我在实际操作中，会额外做一次哈希比对：

# 提取尾部数据并保存为 extracted.tgz dd if=output.jpg of=extracted.tgz bs=1 skip=<BEGIN_CODE的字节偏移> # 对比哈希 md5sum code.tgz extracted.tgz

两条命令的哈希一致，就说明拼接和提取的链路没有丢数据。至于“反侦察”，我只能说，所有尾部拼接类方法都无法对抗文件大小分析和熵值检测——如果对方用工具扫描图片尾部，数据是藏不住的。所以它更适合“便捷传递”而不是“对抗提取”。

4.4 哪些场景最推荐用cat方案

我个人最常用的场景有三个：一是给远程服务器传配置片段，直接把一个.env或nginx.conf拼到产品图上，传到对象存储后需要时再拉回来切出，全程不经过聊天工具的关键词扫描；二是做自动化脚本，把多个项目文件压缩成包拼到一张公司封面图上，一起丢进团队的共享目录；三是CTF赛前练习，快速把payload藏进图片，验证完再换steghide方案。如果你只是偶尔用一次，cat方案完全够了。

5. 方法四：steghide 专业隐写，让代码“溶”进像素里

前面三种方法本质都是“拼接”，只要有人拿十六进制工具打开图片，多加出来的数据就一览无余。如果希望代码真正“隐形”，得用专业的隐写工具steghide。

5.1 steghide和前面几种有什么本质区别

steghide不再把代码附加到文件尾部，而是把代码的二进制数据分散嵌入到图片的像素颜色值里，具体说，是修改每个颜色通道的最低位。一张JPEG图片的像素数量是几十万到上百万级别，每个像素有RGB三个通道，把每个通道的最后1比特换成数据比特，肉眼看起来颜色没有任何变化，文件大小也基本不变。更关键的是，这让文件尾部干干净净，用十六进制编辑器看也看不出明显的“多余内容”。

它和前面几种方案的差距，就像是把纸条贴在书本最后一页，和把文字用隐形墨水写在纸页行间——前者翻到最后一页就能看见，后者需要特定的方法才能显现。

5.2 安装、嵌入、提取的全流程

安装很简单，Debian/Ubuntu系统直接执行：

sudo apt install steghide -y

嵌入代码文件到图片，使用embed子命令：

steghide embed -cf cover.jpg -ef secret.txt -p your_password

参数解释一下：-cf指定载体文件（cover file），就是那张你要隐藏数据的图片；-ef指定要嵌入的文件，就是代码文件；-p指定密码。执行后会输出类似embedding "secret.txt" in "cover.jpg"... done的提示。如果图片尺寸太小、塞不进代码，会报空间不足的错误。

提取时是把过程反过来：

steghide extract -sf output.jpg -p your_password

-sf指定隐写后的图片文件，执行后会在当前目录生成secret.txt。这里要注意，提取时密码必须正确，而且图片文件不能被二次压缩或转码，否则嵌入的数据可能损坏。

5.3 一句话讲清LSB原理

用一句话解释LSB：把每个像素颜色值的最低一位换成你的数据比特，改完之后，像素颜色从250变成251，肉眼根本察觉不到。单个像素能藏3个比特（RGB各1位），一张1000x1000的图片就能藏约37.5万个字节，足够放一个中等规模的脚本或配置文件了。

steghide在LSB之上还做了一层散布处理——数据会按密码生成的伪随机序列打散到图片各处，不是简单地从第一个像素开始顺序写。这就是为什么即使有人猜到用了steghide，没有密码也很难恢复原始数据顺序。

5.4 steghide的边界与注意事项

先说支持格式，steghide只支持JPEG、BMP、WAV和AU这几种格式，不支持PNG，这是个比较常见的坑。很多人习惯用PNG做素材，结果报错说格式不支持，换一张JPEG就顺利了。

再说容量，JPEG图片嵌入的数据量不能太大，设计上要留足余量，否则会嵌入失败或导致图片质量明显下降。我建议代码文件压缩后控制在图片原始大小的10%以内，比如500KB的图片，最多塞50KB左右的数据，稳定性和画质都比较好。

最后是操作顺序：永远保留原始图片和源码备份，因为你嵌入后的图片已经带了数据；如果多次嵌入同一张图，旧数据不保证能被正确提取。我自己就吃过这个亏，把两张图反复嵌入，最后提取时一片乱码。

6. 方法五：Python 自研 LSB 隐写脚本，彻底掌控隐藏过程

steghide虽然好用，但有两个问题没法绕过去：格式只支持JPEG和BMP，且嵌入规则是写死的。如果你需要把代码藏进PNG图片，或者希望自己控制嵌入位置、数据格式、加密逻辑，那就得自己写脚本了。这里给出一份我实际用过的Python实现，基于Pillow库操作像素，代码量不大，但足够跑通整个流程。

6.1 为什么要自己写脚本

自己写脚本最大的意义是“可控”。steghide对嵌入位置有内部算法，你的数据变成什么样、散布在哪里，对使用者来说是个黑盒。而自己实现LSB，可以自由决定哪些像素通道存数据、数据头用什么格式、是否加密，甚至能做成批量处理的工具。另外，Python生态里的Pillow可以处理PNG，这正好补上steghide缺失的一环。

6.2 核心原理：LSB隐写到底在改什么

先把图像拆成像素矩阵，每个像素有RGB三个值，取值范围都是0-255。在计算机里，255的二进制是11111111，253是11111101，两者最低位不同。把某个像素的某个颜色通道最低位改成0或1，这个像素的颜色变化程度只有“1/255”，人眼几乎分辨不出来。

存储数据时，我们把代码文本转成一串二进制比特流，然后按照“每1个比特占1个像素的R通道最低位”的方式写进去。以一张1920x1080的图片为例，有约207万个像素，每个像素的R通道可以存1个比特，总共能存约25.9万字节，按UTF-8编码一个汉字3字节计算，能存约8.6万个汉字，放普通代码文件绰绰有余。如果R、G、B三通道全用上，容量再翻三倍。

6.3 完整代码与逐段解读

下面是一份可运行的LSB隐写脚本，包含嵌入和提取两个功能。

from PIL import Image import sys END_MARKER = '00110101' # 自定义结束标记，用于提取时判断数据边界 def text_to_bits(text: str) -> str: """把文本转成二进制比特串，末尾附加结束标记。""" data = text.encode('utf-8') bits = ''.join(f'{byte:08b}' for byte in data) return bits + END_MARKER def embed_text(cover_path: str, output_path: str, secret: str) -> None: img = Image.open(cover_path).convert('RGB') pixels = img.load() width, height = img.size bits = text_to_bits(secret) idx = 0 for y in range(height): for x in range(width): if idx >= len(bits): break r, g, b = pixels[x, y] # 只改R通道的最低位 new_r = (r & 0xFE) | int(bits[idx]) pixels[x, y] = (new_r, g, b) idx += 1 if idx >= len(bits): break img.save(output_path) print(f'[+] 已写入 {len(bits)} 比特到 {output_path}') def extract_text(stego_path: str) -> None: img = Image.open(stego_path).convert('RGB') pixels = img.load() width, height = img.size bits = [] for y in range(height): for x in range(width): r, _, _ = pixels[x, y] bits.append(str(r & 1)) raw = ''.join(bits) end_pos = raw.find(END_MARKER) if end_pos == -1: print('[-] 未找到结束标记，可能图片没有被隐写过') return data_bits = raw[:end_pos] # 每8个比特还原成一个字节 byte_data = bytes(int(data_bits[i:i+8], 2) for i in range(0, len(data_bits), 8)) print(byte_data.decode('utf-8', errors='replace')) if __name__ == '__main__': if sys.argv[1] == 'embed': secret = open(sys.argv[3], 'r', encoding='utf-8').read() embed_text(sys.argv[2], sys.argv[4], secret) elif sys.argv[1] == 'extract': extract_text(sys.argv[2])

使用方式：

# 嵌入 python lsb_tool.py embed cover.png code.txt output.png # 提取 python lsb_tool.py extract output.png

几个关键点拆开说。r & 0xFE是把R通道的最低位清零，不管原来最后一位是0还是1，都会变成0；然后再用| int(bits[idx])把我们的数据位填进去，这样既不影响高7位，又能准确写入1个比特。提取时用r & 1取最低位，一路读下来就还原出比特流。

结束标记END_MARKER的作用是告诉提取方“数据到这里结束”。如果没有它，提取方会把整张图所有像素的最低位都读出来，后面的内容全是被隐藏数据覆盖不到的区域，全是随机0和1，没法判断真实长度。用固定结束标记的缺点是，如果被隐藏数据本身碰巧包含连续相同的8位序列，可能会提前截断；实战中更稳妥的做法是在数据头部用4个字节记录数据长度，我这里是简化版本，方便理解。

6.4 进阶：中文、加密、长文本怎么处理

脚本里已经默认用UTF-8编码处理文本，所以中文注释和路径都没问题。但要注意，如果你要藏的是二进制文件，而不是文本，可以直接用open(file, 'rb').read()拿到字节流，再把每个字节转成8位二进制，提取时再按字节还原写到文件里，这样就不受文本编码限制了。

加密方面，推荐在LSB嵌入前先对数据做一层加密，比如用AES-CTR模式加密后，再调用嵌入函数。这样即使别人发现了LSB数据，没有密钥也还原不出原始内容。Python里可以用cryptography库，几行代码就能实现。我给个伪代码思路：

from cryptography.fernet import Fernet key = Fernet.generate_key() cipher = Fernet(key) ciphertext = cipher.encrypt(secret_bytes) # 再把 ciphertext 交给 embed_text 写入图片

长文本处理要分两步看：一是容量够不够，前面算过，一张1080P的图，三通道全用能存约70多万字节，普通代码根本用不完；二是嵌入速度，纯Python逐像素操作，大图可能会跑十几秒甚至更久。想提速的话，可以用numpy把图片一次性读成数组批量操作，也可以把循环改成每隔N个像素写入一位，牺牲一点容量换速度。

7. 常见问题与排查技巧实录

到这儿，五种方法都撸了一遍。说实话，实际跑起来后遇到的问题往往比原理更磨人，我把这些年踩过的坑集中整理成一份速查表，方便你直接对照。

7.1 问题速查表

7.2 踩坑实录：我在实操中遇到的3件事

第一件事，我曾经用copy /b批量处理了上百张图片，结果发现有些图片在手机里能打开，在电脑的某些看图软件里却提示文件已损坏。排查后发现，原因是部分软件会严格按照JPEG末尾的FF D9标记检查文件长度，尾部多出数据就认为文件不完整。解决方案倒简单：拼接前先把图片统一转成JPEG格式，并确认原图本身没有损坏；如果必须要用PNG，就改用LSB方案。

第二件事，用steghide嵌入代码后，我习惯性把图片压缩了一下再发给同事，结果对方提取时直接报错。这就是有损压缩的破坏力——JPEG压缩会重新编码像素，把嵌入到最低位的比特全部打乱。后来我的原则是，涉及隐写的图片绝不二次压缩，传送过程也不允许任何转码操作。

第三件事，写Python LSB脚本时第一次用结束标记，刚好被隐藏的文本里有一大段连续的二进制序列与结束标记撞车，导致提取时数据被截断，后面一大半内容丢失。修复方法就是前面说的：不要把结束标记写死成固定8位串，而是用一个4字节长度头，先读长度再按长度取数据。虽然代码多了几行，但稳定性提升非常明显。

7.3 安全边界与合规使用

最后必须说一句，这类“隐藏代码到图片”的技巧，本质上是一把工具刀。它可以用来做CTF练习、保护个人配置文件、方便代码分享，也可以被滥用。我在这篇文章里演示的所有方法，都只建议用于学习、开发和正当的数据管理场景，不要用来藏恶意代码、绕过他人的系统保护机制，更不要用于任何违法违规的事。技术本身是中性的，怎么用取决于人，这一点希望你心里有数。

我个人在实际操作中的体会是：日常工作里，80%的需求用cat拼接或copy /b就能解决，真正需要steghide的场景其实很少，Python脚本更像是“给自己造工具”的乐趣。如果你第一次尝试，建议从Notepad++或copy /b开始，跑通一次之后再玩steghide和LSB，这样对整个体系的把握会扎实得多。