且行且远

Archive for the ‘逆向手札’ Category

分类: 逆向手札 由 ssfighter 于 2015年1月18日 发表

一直在Linux上只用Web版处理邮件,就是因为找不到太好的能支持Exchange的邮件客户端。在网上无意中发现了ExQuilla这个Thunderbird的插件,试用了一下还是不错的,很方便,不过只能免费试用60天,60天之后必须付费,价格是$10/年。

网上能找到的解决办法都是用老版本的Thunderbird,搭配老版本的ExQuilla,但版本都太老了点。

花了点时间看了下ExQuilla的注册验证算法,其实算法蛮简单。把exquilla_for_microsoft_exchange-31.0.1136-tb-windows.xpi文件解开, 注册验证相关的算法都在components里面的一个DLL文件exquilla-beta-i686.dll(linux下是一个同名的.so文件),注册码的结构是:

EX0,*@*,2015-03-19,80324c6d8724c3e4cd0111b51a5718ad

可以看到,注册码被用逗号分成了四个部分:

  1. 第一部分是注册类型,EX0是免费给的试用类型,我不知道EX1、EX2是什么情况,但试了下,EX1是可以用的
  2. 第二部分是邮件,*@*是免费给的60天试用的,这里要填有效的Exchange邮箱,可以在选项里Valid Emails里看到
  3. 第三部分是license过期日期。
  4. 第四部分是校验码,分别是前三个部分再加上
    356B4B5C算出来的MD5值。

例如,注册类型EX1、Exchange邮箱i@ssfighter.com,到期日期2015-01-18,可以计算出MD5值为:

MD5(EX1,i@ssfighter.com,2015-01-18,356B4B5C)=
5253dbb7d2b5a6e152974b2003025ba9

用计算出的MD5值作为注册码的最后一部分即可注册成功。


分类: 逆向手札 由 ssfighter 于 2014年9月12日 发表

gSyncit升级到4了,据说11月之后必须得用这个版本才能同步Google Calendar。看了下,其实注册算法没有变,以前的注册机依然可以用。变的只是注册表的路径,如果用以前的注册机的话,生成key.reg文件之后,把Regcode3改成Regcode4,然后再导入注册表就可以了。

当然,也可以下载最新的注册机。方法一样,生成key.reg之后导入注册表即可。
本地下载


分类: 逆向手札 由 ssfighter 于 2012年5月14日 发表

Mathtype 6.8的注册机,需要的下载吧。其实0day一周前就已经放出来Keygen了,这个已经很晚啦。

抱歉,不再提供注册机的下载

Enjoy it!


分类: 逆向手札 由 ssfighter 于 2011年9月13日 发表

昨天经人提醒才知道gSyncit已经升级到3.0版本了,注册算法小变,但改动很小,于是花了点时间做了这个注册机。由于目前自己已经不怎么用了,所以不知道gSyncit已经升级,不知道注册机出的晚不晚,估计网上已经有好些破解了吧。

下载地址:
本地下载 | Box.net


分类: 逆向手札 由 ssfighter 于 2011年4月14日 发表

最近在做RNDIS设备的开发,这方面的资料网上都比较少,周围也找不到人可以问,只好自己对着MSDN的文档硬啃,不过却在起跑线上栽了个大跟头,经过分析之后,基本确定是一个Windows RNDIS驱动的小bug,在此写下来以作记录,同时也希望能帮到遇到同样诡异问题的人。

现象:
我们的USB设备是复合设备,除RNDIS功能之外还有其他的功能,我用IAD来将RNDIS的两个Interface聚合,同时,RNDIS的两个Interface紧接在已有的Interface之后,其接口编号是02、03。在按照MSDN上的inf文件修改过之后,插入设备后可以正确地找到驱动,但安装完驱动之后立刻蓝屏重启,估计是驱动程序初始化时候出现的错误。

分析:
RNDIS的驱动分为两层,一个是rndismpx.sys,一个是usb8023x.sys,前者实现RNDIS协议栈的功能,后者实现USB-RNDIS的枚举、通信等功能。这是因为RNDIS设备本身是总线无关的,只是目前只有USB-RNDIS的功能,但驱动仍然是分层设计的。用WinDBG打开死机后DUMP出来的log文件,可以看到系统崩溃在以下位置:

eax=00000000 ebx=893461b8 ecx=870da99b edx=870da99b esi=870da958 edi=86dd3870
eip=a6c39216 esp=ba507684 ebp=ba507698 iopl=0         nv up ei pl zr na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246
usb8023x!SelectConfiguration+0x9a:
a6c39216 8a4805          mov     cl,byte ptr [eax+5]        ds:0023:00000005=??
Resetting default scope

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x7E

LAST_CONTROL_TRANSFER:  from a6c39472 to a6c39216

