pingmeter.com

hashcat 是一个开源（MIT License）的密码恢复工具，支持 Linux、Windows、macOS，可跑在 CPU、GPU、APU 等任何带 OpenCL 运行时的设备上，内置 450+ 种哈希类型。要跑通一次恢复，你需要四样东西：正确的 GPU/CPU 运行时、hashcat 本体、目标哈希的类型编号（hash-mode）、以及候选密码来源（字典或掩码）。下面按这个顺序走一遍。

一、装好运行时和 hashcat

hashcat 本身是单个可执行文件，但计算后端依赖厂商运行时。官网列出的驱动要求：

从官网 Download 区下载对应平台的二进制包（当前版本 v7.1.2，2025.08.23 发布），或从 GitHub 仓库取最新开发版。下载页同时提供 PGP 签名，需要校验完整性时可用签名公钥（Key ID 2048R/8A16544F）验证。

装完先确认设备能被识别：

hashcat -I

预期输出会列出可用的 OpenCL 平台和设备（如 CUDA、HIP、OpenCL 后端及其设备名）。如果这里为空或报错，说明运行时没装对，先解决这一步再往下走。

二、确定 hash-mode

hashcat 用数字编号区分哈希类型，这是最容易出错的一步——模式选错，跑再久也不会有结果。

• 用 hashcat --example-hashes 可以查看各模式的示例哈希和编号。
• 官网 Algorithms 区列出了已实现的算法，包括 MD4、MD5、SHA1、SHA2 系列（224/256/384/512）、SHA3 系列、RIPEMD-160/320、BLAKE2b/BLAKE2s、Whirlpool、Keccak、SM3、GOST 系列，以及大量加盐/嵌套变体，例如 md5($pass.$salt)、md5($salt.$pass)、md5($salt.md5($pass))、sha256(utf16le($pass)) 等。

判断方法：拿一条你知道明文的哈希做对照，或者看哈希的格式特征（长度、是否带盐、盐的位置）。例如 32 位十六进制且无盐通常是 MD5（模式 0），带 $salt$ 前缀的则要选对应的加盐模式。

三、准备候选密码

hashcat 支持两类主要输入：

• 字典攻击（-a 0）：从文件或 stdin 读取候选密码。适合已有泄露字典、词表或自建列表的场景。
• 掩码攻击（-a 3）：用字符集和占位符穷举，例如 ?l?l?l?l?d?d 表示 4 个小写字母加 2 个数字。适合已知密码结构的情况。

此外还支持 hex-salt 和 hex-charset，处理非文本字节时用得上。

四、运行恢复

基本命令结构：

hashcat -m <hash-mode> -a <attack-mode> <hash文件或哈希> <字典或掩码>

例如用字典跑 MD5：

hashcat -m 0 -a 0 hashes.txt wordlist.txt

用掩码跑 6 位小写字母：

hashcat -m 0 -a 3 hashes.txt ?l?l?l?l?l?l

几个实用行为：

• 多哈希 / 多设备：可以一次传入多个哈希，也可以在同系统内同时用多块设备，甚至混合设备类型。
• 会话与恢复：支持 session 和 restore，中断后能接着跑；也支持交互式暂停/恢复。
• 性能调优：自动性能调优和自动 keyspace 排序（markov-chains）默认参与，一般不用手动干预。
• 温度保护：内置 thermal watchdog，GPU 过热时会自动降速。
• 分布式：可通过 overlay 组网做分布式破解。

五、查看结果与继续

破解成功的明文会写入 potfile（默认在 hashcat 目录或 ~/.hashcat/ 下）。查看已恢复的密码：

hashcat -m 0 hashes.txt --show

如果一次没跑完，用 --restore 恢复上次会话，或重新执行同一命令（hashcat 会跳过 potfile 中已破解的条目）。

常见卡点

• -I 看不到设备：运行时没装或版本不匹配，按第一节的表格对照安装。
• 模式选错：跑完无结果但哈希确实来自该算法，多半是 hash-mode 编号不对，用 --example-hashes 核对。
• 字典太小或掩码范围不对：候选空间不覆盖真实密码，换字典或调整掩码字符集。
• 性能异常低：可能落在了 CPU 后端或驱动未正确加载，用 -I 确认实际使用的设备。

