学好Windbg,基本上可以代替很多工具,这次分享一个查看Object Hook的脚本:
r @$t0 = 2; |
学好Windbg,基本上可以代替很多工具,这次分享一个查看Object Hook的脚本:
r @$t0 = 2; |
虽然微软强烈推荐用注册表代替ini来记录软件配置,但是由于写ini文件的方便性和可读性的优势,还是让很多程序员选择把配置记录到ini文件中。但是用Windows API操作ini文件有个缺点,就是每次调用如GetPrivateProfileInt,WritePrivateProfileString等函数,都会产生一次文件打开关闭以及读写操作,并且对ini文件重新解析,这是非常低效的。所以如果需要大量的操作ini文件,例如需要读取很多配置信息以启动软件,那么这样的用法无疑会增加软件的冷启动时间。为了解决这个问题,我们就需要自己写一个模块,他能够一次性读取并且解析好ini文件。在需要读取的时候直接从内存读取,需要些的时候先全部写到内存里,最后在刷新到文件上。所以我写了一个ParseIni的类,来完成这个工作。代码如下:
|
配置4G内存,并且使用过32bit Windows系统的人都知道,虽然自己有4G的物理内存,但是Windows还是明确的告诉你,它只会用其中的3GB多,还有几百MB物理内存是用不到的,即使你开启了PAE。当然如果你用的服务器系统,那就当我没说。至于微软为啥服务端32bit系统可以用4GB以上,而限制普通客户端系统,按照Windows Internals的说法,是为了考虑驱动程序的兼容性问题。我这里想介绍的是,如何使用这些没有使用的物理内存。
首先,要想使用这些内存,我们必须找到他们,但是找到他们之前,我们还得了解物理内存地址是怎么分配。物理内存地址除了要给RAM提供地址之外,还需要给设备内存提供地址。为了考虑驱动的兼容性,这些设备内存被分配到4G以内的地址上,这样一来,就会有部分RAM不得不分配到4G以外的地址上了,所以我们无法使用它们。
知道了这些,我们就需要聚焦到如何访问超过4GB内存的方法上了。不过方法也很简单,就是MmMapIoSpace函数,这个函数可以访问64bit的物理内存地址,并且将其映射到我们可以访问的虚拟内存上。
说到这里,程序的代码仿佛就呈现在脑海了,不过等等,还忽略了一个最困难的问题!到底有存在多少RAM内存在4GB以上的地址空间呢?说这个问题最为困难,是因为你需要根据不同的情况做出不同的选择。
1.主板支持通过Bios查询RAM内存分配情况,在这种情况下,我们可以调用中断来获得最真实的RAM分配表。
2.主板不支持通过Bios查询RAM内存分配情况,那么我们很无奈的必须采用一个简单粗暴的方法,Write & Test来获得4GB以外到底有多少RAM可用。
对于第二种情况,我们的做法是通过MmMapIoSpace函数,把4GB以上的物理地址逐一映射到虚拟内存中,然后写入特殊值,写入后马上读取,看是否写入成功,成功则证明RAM可用。
对于第一种情况,这里又要分为两个分支:
首先你的系统是NT6内核以下的情况,这时可以调用Ke386CallBios函数,调用中断接口。
而对于NT6的内核,我们需要调用新的x86BiosCall等一套函数。
需要调用的中断函数是0x15以及AX=E820,通过这个中断和功能号,我们就能获得SYSTEM MEMORY MAP
下面附带上这个功能的使用方法
INT 15 - newer BIOSes - GET SYSTEM MEMORY MAP |
获得了4GB内存以上的RAM范围以后,再加上MmMapIoSpace,我们就能够访问系统没有使用的内存了。
说了这么多,这个有什么具体应用呢?我见过最多利用这个特性做的产品就是内存盘了。也没看到什么用的特别好的其他应用的方面,我想原因主要有三点,第一,即使获得了物理内存,最后还是映射了4GB以内的虚拟内存上,内存操作终究无法访问直接更多物理内存;第二,这部分内存没有系统统一管理,同类型的软件无法共存;第三,有4G内存赶紧快去换个64位系统吧=v=。
14年的早些时候发布过SSD TRIM技术的文章,文章里面记录了关于TRIM技术的一些东西,其中就包括在Windows上如何使用TRIM。当然Windows 7及其更高版本的系统都是自带TRIM功能的,只有XP没有这个功能,当时我就写了个工具,在XP下进行TRIM。现在想想确实也没啥意思,就把代码分享说来吧。
Windows中有一种共享类型的服务,这种服务的特点是,他们可能同时有多个不同服务运行在同一个进程内。这些服务通常都是一些dll,他们被加载到宿主进程内运行,这个宿主进程我们见到最多的就是svchost了,如下图所示:
Windows这样做的好处就是尽可能的节约资源,当然不好地方就是,如果出了问题那么难以调试和定位。所以,为了更好的定位共享服务的工作线程,微软支持了一种叫做Service Tag的东西。Service Tag简单的说就是标注线程属于哪个服务的,这个是由Service Control Manager支持的。在TEB中有一个SubProcessTag字段,每当一个服务注册并且运行的时候,Service Control Manager会分配给服务线程一个id,这个id就是SubProcessTag,它能够唯一的表示服务,而且这个值是一直都被继承的,也就是说,如果服务线程再创建线程,那么新的线程的SubProcessTag也会被标记为父线程的id。当然,也有一种例外,那就是如果用了线程池,就不会继承SubProcessTag了。
在Advapi32.dll中有一个函数,叫做I_QueryTagInformation,这个函数可以根据SubProcessTag去查询Service的信息,有兴趣的同学可以看看下面的链接:http://wj32.org/wp/2010/03/30/howto-use-i_querytaginformation/
一转眼,一年又过去了,又到了总结过去的一年,计划新年的时候了。过去的一年里,最大的感觉是,好想经过了好多事情,但却没有经历什么事情。说起来挺绕的,慢慢来回忆下吧。
首先是工作上的事情,由于在前年整个部门被裁,去了一个价值观上和自己的很不同公司。事实证明,这确实不是什么好的决定,吐槽的事情就不细说了。之所以没换公司,是因为我觉得在北京待不了多久了,跳槽只会坑了其他的公司。所以也就勉强的继续干着。虽说是勉强的干活,但是工作的时间还是将近占用了每天的三分之二。工作的内容也没有什么创造性,基本上就是在可怕的代码里改来改去,当然了,也许这也是他这么可怕的原因吧。
多米乐骨效应,工作占用大量的时间,也导致我2014年的计划大打折扣。脚本编译器,写了一半听了下来,minikernel也没什么进展,唯一比较让人舒心的是,0CCh的山寨小工具,还是在慢慢的变多,其中还有花了大量精力写的everything_study,不过由于算法还没没达到目标效果(没有everything快,数据库也比他的大很多),所以没有放出来,也就是自己在用。确实也是因为工作的原因,没有太多时间和精力去改造文件id间相互索引的算法了。再说说健身,同样的理由,工作时间长影响身体和健身,现在25分钟基本上就跑个4.7km,13年的最后,都是能跑5km多点的。
不过东方不亮西方亮了,有失意的地方,总会在其他地方补回来=v=,生命中终于又多了一个人,能让我更加坚定的回老家了。所以,今年的计划特别难定,因为不知道回老家后到底是什么个情况。只能说回去之前继续坚持着,回去之后去找个心仪的事情。然后,编译器和minikernel希望能继续写,编译器希望能写玩,因为并不难。minikernel就比较复杂了,只能说能写多少写多少。另外我也特别喜欢山寨各种各样的小工具,自己造轮子自己用,赶紧挺开心的。健身方面,回去前照旧,回去后尽量保持。
其实生活上14年真的还算挺开心的,和sysdbg的博主一起还打完了好几个ps3的游戏。比如《神秘海域3》,《第一次世界大战——勇敢的心》等等=v=,还有他13年欠我的金钱豹还没请我吃呢…
最后,我还是希望2015年,我自己和家人、亲戚以及基友们,身体健康,阖家辛福快乐,工作顺利发大财!
Python干啥都挺方便的,出了调用win32的api。当然了,可以用pywin32这种库。但我不喜欢为了一两个api又给简单的东西加一堆依赖。比如获取文件版本,本来想在网上找个函数复制过去用得了,却发现还真没啥好用的。无奈自己就写了一个。
|
最近百度也推出的自己的公共DNS,现在可供我们选择使用的DNS也多了起来。但是每次更改DNS都输入IP,确实挺麻烦的。于是我周末在家就写了个切换DNS的小程序,绿色且易用,能在配置好的DNS直接切换,当然也能切换回自动获取DNS的模式。至于配置文件,可以手动修改,也可以通过程序来修改,都挺方便的。
配置文件格式如
[Google DNS]
dns1=8.8.8.8
dns2=8.8.4.4
[Open DNS]
dns1=208.67.222.222
dns2=208.67.220.220
…
下载:DNSSwitcher
今天无意中看到了HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU这个键值的用途,虽然感觉没啥实际用途,但是也挺有趣的,于是写了个小程序读取它。这个键值的意义非常明确,就是记录打开保存对话框的最近操作的文件的PIDL。所以我们可以通过PIDL来获得文件路径,就这么简单,确实没啥特别的实际用途吧,就当娱乐了。枚举的效果如下:
代码也很简单:
|