Caution : ** **本文所描述的安装方式已经过时（2019年3月），你可能需要参考别的资料 此外，wine-devel仅建议在开发环境下使用，生产环境有另一个版本的wine 由于自己服务器的应用栈都是Linux系，而有些时候又不得不跑一些Windows下的应用程序（比如一些莫名其妙的类库、Windows下的一些奇奇怪怪的程序），因此需要安装wine，而目前在google搜到的都是一些陈芝麻烂谷子的不知道多少年前出来的东西，在当前环境压根用不了，所以写一篇短文记录下。 首先，如果你用Google搜“Ubuntu wine”的话，一篇2017年的文章会告诉你这么做：

1、安装源

sudo add-apt-repository ppa:wine/wine-builds

sudo apt-get update

2、安装wine

sudo apt-get install --install-recommends wine-staging

sudo apt-get install winehq-staging

3、卸载wine

1).卸载wine主程序，在终端里输入：

  sudo apt-get remove --purge wine

2).然后删除wine的目录文件：

  rm -r ~/.wine

3).卸载残留不用的软件包：

  sudo apt-get autoremove

4、终端中输入wine，检测是否安装完成。

然而当你实际这么做的时候你会发现第一步就会告诉你“**这个源已经过期了**”

https://launchpad.net/~wine/+archive/ubuntu/wine-builds

!!! PLEASE NOTE THAT THIS REPOSITORY IS DEPRECATED !!! For more information, please see: https://www.winehq.org/pipermail/wine-devel/2017-March/117104.html The following commands can be used to add the new repository: wget https://dl.winehq.org/wine-builds/Release.key sudo apt-key add Release.key sudo apt-add-repository ‘https://dl.winehq.org/wine-builds/ubuntu/‘

所以实际上的操作应该是：

1. 从 https://dl.winehq.org/wine-builds/Release.key 获取PGP签名KEY

wget https://dl.winehq.org/wine-builds/Release.key && sudo apt-key add Release.key

2. 导入源

sudo apt-add-repository ‘https://dl.winehq.org/wine-builds/ubuntu/‘

3. dpkg添加i386构架（如果你正在使用64位的操作系统）

dpkg –add-architecture i386

4. 更新源，并安装 wine-devel

apt update && apt install wine-devel

安装需要消耗大约700M+的下载流量以及约1.2G的硬盘空间（如果我没记错的话）

5. 安装完毕以后，wine的HOME路径在 /opt/wine-devel ，执行文件则在 /opt/wine-devel/bin ， 你需要将这个路径加入环境变量PATH中：

sudo vim /etc/profile

添加下面一行：

export PATH=/opt/wine-devel/bin:/opt/wine-devel:$PATH

:wq保存

然后 source /etc/profile 或者重新登录以后，运行 “wine –version”，看到版本号就说明安装成功了。

Virtual Private Server ，虚拟个人服务器，你可以简单的理解为类似于阿里云和腾讯云的那种云服务器，但是他们在质量上面有所差别。 这篇文章是一个不怎么完整的VPS 选购指南，本人玩VPS也有差不多两年多的时间了，便宜的贵的大众的基本都试着用过，在这篇文章里面我会尽量给出选购VPS时需要考虑的一些问题和注意点，包括配置、虚拟化类型、网络线路、商家口碑等。 另外：本人是非常反感某些为了AFF而吹嘘“这家的VPS质量不错云云”之类的，尤其是搬瓦工吹，DigitalOcean吹和Vultr吹。你们为了那点AFF钱忽悠别人有意思吗。

0x00 虚拟化类型

目前市面上常见的虚拟化类型一共5种，包括KVM / Xen (又分为PV / HVM) / VMWare / HyperV 以及 OpenVZ，其中前四种（除开Xen-PV）都是完全虚拟化（Full Virtualization），而Xen-PV是半虚拟化，OpenVZ则为容器级别虚拟化。 完全虚拟化的优势在于，所有的资源（内存、硬盘）一旦分配基本上都是独占的。而对于容器虚拟化，你的资源只是代表着你最多可以占用的资源数，除非商家有明确表示分配给你的配置是独享资源（“Dedicated”）。因此一般而言，OpenV容易存在超售的情况。 什么是超售？比如我一台4核8G内存的服务器，如果用前面的全虚拟化系统去开配置为512M内存的虚拟服务器，抛开资源损耗，我最多可以开出8G / 512M = 8192M / 512M = 16台服务器。但是对于OpenVZ这种半虚拟化则不一定，由于每一台VPS实际上很多时候并不会完全用完分配的资源（比如说你买了一台1G内存的OpenVZ，但是你很多时候可能就用了200M左右，这样就空闲800M内存），但是这些闲置的资源吧对于主机商来说好像太浪费了，于是他们就会在同一台宿主机上多卖几台这种配置的服务器，导致开出来的服务器数量超过了原定的数量。这种就叫超售。 当然，超售不仅仅存在于内存上，CPU和网络甚至硬盘都是可以超售的，典型的CPU超售类似于一台i7的4核8线程处理器却开出了32个KVM虚拟服务器，实际上就成了几乎4个虚拟服务器共用一个处理器线程。而网络超售更为恶心，在使用的时候你会发现服务器的网速奇卡无比，网络超售的一个典型的例子就是AlphaRacks家的OpenVZ系列服务器，标明是1Gbps的端口，实际跑起来10Mbps都没有。 另外，完全虚拟化可以自己定制内核，或者内核打补丁，而容器化虚拟的OpenVZ是和宿主机共用内核的，目前OpenVZ的内核大部分主机商用的都是2.6.32版本，比较陈旧了（虽然比较稳定），对于一些新的软件要求新版本内核的可能就没法只吃到了。此外，OpenVZ由于容器的特性，大部分涉及内核上的功能如果主机商不给你开的话你是没法用的。 当然了，由于完全虚拟化的成本对比容器虚拟化更高，因此一般完全虚拟化的VPS售价对比OpenVZ的也会更贵一些。 2018.05.09 注： 市面上大多是用的是OpenVZ 6 ， 这个版本将在2019年结束安全更新支持，因此已经不再建议购买OpenVZ架构的VPS了

0x01 基本配置

基本配置指的是一台VPS的资源配置，包括CPU、内存、硬盘等，要注意的是，由于你买的是“虚拟服务器”，你的资源其实都是在母鸡（用于虚拟化的宿主机上）虚拟出来的，所以更多的时候CPU会被称之为vCPU （Virtual CPU Resource）。 需要注意的是，对于CPU资源，一般的VPS提供商除非标明了“独享资源”，否则请不要长时间占满100%，不然的话会被主机商以违反TOS关停机器，包括之前提到的DigitalOcean和Vultr都是这样。 当然，在这一点上面几大云（阿里云/腾讯云/AWS）倒是容许CPU完全占用的。 内存上面的话，个人建议还是256M起步吧，对一般群众而言的话，各种运行环境装完256M内存刚好是一个能跑的地步（折腾党曾经在32M内存搭过WordPress，不过那个流畅度。。。。。平民还是不要折腾吧） （什么，你只搭梯子？搭梯子128M就够了） 至于硬盘的话，完全看价位了。出于超售成本的问题，同一商家同价位的OpenVZ VPS一般能比KVM这些虚拟化的VPS拿到的要多（至于实际能用多少，那就真的看主机商良心不良心了，某主机商曾经卖过400GB的OpenVZ VPS，但是一段时间之后用户发现自己实际能用的空间不断缩水最后只有几十G了）

