最近闲来有事, 分析了一个非常低端(非常低端的意思是说你不应该对她是否能取代你现有的QQ客户端作任何可能的奢望,她只是一个实验性的东西)的手机QQ的协议, 是手机QQ3.0, 
     所用到的TCP/HTTP通信协议版本是1.4, 也不知道是哪一年release的了, 至少有七八年的历久了吧, 反正就是: 功能非常弱!

主要的分析原因是想学学网络方面的编程经验(这是我第2次弄socket编程 :-) ), 以及学学怎么抓包分析.

主要用到的工具软件

手机QQ3.0: http://www.ruan8.com/soft_5872.html

kEmulator(Java模拟器):http://gamevina.us/kemulator-vh/

Wireshark(协议分析):http://www.wireshark.org/download.html

Java Decompiler(Java查看(和谐)工具):http://jd.benow.ca/

分析流程简要介绍

1.获取服务器信息

网上分析这个版本手机QQ的用户不在少数, 我也了解到这个版本比较容易分析, 协议简单, 所以...

首先, 打开这个网址:http://conf.3g.qq.com/newConf/kjava/aubin2.jsp

(注意使用unicode编码查看, 否则可能乱码) 然后你就会看到类似下面的东西:

SERERCONFIG_NUM=5& SERVERCONFIG_TYPE=KQQTCP,KQQTCP,KQQHTTP,KQQHTTP,KQQHTTP& SERVERCONFIG_URL=socket://58.60.12.177:14000,socket: //211.136.236.88:14000,http://tqq.tencent.com:8000,http: //mconn.tencent.com:14000,http: //kconn.tencent.com:21001&UPDATAECONFIG_NUM=1& UPDATECONFIG_VERSION=2.4.2&UPDATECONFIG_MUST=N& UPDATECONFIG_URL=http://mq.3g.qq.com/g/s?aid=mqq& UPDATECONFIG_HELPTXT=请升级到2.4.3版QQ2005(Java 版)&SMSSERVICE_NUM=2&SMSSERVICE_NAME=24小时在线,关注好友& SMSSERVICE_ADDRESS=10661700,1066170056& SMSSERVICE_TEXT=HQ,SQKJ%2c||QQNO||&SMSSERVICE_HELPTXT=不用手机上网,通过短信就能登陆QQ,累积在线时间真是方便,让你QQ等级不停增长!%0a当前操作需要通过短信操作完成,选择取定将发送一条短信,请根据收到的短信提示完成操作!, 关注此QQ好友,好友一上QQ马上就会有短信通知你手机!随时随地和TA在QQ上“偶遇”,资费10元/月。%0a当前操作需要通过短信操作完成,选择确定将发送一条短信,请根据收到的短信提示完成操作。

其中:

SERERCONFIG_NUM表示目前可以使用的服务器的个数 
        SERVERCONFIG_TYPE表示服务器类型:KQQTCP表示TCP服务器,KQQHTTP表示HTTP服务器 
        SERVERCONFIG_URL:服务器地址 
        ......(不重要)

注意:各值以逗号分隔; 键值对间使用&符号连接.

至于手机QQ要使用哪个服务器, 现在还不知道, 反正是其中一个, 过滤试一下就知道了.

2.过滤通信协议

先打开Wireshark进行网络封包过滤: 选择一张活动网卡, 然后start.

应该马上就可以看到,  wireshark已经显示了很多数据包... 数据太多, 不便查看, 于是过滤显示一下,

以QQ的第一个tcp服务器为例: 在Wireshark的Filter Expression里面输入过滤表达式, 并点击Apply应用:

用kEmulator运行手机QQ并登录:

接下来, 如果QQ使用了第一个服务器的话, 那么Wireshark将会显示以下信息:

没错, 你没有看错, 协议可以说全部是明文的, 完全就像是HTTP那样的...

比如VER=1.4代表版本号为1.4, CMD=Login表示命令为登录, UIN=***表示QQ...............

3.协议分析

好了, QQ和服务器的所有通信都是基于这种HTTP的键值对方式, 下面列出一些常见的键值对:

VER=1.4 表示当前使用的协议版本, 不过服务器返回的版本可能有所不一致
CON=1 这个不知道是什么意思, 通过查看QQ的代码可见其貌似是固定值1
CMD=*** 当前的命令, 有Login, Logout, Query_Stat2等等.
SEQ=*** 当前命令的序列号, 以此来标识不同的命令序号, 每下一次发送时, 在上一次的基础上加1
UIN=*** 当前登录的QQ号, 不变

