有的人可能会有些疑问，这个好像跟逆向没啥关系，其实不是的。逆向工程的本身就是在不能轻易获得必要的生产信息的情况下对成品进行分析，然后推导出设计原理的过程。把成品看成一个黑盒，那么这个黑盒中对外开放的接口就显得尤为重要了。
所以在拿到一个新的app之后，第一件事不是忙着去编译反编译巴拉巴拉折腾一堆。而是对这个黑盒的接口做测试。
这里介绍一些我曾经用到过的抓包工具。
1、wireshark。（这个除了http，看得到更多的协议）
2、fidder（http）
3、burpsuite（http）
这里的这3个工具是我比较常用的。这里介绍下他们的使用方法。
对于wireshark，如果我们要使用它对手机端app进行抓包分析，需要先在pc端安装一个无线网卡，又或者是360免费wifi之类的软件。总之就是让你的pc释放出一个可以让android手机连上的热点，让android机的流量经过pc，才能对流量进行分析。wireshark因为可以抓取除了http之外的协议类型，所以使用的范围可以更加广一点。
另外有点需要介绍的是wireshark对网络封包的抓取是旁路的，其本质就是wireshark使用的是对网卡数据的复制，所有经过网卡的流量都会被抓取。这样一来就不限制是应用层面上的数据包了，而是可以抓取到更多更全面的包。但是因为是旁路，所以无法去修改这些数据包。简单的可以理解为它只是将流量copy出来一份，供你查看而已。
如果要做一些比较猥琐的事情。。。比如修改request和resopnse，就要用到2、3工具了。当然前提是针对应用层面上的协议。比如说这里的http、https、websocket等。有的人可能会觉得到这里，味道就有些变了。确实是这样，如果你修改了应用的request或者response值。我们其实就可以视为你已经发动了一次中间人攻击。将我们的代理工具视应用的web 后台和app之间中间人，在双方都不知道的情况下我们修改了一次他们之间的通信，这种对request或者response包的重构，可能是我们精心设计的，以为了达到某些目的。可能是或者某些数据或者验证某些想法。话题有点跑远了，我们回到HTTP抓包上。。
下面是HTTP协议抓包介绍：
对于fidder，burpsuite等http流量，可以通过代理的方法进行抓取。
有的人可能对HTTP代理不太理解。这里简单介绍些HTTP代理的运作。
上述的代理工具，burp，fidder这些工具其实本质上就是一个HTTP代理服务器。在不同的系统代理的设置有不同的方法。一些应用比如浏览器，有自己的代理选项，找到高级设置页面去设置即可，但是这样设置的代理可能只在浏览器中生效。如果是windows系统，可以在IE浏览器中设置代理(这里设置的就是全局的代理了)。如果是android手机，可以在wifi设置的高级选项中设置代理。当我们在系统中设置了代理，这时候运行在我们系统中的http客户端在发送请求的时候，就不会按照正常的流程去进行dns解析，而是直接去连接我们的代理服务器（比如这里就是我们的burp和开放的代理端口，无论是http还是https亦或是其他支持的代理协议，全部都是连上这一个端口）。然后代理服务器接收到来自http客户端的请求后再去连接真正的服务器。所以，我们经常是将代理看做是一个中间人，实际上也确实是这样。
下面简单介绍下代理的设置方法。
具体就是让android手机和pc 处于同一个局域网。然后在android机上设置代理（一般在在wifi设置里面，点卡连接的wifi，然后点开高级设置，一般就可以看到）。设置代理的IP为PC 的IP，端口为任意没占用的端口就行。比如，android机和你的pc都连上一个热点名称叫test的wifi，然后查看pc的IP 为192.168.1.100，就需要在android机上设置代理的ip为192.168.1.100，端口任意，我一般是设为8080,80xx之类的，只要不被占用就行。
接下来需要打开fidder或者burp等代理软件，这里以burp为例，
点开proxy选项，选择options。这里可以点击add或者edit都行。
然后选择你要监听的ip和输入监听的端口，就是在android机上设置的那个ip和端口。这样一来，android机的http流量就会经过burp，打开http history 选项卡，在列表中就可以看到我们截取的http流量
对于fidder，使用方法也是类似的，无非是找到设置代理的地方，然后将代理的ip 和端口填进去，然后开始监听而已。
我们上面有提到过，burp还可以对http进行修改。我们可以很容易找到有intercept选项，这里是拦截到的数据包，我们可以在option里面设置需要拦截的数据包，然后进行一定的修改后再response。当然拦截request也是可以的。这里做request和response修改是为了更好的测试对应的接口，找到我们关注的信息。
具体的拦截规则这里不介绍，只是提醒有这样一个功能而已。关于burp，其实能做的事情还有很多，有更多更有意思的功能，有兴趣可以私下交流。
上面是对于HTTP的截取，但是大多数情况下，http的截取已经帮不上很大的忙了。因为大多数app开发者也认识到了http是明文的，容易被利用，所以将http升级到了更加安全的https。
下面是HTTPS协议抓包介绍：
如果想回头先了解下https 的可以看
相比于传统的HTTP抓包，HTTPS的抓包需要在设置代理之后加上一步证书的验证。
在进行https中间人攻击中，攻击机以自己的证书替代服务器发给客户端的证书。通常，客户端不会验证该证书，直接接受该证书，从而建立起和攻击机的安全连接。这样，客户端发送的数据，都会被攻击机获取和解密。
注意上面说的是通常，但是也有不通常的。而且大多说网站和app也正在向这种不通常转变。
首先是证书绑定(Certificate pinning)
证书锁定Certificate Pinning是SSL/TLS加密的额外保证手段。它会将服务器的证书公钥预先保存在客户端。在建立安全连接的过程中，客户端会将预置的公钥和接受的证书做比较。如果一致，就建立连接，否则就拒绝连接。
Certificate Pinning在手机软件中应用较多。因为这些应用连接的服务器相对固定，可以预先将服务器的X509证书或者公钥保存在App中。例如，苹果应用商店Apple App Store就预置了这个功能。当使用中间人工具或者Fiddler之类的工具拦截数据，就会造成应用商店无法联网的情况。
https代理抓包原理
简单来讲，就是burp充当客户端与服务端通信，得到服务端的响应之后用自己的证书充当服务端与app通信。如果app不对证书进行验证，或应用使用系统的ca信任库进行验证，而系统又安装了burp的证书，burp就可以完成中间人的角色。所以我们的破解需要研究这个证书认证的过程，如果认证过程不完善，那我们就可以使用相应的手段进行破解。
我们首先来一个假的 https 的认证，比如我们在app开发过程中，认证逻辑中这么写：
static SSLSocketFactory trustAllSocketFactory() throws Exception{
TrustManager[] trustAllCerts = new TrustManager[]{
new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return null;
}
public void checkClientTrusted(X509Certificate[] certs, String authType) {
}
public void checkServerTrusted(X509Certificate[] certs, String authType) {
}
}
};
SSLContext sslCxt = SSLContext.getInstance("TLSv1.2");
sslCxt.init(null, trustAllCerts, null);
return sslCxt.getSocketFactory();
}
那么恭喜你，你的https形同虚设。因为这样是接受所有证书(不对证书做验证)，此时直接通过代理就可以抓包。像这代码一般都是放在爬虫里抓数据的。那么根本就不能算是用上了https。。
接下来，开发者要进阶了。比如做了一些简单的校验。。。
这时候我们的HTTPS绕过游戏才算真正开始：
防线1：使用系统CA库认证
针对信任系统自带CA库情况。有的开发者会信任系统自带的CA库证书，所以我们方法很简单，将中间人证书放到系统库中就行，自动会信任的。
比如安卓浏览器，Mac下的Chrome浏览器都是使用系统的信任证书做验证。另外像下面这类代码请求https，应用也是通过系统信任证书做验证。
URL url = new URL(“https://www.baidu.com/“);
HttpsURLConnection urlConnection = (HttpsURLConnection) url.openConnection();
urlConnection.connect();
System.out.println(urlConnection.getResponseCode());
对于这种情况，将burp suite等工具的CA证书安装到系统中就可破解。如下是安卓上安装burp证书的过程。
1、导出burp ca证书
当然除了这种方法导出证书之外，还有另一种方法，就是在浏览器中直接访问监听端口，比如设置了127.0.0.1:8080 作为代理端口，则就直接在浏览器访问127.0.0.1：8080，这时候会弹出一个页面
，下载后将证书保存到本地就行。
2、直接将证书上传到手机，点击安装就可以，有的可能到设置里面去找
这里再顺便说说pc 的吧。
PC上的firefox浏览器维护着一套受信凭据，点击 首选项->高级->证书->查看证书，在证书机构中导入就可以了，如下图
点击查看证书，然后选择服务器的选项卡，导入
导入刚才的cacert.der文件，那么在服务器中就会存在“PortSwigger CA”这样的证书（burp的内置证书）
另外，我们还可以通过浏览器对我们证书的格式进行转化，比如，这里导出证书，我们会得到一个PortSwiggerCA.crt 格式的证书，保存到本地
3、最后信任证书
我们将刚刚导出的PortSwiggerCA.crt 导入到证书机构中，并勾选信任此CA标识的网站
完成之后，就可能正常访问https 网站并通过burp抓取数据包了。这里我说的是可能，因为https 的绕过通常还没有这么简单。请耐心看下去吧。
这里多提一下，burp suite出于安全考虑，每次安装都会重新生成一套CA证书，所以如果重新安装了burp，要记得将系统中的CA证书更新。
前面提到了，将burp证书导入到android系统中并且设置信任就可以解决这个问题。显然现在很多的android app 开发者也意识到了，系统信任的证书就就不一定是安全证书，而且很有可能是系统遭遇攻击，恶意导入的中间人证书。
聪明的开发者从来就没觉得这招很棘手，因为让这一招失效的方法也很简单，就是不相信系统信任的证书，这个在app中可以设置。设置的方法这里就不提了，反正也就是几行代码。那么不相信系统证书，就只能相信自己自带的证书了。这种情况app 中肯定会自带server端的公钥证书，而且一般都在assert目录中，老鸟可能会对证书加密，不好找。但是大致方向就是这样的。这种自带证书进行验证，就叫做证书绑定
证书绑定（Certificate Pinning）
前几年的app虽然也都用了https协议，但只需要简单地通过设置代理就能抓到，而从去年开始遇到的几个app都不能走代理抓包了，一设置代理就说网络有问题，联不上网。经过分析其实很多都用了证书绑定技术，证书绑定简单来说就是app只信任自己内置的证书，如果服务端的证书与app内的信任证书不符，客户端主动拒绝连接，从而造成“网络无法访问”。如下是引用自stackexchange的关于证书验证与绑定的相关评论。
Typically certificates are validated by checking the signature hierarchy; MyCert is signed by IntermediateCert which is signed by RootCert, and RootCert is listed in my computer’s “certificates to trust” store.
Certificate Pinning is where you ignore that whole thing, and say trust this certificate only or perhaps trust only certificates signed by this certificate.
So for example, if you go to google.com, your browser will trust the certificate if it’s signed by Verisign, Digicert, Thawte, or the Hong Kong Post Office (and dozens others). But if you use (on newer versions) Microsoft Windows Update, it will ONLY trust certificates signed by Microsoft. No Verisign, no Digicert, no Hong Kong Post office.
Also, some newer browsers (Chrome, for example) will do a variation of certificate pinning using the HSTS mechanism. They preload a specific set of public key hashes into this the HSTS configuration, which limits the valid certificates to only those which indicate the specified public key.
翻译：
通常证书有自己的校验结构和组织，我的证书是被一个由根证书签名过的中间证书签名过的，而根证书是在我的电脑中被加入了信任列表中的。
证书绑定的意思就是忽略所有的东西，只信任当前这个证书以及被这个证书签名过的证书。
举个例子，如果你想要的访问google.com，那你的浏览器会信任一些被 Verisign, Digicert, Thawte,或者Hong Kong Post Office签名过的证书，如果你更新到最新的windows 系统，那就只会信任 Microsoft 签名过的证书，而不是Verisign, Digicert, Thawte,或者Hong Kong Post Office这些签名过的证书。
当然一些新的浏览器，例如chrome等，会根据HSTS 机制做一些证书绑定的变体，它们预加载一些具体的公钥哈希到HSTS配置中，这样就限制了只有被指定了公钥的有效证书才能生效。
（渣渣翻译，不知道我理解到位没有。。）
前面我们将中间人证书放到系统信任库中，突破了第一道https防线，那么现在我们遇到第二道防线，那就是证书绑定。证书绑定意味着，客户端会使用自带的证书来验证服务器是否是可信。
一般来说这里只是客户端校验服务器，而服务器是不校验客户端的。也就是谁来请求服务器都
根据证书绑定的描述，来突破这第二道安全防线：
从根本上来说，校验逻辑是手机在做的，只要手机上的校验逻辑没有正常执行就可以绕过这个校验流程。总的有下面几个方法
1、反编译app, 修改认证逻辑（不过这种方法慢慢不可取了，因为大多数app现在已经不是这么容易反编译和回编译了，而且回编译之后还要重新签名，绕过签名又是一件麻烦事。这个方法效率太低）
2、用xposed或修改smali控制创建连接的SSLSocketFactory，使它不加载信任库。
这里简单介绍下第二种方法，这是主流的也是我常用的方法。而且大神们已经给出了解决方案，我们拿来用就行。我一般是使用xposed+justTrustme 进行这种证书校验后的https 包的抓取。这时候我们就可以使用xposed+justTrustme 来帮助我们抓包。
不过这里因为篇幅有限，我们重点是https抓包的问题，所以对于xposed框架，这里只是提一下，不做介绍，后续会专门有关于xposed的专题整理出来。
xposed 是一款框架服务，安装的话需要先root手机。justTrustme是一款 xposed 的插件，xposed 插件是可以自行开发的，所以可以按照自己的需要开发出很多强大的模块出来。这里的justTrustme 在https://github.com/Fuzion24/JustTrustMe/releases/latest 可以下载，然后安装到安装了xposed框架的手机中
如上图就是安装并激活了xposed框架。然后安装我们的justTrustme 插件，并勾选启用。
当我们安装了插件，可以在模块列表中看到我们的插件列表，这里勾选启用。启用后可能需要重启一次手机才能生效。手机重启过后，我们就可以使用burp进行抓包了。你会发现原来不能抓包的https 现在都可以抓包了。
上面我们简单介绍了下如果遇到经过完整校验的https应该怎么抓包，这里用到了xposed框架。到这里为止，就可以解决大多数https抓包问题了，也就成功突破了这个第一道HTTPS的安全防线。但为什么是大多数，根据目前抓包的状况看，依旧是有一些未知的https流量，显然是一些安全程度要求较高的应用，除了做了证书方面的校验，还采取了别的措施。
这里介绍下我遇到的第三道HTTPS安全防线。
为了更好说明这个第三道防线，我们再来看看HTTP请求的一些细节。
上面是一个简单的http请求。这个请求是正常没有使用代理的。这个时候客户端向服务器的请求行里面其实只有url部分，并没有实际连接的主机名/IP，和端口号。因为在没有中间人代理的情况下，客户端在发送HTTP报文之前，就已经知道了服务器的地址并且与之建立了TCP连接，没必要在发送主机名和端口号。但是在代理的时候，情况就不一样了。客户端会先去连接代理服务器，而代理服务器却没法连接正确的服务器，因此客户端发送给代理服务器的请求其实会在请求行里面加上完成的url，方便代理服务器解析真正的服务器地址。
代理能实现的核心就是应用中的http客户端会去连接我们设置的代理服务器。当然我们的代理服务器如果在系统层面上做了设置，标准的http客户端是应该按照要求去执行的。就是系统中的http客户端都应该在http请求前检查下系统中是否设置了代理，如果有，就按照系统代理走。但是因为HTTP客户端基本都是应用自己实现的，所以不一定会这么中规中矩地执行这些标准。虽然大多数HTTP客户端都按照标准实现了代理功能，但是涉及到一些敏感的流量时候，并不一定会使用这种系统层面上的代理。可能是直接不发送请求给你报一个网络异常，又或者是使用自己信得过的代理完成这次敏感的请求。总之，不同平台有自己不同的处理方法。
那么问题就出现在这了，一些有经验的app开发人员会对当前app运行的网络环境进行判断，如果发现了使用代理上网，就不进行请求或者换用自己信得过的代理服务器。那么我们依旧是抓不到这种HTTP数据。因为这些数据压根就没走我们的代理服务器。
那么有没解决的方法？有的，只要想办法让流量经过我们就好
1、dns欺骗。这是一种常见的改变流量流向的方法。通过修改dns引导http客户端连接上我们的目标服务器。但是这种方法局限性也是比较明显的。首先要架设dns服务器。知道目标流量的域名，才能有效对流量进行引导
2、在网络的上层进行流量的转发。比如在上层流量中过滤出目标终端80和443端口的流量，并且将流量转发到我们的代理服务器上。这种方法就比较高级了，完成流量引导之后就是坐等接收数据了，但是需要有专门的设备。而且这种设备一般也只有保密单位或者安全单位才有。
3、使用***工具转发流量到我们的目标服务器。这种方法需要拿到客户端并安装上***工具，但是如果这个前提容易办到的话，就算是比较理想的一种方法了。
这里我依旧选择用方法3进行测试，因为对于逆向学习来说，测试机就在手边，安装一个***工具根本就算不上是一项困难的事。android的***工具网上一搜一大堆，这里我介绍我用的一款 drony (当然别的工具也行，开心就好)
安装完成drony之后，我们可以切换到setting选项卡，并且选中网络类型为wifi。
然后点击选中我们连接的wifi网络，这个网络应该要能连接上我们的代理服务器，比如与我们的代理服务器同网段什么的。
然后进去将代理模式打开为手动，设置代理的ip和端口号。最后点击保存运行即可。这款软件有一个我喜欢的好处就是可以设置直接的代理规则。比如可以指定哪些app的流量经过代理，甚至还可以指定ip和端口肚饿流量才转发，因为我们知道一个app中并不是所有流量都是http的，我们也不希望所有的流量到引导到我们的代理服务器，所以有针对性的可设置代理规则就很管用了。
其他的代理软件也是大同小异的，不外乎就是一个代理ip和端口的设置。这是完成之后就去查看你的burp吧。然后你就会发现又多了不少的流量哈哈。这些流量就是之前不通过我们代理走出去的。
总的来说就是，我们的防线3，就是会判断当前的网络状况，如果系统中有设置代理，就断开连接。
但是，是否这就是终极方案？非也。我们传统HTTPS还没完呢。为什么这么说？
我们前面提到的HTTPS其实只是做了一半。哪一半？那就是客户端验证了服务器。
那反之，还剩下一半。就是服务器也要验证客户端啊。
于是乎就有了HTTPS的双向认证。那我们之前做的，其实只是HTTPS的单向认证而已。
双向认证中，客户端和服务器端都带有自己的证书。而且互相校验。
在我们上述的xposed方案中，客户端这边算是完全掌握了。即使服务器是中间人，客户端都能完全信任。但是服务器呢？这个就不行了。因为中间人没有客户端的证书，所以服务器是不会买账的。。
额，好像说漏嘴了。。明显的让服务器买账的方法，就是让中间人拥有客户端的证书哈哈。这样岂不是就能完全伪装成客户端了么？
是的，事实就是如此。只不过伪装也是有难度的。虽然客户端已经在你手中，但是老鸟们肯定经过处理，不会这么容易让你找到证书的藏身之地，即使找到了，也很可能二次加密了。这也是HTTPS最后的倔强。
但是道理还是简单的。找到这个证书。导入到我们的burp。那么burp就是一个完美的中间人。
首先我们注意到我们使用的代理工具，比如，burp，fidder等。这些工具是可以生成自己的证书的，也支持双向证书的验证。但是在使用这些工具抓取https数据包时，默认是单向认证的。也就是默认不转发证书给服务器端。
接下来让我们介绍几种客户端证书校验的突破方法：
1、找到这些app对应的web平台（可以根据域名这些判断），然后直接在web应用上提取证书。一般在双向认证过程中会弹出确认证书的弹出框，或者通过查看证书属性，类似的方法提取证书。像有的金融类应用，还会提过一个U盾之类的东西，其实这种usb-key很可能就带有证书，我们可以从中提取。如果本身具有导出功能的话更好。但是一般来说，这种安全要求较高的应用，一定是有各种方法阻止这个证书的获取的。
安装证书之后我们可以导出这个证书，或者事后keytools 工具来生成证书
2、很多时候app中的应用并不一定有对应的web应用。这时候就要我们在应用中找证书了。一般的证书会跟android 应用一起打包(当然也不排除有那种动态发送过来的)。这时我们可以搜索一些证书的后缀文件，例如cer/p12/pfx等，一般安卓下的为bks，也可以先去assets或者res目录下去找找。
找到证书之后，我们可以尝试安装一下证书。
当然安装的过程肯定是会需要我们输入私钥的。这个私钥也必定藏在app中。
用java代码模拟双向认证的请求的过程：
// 双向认证证书
KeyStore keyStore = KeyStore.getInstance("PKCS12");
KeyStore trustStore = KeyStore.getInstance("jks");
// keyStore是服务端验证客户端的证书，trustStore是客户端的信任证书
InputStream ksIn = new FileInputStream("E:/Java/jre8/lib/security/re/1.pfx");
InputStream tsIn = new FileInputStream(new File("E:/Java/jre8/lib/security/re/1"));
keyStore.load(ksIn, "123456".toCharArray());
SSLContext sslContext = SSLContexts.custom().loadTrustMaterial(trustStore, new TrustSelfSignedStrategy())
.loadKeyMaterial(keyStore, "123456".toCharArray()).setSecureRandom(new SecureRandom()).useSSL().build();
ConnectionSocketFactory pSocketFactory = new PlainConnectionSocketFactory();
SSLConnectionSocketFactory sslConnectionSocketFactory = new SSLConnectionSocketFactory(sslContext);
Registry<ConnectionSocketFactory> r = RegistryBuilder.<ConnectionSocketFactory> create()
.register("http", pSocketFactory).register("https", sslConnectionSocketFactory).build();
PoolingHttpClientConnectionManager secureConnectionManager = new PoolingHttpClientConnectionManager(r);
HttpClientBuilder secureHttpBulder = HttpClients.custom().setConnectionManager(secureConnectionManager);
HttpClient client = secureHttpBulder.build();
HttpGet httpGet = new HttpGet("https://xxx.com");
HttpResponse httpResponse1 = client.execute(httpGet);
我们可以参考上面java 请求中做客户端校验的代码。按照这些写法反编译一次，找到类似的smali 代码。
最后通过对smali 的研究找到其中的私钥。
当然不排除这个私钥的保存是在native层做的。这就需要对native层做分析了。不过这不是这文章说明要说明的内容。
最后让我们来回顾下HTTP的几个防线和绕过方法：
1、纯HTTP
方法：设系统代理直接抓包
2、HTTPS 信任系统CA
方法：生成中间人证书，并导入到系统信任库
3、HTTPS 证书绑定
方法：使用xposed + justTrustme 插件。绕过本地证书校验逻辑
4、HTTPS + 代理检测
方法：使用***工具代理
5、HTTPS 双向认证
方法：从客户端中找到内置证书，并安装到中间人工具中进行请求。
以上就是面对HTTPS常用的几招了。
一般来说，如果一款app中抓不到什么包，但是app中的数据却是正常加载，大多数都是因为设置的问题或者是app中做了什么限制，用其他的tcp协议还是比较少的。如果是直接用tcp的话这个代价也太高了，不太实际。
这里说到了http抓包，那就再介绍一款神器吧，虽然这个工具在这里暂时没用到，但是在pc端的抓包分析中是必不可少的。这个神器叫Proxifier。有兴趣的可以下载来看看，软件很小但是功能很强大很实用。
界面是这样的，安装在pc上。我觉得这个好用的地方就是它可以设置代理规则。比如说，我们前面在本地8080口开了burp，想抓本地chrome的流量，原先有两种方法。1、设置chrome代理，2、设置全局代理。当然在IE中设置全局代理也是可以的。但是这样的话就会带来了很多额外的流量，这些流量大多数是其他应用的，过多的无关流量会给我们分析加大难度。当然除了这一个原因外还有更重要的，并不是每一个应用都支持设置代理的。浏览器基本都可以，但是其他应用呢？比如你要抓取桌面版wechat 的包？除了全局代理，你还会怎么做？
遇到这种情况，使用Proxifier事情就变得简单多了。这个工具可以自己设置代理规则，甚至可以指定运行中的哪个应用的数据需要经过代理。如此一来，就更加方便我们对某一个目标尽心抓包分析了。
以上就是http(s) 抓包中我觉得有用的一些东西。如果使用Fidder进行抓包，过程也大致相同，感兴趣的可以到这个老哥下看他的文章
对https 的抓包就先写到这，如果有新的东西会不定时更新
水平有限欢迎指正