0x02 网络线路

买服务器肯定是自己用的，如果自己用着都卡，那就真的没什么意思了。这里主要告诉各位线路上的一些说明。 中国大陆主要出口就是三大运营商的出口，包括中国电信163骨干网、中国电信下一代承载网（CN2）、中国联通骨干网（分为AS4837和AS9929，也就是老网通的骨干网）以及中国移动骨干网。对于出口质量的话移动联通其实都还可以，电信的话家庭用户一般都是走163骨干网，CN2则是真正的“世界加钱可及”，但是CN2的网络质量确实还可以。 所以买VPS之前，建议各位找商家要测试IP看下线路。这里个人比较常用的是ipip.net的工具。 对于电信用户的话，由于163骨干网出口已经非常极其特别拥堵了，所以一般的VPS体验上会比较尴尬。而走CN2的VPS也要看价格，在这个点上面阿里云国际版的新加坡和香港地区是非常值得一用的，何况新加坡也只有4.5刀/月。 至于AFFMAN，主机测评等垃圾网站口中常吹的搬瓦工CN2，其实就是C3（Zenlayer）机房的机器，只有国际出口走了CN2，其他的都是163的路由，而且由于C3机房的国人太多，基本被飞机场玩坏，线路早就不能和当初刚出来的时候比了。估计除了走上海出口的几个省份以外其他的都没法好好用。（至少广州出口走C3是如此） 2018.02.28 注： QuadraNet在2月份将原来10Gbps的163接入改成了10Gbps的CN2 GT接入，和C3一个样子，然而QN本身就有大量中国用户，加上超卖带宽无底线，所以QN实际上对电信并不是一个很好的选择。不要因为有CN2就上当。 如果你是联通用户，一般推荐日本的服务器，主要是联通到日本基本上是直连，而且用户数量以及带宽的原因，实际上家用联通用户出国的速度都是不错的。当然，如果你要买美国的服务器的话，可以考虑几个直连线路（比如QuadraNet机房，C3机房的） 至于移动，亚洲这么多VPS，电信联通绕路的移动基本都是直连，随便选一个有何不可？

0x03 关于商家

emmm，现在有很多人都在做着“主机测评”“VPS测评”之类的网站，借口“测试VPS性能”实则是推销AFF给自己拉点佣金罢了。 啥，你问我什么是AFF？就跟带路党差不多，人家介绍你去买某家的VPS，他能拿到相当于你付款的一定比例的佣金。 本来对AFF我是不反感的，但是现在整个网络上各种傻逼为了佣金不择手段狂吹辣鸡VPS，把一个垃圾的不行的VPS吹上天，最典型的就是“X机测评”这个站，以及V2EX上某些DigitalOcean / Vultr / Linode 吹（人家说的是阿里云有问题了，你跑出来说用DO用Vultr，阿里云的线路秒你们的渣渣NTT难道还秒不了？MDZZ） 下面是个人总结的《绝对不可碰的黑名单商家》，这些商家都有一个特点：技术不行，非常坑。排名不分先后

• HostMyBytes : 你关机了还能给你计流量，找客服修了两次都没修好
• HostHongKong : 虽然你是卖HK小鸡的，然而低价+疯狂超售买了也没法用，一个apt update执行1小时，体会一下。而且老板据说不讲道理。
  • AlphaRacks : 超售狂魔，非常不稳定，动不动就卡死或者网络1KB
  • Nfphosting / WootHosting : 与 AlphaRacks \ HostMyBytes以及还一家什么名字的来着并称“超售五杰”，专业低价高配但是超售到爆，根本不建议使用
  • Hostodo : 同上，技术垃圾
  • 大部分（80%）的国人商家（比如 xx速度，把美国Cera机房当香港机房卖的坑爹玩意儿）

以及需要谨慎上车的：

1. Virmach : 价格屠夫，然而TOS限制也很厉害，资源一旦滥用（CPU过载/IO长时间占用）都会导致关机甚至termination，对于喜欢跑高负载应用的并不建议。此外，这家的网络主要是colocrossing，对国内速度非常一般。
2. 搬瓦工 ： AFFMAN吹出来的品质，实际质量只有自己用才知道，超售厉害但是好在控制得当。最近墙得厉害的时候换IP费用3刀起步，被称为GFW战略合作伙伴
3. Vultr / Linode / DigitalOcean : V2EX三大吹，号称秒天秒地秒空气，实际上现在的网络质量对国内比较糟糕，很难做到一个地区满足三网需求。此外，Vultr / Linode 日本新开的基本都已经被玩坏了。这三家由于早前各种活动和国人的大量涌入，导致目前IP也很容易开出被墙IP

一般建议能上车的：两大云（腾讯云HK 、阿里云HK、阿里云新加坡）（然而阿里云最近也被一群人玩坏了，群众反映被墙以后换了20个IP都是被墙的，可见被玩坏到什么程度） 当然还有一句话：世界加钱可及。有钱啥搞不定的（） 但是如果非要低价、优质，可以说是不存在的。

0x04 AFF站 黑名单

说这个可能会被人黑说眼红，但是当说还是要说。信AFFMAN交智商税。 黑名单：

1. 主机测评
2. 小夜博客

Protobuf是谷歌发布的一套用于序列化结构数据的方法，全称Protocol Buffers。它包含了一套接口描述语言，用来描述一些数据结构，并使用配套工具生成代码，解析或序列化成数据流。其主要目的是希望能够比XML更轻量、快速，以此提高处理效率。 一般而言经常用到的两个部分包括Message和RPC，在开始之前，我们使用一个简单的示例来描述一下：

//message是Protobuf的数据结构，类似于C语言的Structure，其包含了一系列数据域
message HelloWorld{
required string name = 1; // message的数据域，相当于C语言中Structure的变量/Field
optional int32 number = 2;
repeated string message = 3;
}

message Response{
optional string response = 1;
}

rpc HelloWorldRpc (HelloWorld) returns (Response){}