命令的规定: 
                   每个命令以\r\n结束, 这就意味着命令字段中不能再出现其它的\r\n, 还有,要把\n换成%0D,\r换成%0D 
                   每条命令都使用UTF-8编码, 同时命令中出现的逗号,&等要转换url编码, 不然要误解释命令.

1.    登录命令: VER=1.4&CON=1&CMD=Login&SEQ={seq}&UIN={qq}&PS={ps}&M5=1&LG=0&LC={lc}&GD={gd}&CKE=\r\n 
       服务器响应:VER=1.1&CMD=Login&SEQ={seq}&UIN=2933278370&RES=0&RS=0&HI=60&LI=300&SG=***&SSG=207390864\r\n 
                   SEQ序号应该和你发送时一样, 不然就是错的. 
                   RES=0代表服务器成功响应 
                   RS=0代表登录成功,其它均为失败; 若失败:则有相应的RA字段标识错误信息, 比如Password Error!

如果有SID或者COMP字段, 记得保存起来, 因为后面的某些搞不懂的命令还要用它们. 其它的比如什么HI和LI就不知道是什么东西了. 
                  如果出现了VC字段, 则说明需要验证码信息, 我测试了很久, 一直没遇到, 暂时不说这个...

2.取得所有QQ好友及其基本信息 
            命令:VER=1.4&CON=1&CMD=SimpleInfo2&SEQ={seq}&UIN={qq}&SID={sid}&XP={xp}&UN=0&TO=0\r\n 
            回复:VER=1.1&CMD=SIMPLEINFO2&SEQ={seq}&&UIN={qq}&RES=0&NP=65535&SN=0&UN=&FC=&NK=\r\n 
                       XP是前面根据login命令计算出来的, 具体可以看我后面的代码. 
                      RES=0同样代表服务器正确响应. 
                      NP=65535表示当前返回了所有的好友信息, 如不是, 需要多次查询, 你应该没有那么多好友吧? 
                      SN表示当前返回的好友基础信息的个数, (注:我全没有写出来) 
                      UN表示好友QQ号, 以逗号分隔(我没列出) 
                      FC表示头像ID 
                      NK表示昵称, 以逗号分隔

3.取得好友状态 
             命令:VER=1.4&CON=1&CMD=Query_Stat2&SEQ={seq}&UIN={qq}&SID=&XP={xp}&CM=2&UN=0\r\n 
            回复:VER=1.1&CMD=QUERY_STAT2&SEQ={seq}&UIN={qq}&RES=0&FN=1&SN=2&ST=10,30&UN=..\r\n 
                        FN是不是finish的意思? 不知道. 
                        SN返回信息的个数 
                        ST状态:10-在线,20-离线,30-离开,40-隐身 
                        UN:QQ号, 与状态一一对应

4.发送消息给好友 
            命令:VER=1.4&CON=1&CMD=CLTMSG&SEQ={seq}&UIN={qq}&SID={sid]&XP={xp}&UN={qq2}&MG={mg}\r\n 
            回复:VER=1.1&CMD=CLTMSG&SEQ={seq}&UIN={qq}&RES=0 
                            UN代表好友的QQ 
                            MG表示消息, 必须是部分url编码的 
5. ............. 
还有几条命令, 比如加好友, 删除好友, 我就不写了 , 加上有些也没做测试.

4.模拟登录

1. 可以先用GET方式获取到服务器IP信息

