安全测试之探索windows游戏扫雷
作者:京东工业 宛煜昕
扫雷游戏相信很多人都从小玩过,在那个电脑游戏并不多的时代,扫雷成为玩的热度蛮高的一款游戏之一,然而就在有一次,接触到了一次不寻常的扫雷过程,使得后来我也有了这个冲动,也来做一次。通过动态调试,逆向和C来写一个扫雷辅助工具从而提高逆向与编码技能。
动态调试(分析)
首先进行扫雷程序的动态调试(分析):
打开OD(ollydebug工具),把扫雷拖放到OD中,F9运行;ctrl+G输入要跟随的表达式,输入rand,点击【确定】,跳转到该函数调用处,F2设置断点,此次是想通过API rand函数来找寻突破口。在扫雷窗口的雷区中任意点击一个位置(图片中出现2的位置),再点击还原(【笑脸】按钮-),如下图:
此时OD会在刚设置的rand处的断点断下来,如下图:
通过找到随机函数rand,下面进行栈回溯,回到上级函数中,来找到push(压入栈)的参数,也就是说随机生成函数(rand)是随机生成的高,宽,雷数。点击K(调用堆栈),弹出K调用堆栈窗口,查看堆栈窗口信息,找到返回地址,双击K调用堆栈窗口中的返回地址,返回到上一层,此过程称为栈回溯。仔细观察下图的堆栈信息010036D2(返回地址)。
单步F8,观察寄存器,数据窗口和堆栈窗口变化,dword ptr ss:[esp+0x4]或dword ptr ds:[XXX]数据窗口跟踪数值(000DFC44值是09),如下图:
返回到上层函数后,分析这里面的指令,得知刚才随机rand生成的宽(09),如下图,注意观察地址010036C7。
首先从这个函数返回的结果着手分析eax,单步后,可以看到往堆栈中(地址010036D2)压入了一个数字09,如下图:
通过以上分析,基本可以猜测得到周边的随机函数rand生成是高,雷数。可以试着改变扫雷设置(自定义雷区),如下图,来准确定位rand函数及传参,点击【确定】,再点击【还原(笑脸-)】按钮。
观察OD,如下图:
发现push 0C(000DFC84值为0C),可以确定这个rand函数push 0C就是雷区的高度。同时在内存区域也能明确看到一个大致的雷区图形,通过以上方法,大致可以猜测0x80就是雷。或者与IDA共同分析,通过静态分析,可以更直观的看到程序逻辑。得到如下数据:基地址,雷数等信息,如下图:
以上代码大概意思是先设置了全局宽0x09,高0x0C,雷数0x0A的变量,通过判断两层循环,随机生成了宽和高。得地图基地址:0x01005340。通过分析下图得知无雷是0x0F,有雷是0x8F,墙壁是0x10。
通过宽,高的地址,打印出扫雷区域和雷数,并可以更直观的区分边墙,雷。
下面开始要想如何标记雷了,通过假设WinProc(通过栈回溯到消息回调函数)中看到有关GetDC函数,大致猜测会用到Bitblt,在OD中ctrl+g输入要跟随的表达式,录入“BitBlt”,按F2设置断点,点击扫雷区域任意一个位置,OD会断在BitBlt位置。
在BitBlt中还有一个BitBlt函数,初步判断觉得是用双缓冲方式绘图,
BitBlt(hDestDC,//目的DC XDest, // 目的x坐标 YDest, // 目的y坐标 10, // 10, // 重绘区域的高和宽 hSrcDC, // 源DC 0, 0, SRCCOPY);// 指定操作方式计算雷的坐标(点击第一个扫雷的方块,查看坐标),需要注意边墙,如下图:
减去边墙的值:
-0x04=0x0C(12)-0x10(16)
0x27=0x37(55)-0x10(16)
得到坐标公式:x(XDest:12)=1*0x10(16)-0x04(4),y(YDest:55)=1*0x10(16)+0x27(39)。
代码编写
通过以上大致的分析,可进行代码的编写了,
成果
输入3landmine位置,获取出landmine(10墙壁,8Flandmine,0F无雷)
输入2自动扫雷,标记雷并开出地图
通过这个小项目,首先加强了对软件的一种逆向思维,如:看到这一种面板,大概猜到是用数组来实现的,其次雷的布局是随机生成的,然后通过动态调试可以了解实现方法(开发者的一种实现思路),可找到关键的基地址,几种状态(无雷,有雷,墙壁),最后编码阶段可以理解内存的操作,几个重要的API,FindWindow获取句柄,OpenProcess打开句柄,ReadProcessMemory读取内存信息,PostMessage异步消息模式,CloseHandle关闭句柄。其中有一些分析有误或不到位的地方还请拍砖。多逆向,分析代码有很多帮助,不仅可以拓宽自己编程与测试的思维及水平,还能发现,开发及利用程序中的漏洞或给程序打补丁等。希望小伙伴们在这条任重而道远的路上加油,互勉。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
京东金融Android瘦身探索与实践
作者:京东科技 冯建华 一、背景 随着业务不断迭代更新,App的大小也在快速增加,2019年~2022年期间一度超过了117M,期间我们也做了部分优化如图1红色部分所示,但在做优化的同时面临着新的增量代码,包体积一直持续上升。包体积直接或间接地影响着下载转化率、安装时间、磁盘空间等重要指标,所以投入精力发掘更深层次的安装包体积优化是十分必要的。根据谷歌商店的内部数据,APK体积每减少10M,平均可增加~1.5%的下载转化率,如图2所示: 图1 京东金融Android版本2019-2022体积变化过程 (红色部分是期间做的部分优化,但是很快就反弹回去了) 图2 谷歌商店应用转化率增加幅度 / 10M [1] 因此2022年9月开始我们针对金融APP进行了瘦身专项整治,在不考虑增量的情况,无删减业务代码的情况下实现从117M瘦身至74M,在本次安装包瘦身过程中我们遇到了不少坑,同时也积累了些经验,在此分享给大家。 二、APK分析 接下来我们会简单分析下 Apk内各组成部分,以及 Apk 作为 ZIP,其标准结构是什么样的,为包瘦身的目标设定及任务拆解提供数据支撑。 2.1 ...
- 下一篇
B站容量管理:游戏赛事等大型活动资源如何快速提升10+倍?
一分钟精华速览 当成千上万的服务器都处于低利用率时,就意味着巨额的浪费,良好的容量管理可以帮助消除某些“最后时刻”的临时应急式的盲目或者超量采购。除了成本合理控制方面,容量管理还要预估对客户可能产生影响的业务发展和风险变化。 B站在降本增效大背景下,从业务视角对整体容量做了可视化管理,本文详细描述了其容量管理的背景、思路及成效。 作者介绍 哔哩哔哩资深SRE专家 张鹤 TakinTalks社区专家团成员,2020年加入B站,先后负责主站/直播/OGV/推广搜相关的SRE工作。深度参与多活、活动保障、混沌工程、容量治理相关的建设,并主导容量管理平台、混沌平台的架构设计和落地。曾负责B站S赛、跨年晚会、拜年祭等相关活动的基础架构保障工作,目前主要负责推广搜业务的稳定性建设、PaaS治理。 温馨提醒:本文约4500字,预计花费9分钟阅读。 后台回复 “交流” 进入读者交流群;回复“2252”获取课件资料; 背景 对于B站来讲,我们最大的三个活动是S赛、拜年纪、B站跨年晚会。在用户增长的背后,SRE团队做了非常多的事情来保障业务连续性,比如多活、混沌工程等等。 今天换个角度聊聊——“容量管理”...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS关闭SELinux安全模块
- CentOS8安装Docker,最新的服务器搭配容器使用
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Windows10,CentOS7,CentOS8安装Nodejs环境
- 设置Eclipse缩进为4个空格,增强代码规范