共计 4576 个字符，预计需要花费 12 分钟才能阅读完成。
应用 Java 代理和 Byte Buddy 为 JVM 构建调试工具。
Java 和 JVM 通常更宽泛地用于所有中央的服务，然而通常很难调试和手动测试，尤其是在简单的微服务体系结构中。
HTTP 申请和响应是这些服务之间以及与它们的内部 API 进行交互的外围，然而它们通常也是不可见和不可拜访的。在手动测试和原型制作过程中，很难查看所有收回的申请，在运行中的零碎中模仿异样响应和谬误，或者模仿依赖关系。
在过来的几周中，我建设了一个 Java 代理，能够齐全主动地做到这一点。它能够在启动或稍后附加时抓住任何 JVM 中所有 HTTP 和 HTTPS 申请的控制权，以将它们重定向到代理，并信赖该代理解密所有 HTTPS，从而容许所有 JVM 流量的 MitM。零代码更改或须要手动配置。
这意味着您能够抉择任何 JVM 过程 - 您本人的本地运行的服务，Gradle，Intellij，以及您喜爱的任何货色 - 并在 2 秒钟内查看，断点和模仿其所有 HTTP（S）申请。
在这篇文章中，我要带你通过这怎么可能，这样你就能够理解一些 JVM 的机密力量的细节，学习如何将原始字节码为本人，并建设在对例子和源代码，这背地构建本人的调试和检测工具。
如果您只是想立刻尝试，请下载 HTTP Toolkit。
如果您想晓得这在事实中是如何实现的，以及如何编写能做到这一点的代码，请持续浏览：
这里产生了什么？
在某些方面，拦挡所有 HTTP（S）应该很容易：JVM 具备规范的 HTTP 代理和 SSL 上下文配置设置（例如 -Dhttp.proxy 和 -Djavax.net.ssl.trustStore），因而您能够尝试通过在启动时设置这些选项从内部进行配置。
可怜的是，这是行不通的。大多数古代库默认状况下都会疏忽这些设置，而是抉择提供本人的默认值和配置界面。即便该库没有，许多应用程序也会显式定义本人的连贯和 TLS 配置。通常，这通常很不便且理智，然而在当前要开始调试和手动测试 HTTP 交互时十分不便。
无需在启动时设置没人应用的配置值，咱们能够应用 Java 代理强制捕捉 HTTP。Java 代理容许咱们从内部连贯到 JVM 过程，运行咱们本人的代码并重写现有的字节码。
当咱们的代理连贯到 JVM 时（无论是在启动之前加载所有内容，还是在当前加载），咱们都会与内置软件包中应用的特定类和一长串风行的内部库进行匹配，以查找从 TLS 配置状态到连接池的所有内容逻辑，并且咱们在整个过程中进行了一些小的更改。这使咱们能够更改默认值，疏忽自定义设置，从新创立现有连贯以及重新配置要由咱们的 HTTPS 拦挡代理拦挡的所有 HTTP（S）。
这真是太酷了！从 JVM 过程内部，咱们能够应用它牢靠地重写任意字节码，以更改代码库中所有 HTTP 的工作形式，并本人管制整个事件。它是针对类固醇的面向方面的编程，并且非常容易实现。
让咱们来谈谈细节。
什么是 Java 代理？
Java 代理是一种非凡类型的 JAR 文件，能够附加到其余 JVM 过程，并且 JVM 赋予它额定的势力来转换和检测字节码。
它们已被 JVM 工具宽泛应用，从应用 New Relic 进行应用程序监督到应用 PiTest 进行渐变测试，包罗万象。
只管有名称，但它们并非仅 Java。它们实用于在 JVM 上运行的任何货色。
有两种应用 Java 代理的办法。您能够在启动时将其附加，如下所示：
或者您能够稍后动静附加它，如下所示：
代理能够在其 JAR 清单中具备两个独自的入口点来治理此入口点：一个用于启动时的附件，另一个用于当前的附件。还有一些 JAR 清单属性能够抉择转换字节码。为 gradle 构建的 JAR 进行配置如下所示：
最初，您有一个实现这些办法的代理类。像这样：
这测试类咱们在这里给咱们提供了像 addTransformer 和 redefineClasses 办法，咱们能够用它来读取并笼罩在虚拟机的任何类别的原始字节码。
HTTP Toolkit 包含从以上所有内容构建的代理 JAR，该代理 JAR 容许它附加到任何 JVM 应用程序，在该应用程序内运行代码（在可能的状况下应用惯例 API 设置默认值和配置值）以及转换和挂钩所有 HTTP 的内部结构相干的类，咱们关怀。
然而，代理程序的设置只是第一步：这使咱们简直能够齐全扭转指标应用程序正在执行的操作，然而确定如何转换类很简单，转换存在一些限度，并且不解决原始字节码简略…
您如何转换原始字节码？
简而言之：应用 Byte Buddy。
这是一个简单的库，能够应用字节码执行许多弱小的性能，包含在运行时动静生成子类和接口实现（例如，对于模仿框架），手动更改类和办法以及通过模板主动转换字节码。
在代理工具（例如 HTTP Toolkit）的状况下，咱们对模板办法感兴趣，因为 Java 代理有一个局限性：从新加载曾经加载的类时，新定义必须与雷同的类模式匹配。这意味着咱们能够将新逻辑增加到现有办法主体中，然而不能在现有类上创立新办法或字段，也不能更改现有办法签名。
为了解决这个问题，Byte Buddy 的内置“倡议”零碎定义了办法转换模板，它能够利用于咱们，同时确保该模式永远不会以任何其余形式更改。
首先，咱们须要设置 Byte Buddy。此配置仿佛很好地工作：
而后，咱们定义一个 Advice 类，它将转换咱们的指标。征询类如下所示：
这示意“在指标办法主体的开端，插入额定的逻辑，该逻辑将返回值替换为[咱们的代理值]”。
此处的代码无效地注入到办法主体的开端（因为 Advice.OnMethodExit），并且能够在办法参数（例如 @ Advice.Return）上应用正文，以将该模板办法中的变量链接到办法参数，字段值，“this”，或在现有办法主体中返回值。
要将这些联合在一起，咱们必须通知 Byte Buddy 何时利用此倡议，如下所示：
Byte Buddy 应用此流畅的 API 来构建从类型匹配器（如此处的“命名”）到类型转换器的映射，而后构建将特定倡议模板利用于与某些模式匹配的办法的转换（例如 hasMethodName（“getProxy”））。
下面的代码实际上是咱们用来拦挡 OkHttp 的理论实现逻辑：对于所有 OkHttpClient 实例，即便是在附加时已实例化的实例，咱们也会笼罩 getProxy（），因而无论其先前的配置如何，它始终返回咱们的代理配置。这样能够确保来自所有 OkHttp 客户端的所有新连贯都转到咱们的代理。
不过，这只是一个简略状况的一部分（残缺的 OkHttp 逻辑在此处），并且对所有 HTTP 进行的操作要简单得多……
哪些转换容许您捕捉所有 HTTPS？
通过以上内容，咱们能够构建能够附加到 JVM 指标的 Java 代理，并轻松地任意转换方法主体。
有用的拦挡 HTTP（S）依然须要咱们找到咱们关怀的办法主体，并钻研如何对其进行转换。
实际上，要转换任何指标库以拦挡 HTTPS，须要执行三个步骤：
重定向新连贯以通过 HTTP Toolkit 代理服务器
在 HTTPS 连贯设置期间信赖 HTTP Toolkit 证书
附加到已运行的应用程序时，应用任何关上的非代理连贯重置 / 进行
我不会针对每个受反对的库的每个版本进行具体的实现（如果您有趣味，请随时浏览残缺的源代码），但让咱们来看几个说明性示例。
其中一些逻辑是用 Kotlin 编写的，并且在下面应用了一些帮忙程序，然而，如果您已浏览以上内容，并且理解 Java，则将取得要点：
拦挡 Apache HttpClient：
Apache HttpClient 是其 HttpComponents 我的项目的一部分，该我的项目是古老的 Commons HttpClient 库的继承者。
它以各种各样的模式存在了很长时间，曾经被宽泛应用，侥幸的是，它很容易被拦挡。
例如，对于 v5，所有传出流量都通过 HttpRoutePlanner 接口的实现来运行，该接口决定应将申请发送到何处。
咱们只须要更改该接口的所有实现的返回值即可：
仅此一项，咱们就将所有流量重定向到其余中央。
同时，重置所有 SSL 连贯须要先创立 SSL 套接字能力更改 SSL 配置。
令人高兴的是，下面的“HttpRoutePlanner”办法甚至不须要重置连贯：申请路由不再与现有的关上连贯匹配，因而申请立刻停止使用这些连贯，而开始应用咱们的代理，而现有连贯则有害暂停。
拦挡 Java 的内置 ProxySelector：
让咱们尝试一些更艰难的事件：咱们能够重写内置的 Java 类吗？咱们能够。
当咱们的代理首次附加时，它将应用一般的公共 API 更改默认的 ProxySelector，以便应用 Java 的默认代理选择器的任何代码主动应用咱们的代理，而无需进行任何转换。
然而，可怜的是，某些应用程序手动治理代理选择器，这可能导致 HTTP 无奈被拦挡。
为了解决这个问题，咱们在代理设置过程中应用一般的 ProxySelector.setDefault（）API 设置了代理选择器，而后咱们转换了内置类以齐全禁用该设置器，因而其他人都无奈更改它。
看起来像这样：
转换内置类的确有一些正告，例如，您须要在设置 Byte Buddy 的过程中设置.ignore（none（）（请参见下面的示例），并且您不能在倡议中援用任何非内置类型对于这样的简略更改，这不是什么大问题。
拦挡 Spring WebClient HTTP：
好的，最初一个例子，让咱们看一个更简单的状况。Spring 的 WebClient 如何工作？
Spring WebClient 是一个绝对较新的客户端 - 它是作为 Spring 5 的一部分公布的一个响应式客户端，默认状况下在 Reactor-Netty 的顶部提供了 Spring 集成的 API（但也能够配置为应用其余引擎）。
我狐疑绝大多数用户都应用默认的 Reactor-Netty 引擎，如果不应用默认引擎，那么他们将应用曾经被咱们的另一种配置拦挡的引擎。这意味着咱们只须要拦挡 Reactor-Netty，咱们将捕捉所有筹备调试的 Spring WebClient 通信。
十分有帮忙的是，Reactor Netty 将咱们关怀的所有状态（代理和 SSL 上下文）都存储在一个地位：HttpClientConfig 类。咱们须要以某种形式为所有实例重置该外部状态，然而在公共 API 中并没有不便地公开它。
然而，更有用的是，在每个申请期间克隆了他们的 HttpClient 类，将配置传递给申请的客户端，这为咱们提供了一个完满的钩子，能够在每次申请之前获取并批改配置。
看起来像这样：
好的，尽管我齐全冀望，只管浏览本文的人中有一半可能会着迷，但另一半会感到恐惧。
在这里，咱们深深地陷入了图书馆外部的深渊，并且毫不 pent 悔。
这的确有一些正告：库更改很可能会毁坏这一点，或者某些转换可能会导致副作用。我不建议您在生产中进行此操作，而无需进行更认真的转换和测试，然而对于本地开发和测试而言，危险很低，这就像一个魅力。
在实践中，我狐疑脆弱性问题会很小。咱们正在转换的代码是连贯设置的低级外部，它很少更改。这里对各种指标的回购示意不满，这表明在大多数状况下，此逻辑自 v1 以来简直没有扭转，或者每 5 年左右仅稍微扭转一次，并且在有变动时更新此逻辑并不是一项艰巨的工作。此外，只管新的库也将问世，但它们中的大多数库都是在这些现有引擎的根底上构建的，因而咱们能够收费为它们提供反对！
参考：《2020 最新 Java 根底精讲视频教程和学习路线！》
原文链接：https://blog.csdn.net/weixin_…