hashcat 只应用于你拥有或已获授权测试的哈希；对他人系统使用属于未授权访问。

march-hare.com 提供 CVSNT/CVS 2.x 的客户端与服务器下载，覆盖 Windows、Linux、Mac OS X、HP-UX 等平台。如果你需要为某个操作系统获取对应的 CVS/CVSNT 安装包，可以先在该站点的下载页面按平台和角色（客户端/服务器）筛选。下载前建议先确认目标系统的架构与所需版本号，避免装错包。

能下载到什么

该站点围绕 CVS/CVSNT 提供两类下载内容：

• 服务器端（Server）：用于搭建版本控制服务，供团队通过 CVS 协议访问仓库。
• 客户端（Client）：用于连接已有 CVS/CVSNT 服务器，执行检出、提交、更新等操作。

下载按操作系统分类，站点关键词覆盖 Windows、Linux、Mac OS X、HP-UX，说明这些平台都有对应安装包。

按平台选择对应文件

选择时先确定两件事：你要装的是客户端还是服务器，以及目标机器的操作系统与架构。同一平台下客户端和服务器是分开的文件，不要混用。

下载前的注意事项

• 确认版本号：CVS 2.x 与 CVSNT 的版本线不同，先明确项目需要哪一条版本线，再下载对应文件。
• 确认系统架构：32 位与 64 位安装包不通用，装错会导致无法运行。
• 理解 CVSNT 与传统 CVS 的关系：CVSNT 是在传统 CVS 基础上发展出的实现，在 Windows 环境下支持更完善。如果项目仍在使用传统 CVS 工作流，需要确认所选版本与现有仓库的兼容性。
• 判断是否仍适合当前项目：CVS/CVSNT 属于较早期的版本控制方案，新项目通常有更现代的选择。若维护的是既有 CVS 仓库，继续使用对应客户端/服务器是合理的；若是全新项目，建议先评估替代方案。

下载后如何验证与安装

1. 核对文件完整性：下载完成后，检查文件大小是否与页面标注一致；若站点提供校验值（如 MD5/SHA），用对应工具比对。
2. 确认文件类型：Windows 通常为可执行安装包，Linux/Unix 平台可能是压缩包或包管理格式，按平台惯例解压或安装。
3. 执行安装：运行安装程序或解压到目标目录，按提示完成配置。
4. 验证安装结果：在命令行执行版本查询命令（如 cvs --version 或 CVSNT 对应的版本命令），能正确输出版本信息即表示安装成功。
5. 连接测试：客户端安装后，尝试连接一个已知的 CVS 服务器，确认能正常检出或列出仓库内容。

常见卡点

• 装错角色：把服务器包当客户端装，或反之，导致命令不可用。
• 架构不匹配：在 64 位系统上装了 32 位包（或反之），运行时报错。
• 版本与仓库不兼容：客户端版本与服务器端协议不一致，连接失败。
• 缺少依赖：部分 Unix 平台安装前需要先满足系统依赖，否则安装中断。

如果下载页面未明确标注版本号或架构，建议先查看站点上的版本说明或发布记录，再决定下载哪个文件。

网站 uptime 监控的核心不是“ping 一下看通不通”，而是用多个地点的探测节点反复确认故障、在确认后按预设方式告警，并在条件允许时自动执行恢复动作（如切换 DNS 到备用服务器）。Pingmeter 这类服务的典型流程是：多地点扫描 → 误报过滤 → 延迟告警 → 恢复动作 → 状态页与日志留存。适用条件是：你有一个可被公网访问的网站或服务，并愿意为关键服务准备备用服务器或备用 DNS 解析。

多地点扫描与误报防护：先确认，再告警

单点 ping 失败很常见——本地网络抖动、某个运营商线路问题、探测节点自身异常，都会造成“假宕机”。Pingmeter 的做法是从不同国家的多台服务器同时扫描，并对错误进行二次检查，只有多个地点都确认异常时才判定为宕机。资料中明确写到“False-Alarm Protection：We double check for errors, and we do it from multiple locations”，目的就是排除瞬时网络延迟造成的误报。

扫描频率可以自定义，资料强调“Every Single Minute Counts”，即支持每分钟级别的扫描间隔。间隔越短，发现故障越快，但探测请求也越多；对大多数展示型网站，1 分钟级已经足够，对交易类服务可再评估是否需要更密集的探测。