如上所示定义了一个Protobuf消息，它包含了一个名叫HelloWorld的Message，而这个Message包含name、number和message三个字段每个字段前的修饰符(required / optional / repeated)则代表了数据的特性，字段后的数字代表他的TAG，这个TAG用于消息的序列化。 而同时，我们还定义了一个RPC，RPC全称为“远程过程调用”，简单的理解就是，发送一个消息给远端Server，然后远端Server执行一个逻辑，返回一个结果。这有点类似于你去餐厅吃饭，告诉厨子“我要吃土豆炒肉片”这个消息，然后厨子就执行“做菜”这个逻辑以后返回“土豆炒肉片”给你。 所以总的来说你可以认为Protobuf是“面向消息编程的RPC框架”。 在Protobuf中，message定义的基本类型包括int32/int64 (类似于C语言的long)，uint32/uint64 , string，bytes，并且，你可以在message中嵌套一个message，就像以前写C语言结构体的时候嵌套结构体一样。类似于下面：

message Ticket{
required int32 id = 1;
required string key = 2;
}

message Passenger{
required int32 id_card = 1;
required Ticket ticket = 2;
optional string identification = 3;
}

很简单的结构，对不对，那么之前说过，required / optional / repeated 代表这个数据域的特征，他们分别是：

• required : 必要数据域，此数据域在此Message中必须赋值，否则会抛异常。
• optional : 与required相反，这标志这个数据域是可有可无的。
• repeated : 表示这个字段会出现多次，实际代码实现类似于数组。

需要注意的是：在Protobuf v3中，Google移除了这些限定字，从v3开始除非标明为repeated字段，否则所有字段默认为optional，不再有required这一限定 然后我们在C++里面为他赋值：

/**
message Ticket{
required int32 id = 1;
required string key = 2;
}

message Passenger{
required int32 id_card = 1;
required Ticket ticket = 2;
optional string identification = 3;
}
*/

Passenger pPassenger;
pPassenger.set_id_card(123456); // set_xxxx 用于设置字段的值，字段名在方法中全部是小写
Ticket* ppTicket = pPassenger.mutable_ticket(); //如果需要修改嵌套的message，使用mutable_fieldname 来获取指针然后修改
ppTicket->set_id(2333);
ppTicket->set_key(“This is a key”);

// get value
string szTicketKey = ppTicket->key(); //get时直接使用其名称
//或者你也可以这样
szTicketKey = pPassenger.ticket().key(); //

当然你可能会注意到在这里我并没有去设置一个optional字段的值，那么对于一个optional字段，如果我没有设置值的话，应该如何处理呢？ 答案是：你可以使用 message.has_xxxx() 来判断是否设置了这个字段。 当然，对于一个optional的字段，其在初始化时会有一个默认值，这个值在不同的类型下表现为： string : 空字符串 数字类型（int/double/float等）: 0 布尔类型（boolean） : false Message : 空消息体 当一个optional字段没有被设置，而你调用了getter时，就会返回上面对应的默认值。

只做点醒作用，不会告诉你实际该怎么做，也不要想从这里找源代码。没有意义。 这文章对于真的有这份心自己弄的，肯定有所帮助，对于伸手党和心怀不轨的嘛，呵呵。 哦，伸手党还是滚回去吧，这里没你能看的东西。

0x00 回顾

我们先来想想Netkeeper的拨号流程：

1. 你在客户端输入账号密码点登陆
2. Netkeeper调用RasDialW函数拨号，其中参数RASDIALPARAMSW包含了拨号的账号和密码
3. 系统开始向BAS发包，认证，建立连接。

所以我们动手的地方可以在： 1.客户端本身 2.系统层面 3.中间人

0x01 客户端本身

客户端本身拨号的时候会有一系列函数调用，所以通过Inline hook可以起到一定作用，hook RasDialW函数并获取其参数即可知道用户名和密码。 然而呢。4.7 + 的Netkeeper / WeNet有了自保护机制，某人说的是呢信利调用了CreateFileW 并指定参数来另行加载了一份 RasApi32.dll，也就是说在这种情况下就算你hooke了RasDialW由于他调用的不是你Hook的那份DLL，所以没啥用。 所以说下来的话你可以通过在程序启动的时候注入你的DLL，把某些API给HOOK了，然后涉及到关键DLL的直接给返回你HOOK好了的，指定的句柄，这样应该是OK的。 总的来说inline hook不能通过常规手段达到，所以单纯写钩子没啥意义，不用点手段你根本就勾不到。（当然有没有什么漏掉的API可以试试的也不是不可能。） 当然还有一个办法就是读他的内存，类似于Cheat Engine. 至于读什么内容嘛，你想想他什么拨号的时候有些东西，哪些是固定的，然后再去考虑特征，很快就出来了。 啥？你说你是做外挂的啊，内存挂你不可能不会撒，这个就不需要我来教了吧。

0x02 系统层面

RasDialW调用的时候会向系统日志写入拨号的信息，包括使用的真实用户名，你可以通过事件查看器搜索RasClient的事件看到。 当然啦，托江西地区同学的福，你们的作死让手动版泛滥，现在4.8以上的客户端直接清空事件日志了。所以一般手段是看不到的 —— 但是不代表没有办法。你依然可以使用系统事件订阅API来完成这个操作，甚至是事件日志重定向，而且这个点还是比较有效的。 EvtSubscribe，就提示这么多了，这也是最简单的办法。对应C#的API的则是 EventLogWatcher 至于怎么用，好好理解事件模型吧。 这个方法很看脸，因为呢，往往有些时候事件放在缓冲区还没来得及被读取，你的日志就被客户端清除了。之前Simple Netkeeper用的这套方法很不稳定就是因为这个原因，我也不想说太多。拿来玩玩还是可以的。 当然我没试过RasDial的事件HOOK是否有用。你们可以试试？

0x03 中间人

PPPoE协议本身是二层协议。拨号的时候系统会发包到远端的BAS，所以你可以用中间人的手段来做，抓取PAP或者CHAP的验证包就能知道账号和密码。 至于怎么玩中间人嘛，虚拟机装个PPPoE Server就好了嘛，剩下的就看你自己怎么玩咯。玩这个不会抓包，会抓包玩python或者写代码玩不来，就真的滑天下之大稽了啊。 哦，别跟我说易语言，那东西自娱自乐就够了。

0x04 关于心跳

老规矩，443端口，QUIC的UDP，或者非HTTPS流量TCP，心跳服务器嘛。。。自己抓包看看吧：） 至于原文是什么加密是什么，人家信利某客户端VMP混淆算法了偏偏不混淆心跳，这是破罐子破摔呢还是新版要上了所以干脆不管了呢。