STACK_TEXT:
ba507698 a6c39472 00000000 86dd3870 00000000 usb8023x!SelectConfiguration+0x9a
ba5076b0 a6c39aad 86dd3870 896c8de4 86d57738 usb8023x!InitUSB+0x32
ba5076c4 ba3e115b 86e22ecc 86e22efc 86e22cf8 usb8023x!RndisInitializeHandler+0x2d
ba507724 b9dd4dea ba507760 ba507768 b9dd0200 RNDISMPX!RndismpInitialize+0x2eb
ba5078dc b9dd49cc 8a0d9d88 ba507900 ba5079a8 NDIS!ndisMInitializeAdapter+0x3b7
ba5079b0 b9dd48ba 8a0d9d88 00000000 896dc648 NDIS!ndisInitializeAdapter+0xb9
ba5079e4 b9dd5daf 86ddb698 86ddb7bc 86ddb698 NDIS!ndisPnPStartDevice+0xd6
ba507a14 ba3e5ed6 86d57638 86ddb698 86ddb7e0 NDIS!ndisPnPDispatch+0x306
ba507a30 804ef19f 86d57638 00000000 ba507aac RNDISMPX!PnPDispatch+0x4c

可以看到,是在USB初始化检查配置描述符的时候出错的,于是赶紧检查自己的USB配置描述符,并未发现问题,只好用IDA打开usb8023x.sys,进行逆向分析,定位在系统崩溃的位置:

.text:00011210 call ds:__imp__USBD_ParseConfigurationDescriptor@12 ; USBD_ParseConfigurationDescriptor(x,x,x)
.text:00011216 mov cl, [eax+5] ; 系统崩溃处!
.text:00011216 ; 返回值eax为零,造成内存访问错误,导致系统崩溃。

可以发现,usb8023x.sys在调用完解析配置描述符的函数之后,并没有判断是否解析成功。查询WDK文档可知,USBD_ParseConfigurationDescriptor的返回值是一个指针,指向要查询的接口描述符的首字节。如果找不到该接口的编号,则返回NULL。在这里,驱动没有找到我们的接口描述符,又没有进行失败检验,因此造成了内存访问错误,系统崩溃。可是我的接口描述符明明是有的啊,继续往上看:

.text:000111FA and [ebp+arg_0], 0 ; Interface number从0开始
.text:000111FE add ebx, 18h
.text:00011201 cmp byte ptr [esi+4], 0 ; 有几个Interface?
.text:00011205 mov [ebp+var_8], ebx
.text:00011208 jbe short loc_11233
.text:0001120A
.text:0001120A loc_1120A: ; CODE XREF: SelectConfiguration(x)+B5j
.text:0001120A push 0 ; AlternateSetting
.text:0001120C push [ebp+arg_0] ; Interface number
.text:0001120F push esi ; Configuration Descriptors
.text:00011210 call ds:__imp__USBD_ParseConfigurationDescriptor@12 ; USBD_ParseConfigurationDescriptor(x,x,x)
.text:00011216 mov cl, [eax+5] ; 系统崩溃处!
.text:00011216 ; 返回值eax为零,造成内存访问错误,导致系统崩溃。

可以知道,esi=870da958处保存着配置描述符。[ebp+arg_0]是接口的编号,usb8023x.sys将从接口0开始查找,可是我的RNDIS设备是接口2、3开始的,在WinDBG中看看esi处的数据:

0: kd> db 870da958
870da958  09 02 43 00 02 01 04 c0-00 09 04 02 00 01 02 02  ..C.............
870da968  ff 00 05 24 00 20 01 05-24 01 00 01 04 24 02 00  ...$. ..$....$..
870da978  05 24 06 02 03 07 05 83-03 08 00 01 09 04 03 00  .$..............
870da988  02 0a 00 00 00 07 05 84-02 40 00 00 07 05 04 02  .........@......
870da998  40 00 00 00 00 00 00 00-0a 00 05 0a 46 53 66 6d  @...........FSfm

其中前9个字节的配置描述符并不是从我的设备上传上来的,应该是Windows驱动在对复合设备进行描述符分析的时候自动生成的,可是后面的具体的接口、CDC、端点描述符确是直接memcpy过来的,而usb8023x.sys首先从接口0开始解析,然而接口0是不存在的,自然造成系统的崩溃。

解决:
这个问题主要是usb8023x.sys认定RNDIS的接口必须从0开始,而且驱动没有进行函数返回值的判断,造成的系统崩溃。解决方法也很简单,只需要把自己的设备的RNDIS的接口放到最前面即可。当然,如果USB设备不是复合设备,只有RNDIS一个功能,那么这些问题应该都不会遇到。

转载请注明出处,谢谢。