告警：短信、语音、邮件与延迟策略

确认宕机后，Pingmeter 的告警渠道包括 SMS、语音电话和邮件。资料中的触发条件是：故障从多个地点被确认、持续了指定时间，且恢复动作未能让服务重新上线，才会打电话、发短信或发邮件。

这里的关键设计是“延迟告警”（Delayed Alarm）：在延迟窗口内持续观察服务器是否自行恢复，只有恢复失败才通知你。这适合两类场景：

• 短暂抖动较多的服务，延迟告警可以避免半夜被误报吵醒；
• 已有自动恢复动作的服务，先让恢复动作跑完，失败再叫人。

代价是告警到达时间会推后。如果业务对分钟级中断极其敏感，应把延迟窗口设短，而不是完全关闭确认机制。

自动恢复：DNS 故障转移与服务器恢复

Pingmeter 的恢复动作主要有两类：

1. DNS 故障转移：通过集成 Cloudflare 等 Nameserver 提供商的 API，在主服务器宕机时自动把域名 DNS 指向备用服务器，主服务器恢复后再切回。这要求你提前准备好备用服务器，并在 DNS 服务商侧配置好可被 API 调用的权限。
2. 服务器恢复：对 Web 服务器或数据库服务器执行恢复动作，例如重启服务。

安全限制值得注意：资料明确说明，出于安全考虑，Pingmeter 不提供基于密码的 SSH 登录恢复动作，而是使用密钥登录，并为每个恢复动作生成不同的密钥。这意味着你不能指望它用账号密码帮你登录服务器操作；需要恢复的机器必须提前配置好密钥授权。

状态页与维护模式：对外透明，对内少打扰

• 状态页（Status pages）：可以生成公开状态页，向访客展示网站或服务的 uptime 与 downtime，挂在你自己拥有的子域名下，并支持密码保护。适合对外承诺 SLA 的团队，或需要减少客服重复询问的场景。
• 维护模式（Maintenance Mode）：提前设定计划维护时间，在此期间不触发恢复动作、不发送告警电话。这是避免“计划内停机被当成故障”的必要配置，上线前就应把例行维护窗口填进去。

性能图表与日志：回看宕机、ping 时间与失败地点

Pingmeter 会保留扫描日志和性能图表，你可以回看每次宕机的记录、ping 时间以及哪些地点的探测失败。资料称可以收到从开始使用服务那天起的逐分钟报告。这对事后复盘很有用：例如需要判断某次故障是单地区网络问题还是全局服务问题，失败地点分布就是直接证据。

选择这类服务时该核对什么

如果只需要“挂了通知我”，基础的多地点检测加邮件/短信告警就够了；如果希望减少人工介入，则应重点评估 DNS 故障转移和密钥式恢复动作是否与你的现有架构匹配。Pingmeter 的定价与登录限制在现有资料中未提及，注册前需自行在官网确认。

ping 通过向目标主机发送 ICMP 回显请求（Echo Request），等待对方返回回显应答（Echo Reply），从而测量数据包往返时间（RTT，即延迟）并统计丢包率。它适合快速判断“这台机器到目标 IP 是否可达、链路质量如何”，但不能证明网站服务正常——ping 通只说明主机网络层可达，HTTP 服务可能仍然挂掉。适用条件：你有命令行环境（Windows、macOS、Linux 均可），且目标主机或中间防火墙没有屏蔽 ICMP。

基本原理：一次 ping 发生了什么

1. 本机向目标 IP 发出一个 ICMP Echo Request，携带序号和时间戳。
2. 目标主机（或网关）收到后回一个 Echo Reply。
3. 本机用收到应答的时间减去发出时间，得到往返延迟；序号缺失则计为丢包。
4. 应答中的 TTL 值每经过一个路由跳减 1，可粗略推断经过的跳数。

因此 ping 结果里的 time 是往返时间，TTL 反映路径长度，丢包率反映链路稳定性。

各平台常用命令

示例（Linux/macOS 发 10 个包）：

ping -c 10 example.com