马云老板的学生鸡越来越不好使了，先是莫名其妙的高负载，然后是WordPress插件更新总是失败（其实是网络问题，出口太堵了），这就比较蛋疼了，而且每周更新服务器软件的时候都会莫名的尴尬，用PPA源的程序更新几百K都要花上十几分钟的时间，这没法忍了。 讲道理： 1. 服务器一个apt-get就能把负载撑到0.7 2.访问外网只有20KB/S的速度，甚至不到。一次update遇到PPA源就要爆炸 这你让我怎么玩，马云大哥。 然后用了一段时间QQ云广州区还算行。。。逢着这几天阿里云的奇葩事情（IT之家的事儿），所以就干脆搬站好了。毕竟腾讯云这边虽然只有1M带宽，好歹每个月有免费的10G CDN的流量，速度也应该慢不到哪里去。 其实WordPress搬站还是很容易的，不管是导入导出也好还是怎么，我是直接偷懒把网站目录压缩然后数据库直接mysqldump，丢到QQ云导入就不管事儿了，反正完整性都还在，没什么需要改动的地方。 只是想想续费就比较蛋疼，每月续一次。。。 虽然马云老爹的服务器续到明年7月了，然而。。。青岛这边这个情况我也没办法做为长久考虑。等抽个空了还是把备案之类的丢到腾讯云那边去吧。 （嗯？这和我在鹅厂有半毛钱关系么？并木有啊。

Updated @ Feb 15,2016 为Ubuntu准备了一键脚本来配置服务器/生成客户端配置文件，请戳这里 今年年初的时候显得极其特别以及非常无聊，剁了几个便宜货VPS，包括一个年付1.99刀独立IP的，还有四个NAT VPS（也就是和别人共享公网IP，自己只能用指定的20个端口的MINI VPS，但是带有至少/112 的IPV6地址）。比较蛋疼的是这几个NAT VPS给的端口都太高了，全部是10000+的端口，而且有两台NAT VPS是没有反向代理功能的（反向代理是服务商提供的功能，在设置好绑定的域名之后会把共享公网IP的80端口对应的请求转发到你服务器的80端口），部署其他的业务访问起来也很麻烦。鉴于那个1.99刀的服务器只有64M内存，也不太可能跑大一点的东西，所以就考虑把这些服务器干脆全部拉成一个内网，然后拿这64M的VPS作为反向代理提供服务。 拉内网和搭VPN差不多是一个意思，所以一开始计划在64M服务器搭PPTP Server，然后NAT VPS作为PPTP Client连过去，然而配置第一台服务器就出了麻烦，pptpsetup提示内核不支持mppe-128，然而OpenVZ虚拟化的VPS并不支持自己修改内核，所以意思就是PPTP在这里行不通没法玩。 那么L2TP Over IPSec ？ 64M的VPS本身也是OpenVZ虚拟化，而且内核开启IPSec支持的商家寥寥无几，我试着用Softether的L2TP功能，但是连上去以后是做不到内网互通的（至少客户端和服务端是不行的，你在ifconfig连内网的IP都看不到），所以也只能作罢 所以最后选择用OpenVPN来配置内网环境，基于tun设备+证书认证，加上OpenVPN本身会在断线后自动尝试重连，因此可以避免一些麻烦。 先按照 Digital Ocean提供的服务端配置方法，在64M服务器上配置好服务端。 由于我们这次配置只是考虑内网互通，而不是作为VPN访问网外资源，因此UFW和NAT转发配置部分不是必须的，可以直接忽略。push route部分也是不必要做的，NAT VPS本身并不需要走64M的VPS才能访问互联网，不然的话内网连上来以后所有的流量全部走64M的VPS了，这对访问速度有一定的影响。 然后，生成CA和客户端证书，（比如生成client1.crt和client1.key）。将证书的文本inline到client的配置文件中，我这里使用的配置文件是直接从Softether生成的配置文件修改而来的，内容如下。

dev tun proto udp remote 服务器地址 端口 cipher AES-128-CBC auth SHA1 resolv-retry infinite nobind persist-key persist-tun client verb 3 #auth-user-pass pass.txt comp-lzo —–BEGIN CERTIFICATE—– <CA证书的公钥内容，也就是ca.crt> —–END CERTIFICATE—– —–BEGIN CERTIFICATE—– <客户端证书的公钥内容，也就是client.crt> —–END CERTIFICATE—– —–BEGIN PRIVATE KEY—– 《客户端证书的私钥内容，也就是client.key》 —–END PRIVATE KEY—–

把文件保存为 config.ovpn，丢到客户端，并在客户端运行 openvpn –config config.ovpn，正确配置的情况下，半分钟后客户端运行ifconfig应该能看到一个带有内网IP的tun设备，这表示已经连接成功。

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.44.18 P-t-P:192.168.44.17 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:59 errors:0 dropped:0 overruns:0 frame:0 TX packets:69 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:4980 (4.9 KB) TX bytes:5412 (5.4 KB)

ping下服务器

PING 192.168.44.1 (192.168.44.1) 56(84) bytes of data. 64 bytes from 192.168.44.1: icmp_seq=1 ttl=64 time=68.0 ms 64 bytes from 192.168.44.1: icmp_seq=2 ttl=64 time=67.8 ms 64 bytes from 192.168.44.1: icmp_seq=3 ttl=64 time=68.1 ms 64 bytes from 192.168.44.1: icmp_seq=4 ttl=64 time=67.6 ms 64 bytes from 192.168.44.1: icmp_seq=5 ttl=64 time=68.0 ms 64 bytes from 192.168.44.1: icmp_seq=6 ttl=64 time=67.7 ms 64 bytes from 192.168.44.1: icmp_seq=7 ttl=64 time=67.9 ms ^C — 192.168.44.1 ping statistics — 7 packets transmitted, 7 received, 0% packet loss, time 6006ms rtt min/avg/max/mdev = 67.643/67.912/68.106/0.211 ms

服务器Ping客户端

PING 192.168.44.18 (192.168.44.18) 56(84) bytes of data. 64 bytes from 192.168.44.18: icmp_seq=1 ttl=64 time=67.7 ms 64 bytes from 192.168.44.18: icmp_seq=2 ttl=64 time=67.7 ms 64 bytes from 192.168.44.18: icmp_seq=3 ttl=64 time=67.9 ms 64 bytes from 192.168.44.18: icmp_seq=4 ttl=64 time=68.0 ms 64 bytes from 192.168.44.18: icmp_seq=5 ttl=64 time=67.7 ms 64 bytes from 192.168.44.18: icmp_seq=6 ttl=64 time=70.4 ms 64 bytes from 192.168.44.18: icmp_seq=7 ttl=64 time=67.8 ms 64 bytes from 192.168.44.18: icmp_seq=8 ttl=64 time=67.6 ms ^C — 192.168.44.18 ping statistics — 8 packets transmitted, 8 received, 0% packet loss, time 7010ms rtt min/avg/max/mdev = 67.619/68.144/70.480/0.910 ms

客户端ping客户端

root@nat:~# ping 192.168.44.14 PING 192.168.44.14 (192.168.44.14) 56(84) bytes of data. 64 bytes from 192.168.44.14: icmp_seq=1 ttl=64 time=140 ms 64 bytes from 192.168.44.14: icmp_seq=2 ttl=64 time=140 ms 64 bytes from 192.168.44.14: icmp_seq=3 ttl=64 time=140 ms 64 bytes from 192.168.44.14: icmp_seq=4 ttl=64 time=141 ms 64 bytes from 192.168.44.14: icmp_seq=5 ttl=64 time=140 ms 64 bytes from 192.168.44.14: icmp_seq=6 ttl=64 time=141 ms 64 bytes from 192.168.44.14: icmp_seq=7 ttl=64 time=140 ms 64 bytes from 192.168.44.14: icmp_seq=8 ttl=64 time=140 ms ^C — 192.168.44.14 ping statistics — 8 packets transmitted, 8 received, 0% packet loss, time 7008ms rtt min/avg/max/mdev = 140.628/140.910/141.689/0.494 ms

