Python 3 "Violent Python" 源代码

TJ O'Connor 所著《Violent Python》一书的源代码。代码已全面转换为 Python 3，按照 PEP8 标准重新格式化，并进行了重构，以消除因使用已弃用库而导致的依赖问题。

本人也进行了类似的转换，将 Justin Seitz 所著《Black Hat Python》的源代码转换成了 Python 3。如果你还没看过，可以点击这里查看。

使用方法

只需为项目创建一个新目录（DIR），为其创建一个新的虚拟环境或 venv（推荐），使用 git clone 克隆此仓库，然后使用 pip install 安装依赖。

user@host:~/DIR$ git clone https://github.com/EONRaider/violent-python3
user@host:~/DIR$ python3 -m venv venv
user@host:~/DIR$ source venv/bin/activate
(venv) user@host:~/DIR$ pip install -r requirements.txt

注意

• 文件和目录的命名方式便于与每章所呈现的内容相关联。
• 作者频繁使用的字符串拼接已被替换为字符串插值，以提高可读性并符合更现代的标准。
• 文件、变量、函数、类和方法的名字现在符合 PEP 8 命名标准。
• 整个源代码中，已弃用的 optparse 库已被替换为 argparse。所有参数解析现在都包含在每个文件的 __main__ 执行范围内。原代码中脚本执行所必需但被视为可选的 CLI 参数，现已实现为位置参数。现在所有使用 argparse 的脚本都可以通过向 CLI 提供 -h 参数来获取用法提示。将边界和控制器对象的职责都交给 CLI 解析器在软件架构上肯定不是最佳选择，但为了与原作者的意图保持一致，仍保留了原样。
• 所有违反 PEP 8: E722 不要使用裸 except 的情况都已重构，使用了更具体的异常子句。
• 作者有一个习惯，即打开文件/数据库后保持其打开状态，而不调用文件/数据库对象的 close() 方法。因此，所有涉及文件和数据库操作的地方已使用上下文管理器进行重构。
• 由于 UTF-8 已成为 Python 3 的默认编码（取代了 Python 2 的 ASCII），因此去除了所有关于解释器使用编码的注释（即 # -*- coding: utf-8 -*-）。
• 尽管从最佳实践的角度来看完全不当，但为了不产生与原始代码逻辑的重大偏离，全局变量的使用保持不变。
• 本书第 5 章中的代码已经过重构，尽管实际上它充其量只能算是历史遗迹。其大部分功能不仅依赖于作者作为示例列出的非常特定场景，还依赖于过去几年已不再现实的漏洞利用（例如嗅探仍依赖 WEP 安全算法加密流量，或者更糟糕的是根本不保持任何安全的 802.11 无线网络的流量），或者要求读者获取特定无人机型号的荒谬期望（如果他想看到代码运行的话）。为了避免直接说阅读这一章的努力几乎毫无意义，我可能会补充说，与嗅探探测请求和信标请求相关的代码仍然有一些用处。
• 第 6 章中涉及 Google 和 Twitter 的代码在它们当前处理 API 的方式上已经过时，不值得费心重构。如果你有兴趣处理它们，请进行重构并向此仓库提交拉取请求。

重构

未在下面列出的文件可以认为已经按照“注意”部分的规定以某种方式进行了重构。

• chapter01/vuln_scanner.py 的结构导致不存在的文件会在运行时引发 OSError 异常。因此，调用 check_vulns() 的迭代控制已被移入在 main 函数中定义的条件语句中。
• chapter02/nmap_scan.py 实现了一个 main 函数，其唯一目的是调用已弃用的 optparse 库，该库已被 argparse 替换。因此，main 函数已被移除。原始代码中作为 optparse 调用一部分的迭代控制结构实现方式导致每次扫描一个端口时都会执行一次新的 nmap 调用。该迭代已被移入 nmap_scan 函数，以避免浪费周期。
• chapter02/ssh_command.py 的初始化代码已被移入 __main__ 执行范围。外作用域中与函数参数名冲突的变量名已被更改。原本编码的返回提示信息现在已被解码，以提高可读性。
• chapter02/ssh_brute.py 将 pxssh 作为独立库导入，但实际上它是 pexpect 库下的一个库。这个错误导致 ModuleNotFoundError 异常，现已修正。书中呈现的代码本身充满了缩进错误，使其无法使用，现已修复为可运行状态。

翻译

其他语言的贡献可以在这里查看：

• 由 Bedirhan Budak 翻译为土耳其语

贡献

根据常识，首先尝试通过 issue 讨论你希望对此仓库进行的更改。

1. 确保你想要引入的修改确实能产生一个拉取请求。一两个行的更改应通过 issue 提出。
2. 如有必要，更新 README.md 文件，包含与项目结构更改相关的详细信息。
3. 确保包含修改的提交信息遵循标准。如果你不知道如何操作，这里是一个很好的参考。
4. 你的请求将尽快得到审查（通常会在 48 小时内）。