预期输出末尾会给出统计：10 packets transmitted, 10 received, 0% packet loss，以及 min/avg/max/mdev 的延迟分布。Windows 则显示“已发送 = 10，已接收 = 10，丢失 = 0 (0% 丢失)”和“最短/最长/平均”往返时间。

如何解读结果

• 延迟（time/平均往返时间）：局域网通常 <1 ms；同城公网几毫秒到十几毫秒；跨洲几十到两百毫秒以上都属正常范围。数值稳定比绝对大小更重要。
• 丢包率：0% 为理想；偶发 1%–2% 可能只是瞬时拥塞；持续丢包说明链路或目标有问题。
• 延迟抖动（mdev/标准差）：抖动大意味着网络不稳定，语音、视频类应用会明显受影响。
• TTL：可辅助判断是否经过多层路由，但不同系统初始 TTL 不同（常见 64、128、255），只能粗略参考。
• 请求超时（Request timed out）：可能是丢包、目标屏蔽 ICMP，或路径中断，需结合后续排查。

ping 不通时的排查顺序

按“由近到远”逐层排除，每步都有明确预期结果：

1. 本机回环：ping 127.0.0.1。不通说明本机 TCP/IP 协议栈异常。
2. 本机 IP：ping 本机局域网 IP。不通说明网卡或驱动问题。
3. 网关：ping 默认网关（用 ipconfig/ip route 查）。不通说明本地网络或网线/Wi-Fi 问题。
4. 公网 IP：ping 8.8.8.8 或 ping 1.1.1.1。不通说明出口网络或运营商链路问题。
5. 域名解析：ping example.com 若提示“找不到主机”，先用 nslookup example.com 或 dig example.com 检查 DNS；能解析出 IP 但 ping 不通，再回到第 4 步判断是链路还是目标屏蔽。
6. 目标屏蔽 ICMP：很多服务器和云防火墙默认丢弃 ICMP。此时 ping 不通不代表服务不可用，改用 curl -I https://example.com 或 telnet example.com 443 验证端口与服务。

常见卡点：公司网络或云安全组屏蔽 ICMP 导致“假不通”；目标只禁 ping 但 Web 正常；本地开了代理/VPN 使路径变化，结果与直连不同。

ping 与网站可用性监控的区别

ping 检测的是主机网络层可达性，而网站可用性监控检测的是应用层服务是否正常响应。两者互补：

• ping 通、但 HTTP 返回 502 或超时——主机活着，Web 服务挂了。这时需要的是 HTTP 探测，而不是 ping。
• 主机被防火墙禁 ICMP、但网站正常——ping 不通，服务却可用。

Pingmeter 这类监控服务的做法可以说明这一区别：它从多个国家、多个地点的服务器每分钟对网站发起扫描，先做误报防护（从多个位置复核错误，排除瞬时网络抖动），确认宕机后还有延迟告警窗口，在窗口内持续观察是否自行恢复，只有问题持续才通过短信、语音电话或邮件通知。它还能在宕机时执行恢复动作，例如通过 Cloudflare 等 DNS 服务商 API 把域名自动切到备用服务器（DNS Failover），并支持维护模式避免计划内维护触发告警。这些能力都建立在“服务层探测 + 多位置复核 + 恢复动作”之上，是单纯 ping 命令做不到的。

所以实践中的分工是：用 ping 做本机到目标的快速连通性与延迟初判；用 HTTP/端口探测或专业监控服务判断网站是否真正可用，并在宕机时获得告警与自动恢复。

快速上手清单

• 想测延迟和丢包：ping -c 20 目标（Windows 用 ping -n 20 目标），看平均延迟与丢包率。
• ping 不通先按“回环 → 本机 IP → 网关 → 公网 IP → DNS → 目标端口”顺序排查。
• 判断网站是否可用，别只看 ping，用 curl -I 或监控服务验证 HTTP 响应。
• 需要 7×24 告警和自动切换，考虑带多位置扫描、误报防护、延迟告警和 DNS Failover 的监控服务。

uptime 指网站或服务在指定时间段内可正常访问的时间，通常用百分比表示；与之相对的 downtime 是不可访问时间。网站 uptime 监控的核心做法是：从多个地点按设定间隔扫描目标，确认故障后发出告警，并在配置允许时执行恢复动作。Pingmeter 的资料显示，其监控覆盖多地点扫描、误报防护、延迟告警、短信/电话/邮件通知、DNS 故障转移和服务器恢复等环节。适用前提是：你拥有可被外部访问的网站或服务器，并能提供相应的恢复凭据或 DNS 服务商 API 权限。