GET  /newConf/kjava/aubin2.jsp HTTP/1.1 
Accept: text/html, application/xhtml+xml,*/* 
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/6.0) 
Accept-Encoding: utf8 
Host: conf.3g.qq.com 
Connection: Keep-Alive 
[blankline]

2. 然后建立socket并连接到服务器

3.向服务器发送命令

4.处理服务器返回

5...............

5.效果展示

3.完结

文章里面只是简要介绍了一些协议方面的东西, 细节处理, 以及完全的命令列表(我也不全知道)也没有完全列出来,若 
需要参考, 还请查看下面的源代码.

参考文章: 
                                 手机QQ协议分析 (一)登陆 
                                 HTTP/1.1 Request - w3school

未完结的源代码: http://pan.baidu.com/s/1c0iYYDa

作者:女孩不哭 
时间:2014年4月6日 
联系:QQ-191035066 
地址:http://www.cnblogs.com/memset

 
 

参考:

微信协议简单调研笔记

微信破解研究总结

Sync协议

  道听途说,加上上面参考中都是提到微信使用Sync协议。去年项目中做过参考Microsoft Exchange ActiveSync 协议来优化消息协议的方案,虽经过长时间讨论定稿,但由于一些原因最终没有实现;也从中深知Sync并不是表面上那么简单、那么好用。

  Sync 有啥问题呢?

  1. SyncKey 生成维护成本

    SyncKey 在ActiveSync中为字符串,客户端不需要解析,但服务端实现要用数字自增,需要强一致性,且不能回退。

  2. 消息的订阅模式 采用类似Zookeeper的One time triggler 还是每条消息都推送一条通知能

    One time trigger能够避免并发通知时,获取消息时重复问题,但增加了交互成本,和客户端实现复杂性。

  3. 自己发的消息,SyncKey怎么获取

    尤其要支持多端同步发消息,保证消息同步;也只好消息发完在给自己同步一遍(自己设备发的可以不带消息体)

  4. 消息推送延时加重

    Sync 消息体获取方式:Notify - Ack - get - Mssage, 也就是至少第四个应用包才能返回消息,在移动网络下成本很高。文中提到消息通过单独https请求,那么延时更为严重了(嗯,实测新版本并非如此)。

手机客户端不再Sync协议

抓包分析版本:Android 微信6.0, 抓包分析可参考:android 移动网络实时抓包

在wifi、gprs网络状况下都相同,客户端会依次尝试使用80、8080、443 端口连接服务器;消息发送、接收都使用长连接进行.

协议格式:

4byte Packet Len(包含4字节本身)

2byte Head Len(包含2字节本身) + 2byte Version(1) + 4byte Operation + 4byte SeqId + ….

(Packet Len - Head Len)  Body

协议交互方式:

- 客户端请求(一应一答,通过seqid匹配):

seqid = 1 开始,依次递增,服务器回复相同的seqid 作为应答

- 服务器推送通知(单向):

seqid = 0,Operation = 7a,  客户端不需要应答

主要业务:

-心跳包:

发起客户端请求,Operation = 0c,长度为16字节,算是最小的包

-发消息:

发起客户端请求,Operation = ed

  单点在线时发完消息后,应答携带SyncKey,不再同步,多点在线时,通过通知同步SyncKey,将随后文章分析。

-收消息:

1. 服务器推送消息, Operation = 7a,  Body 中携带消息内容

    抓包分析时,通过改变消息体大小,可能到接收方第一个包length 也会随之变化,可确认消息是push的。

2. 发起客户端单向请求,即消息的应答Ack

-加密:

未分析,一般来说像whatsapp那样,使用 hash(密码/OTP + 长连接第一个请求获取RandomCode) 做RC4 的密钥

总结:

现在版本的微信消息推送,并非Sync方式,而是推送+ack方式;

从他们协议设计来看,应该最开始用的是Notify + Sync Req + Sync Rsp 方式,因为协议上是不支持服务器发起请求的;

现在改成 Sync 消息+ 单向 Ack Req 的push方式,虽然协议上怪异, 相比Sync 消息接收会更加及时。从以前看到的文章都是说用的Sync协议,应该是是后期版本做了修改,push方式更为高效、而且通过顺序的SyncKey也能够修复丢失的消息。

下面一个通知包示例:

4 byte: 265 PacketLen

2 byte: 16   Head Length

2 byte: 1     Protocol Version

4 byte: 7a   Operation

4 byte: 0   SeqId 这是一个通知性消息

4 byte: unknow header

……. Body

Web客户端

  web微信客户端使用比较标准的Sync协议,Sync协议也比较适合web长轮询模型。

  移动客户端模式下,协议是二进制的而且有加密,很难分析;微信侧重手机端,web端主体协议应该保持与移动端一致,可通过web端推测整体协议实现,json也比较好分析。

  接收一条消息后SyncKey变化: 

  synckey:1_624161340|2_624162225|3_624162051|11_624161867|201_1420112604|1000_1420104656
  synckey:1_624161340|2_624162226|3_624162051|11_624161867|201_1420112631|1000_1420104656

  可以看出:

  - Synckey 有多个,应该是应对不同业务,其中2为为所有个人消息、讨论组消息,其他可能是联系人、朋友圈、订阅号等,201 为当前时间戳。

  - SyncKey 的值为数字自增,不是从0开始,应该有个固定的初始值。  

  - 发消息时,发完需要自己给再自己同步回一下SyncKey。

- 下面是一条消息增量同步结构,一堆要同步字段+是否修改FlagMask,同步协议变得很简洁。

{
"BaseResponse": {
"Ret": 0,
"ErrMsg": ""
}
,
"AddMsgCount": 1,
"AddMsgList": [{
"MsgId": 1625734358,
"FromUserName": "@sssss",
"ToUserName": "@ssssssss2",
"MsgType": 1,
"Content": "捶地笑……",
"Status": 3,
"ImgStatus": 1,
"CreateTime": 1420109883,
"VoiceLength": 0,
"PlayLength": 0,
"FileName": "",
"FileSize": "",
"MediaId": "",
"Url": "",
"AppMsgType": 0,
"StatusNotifyCode": 0,
"StatusNotifyUserName": "",
"RecommendInfo": {
"UserName": "",
"NickName": "",
"QQNum": 0,
"Province": "",
"City": "",
"Content": "",
"Signature": "",
"Alias": "",
"Scene": 0,
"VerifyFlag": 0,
"AttrStatus": 0,
"Sex": 0,
"Ticket": "",
"OpCode": 0
}
,
"ForwardFlag": 0,
"AppInfo": {
"AppID": "",
"Type": 0
}
,
"HasProductId": 0,
"Ticket": ""
}
],
"ModContactCount": 0,
"ModContactList": [],
"DelContactCount": 0,
"DelContactList": [],
"ModChatRoomMemberCount": 0,
"ModChatRoomMemberList": [],
"Profile": {
"BitFlag": 0,
"UserName": {
"Buff": ""
}
,
"NickName": {
"Buff": ""
}
,
"BindUin": 0,
"BindEmail": {
"Buff": ""
}
,
"BindMobile": {
"Buff": ""
}
,
"Status": 0,
"Sex": 0,
"PersonalCard": 0,
"Alias": "",
"HeadImgUpdateFlag": 0,
"HeadImgUrl": "",
"Signature": ""
}
,
"ContinueFlag": 0,
"SyncKey": {
"Count": 6,
"List": [{
"Key": 1,
"Val": 624161340
}
,{
"Key": 2,
"Val": 624162166
}
,{
"Key": 3,
"Val": 624162051
}
,{
"Key": 11,
"Val": 624161867
}
,{
"Key": 201,
"Val": 1420109883
}
,{
"Key": 1000,
"Val": 1420104656
}
]
}
,
"SKey": ""
}


最初,QQ通信协议并没有加密,而是直接采取明文的方式进行传输,到了后来才使用了加密传输,加密算法一直没有变过,使用的是blowfish算法,但是密钥的交换协议变得比较频繁。其实TX也是被逼的,现在的互联网用户比前几年更加注重隐私安全,这么大用户量的通信软件,如果用户与对方之间的聊天信息可以轻易的被第三方破译获取,那么用户量肯定会离开她,而去选择那些能够更加保护好个人隐私的人通信软件。因此,随着时间的推移和技术的发展,以前设计的协议可能会被研发者发现一些弱点,“图谋不轨”者加以利用,会对TX造成一些潜在的风险,他不得不对协议进行修改(QQ2011正式版中的密钥交换中对密码的MD5计算就加入了salt的概念,这个salt就是对应的QQ号码,后面会有详细的描叙)。

QQ协议首选的传输层是UDP,如果UDP不可登陆,那么会再尝试使用TCP进行传输。UDP使用的端口是8000,TCP使用的端口是443,应用协议基本一样,只是在通过TCP进行传输时,前两个字节为协议内容的长度(包括2个字节)。

QQ协议中每个通信内容都带有一个协议头部,如下图:

其中标识1一个字节,版本号、命令字和序号都是2个字节,QQ号码有4个字节,接下来是数据部分(已加密),最后是一个尾部标识1个字节。

在进行协议还原的时候,最关心的就是协议头部的命令字,需要根据不同的命令字,来进行相应的处理,最终获取密钥解密聊天内容。

QQ登陆协议密钥交换过程,首先我们使用Wireshark抓报文分析,观察主要用到的命令字(见上一篇Header部分的介绍)。

QQ2011登陆过程分析
命令字 含义
1、Touch Information(0×0091) 根服务器SAY HELLO,如果对该报文做一些小动作,可以让QQ认为,TX的服务器或网络不能访问…
2、Login Request(0x00ba) 未知,可以不进行处理。
3、Login Verify(0x00dd) 向服务器发送登陆请求,需要使用密码进行运算作为密钥才能机密该报文,解密的报文中包含对第4步的解密密钥。
4、Login get Information(0x00e5) 未知,但是服务器返回的报文你必须得知道,因为这个报文中包含解密会话密钥报文(第6步)的密钥。
5、Login verify E3(0x00e3) 未知,可以不进行处理。
6、Login send Information(0×0030) 客户端向服务器发送sessionKey,使用第4步获取的密钥进行解密。

1、Touch Information(0×0091)

这个报文无需关心,是客户端向服务器在SAY HELLO…

2、Login Request(0x00ba)

未知,在此处并不重要。

3、Login Verify(0x00dd)

非常重要!!获取会话密钥首先得解密该报文。但是要解密该报文,必须得知道该登陆QQ用户的密码,而用户密码只有用户和TX知道,第三方是不知道的(也有可能存在“不可思议”的第三方…)。数据传输过程中使用的加密算法是blowfish,这个算法目前从公开的资料上来说,还没有发现漏洞。因此,要实时获取用户的聊天信息,除非已经知道密码了,或者已经暴力破解了密码(这里简单介绍一下怎么进行暴力破解,这里的暴力破解,当然不是模拟一个QQ客户端不停的向TX服务器发送登陆请求,这样太慢了,而且TX那边也会有记录。首先,得分析出这个报文的密钥生成算法[不是简单的直接使用密码作为密钥],加密算法(这个已知,是blowfish),第二,需要将对方的登陆报文截取保存到文件,然后写一个程序,不停拼接字符串、数字、标点符号进行组合,根据第一步分析它密钥的生成方法生成出密钥,然后作为blowfish算法的密钥,去解密报文,如果解密成功,恭喜你,你暴力破解到了一个QQ密码。但是这种概率比较小,即使有一些,这些号码的价值不大,扯远了…)。

LoginVerify报文的解密密钥生成方法,在QQ2011版本之前,是MD5(MD5(PWD)),对QQ的密码做了两次MD5运算。但是QQ2011版本(包括2011版本)之后,这个算法做了一点修改,就是:MD5(MD5(PWD+QQ_NUM)),这个修改其实是非常有必要的,为什么呢?因为随着硬件技术的发展,以及前些年MD5彩虹表的推出,简单密码的MD5值非常容易就能从彩虹表中找出对应MD5值,从而得到原始字符串密码,即使TX做了两次的MD5运算。在彩虹表的推出或以前(因为我也不知道是在这以前还是以后,呵呵),在执行MD5运算时,就有了加SALT的说法,很形象!加盐,在这里,QQ_NUM就是盐,这样就加大了使用彩虹表破解的难度。

使用密码根据以上的算法得出解密密钥,解密Login Verify报文后,会得到一个新的密钥,这个密钥暂且就叫做verify_key。

Login Verify Reply(0x00dd)

服务器对客户端Login Verify报文的响应,这个报文需要verify_key作为密钥进行解密,得出一个新的密钥-verify_reply_key。

4、Login get information(0x00e5)

客户端接收到服务器的Login Verify Reply报文后,会使用verify_reply_key加密数据发送到服务器,而这里面又包含了一个key – get_info_key。

5、Login verify E3(0x00e3)

未知,此处可以不进行处理。

6、Login send Information(0×0030)

使用get_info_key解密该报文,得到会话KEY – session key。

回想一下:密码是关键,有了密码才能解密Login Verify(0x00dd)报文,解密了Login Verify(0x00dd),才能解密后续的的报文。其步骤是:passwd -> verify_key -> verify_reply_key -> get_info_key -> session_key。

前面两篇简单的介绍了QQ登陆协议密钥交换过程以及所使用的加密算法,知道了这两点,就可以对它的协议进行还原了。

QQDecrypt,通过winpcap抓包,实时对QQ聊天协议进行还原。

除了聊天协议之外,我们还可以对QQ相关的协议进行还原,包括但不限于:

1、QQ文件传输

2、QQ音频传输

3、QQ视频传输

4、QQ密码验证程序

5、QQ密码获取,是的,你没有看错,有一种主动的方法(用户登录时)就可以获得QQ的密码。在网络出口获取,而不是在客户端进行HOOK的方式获取。

协议分析TMP的更多相关文章

  1. Memcache的使用和协议分析详解

    Memcache的使用和协议分析详解 作者:heiyeluren博客:http://blog.csdn.NET/heiyeshuwu时间:2006-11-12关键字:PHP Memcache Linu ...

  2. MySQL协议分析2

    MySQL协议分析 议程 协议头 协议类型 网络协议相关函数 NET缓冲 VIO缓冲 MySQL API 协议头 ● 数据变成在网络里传输的数据,需要额外的在头部添加4 个字节的包头. . packe ...

  3. [转]Memcache的使用和协议分析详解

    Memcache是什么 Memcache是danga.com的一个项目,最早是为 LiveJournal 服务的,目前全世界不少人使用这个缓存项目来构建自己大负载的网站,来分担数据库的压力. 它可以应 ...

  4. Google的Protobuf协议分析

    protobuf和thrift类似,也是一个序列化的协议实现,简称PB(下文出现的PB代表protobuf). Github:https://github.com/google/protobuf 上图 ...

  5. 蓝牙协议分析(7)_BLE连接有关的技术分析

    转自:http://www.wowotech.net/bluetooth/ble_connection.html#comments 1. 前言 了解蓝牙的人都知道,在经典蓝牙中,保持连接(Connec ...

  6. 协议分析 - DHCP协议解码详解

    协议分析 - DHCP协议解码详解 [DHCP协议简介]         DHCP,全称是 Dynamic Host Configuration Protocol﹐中文名为动态主机配置协议,它的前身是 ...

  7. PYTHON黑帽编程1.5 使用WIRESHARK练习网络协议分析

    Python黑帽编程1.5  使用Wireshark练习网络协议分析 1.5.0.1  本系列教程说明 本系列教程,采用的大纲母本为<Understanding Network Hacks At ...

  8. Thrift的TCompactProtocol紧凑型二进制协议分析

    Thrift的紧凑型传输协议分析: 用一张图说明一下Thrift的TCompactProtocol中各个数据类型是怎么表示的. 报文格式编码: bool类型: 一个字节. 如果bool型的字段是结构体 ...

  9. BT协议分析(1)—1.0协议

    简述 BT下载是采用P2P的下载方式,下载的大致形式采用如下图所示,处于图示中心的称为Tracker服务器,其余称为Peer.   缺点 1.资源的安全性 2.资源的实效性(没有上传者则BT也将失效) ...

随机推荐

  1. Python Day11

    RabbitMQ队列 RabbitMQ是一个在AMQP基础上完整的,可复用的企业消息系统.他遵循Mozilla Public License开源协议. MQ全称为Message Queue, 消息队列 ...

  2. MySQL存储引擎--MyISAM与InnoDB区别

    InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型,这两个表类型各有优劣,视具体应用而定.基本的差别为:MyISAM类型不支持事务处理等高级处理,而InnoDB类型支持.MyISA ...

  3. php 生成word的三种方式

    原文地址 http://www.jb51.net/article/97253.htm 最近工作遇到关于生成word的问题 现在总结一下生成word的三种方法. btw:好像只要是标题带PHP的貌似点击 ...

  4. gevent

    gevent是一个基于协程的python网络库. 特性: 1.基于libev的事件循环 2.基于greenlet 轻量级的执行单元  (what is greenlet ?) 3.来自python标准 ...

  5. Sharp Memory LCD (ls013b7dh03)驱动

    网上找不到什么靠谱的资料,甚至我调好了夏普原厂和代理商还来找我要demo,  哎,苦逼的码农. lcd_main.c #include "ls013b7dh03.h" #inclu ...

  6. std::unique_lock<std::mutex> or std::lock_guard<std::mutex> C++11 区别

    http://stackoverflow.com/questions/20516773/stdunique-lockstdmutex-or-stdlock-guardstdmutex The diff ...

  7. 调用手机在线API获取手机号码归属地信息

    手机在线(www.showji.com)始创于2001年,发展至今已拥有国内最准确.号段容量最大的手机号码归属地数据库系统, 目前号段容量将近33万条,每月保持两次以上规模数据更新,合作伙伴包括:百度 ...

  8. windows命令

    开始--运行--cmd 进入命令提示符 输入netstat -ano 即可看到所有连接的PID 之后在任务管理器中找到这个PID所对应的程序如果任务管理器中没有PID这一项,可以在任务管理器中选&qu ...

  9. Toad各版本所包含的组件

    Toad for Oracle Base Edition Toad for Oracle Knowledge Xpert for PL/SQL Knowledge Xpert for Oracle A ...

  10. jQuery stop()用法

    jQuery stop()的用法: stop(true)等价于stop(true,false): 停止被选元素的所有加入队列的动画. stop(true,true):停止被选元素的所有加入队列的动画, ...