至此内网已经可以互通，剩下来的就是研究研究内网安全配置了。

- - 今年年初的时候嫌电信的4M电话线速度不够，在听说小区联通接了光纤以后毅然决定换到联通的智慧沃家上面来，20M的网带电视什么的比起电信之前119一个月4M小水管不知道划算的到哪里去了，上行速度快的让我和GFW谈笑风生啊 然后呢，联通那个时候对IPTV用户送了个机顶盒，拿到手折腾了几下发现纯粹就是个Android的盒子而已，而且限制还蛮厉害的，不能从联通官方的应用商店之外的渠道装APP。当时因为没什么意向折腾也就没有在意。直到今天回舅舅过来的时候问我“这盒子能刷么？”，我想想安卓的东西大抵都是能刷的吧，然后说“应该可以”，于是就开始折腾了起来。 机顶盒型号为DC5000，机身可用存储5.02G，估计是8G的ROM吧。Android的盒子想想都是ARM的，这年头的ARM不是4核起步似乎都对不起人了嘛（ARM：论核心数，我不是说你一个，我是说在座所有双核还有胶水核，都是辣鸡(ಥ_ಥ)） 不过折腾了大半天发现这机顶盒的确挺坑爹的：

• APP只能从联通应用商店安装
• 从他自带的文件管理里面浏览，所有存储设备里面的APK文件被“技术性忽略”而不给显示，所以也就没法安装
• 回舅舅尝试曲线救国用HTML试图打开浏览器，然而这里面出了一个HTML Viewer并没有一个能用的浏览器

然而百密一疏，回舅舅在打开联通的应用商店的时候突然弹了一个Android程序的安装界面，嗯，应用商店自己更新了。。。更新了。。。 嗯？好像有啥不对？你运行APK了？啥？你运行APK了？ 于是果断点了取消安装，返回去再打开应用商店看，结果这玩意儿傻乎乎的又开始请求更新，下载APK，然后弹出安装界面。 然后我就想了想，这套路我玩儿的有点多了啊，HTTP请求更新啊，那就干脆做个中间人看看能不能抓到点什么。托这机顶盒带WIFI功能的福，这种贱人实行起来简直是too simple啊有没有，开个承载网络，wireshark直接抓承载网络那张卡就好了。 然后就抓到一堆过程：

• 先是请求了一个用户登录
• 然后请求了一次心跳
• 接着请求更新，返回了一个很明显的APK下载地址

哎呀妈呀这套路不咋地啊，jsp + servlet，IP和端口都是写死的啊，DNS请求一个都没找到啊，那行嘛，老板，来点儿乐子。 上虚拟机+ Nginx，然后把抓到的上述过程的返回包原模原样给贴进去（当然要改返回的下载链接啦，这里为了方便就听了回舅舅的改到了沙发XX的APP链接去了）。开同样的端口，上同样的IP（怎么改IP？这程序下载更新的时候IP就在那一个C段范围里面，所以直接虚拟网络编辑器里面把某个VMNet的子网改成那个C段的网就好了），配同一个目录，艹最傻逼的APP。 为了保证路由没错，我还特地在电脑上Ping了下那个“服务器”的IP，嗯，TTL=64，没错啦。 然后，见证奇迹的时候到了。。。欸？你怎么还是下载的那个鸟应用商店？ 卧槽？为毛虚拟机的Nginx没有收到请求？ 然后我回过神来，我开启的承载网络共享的是有线网。。。这数据包估计直接走有线网共享出去了（看来路由表还真是路由表。。。只对本机有效啊 然后对于这些数据包，表情应该类似于“对方不吃你这套路由并向你丢了一个官方的应用商店” 好好好你6，拿我虚拟机加个网卡直接桥接到路由器的网，然后路由器配个路由指回来好了。 虚拟机从路由器拿到的IP是192.168.1.109 我要劫持的IP是202.99.114.0/24 然后直接在路由器丢了一条规则： 于是数据包的表情应该变成了“我去年买了块表”的崩溃状态？ 打开那个应用商店，嗯，开始更新了，我看了下wireshark里面，登录了。。。。。嗯？？？报错？

405 Method Not Allowed ——————————- Nginx

什么鬼？POST给我来405？ 然后谷歌了一番，nginx禁止POST静态资源。。。于是又要加一条规则让他老老实实成功

error_page 405 = $uri;

然后再来一次，登录了，心跳了，更新了， 然后。。。这B应用市场给我报了一个客户端更新错误 excuse me ????????你在做啥，大兄弟，地址给你了啊 然后反过来仔细看了下抓包。。。发现这东西请求的下载根本不是我返回的那个地址，而是在。。。一个莫名其妙的操作之后，这个操作似乎像服务器请求了“版本是否可用”的消息，然后返回了一个downloadUrl字段。 当时电脑开着虚拟机访问不了那个网段，然后就丢到手机直接打开看看。。。然后QQ内置浏览器直接显示了一串乱码

<乱码>META-INF/<乱码1号乱码2号……….乱码n号>