uptime 与 downtime 怎么衡量

uptime 关注的是“服务是否可用”，而不是“服务是否快”。常见衡量方式是把统计周期内的可用时间除以总时间，得到可用率。例如一个月内累计不可用 43 分钟，按 30 天计算，可用率约为 99.9%。这个数字的意义取决于监控频率：扫描间隔越粗，越可能漏掉短时故障。

Pingmeter 的资料强调“每一分钟都重要”，支持从多个地点同时扫描，并允许自定义扫描间隔。对读者来说，选择监控服务时应先确认两件事：扫描间隔是否满足你的故障容忍度，以及是否支持多地点，避免单一网络线路的偶发问题被误判为宕机。

多地点扫描与误报防护如何判断宕机

监控系统判断宕机不能只看一次请求失败。Pingmeter 的描述是：从多个地点双重检查错误，确认 downtime 不是瞬时网络抖动造成的；同时支持延迟告警，在延迟期间持续观察服务器是否自行恢复，只有未恢复才通知你。

这套机制解决的是两类误报：

• 单点网络波动：某个扫描节点到目标服务器的线路抖动，其他地点仍可访问，不应判定为全站宕机。
• 短暂重启或瞬时错误：服务器在几十秒内恢复，延迟告警可以避免半夜被无效电话叫醒。

配置时的关键输入是“确认故障所需的地点数量”和“延迟告警时长”。预期结果是：只有多地点持续失败且超过延迟窗口，才触发通知。常见卡点是延迟设得过长，真实故障的通知被推迟；设得过短，又容易收到误报。建议按业务对停机时间的容忍度来定。

宕机确认后如何告警

Pingmeter 资料列出的通知渠道包括短信、语音电话和邮件。触发条件是：多地点确认 downtime 持续指定时间，且恢复动作未能让服务重新上线。资料还提到“在线检测器”：宕机发生时检测网站上的在线访客数量，并在通知中告知访客数，帮助判断影响范围。

此外，维护模式允许你预设计划维护时间，在此期间不触发恢复动作和电话通知。这对有固定发布窗口的团队很实用：把已知的维护时段录入，避免把计划内停机当成故障处理。

自动恢复动作适用于哪些场景

Pingmeter 提供两类恢复动作：

选择时看两点：如果故障多为进程挂死或服务未启动，服务器恢复动作更直接；如果是整台主机或机房不可用，DNS 故障转移更合适。两者都需要提前配置，不能等宕机后再补。

公开状态页与记录回看的作用

Pingmeter 支持在自有子域名下生成公开状态页，展示网站或服务的 uptime 与 downtime，并可设置密码保护。状态页适合对外沟通：用户能看到已知故障，减少重复询问。记录回看方面，资料称会保留扫描日志，可查看历史 downtime、ping 时间和失败地点，并从启用服务之日起获得逐分钟报告。

使用建议：状态页对外发布前，确认展示范围不泄露内部服务细节；日志回看则用于事后复盘，例如对比故障时段的失败地点分布，判断是局部线路问题还是全局故障。

上手检查清单

要落地一套 uptime 监控，按以下顺序确认：

1. 明确目标：监控首页、关键 API 还是数据库端口，不同目标对应不同扫描方式。
2. 设定扫描间隔与地点：按故障容忍度选择，间隔越短越能发现短时故障，但扫描量也越大。
3. 配置误报防护：设置多地点确认和延迟告警时长，先观察一段时间再收紧。
4. 填写通知渠道：短信、电话、邮件至少保留一种可靠渠道，并确认接收人。
5. 准备恢复动作：需要自动恢复时，提前配置密钥登录或 DNS 服务商 API，并测试备用服务器可用性。
6. 设置维护模式：把计划维护窗口录入，避免误告警。
7. 验证：人为制造一次可控的短时不可用，确认告警是否按预期触发、恢复动作是否执行。

常见卡点集中在恢复动作的凭据配置和 DNS 切换后的回切流程；这两项建议在正式依赖前单独演练一次。