简介面向网络安全从业者与渗透测试学习者的神行-网侦(渗透)便携浏览器压缩包主打免安装、可随U盘等移动介质快速部署的轻量测试环境用于安全检测、网络侦查与漏洞评估等场景。资源描述围绕渗透测试的价值、工具特性与标准流程展开便携运行、集成端口扫描与漏洞扫描等常用模块、借助代理等手段降低被识别风险并按信息收集、漏洞扫描、探测验证、利用渗透到报告与修复建议的顺序梳理测试环节同时强调合法授权与操作规范。压缩包整体约120.62MB包内文件总数与类型明细暂未提供需解压后自行查看目录结构。目前已有416人学习下载适合具备一定网络基础、希望搭建随身测试环境并对照流程做查漏补缺的中级安全人员参考。1. 便携浏览器在授权测试里到底解决什么问题客户现场的机器不让装软件临时申请一台测试机要走两周流程可交付时间只剩三天——这种局面下便携浏览器就是那根救命稻草。它把运行时、配置目录、扩展和书签全部塞进一个文件夹解压即用不写注册表、不碰系统路径拔掉 U 盘就能带走。对做网络安全评估的人来说它解决的不是「能不能上网」而是「能不能在一个干净、可回滚、行为可解释的环境里观察目标系统的前端表现」。适合谁需要频繁切换测试环境的安全工程师、做前端接口自查的开发、以及要给第三方做验收但拿不到管理员权限的评估人员。不适合谁想拿它当日常主力浏览器的人便携化的代价是更新滞后和配置漂移。2. 拆包看清结构便携浏览器目录里藏着的四层东西拿到一个几百兆的压缩包很多人的第一反应是双击主程序看能不能跑起来。我一般反着来先解压到固定路径再用find把目录骨架打印一遍。原因很实在——便携版浏览器最容易出问题的地方从来不是主程序而是它自带的配置目录和启动脚本。你不先看清楚它把用户数据放在哪、预置了什么扩展、有没有写死的相对路径后面所有的测试结论都可能是被污染过的。2.1 解压后先别急着双击解压本身没什么技术含量但路径选择有讲究。不要解压到桌面或者带中文、带空格的目录某些打包脚本里写的是相对路径遇到空格直接崩。我习惯统一放到~/lab/下面按批次编号方便后面做目录级 diff。# 建立独立的工作根目录避免和其他测试批次混在一起 mkdir -p ~/lab/portable/run-001 cd ~/lab/portable/run-001 # -q 静默解压-d 指定目标目录压缩包放同级的 incoming 目录 unzip -q ~/lab/incoming/portable-browser.zip -d . # 只看两层目录先建立整体印象不要一上来就 find 全量 find . -maxdepth 2 -type d | sort # 统计文件数量和总体积用来和后续批次做对比 find . -type f | wc -l du -sh .-maxdepth 2是关键参数便携包动辄几万个文件全量find会刷屏且没有信息量。两层目录足够看出它是不是标准的三段式结构可执行文件区、用户数据区、附加资源区。一个典型的便携浏览器目录大致长这样不同打包方式会有出入但层次逻辑大同小异目录/文件作用要不要动bin/或根目录主程序浏览器可执行文件不动但要校验哈希profile/或data/用户数据目录含书签、Cookie、缓存必须换成干净副本extensions/预置扩展逐个看 manifest能删则删*.bat/*.sh启动脚本通常带一堆参数必须逐行读readme/说明.txt打包者留下的使用说明读一遍常藏关键参数那张表里最容易被忽略的是启动脚本。便携版为了做到「双击即用」往往在脚本里写死了--user-data-dir、--disk-cache-dir甚至首页地址。我见过一个包里脚本直接指向一个已经不存在的盘符双击后浏览器起得来但配置全丢表现出来就是「每次打开都是全新状态」很多人以为是浏览器坏了其实是路径没对上。读脚本的时候重点看三件事路径是不是相对路径、有没有带--disable-*这类削弱安全性的参数、有没有把调试端口开到0.0.0.0。最后一条是血泪经验调试端口开在公网可达地址上等于把整个浏览器的控制权交出去。# 把所有启动脚本找出来逐个打印内容 find . -maxdepth 2 \( -name *.sh -o -name *.bat -o -name *.cmd \) -print -exec cat {} \; # 单独检查有没有把调试端口暴露到所有网卡 grep -rn remote-debugging-address . --include*.sh --include*.bat第二条grep如果命中0.0.0.0这个包我就不用了或者至少手动改成127.0.0.1。这不是洁癖调试端口没有鉴权任何能连上这个端口的人都可以读写页面、导出 Cookie。2.2 profile 目录才是行为差异的来源同一个浏览器二进制配上不同的 profile行为可以完全不一样。这是因为账户登录态、扩展、主页设置、甚至语言和时区偏好都落在用户数据目录里。便携包为了「开箱即用」经常预置一份配置好一切的 profile这对普通用户是便利对做评估的人是污染源。判断方法很直接看profile/Default/下面有没有Cookies、Login Data、Preferences这几个文件以及它们的大小。# 定位用户数据目录通常在 profile/ 或 data/ 下 PROFILE_DIR$(find . -maxdepth 3 -type d -name Default | head -n 1) echo profile: $PROFILE_DIR # 列出关键文件及大小Cookies 超过几十 KB 就说明带着登录态 ls -lh $PROFILE_DIR/Cookies $PROFILE_DIR/Login Data $PROFILE_DIR/Preferences 2/dev/null # 用 sqlite3 数一下预置了多少条 Cookie注意先拷贝一份再查避免锁库 cp $PROFILE_DIR/Cookies /tmp/cookies-check.db sqlite3 /tmp/cookies-check.db select count(*) from cookies;sqlite3直接查原库会遇到database is locked因为浏览器进程可能持有句柄所以先cp一份到/tmp再查。这个细节看起来小实际能省掉一轮「为什么查不出来」的自我怀疑。查出来的条数如果是个位数说明基本干净上百条的话这份 profile 里大概率带着某个系统的登录会话。带着别人的登录态去做测试结论是不可信的——你看到的页面可能是个已登录视图而不是目标系统对匿名用户的真实响应。我的做法是保留原始 profile 作为对照另外复制一份并清空关键数据做基线对比# 备份原始 profile后面用来做差异对比 cp -a $PROFILE_DIR ~/lab/portable/run-001-profile-orig # 建立干净基线只保留 Preferences 的结构删掉状态类数据 rm -f $PROFILE_DIR/Cookies $PROFILE_DIR/Cookies-journal $PROFILE_DIR/Login Data rm -rf $PROFILE_DIR/Local Storage $PROFILE_DIR/Session Storage删之前一定先备份cp -a的-a保留权限和时间戳方便后面判断哪些文件是打包时写入的、哪些是运行后生成的。2.3 完整性校验与残留配置清理便携包在传递过程中被改动是常事尤其是通过聊天工具转发过几轮的包中间可能被塞了东西。校验分两层文件级哈希和结构级异常。# 对所有可执行文件和脚本算哈希输出留档 find . -type f \( -name *.exe -o -name *.sh -o -name *.so -o -name *.dll \) \ -exec sha256sum {} \; | sort -k2 ~/lab/portable/run-001.sha256 # 看文件修改时间分布打包时间应该集中出现明显偏离的要留意 find . -type f -newermt -1 day | head -n 20哈希本身不能证明安全但能证明「和上次比有没有变」。做多批次测试时把每次的哈希清单存下来下次一对比就知道包里哪些文件被动过。修改时间那条命令更实用正常的包文件时间集中在打包那一天如果某个脚本的修改时间明显晚于其他文件那它大概率是后来加进去的。结构级异常主要看三类根目录下多出来的autorun类文件、扩展目录里的可疑项、以及配置里写死的远程地址。# 检查扩展目录打印每个扩展的 manifest 关键字段 for d in $(find . -maxdepth 3 -type d -name *extension* -o -maxdepth 3 -type d -name extensions); do echo $d find $d -name manifest.json -exec sh -c echo -- $1; cat $1 _ {} \; donemanifest.json里重点看permissions和content_scripts。前者如果包含all_urls加上webRequest意味着这个扩展能看到所有站点的全部请求后者如果matches写的是*://*/*说明它往每个页面都注入脚本。预置这类扩展的便携包我不会直接用于评估要么删掉扩展要么用干净 profile 启动。提示清理配置前先把原始包完整备份一份评估过程中如果出现「和预期不符」的现象需要能回到原始状态复现否则排查会变成猜谜。3. 搭隔离环境快照、独立数据目录与回环抓包便携解决了「不装软件」但没有解决「不污染」。浏览器跑起来会写缓存、写历史、写 IndexedDB这些东西落在便携目录里下一轮测试就会带着上一轮的痕迹。真正能复现的环境必须做到每次启动都是同一个起点而且能证明它确实是从同一个起点启动的。3.1 为什么每次测试都要从快照起虚拟机快照是成本最低的可回滚手段但很多人只快照一次就一直用导致快照本身也在漂移。我的习惯是每个测试批次开始前重建一次快照而不是复用上周的。重建过程不复杂关键在于把「环境指纹」记下来出问题时有对照。# 记录环境指纹和测试记录放在一起 date -u %Y-%m-%dT%H:%M:%SZ ~/lab/portable/run-001/env.txt hostname ~/lab/portable/run-001/env.txt uname -a ~/lab/portable/run-001/env.txt ip -brief addr ~/lab/portable/run-001/env.txt # 记录时区和语言很多前端行为差异来自这两个设置 timedatectl | grep -E Time zone|Local time ~/lab/portable/run-001/env.txt echo LANG$LANG LC_ALL$LC_ALL ~/lab/portable/run-001/env.txtdate -u用 UTC 输出避免不同机器时区不同导致记录对不上。时区和语言这两项看着无关紧要实际影响不小某些站点会根据Accept-Language返回不同版本的页面如果你的环境是英文而目标是中文看到的接口清单可能都不一样。快照的另一个作用是兜底。测试过程中如果浏览器把系统搞出异常装了个奇怪的扩展、改了系统设置回滚比修复快得多。我一般会在快照描述里写清楚三件事快照时间、当时的便携包哈希、以及这一轮要测的目标地址范围。下次看到这个描述就知道该不该用它。3.2 启动参数怎么配才不留痕参数配置是整篇里最值得抄作业的部分。下面这套参数是我在多次评估中收敛出来的目标是三件事数据目录可控、后台行为收敛、调试接口只在本地。#!/usr/bin/env bash # 启动便携浏览器参数按功能分组方便按需裁剪 set -euo pipefail BROWSER_BIN$HOME/lab/portable/run-001/bin/chrome PROFILE_DIR$HOME/lab/portable/profiles/run-001 CAPTURE_DIR$HOME/lab/capture mkdir -p $PROFILE_DIR $CAPTURE_DIR $BROWSER_BIN \ --user-data-dir$PROFILE_DIR \ --profile-directoryDefault \ --no-first-run \ --no-default-browser-check \ --disable-sync \ --disable-background-networking \ --disable-component-update \ --disable-featuresTranslate,OptimizationHints \ --disk-cache-size104857600 \ --remote-debugging-port9222 \ --remote-debugging-address127.0.0.1 \ --window-size1440,900 \ about:blank逐条说清楚为什么这么设因为换环境时你需要知道哪条能删参数作用建议值能不能删--user-data-dir指定用户数据根目录每批次独立不能删--profile-directory指定子配置目录Default可删--no-first-run跳过首次引导弹窗固定开不能删--no-default-browser-check跳过默认浏览器检查固定开不能删--disable-sync关闭账号同步固定开不能删--disable-background-networking关闭后台联网探测固定开建议保留--disable-component-update关闭组件自动更新固定开建议保留--disable-features关掉翻译和优化提示按需可删--disk-cache-size缓存上限单位字节100 MB可按需--remote-debugging-port调试端口9222不用脚本时删--remote-debugging-address调试端口绑定地址127.0.0.1不能改成0.0.0.0--disable-background-networking这条值得单独讲。浏览器在后台会做一堆探测请求包括组件下载、时间同步、安全浏览服务查询。这些请求混在你的测试流量里抓包时很难区分哪些是目标系统的、哪些是浏览器自己发的。关掉它流量清单会干净很多。同理--disable-component-update防止它自己升级组件导致版本漂移。--remote-debugging-address127.0.0.1是硬性要求。默认情况下调试端口只监听回环但有些打包脚本会手动加上0.0.0.0一旦加上同一网段的人就能连上来。这条参数我每次都会显式写一遍不依赖默认值。set -euo pipefail这三个 shell 选项也建议保留-e让命令失败时立刻退出-u让引用未定义变量时报错-o pipefail让管道中间失败也能被捕获。便携环境的脚本最怕「失败了还继续往下跑」最后跑出来的结果不知道是哪一步的。3.3 用回环抓包确认出站请求参数配好之后下一步是证明环境确实按预期工作。最直接的办法是在回环接口上抓包看浏览器到底发了哪些请求。这一步会暴露很多藏不住的东西预置扩展的回连、打包者留下的统计埋点、甚至是主页的自动刷新。# 只抓回环上目标端口的流量-s 0 抓完整包-n 不做 DNS 反解 sudo tcpdump -i lo -n -s 0 -w ~/lab/capture/run-001.pcap tcp port 8080参数说明-i lo限定回环接口避免抓到无关流量-n关掉反向解析否则抓包过程本身会发 DNS 查询-s 0抓完整数据包而不是只抓包头-w直接写文件方便事后分析。过滤器tcp port 8080按你的目标服务端口改。抓下来的 pcap 用脚本过一遍比肉眼翻 Wireshark 快得多# 统计 pcap 中的目标地址和端口组合快速定位异常外联 from collections import Counter from scapy.all import rdpcap, IP, TCP cap rdpcap(/home/lab/capture/run-001.pcap) counter Counter() for pkt in cap: if IP in pkt and TCP in pkt: # 只记录 SYN 包避免同一条连接被重复计数 if pkt[TCP].flags 0x02: counter[(pkt[IP].dst, pkt[TCP].dport)] 1 for (dst, dport), cnt in counter.most_common(20): print(f{dst}:{dport}\t{cnt})pkt[TCP].flags 0x02是在判断 SYN 标志位只统计连接发起次数这样一个长连接不会被算成几十次。输出里如果出现你没有访问过的地址那就是浏览器自身的后台请求回去检查是不是漏了--disable-background-networking。抓包只能看到网络层看不到「哪个页面发起的」。要定位到具体页面得靠下一章的调试协议。4. 把浏览器变成检查工具请求、Cookie 与扩展面便携浏览器本身只是个容器真正让它变成检查工具的是调试协议。开着--remote-debugging-port启动之后可以用脚本接管页面自动收集请求、导出 Cookie、检查存储比手动开开发者工具逐条翻效率高一个数量级。这一章的三段脚本可以直接拿去改目标地址用。4.1 用脚本收集一份请求清单手动开网络面板的问题是容易漏页面加载完你才开始看前面的请求已经滚过去了。用脚本从页面打开前就挂上监听一条不落。# 收集单次页面访问的全部请求输出方法、类型和地址 from playwright.sync_api import sync_playwright TARGET http://127.0.0.1:8080/ # 只填自有或已获书面授权的地址 with sync_playwright() as p: browser p.chromium.launch( executable_path/home/lab/portable/run-001/bin/chrome, args[ --user-data-dir/home/lab/portable/profiles/pw-001, --disable-sync, --disable-background-networking, ], headlessFalse, # 有头模式方便肉眼对照页面状态 ) ctx browser.new_context(ignore_https_errorsFalse) reqs [] # 监听请求事件把关键字段压成一个元组存起来 page ctx.new_page() page.on(request, lambda r: reqs.append( (r.method, r.resource_type, r.url) )) page.on(requestfailed, lambda r: reqs.append( (FAILED, r.resource_type, r.url) )) page.goto(TARGET, wait_untilnetworkidle, timeout30000) for method, rtype, url in reqs: print(f{method:8} {rtype:12} {url}) browser.close()wait_untilnetworkidle表示等网络静默 500 毫秒再继续适合页面有异步加载的场景如果页面有长轮询这个条件永远不满足就把timeout调小并改用domcontentloaded。ignore_https_errorsFalse表示不忽略证书错误评估场景下应该保持严格证书有问题就应该暴露出来而不是被吞掉。requestfailed这个事件容易被忽略但对排查很有用。失败的请求会单独标记成FAILED你能一眼看出哪些资源加载不出来——有时候接口 404 不是后端问题是前端把地址写错了。拿到清单后按域名分组看比逐条读更快# 按域名聚合快速看出页面依赖了哪些外部资源 from urllib.parse import urlparse from collections import defaultdict grouped defaultdict(list) for method, rtype, url in reqs: host urlparse(url).netloc or (relative) grouped[host].append((method, rtype, url)) for host, items in sorted(grouped.items()): print(f\n {host} ({len(items)} 条)) for m, t, u in items[:5]: print(f {m:6} {t:10} {u})如果输出里出现第三方统计、字体、CDN 的域名说明页面确实在往外发请求。这些是不是问题取决于目标系统的合规要求但至少你手里有一份可交付的清单而不是一句「好像有外链」。4.2 Cookie 属性逐项过一遍Cookie 的问题往往不是「有没有」而是「属性对不对」。HttpOnly缺失意味着脚本能读到Secure缺失意味着明文通道也会带上SameSite设成None又没配Secure的多数浏览器会直接拒绝。这些属性在开发者工具里能看但一条条点太慢。# 导出当前上下文的全部 Cookie 并标注属性风险 cookies ctx.cookies() risky [] for c in cookies: flags [] if not c.get(httpOnly): flags.append(缺少 HttpOnly) if not c.get(secure): flags.append(缺少 Secure) if c.get(sameSite) in (None, None): flags.append(SameSite 过宽) if flags: risky.append((c[name], c.get(domain), flags)) for name, domain, flags in risky: print(f{name:24} {domain:24} {; .join(flags)}) print(f\n共 {len(cookies)} 条其中 {len(risky)} 条存在属性缺失)字段含义对照一下httpOnly为False表示前端脚本能通过document.cookie读到secure为False表示在明文通道上也会发送sameSite为None表示跨站请求也会带上。三者组合起来的风险不一样判定标准是会话类 Cookie 三项都应该满足而纯前端的偏好设置类 Cookie 缺HttpOnly是正常的。这段脚本有个前提ctx得先访问过目标页面否则拿到的是空列表。所以实际使用时把它接在 4.1 的goto之后不要单独跑。4.3 扩展与预置脚本的风险面便携包如果预置了扩展这个扩展就在你的每一个测试页面里运行。它的权限决定了它能做什么而manifest.json里的permissions字段就是权限清单。# 打印所有扩展的权限声明按扩展目录分组 find ~/lab/portable/run-001 -name manifest.json -path *extension* | while read -r m; do echo $m # 用 python 解析避免 jq 缺失 python3 -c import json,sys djson.load(open($m)) print( name:, d.get(name)) print( permissions:, d.get(permissions, [])) print( host_permissions:, d.get(host_permissions, [])) csd.get(content_scripts, []) for c in cs: print( content_scripts matches:, c.get(matches)) done看三个字段就够了permissions里有webRequest或cookies的能读请求和 Cookiehost_permissions里是*://*/*的对所有站点生效content_scripts.matches是通配的说明它往每个页面注入脚本。处理方式分两种。如果这个扩展是目标系统运行必需的那就保留但记录下来评估结论里要注明「页面行为受扩展影响」如果不是必需的删掉再测一遍——两次结果对比就能看出扩展到底改了什么。这个对比过程比争论「扩展有没有影响」有用得多。注意删扩展之前先确认它不是授权校验的一环。有些内部系统会依赖特定扩展做客户端环境检查删掉后页面直接白屏这时候要看的是控制台报错而不是继续怀疑网络。5. 避坑与排查五条翻车记录下面这五条都是实际踩过的按「现象 → 原因 → 解决」写遇到同类问题可以直接对号。5.1 启动阶段的三类翻车现象一双击能启动命令行启动却提示配置目录只读。原因是打包脚本用的是相对路径而你在别的目录下执行主程序相对路径解析到了没有写权限的位置。解决方法是启动前先cd到包的根目录或者显式传绝对路径的--user-data-dir。我现在的脚本里路径全部用$HOME展开的绝对路径就是为了绕开这个。现象二浏览器起来了但地址栏输入任何地址都跳到同一个页面。原因通常是预置 profile 里写死了主页策略或者启动脚本里带了首页参数。排查方法是看profile/Default/Preferences里的homepage和session.startup_urls字段以及启动脚本最后那个位置参数。解决方法是新建一个空 profile 目录启动确认主页恢复正常再回头决定要不要保留原配置。现象三调试端口连不上curl 127.0.0.1:9222/json返回空。先确认进程还在不在再确认端口绑在哪个地址上ss -lntp | grep 9222如果输出里是0.0.0.0:9222而不是127.0.0.1:9222说明绑定地址被改过这时候要做的是改回回环而不是去连它。如果根本没有输出那就是参数没生效检查是不是同时传了两个--remote-debugging-port后一个会覆盖前一个。5.2 行为与数据阶段的两类翻车现象四脚本收集到的请求数明显少于开发者工具里看到的。原因是监听挂得太晚。page.on(request, ...)必须在goto之前注册如果先goto再挂监听首屏请求全部漏掉。这个问题在新手写的脚本里非常常见表现就是「明明页面加载了很多资源脚本只报三条」。解决办法是把监听注册放在new_page()之后、goto()之前顺序不能反。现象五同一个页面跑两次Cookie 数量差很多。原因是两次用了同一个 profile 目录第二次带着第一次的会话。便携环境最容易在这里翻车因为默认路径是固定的。解决方法有两个要么每轮启动前删掉 profile 目录重建要么用带批次号的新目录。我倾向后者删目录的操作不可逆万一第一轮的数据还要用就麻烦了。# 按批次号建目录避免复用导致状态污染 BATCH$(date %Y%m%d-%H%M%S) mkdir -p ~/lab/portable/profiles/$BATCH echo 本轮 profile: ~/lab/portable/profiles/$BATCH补一条容易被当成玄学的某些页面在无头模式下和在 headed 模式下返回内容不一致原因是前端做了环境检测。遇到「脚本抓不到但手动能看到」先把headless改成False再跑一遍能排除掉一大半假问题。6. 进阶把便携环境固化成一份可复现清单前面几章的做法如果每次都手动敲一遍迟早会漏步骤。我的做法是把它固化成一个启动前检查清单加一个引导脚本每次开新批次先跑脚本再对着清单勾。检查项通过标准不通过的处置包完整性哈希清单与上批次一致或已记录差异重新获取包不继续profile 状态新建目录Cookie 计数为 0删除重建扩展清单无webRequest 通配注入删除扩展后重测启动参数调试端口仅绑127.0.0.1改参数重开网络观察回环抓包有记录补抓后再操作页面环境指纹时间、主机名、时区已记录补记录引导脚本负责把目录、指纹、参数三件事一次做完#!/usr/bin/env bash # 单批次初始化建目录、记指纹、起浏览器 set -euo pipefail BATCH${1:-$(date %Y%m%d-%H%M%S)} ROOT$HOME/lab/portable PROFILE$ROOT/profiles/$BATCH LOG$ROOT/logs/$BATCH mkdir -p $PROFILE $LOG # 记录环境指纹出问题时用来判断是不是环境差异 { date -u %Y-%m-%dT%H:%M:%SZ hostname uname -sr echo LANG$LANG } $LOG/env.txt # 记录本轮使用的二进制哈希保证可追溯 sha256sum $ROOT/run-001/bin/chrome $LOG/env.txt echo 批次 $BATCH 初始化完成 echo profile: $PROFILE echo 日志: $LOG${1:-...}的写法让脚本既能接受外部传入的批次号方便和测试记录对齐也能自己生成一个。哈希写进日志这一步看着繁琐但在「这个结论是哪一版跑出来的」这种追问面前它是唯一能拿出证据的东西。进阶一点的用法是把这套东西和连续多轮对比结合起来同一目标跑两次一次带扩展一次不带把两份请求清单做差集差出来的部分就是这个扩展的实际影响范围。# 两轮请求清单做差集定位扩展或配置带来的额外请求 sort run-with-ext.txt a.txt sort run-no-ext.txt b.txt comm -23 a.txt b.txt # 只在带扩展那轮出现的请求comm -23输出的是第一个文件独有的行-12是交集-13是第二个文件独有。前提是两份文件都已排序否则结果没有意义——这个前提漏掉的话输出会是一堆看起来像随机的结果我第一次用的时候就栽在这里对着莫名其妙的差集查了半天扩展代码最后发现是没sort。从那以后我每次开新批次都强制先跑一遍引导脚本、再对着清单勾一遍宁可多花五分钟也不要在结论写完两天后发现是环境没清干净。这套东西不复杂难的是每次都走完。希望帮到你。本文还有配套的精品资源点击获取