不过开头的那个META-INF/就算化成灰了我也能认出来，这TM就是一个APK好嘛？？？ 感情你最后下载靠的这个URL？execuse me ？？？那你更新检查拿来干嘛使的啊我去ヽ(ｏ`皿′ｏ)ﾉ 你耍猴呢？ 然后直接把这个“版本是否可用”的消息给毙了，强行返回沙发XX的安装链接 然后这东西终于开窍了。。。。。。电视直接弹出了沙发XX的安装界面 我的内心是这样的：(=ＴェＴ=) 然后安装完之后 总算装上去了，喜大普奔啊。有没有！！！ 装了一堆APP，这下老妈回来总算可以安安心心追新电视剧了。。。。。（之前联通自带的大部分都是老片子好嘛！！！！ 附上电视机斗鱼AV的画面，在电视机上看斗鱼直播是一种什么样的体验（严肃脸 最后。。丢个蛋 （你们这个套路玩的好实诚啊，我差点就相信了

博客启用HTTPS也应该有一年多了，最近闲的无聊的时候F12发现自己网站的HTTP2没了（博客服务器一直是用的Nginx的mainline版本），寻思咋回事儿的时候发现谷歌从Chrome 51开始强行要求ALPN（Application Layer Protocol Negotiation，应用层协议协商）才能开HTTP2。然而搜遍谷歌给出的结果是OpenSSL 1.0.2才支持ALPN，这就搞得Server端用Ubuntu 14.04的我比较尴尬了(1.0.1版)。 当时我心里第一反应是WQNMLGB的OpenSSL……CHACHA20在实验版本才有就算了，ALPN支持也这么坑。。。。。（只是吐槽，不带恶意，毕竟这东西在开源世界还是帮了不少忙的。） 然后思来想去，反正14.04上的OpenSSL已经这个鬼样子了，我还是自己动手编译支持吧，顺便把Chacha20丢进去。 那么问题来了：ALPN和CHACHA20好处都有啥？说对了就给他 首先，上面提到了，ALPN对后面版本的Chrome来说是开启HTTP2协议的必要条件。HTTP2对比Http 1.1做出了比较多的改动，比如Server Push，服务端根据客户端的请求推测他后面会请求的资源，然后一并推送给客户端，这样一来可以减少客户端请求次数。其次，头部压缩减少了传输体积，优化传输效率。 其次，对于CHACHA20加密，CHACHA20是一种流加密方式，并且旨在提供256位高强度的加密，对移动设备的兼容性更好（毕竟PC上有AES-NI指令集可以处理AES加密，然而手机上面并没有）。之前有一篇测试曾对比过三星移动设备使用AES和CHACHA20加密的速度的对比，在同样大小的密文解密情况下，CHACHA20的效率是AES的4倍左右。 所以说了这么多，开工开工。 （对于使用Ubuntu/Debian的同学，如果不想看下文的话，可以参考这份脚本—》链接） 由于OpenSSL目前生产环境还不支持CHACHA20，因此使用LibreSSL替代。 先下载LibreSSL，这里使用2.4.1版本，然后make：

wget http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.4.1.tar.gz -O libressl.tar.gz
tar zxf libressl.tar.gz
cd libressl*

./configure –prefix=/usr LDFLAGS=-lrt
make

mkdir -p .openssl/lib
cp crypto/.libs/libcrypto.a ssl/.libs/libssl.a .openssl/lib
cd .openssl && ln -s ../include ./
cd lib && strip -g libssl.a && strip -g libcrypto.a
cd ../../../

至于为啥不install，毕竟你系统里面还有其他需求OpenSSL的，万一install完出问题那就不好说了。 然后下载Nginx，这里我使用1.10.1的源代码。configure的配置来自于Nginx官方源的配置，但是去掉了GeoIP和Perl支持。 在配置之前，为了保证configure的完整性，避免报错，你可能需要安装下面几个东西：

apt-get update
apt-get install libxslt1-dev libxml2-dev zlib1g-dev libpcre3-dev libgd-dev -y –force-yes

然后configure

tar zxf nginx.tar.gz

cd nginx*

./configure –prefix=/etc/nginx –sbin-path=/usr/sbin/nginx –modules-path=/usr/lib/nginx/modules –conf-path=/etc/nginx/nginx.conf –error-log-path=/var/log/nginx/error.log –http-log-path=/var/log/nginx/access.log –pid-path=/var/run/nginx.pid –lock-path=/var/run/nginx.lock –http-client-body-temp-path=/var/cache/nginx/client_temp –http-proxy-temp-path=/var/cache/nginx/proxy_temp –http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp –http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp –http-scgi-temp-path=/var/cache/nginx/scgi_temp –user=nginx –group=nginx –with-http_ssl_module –with-http_realip_module –with-http_addition_module –with-http_sub_module –with-http_dav_module –with-http_flv_module –with-http_mp4_module –with-http_gunzip_module –with-http_gzip_static_module –with-http_random_index_module –with-http_secure_link_module –with-http_stub_status_module –with-http_auth_request_module –with-http_xslt_module=dynamic –with-http_image_filter_module=dynamic –with-threads –with-stream –with-stream_ssl_module –with-http_slice_module –with-mail –with-mail_ssl_module –with-file-aio –with-ipv6 –with-http_v2_module –with-cc-opt=’-g -O2 -fstack-protector –param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2’ –with-ld-opt=’-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,–as-needed’ –with-openssl=《LibreSSL的绝对路径，比如/opt/nginx/libressl-2.4.1》 –with-ld-opt=”-lrt”

touch下Header File，避免被Nginx 重新编译,然后make

touch /opt/nginx/libressl-2.4.1/.openssl/include/openssl/ssl.h
make

接下来，是make install 还是继续其他的操作，取决在你自己了。对于之前已经安装过的同学，执行make install的话会替换掉之前你安装的版本。因此这步请注意下选择。 我这里是make install替换原版本。 然后，如果你是全新安装，你需要把这份文件丢到/etc/init.d里面，然后执行下面的语句，以确保Nginx开机自动运行

sudo ln -s /usr/local/nginx/sbin/nginx /usr/bin/nginx

wget https://raw.githubusercontent.com/sunflyer/EasyUbuntu/master/nginx.init -O /etc/init.d/nginx

sudo chmod +x /etc/init.d/nginx #安装启动脚本

sudo update-rc.d -f nginx defaults #设置开机自启动

最后运行 nginx -V看看？

nginx version: nginx/1.10.1
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
built with LibreSSL 2.4.1
TLS SNI support enabled

修改你的ssl_cipher配置为下述：（这个是CloudFlare的SSL配置）

EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5:!MEDIUM:!LOW

然后测试下连接。 至此大功告成。

今天早上起来得知学校发布了官方的APP，随便刷了几下后发现功能全面的比以往都要多，包含了校园卡信息以及课程信息等等。想想之前光一个教务系统写爬虫都要死不活的，这会儿突然这么多功能应该是开放了接口，于是开始折腾抓接口，顺便折腾折腾这荒废掉的时光。

0x00 开刀开刀！

通过反编译发现APK没壳没混淆，而且看着中文的Package名一种莫名的违和感。。。 反编译AndroidManifest，找APP入口，以及一些关键字，及其对应的Activity，以便下手分析。从XML获取到的信息来看，程序会执行LoginActivity进行登陆，于是找到对应的Class，然而不太走运的是貌似因为我很久没更新反编译工具了，关键部分的代码全部是error，找不到一点有用的东西。于是干脆导出源代码从Eclipse找重点（其实是没有代码高亮看的不爽） 登录操作位于yh.app.tool.uiengine的Login类，被逼无奈之下还是看了错误的字节码来找点信息。看了半圈之后发现两个关键东西：Constant.number和Constant.code，然后定位到Constant类，顾名思义，常量类。打开以后Ctrl Alt H展开调用引用，发现一个可疑的用于初始化信息的类 然而转到以后并没有什么卵用，代码显示只不过是从数据库初始化罢了，并没有其他的意思。然而对code字段同样操作后，得到另一个关键方法：getFunctionTicket，这个方法用于计算登录用的Ticket字段（类似于身份标识） 然后很意外的得到了Ticket的算法。 也就是说Ticket计算为：yunhua+学号+code+FunctionKey，我还在纳闷这个code是什么的时候，同在研究APP的大白说了一句，这个code是密码。 顺藤摸瓜，为了搞清楚FunctionKey是什么玩意儿，开承载网络当中间人抓包。至于抓包过程嘛因为没留记录，当时只顾着整理去了，所以就干脆留个结果吧 可以看到，程序通过请求list.action来获取功能表，并且每个功能包含其名称，以及FunctionKey，等等。 对getLoginTicket执行引用查看，可以得知两个参数分别为学号和MD5后的密码。不再赘述。 通过抓包发现对功能的实际调用是在服务器端的302跳转。通过rout.action进行，此action角色类似于一个SSO，起到鉴权和真正功能指向的作用。

0x01 流程分析

好了，大致反编译完成以后这点东西也就比较明显了，其实APP并不复杂（其实是因为没混淆没壳2333333），而且这东西实在是太。。。。。忽悠了。至于为啥，放后面再说。 程序在打开以后要求进行登陆，输入学号和密码。初始密码为身份证后6位或者6个0。用户点击登陆以后，程序会进行两个请求，一个是请求login.action来获取学生的个人信息（学院，班级，学号，等等），然后请求list.action获取功能表以及对应的KEY。如果信息错误则无法获取这些信息，表现为错误信息“无权限访问”。login.action需求学号和密码，提交的密码为MD5（密码），list.action需求学号以及Ticket，Ticket算法为MD5(“yunhua”+学号+MD5（密码）) list.action根据大白的描述并不是每次都会请求，因为正如之前所提到的，他在本地有一个SQLite数据库保存数据，这些菜单放在了SQLite进行缓存。 然后，对于每一个功能，根据其FUNCTION_TYPE决定其进行的操作。目前的列表中包含了两种（1或者2），根据情况可以推出，1指代Native或者第三方SDK功能，2指代WEB VIEW。 对于Web View的功能，APP请求rout.action，（GET方式），参数为function_id，学号，ticket，其中ticket算法为MD5(“yunhua”+学号+MD5(密码)+FunctionKey)，服务器端SSO鉴权成功后进行302跳转到正式业务服务器（比如一卡通，等等）进行处理。在正式业务服务器中通过Cookie进行身份鉴权（因为SSO跳转的时候带了sid和ticket），否则提示无权限操作

0x02 不得不吐槽的东西

看完了上面的内容你应该知道我要吐槽什么了吧？

第一点：安全问题。

APP是今天才上线的，然而非常尴尬的是学校的初始密码为身份证后6位，这种乍一看非常安全的东西实际上并不安全。实际上，学校每次大型考试前都会发布一个表格，其中包含了身份证信息和学号姓名这些玩意儿，也就是说如果有心之人一开始就收集数据的话，要拉取用户的信息一点都不困难。 然而可以拉取的信息有哪些呢？校园卡消费记录、余额、考试信息、课程信息、图书信息、成绩。毫不夸张的说，一个晚上拉遍所有信息应该不成问题。（毕竟模拟登陆的API我写了不到3小时的样子 所以说学校在安全方面简直就是在感人。。。当然我估计也是考虑到初始密码没法好好玩，因为这套协议。。。这套协议本身就是明文密码取MD5，估计教务系统密码是带了SALT没法玩。

第二点：设计缺陷

不知道是不是外包公司的问题，这套Ticket协议在我看来其实本身就是一个缺陷比较明显的协议。 首先，综合第一点里面提到的，初始密码身份证后6位，加上在login.action用的密码为不加salt的MD5，那么任何一个想搞大新闻的都可以试图抓到数据后进行爆破。 其次，Ticket这种东西没有一个时间概念。简单来说，一个中间人只要抓到了一次所用的Ticket，那么后面这块内容只要原用户不改密码，服务器的FunctionKey不变，那么这个Ticket永久有效。 这个意思就是：假如某一天我为了追一个妹子故意中间人骗她登录APP以后抓到了这个Ticket，而不巧的是呢他正好是点的一卡通之类的东西，那我是不是可以搞什么“消费记录数据分析”推测她经常在哪里吃饭？然后经常去那里能看到她？最后用各种奇怪的方式让她惊呼“哇为什么每次都这么巧”然后赢取白富美走向人生巅峰？ Ticket本身应该是作为一个鉴权标志，应当带有其时效性才对，不然那些网站过几小时不活动就登出了难道是脑子有坑吗。。。。 此外，你们直接在list.action返回的内容里面，指定了具体负责操作的反射类和Package名称来完成具体任务。。。灵活倒是灵活，然而。。。。你们就不怕出事儿吗。。。。 而且我在实际抓包的时候你们Web View每一个rout.action都是双重请求啊卧槽！

第三点：学校你能好好上HTTPS嘛？

不是我说啥，校园卡消费记录，银行卡绑定，密码这些东西涉及到了，你还明文传输，真的大丈夫？ 上次听说学校的人懒到SSL证书都懒得管了，说要签就签十年，不然学校没人管。然而现在普遍都是2-3年的时效，2-3年换一次证书真的就这么麻烦？学校万年IIS党X个证书也麻烦不到哪儿去吧？ 啥？你跟我说备案？难不成备案了两年他就查不到了吗？

0x03 API LIST

域名：app.cqut.edu.cn 222.178.158.49（222.178.158.48） Ticket计算：LoginTicket : MD5(“yunhua” + number + code); FunctionTicket : MD5(“yunhua” + number + code + KEY) number = 学号 code = MD5(密码) 1.软件更新：GET /UIA/update/updateVersion.action?mobileType=android&versionCode=120 返回： “{\“message\“:\“\“,\“update\“:false}” 2.拉取菜单 ： GET /UIA/function/list.action?userid=《学号》&ticket=《LoginTicket》&Version=1 返回示例：”{\“functionrow_2\“:{\“FUNCTION_TYPE\“:1,\“FUNCTION_ID\“:20150116,\“CLASS_NAME\“:\“yh.app.function.WisdomClass\“,\“FUNCTION_NAME\“:\“智慧课堂\“,\“FUNCTION_FACE\“:\“http:\/\/dc.app.cqut.edu.cn\/DC\/Image\/zhkt.png\“,\“IOS_NOTICE\“:\“segueForWisdomClass\“,\“PX\“:9,\“INTEGRATE_KEY\“:\“AF067B8593174537853C4136586312CC\“,\“PACKAGE_NAME\“:\“yh.app.appstart.lg\“,\“FUNCTION_TYBJ\“:0},\“VERSION_NUM\“:10}” 3.用户登录：POST /UIA/login/login.action userid=学号&password=原始密码MD5 返回：”[{\“usertype\“:1,\“userinfo\“:{\“ZYDM\“:\“0306\“,\“XBDM\“:\“1\“,\“TXDZ\“:null,\“BMMC\“:\“计算机科学与工程学院\“,\“BJDM\“:\“班级号码\“,\“BMDM\“:\“03\“,\“SR\“:null,\“ZYMC\“:\“软件工程\“,\“QQ\“:null,\“SFZH\“:\“身份证号码\“,\“USERNAME\“:\“姓名\“,\“XBMC\“:\“男\“,\“NJDM\“:\“2013\“,\“MZMC\“:null,\“MCDM\“:null,\“DH\“:null,\“USERID\“:\“学号\“},\“islogin\“:\“true\“}]“ 4.功能表（Web View） : GET /UIA/rout/rout.action?userid=学号&function_id=<功能ID>&ticket=

0x04 写在最后

不否认学校这次开明的上了APP来帮助教学。然而我还是希望老师们能够好好评估一下其中可能存在的风险。毕竟学校的系统各种漏洞已经多的不行了，某系统的权限漏洞2年前至今仍在，未被修复。 我就不想说各种抓照片抓XX记录的权限不严的碧油鸡了。毕竟你们喜欢吃的话，你们高兴就好。 我还是想起两年前，在信息处帮老师部署某网站的时候，我说了一句“隔壁学校教务系统被注入了”，然后旁边老师就在笑“什么年代了还玩注入，好笑” 然后我不知道就我们学校这千疮百孔的系统，如果这几年不是防火墙挡着的话，这个老师是不是真的还笑得出来。 骄傲，自大，嗯哼，这个学校从来都不少这种。 我非常高兴的是学校这次敢于跟上信息时代，并且推广。然而我希望你们对学生的信息负点责任，谢谢。

提示：文章适用于四川地区天翼飞Young 3.09客户端。仅给出其协议交换期间的分析，没有算法说明。（我也没有阅读过之前版本的算法，因此如果有什么奇怪的地方还请见谅） 这份客户端是在今年早些时候拿到的，然而当时并没有去管他，因为那时候模拟PPPOE都还是问题。当然自从上次把CHAP模拟搞完了以后翻垃圾的时候翻到了这个东西，于是就想折腾下。正好有个四川的小伙伴，我也就试试看能不能帮个忙。 四川地区天翼客户端使用的是NDIS驱动模式，而且比较蛋疼的是他主客户端计算出账号以后这个鸟驱动还要改一次账号，非常蛋疼。当时想的是我CHAP模拟写完了的话抓账号应该非常容易。然而让我感到奇怪的是对于每次的登录操作，CHAP模拟都抓到了两个不同账号（客户端计算的账号不一样），这说明客户端是连续进行的两次拨号。最开始我以为是因为我CHAP返回了Failure导致客户端更换到“兼容算法”再次进行拨号，直到我拿到四川小伙伴发来的抓包我才发现。。。 “他妈的都是套路。” 话不多说，先来说下总结： 1.点击登陆，客户端计算第一次账号，格式为 ghca + 时间戳的HEX形式8位 + F + 309 + PIN + 原本帐号。原本账号为大写（即便你账号有小写字母） 2.调用RasDialA以后，如果BAS使用CHAP with MD5，则飞young客户端的NDIS驱动开始工作，修改客户端的账号。去掉ghca以后，将时间戳的8位进行算法操作得到新的8个字符，替换原来时间戳部分。 3.服务端收到了驱动修改过的账号后，返回错误信息，包括一个SALT，用于真正的账号计算。 4.驱动调用客户端进行第二次拨号。此时，客户端账号为 ghca + 时间戳HEX8为 + E + 309 + PIN + 原本账号。 5.驱动使用接收到的SALT，将时间戳HEX8位进行变换。此时ghca不会被去除。 6.服务器返回真实登陆情况 账号格式： 四川电信的账号格式为 ghca + 时间戳HEX形式8位 + 标识符（D/E/F） + 版本号（309） + PIN + 原本账号。 例如 ~ghca 5739EBB9 F 3090 1E115098F4033EE 7638 1231231 (这里是为了方便阅读区分因此加了空格。) 你可能会奇怪我为什么会把PIN部分最后四位独立开。看下面我抓到的账号你就会明白了。 最后两行，第一个是在事件查看器里面显示的账号（被我去掉了），也就是他客户端调用RasDial函数的时候所使用的账号，“5739EBB9”很明显的16进制时间戳的意思。第二个是驱动转换后的账号。图中的账号都是我为了阅读方便加了空格。 我之前说到过，四川的每次登陆，实际上都是两次拨号，上图中上面的部分是第一次拨号时驱动转换后的账号，中间部分是第二次拨号驱动转换后的账号。（请注意：中间部分的账号并不清楚来源为何，根据抓到的真实数据标识符为D的账号是没法登陆的。实际上第二次登录的账号应该为标识符E且带有ghca开头，我会在下面说明）。非常有意思的情况是，第一次拨号，PIN的前面部分是全部为大写，而第二次拨号时则全部为小写，而且，PIN部分的最后四位总是大写字母。（或许可以猜测下最后四位是不是MD5之类的HASH算法算出来的一个Signature值） 上面是我CHAP模拟出来的数据，我们再来看看真正登陆的时候的数据是什么样子： 第一次拨号的账号： 这里可以看出来第一次都是这鸟样子，而且服务器返回了Failure，消息内容为32个0. 于是到了第二次拨号的时候，账号就成了这样子： 咯，账号标识符变成E了，而且ghca还在。后面的Authentication Success表明了这才是真正的账号。 想到之前Netkeeper这类东西靠在CHAP Failure或者PAP Failed的Message里面传递消息的情况，我就天真的以为这32个0就是真正的消息，告诉客户端“用ghca”来拨号。然而。。。。。客户端依然返回了标识符D的账号。从头到尾没有出现一个ghca 这就比较尴尬了。我TM好像没漏掉啥啊？难道客户端有毒？ 直到换了一个姿势去看抓到的数据包。。。。。。。 这是我最开始的过滤规则 换个姿势： 然后，这个是CHAP Failure的包： 这个是服务端返回的PADT包： 好像有啥不对？？？ （左边CHAP Failure，右边PADT，注：0xc223表示CHAP协议域，而04 01 00 24中04表示CHAP 失败，Identifier为1，00 24为消息长度（换算十进制也就是36，包括前面的04 01 00 24在内，因此实际Message为32字节）） 我草泥马。。。。。你们四川电信真他妈会玩。PADT里面发SALT老子也是不得不服 那么问题就很明显了，这个NDIS驱动起到的作用应该是： 1.检查是否为CHAP，如果为CHAP则继续操作，否则不管事儿 2.如果客户端下发的账号标识符为F，表示为第一次拨号，去掉~ghca并替换时间戳为算法后的字符串 3.拦截服务器返回的PADT包，提取SALT 4.传递salt给客户端，调用客户端进行第二次拨号。 这就比较尴尬了，SALT是从服务器来的，如果要欺骗账号的话，目前的情况看来只有中间人这条路好用了。（有算法的就是另一回事了好吧 = =） 也就是说，要么你来个中间设备抓真实帐号，要么嘛，你也可以上NDIS和光华冠群的驱动打一架。嗯。 当然目前的情况这客户端貌似没壳，会玩逆向的同学或许可以试试 =。= （完）