存档
解密加上引号，因为并不是真正的解密。 现在很多网站不让你看js源码，就想办法变形，最后再document.write出来。 显然不管它怎么变形，最后总要调用document.write，我们直接在document.write的实现处， 用native调试来下个断点，不就可以读出来了？ 找到document.write函数： C:\>syminfo /S E:\symbol C:\WINDOWS\ie7\mshtml.dll | grep ::write 7DDA72FB[+ 0] ?writeln@CDocument@@QAGJPAUtagSAFEARRAY@@@Z public:long __stdcall CDocument::writeln(struct tagSAFEARRAY *) 7DCE0741[+ 0] ?write@CDocument@@QAGJPAUtagSAFEARRAY@@@Z public:long __stdcall CDocument::write(struct tagSAFEARRAY *) 显然，直接在这两个函数下断点就可以了。 下完需要读一个VARIANT结构，里面是一个VT_I8的safearray，需要了解safearray的结构，就不赘述了。 因为还有更好的办法！ 用firebug直接看就是了。原来也不清楚，原来firebug看时，一个javascript段里调用了document.write之后，就会在dom树里紧跟着看到另一个<script></script>的段。所以，直接用firebug翻看就行了。真是简单啊。 翻看后可以找个工具把代码格式化一下。 有个软件叫sourceformatx，好像已经有四年没有更新了。找了一下crack的文章，说这个软件破解不好会直接破坏系统，因此没有人破解。由于四年过了，现在已经可以搜到完美破解版，但是不是真的完美呢？要是有一点不完美，系统就要挂了，怕怕。所以先不用了，要用也在vmware里用。 thank creese@newsmth.
看了看wrk的代码，发现一个函数会调用ZwCreateFile打开注册表的文件，这个函数就是CmpOpenHiveFiles 这个函数会打开两个注册表文件，master为不带后辍的，secondary为带后辍的。 system32\config\system和software就是这样被加载的。 查找过程，先找SAM，这个词不常见，grep一下找到一个配置表: HIVE_LIST_ENTRY CmpMachineHiveList[] = { { L"HARDWARE", L"MACHINE\\", NULL, HIVE_VOLATILE , 0 , NULL, FALSE, FALSE, FALSE}, { L"SECURITY", L"MACHINE\\", NULL, 0 , 0 , NULL, FALSE, FALSE, FALSE}, { L"SOFTWARE", L"MACHINE\\", NULL, 0 , 0 , NULL, FALSE, FALSE, FALSE}, { L"SYSTEM", L"MACHINE\\", NULL, 0 [...]
dbghelp有个功能，那就是MiniDumpWithUnloadedModules， 当os维护了已经unload的dll的列表时，它会在minidump文件中存入unloaded modules的信息。 只可惜的是，msdn中明说了，dbghelp 5.1并不支持这个标志。 看了一下winxpsp2自带的dbghelp.dll，恰好是这个版本的。 这一个标志是很重要的，因为某些BUG，经查恰好运行到一个非法的地址时Crash， 而这个非法的地址怎么看都像是原来有一个dll恰好加载在这里，但如今 这个dll已经被FreeLibrary了。如果有了这个unload modules的信息， 那么这个BUG就很容易找出来。如果没有的话，就麻烦了，因为程序代码 中都是com指针，虚表调来调处的根本不知道调用处正常情况应当调用的是哪个dll。 既然这个标志重要，自然应当把它启用，但winxp sp2恰恰不支持，如果为了这一个功能 就打包一个体积不小的dbghelp.dll的话，也划不来。 因此，想到一点： 何不自己把unloaded modules的信息，记载下来跟.dmp文件一起上报呢？ 如是开始研究，先写了一个很小的程序来实现产生minidump的功能，然后用ollydbg来调试， 看dbghelp.dll是如何拿到unloaded modules的信息的。 程序虽小，五脏俱全，代码如下： int Filter(_EXCEPTION_POINTERS * source, _EXCEPTION_POINTERS * dest) { *dest->ContextRecord = *source->ContextRecord; *dest->ExceptionRecord = *source->ExceptionRecord; return EXCEPTION_EXECUTE_HANDLER; } void Doxx(EXCEPTION_POINTERS * p) { HANDLE ho = CreateFile(L"oo.dmp", GENERIC_ALL, 0, NULL, CREATE_ALWAYS, 0, [...]
to mark activex control dlls as safety 其实也是老生常谈的问题了，很简单但是要用到的时候却不一定记得。无非就是实现一下IObjectSafety接口。 接口名字我今天就忘了，查了好几下才查到。 这个接口只有两个函数，实现可如下： STDMETHODIMP GetInterfaceSafetyOptions( REFIID riid, DWORD *pdwSupportedOptions, DWORD *pdwEnabledOptions ) { DWORD dwFlags = INTERFACESAFE_FOR_UNTRUSTED_CALLER|INTERFACESAFE_FOR_UNTRUSTED_DATA; if (pdwSupportedOptions) *pdwSupportedOptions = dwFlags; if (pdwEnabledOptions) *pdwEnabledOptions = dwFlags; return S_OK; } STDMETHODIMP SetInterfaceSafetyOptions(REFIID riid, DWORD dwOptionSetMask, DWORD dwEnabledOptions) { return S_OK; }
最近在调试一个小程序发现，windows UI会随机性的hang住，表现为所有窗口都很能动了，做任何操作都要等半天。 在一般的用户看来，这就是windows死机了，肯定会去按reset按钮。 但要是这样就reset的话，程序就没法调试了。咱不是一般用户，自然去看一下为什么UI会hang住。首先立刻就能想到，应该是所有当前桌面的进程里，有一个dll，它在进行同步操作，而被同步的那个进程呢，恰好就是被调试进程，所以同步就失败了。这时候就会死锁。但如果WaitForobject函数超时不是无限的话，到时候还能活一下。现在这个表现，正好符合这一点，因此wait函数肯定是有限超时的。 好，拿出万能的调试器ollydbg来查吧。首先，打开一个记事本，然后用deskswitcher创建一个desktop。然后开始调试，一直调到卡住时。还好deskswitcher的快捷键还是有反应的，切换到这个新的桌面上。然后就开始调试前面这个桌面的记事本。 为什么要调记事本呢，因为它最简单，最容易找到问题。 attach上调试器后，直接break下来，看callstack，最后翻到调用wait的地方： 在输入法的msctf.dll中有如下调用： push 1388h (dec=5000) push xxx call WaitForSingleObject 可以看到，msctf里waitforsingleobject(xxx,5000), 5000就是5000毫秒就是5秒，所以做任何一个动作之后，等5秒桌面又能活一小下。再次进入这个call又要5秒。把5000改回1,切回原桌面，发现这个记录本响应很快了。其它程序还是基本不能操作，更进一步证明：问题就在这里。msctf等待一个share的对象5秒时间，但这个share对象被某进程A占用了，而A恰好又处在调试中，被调试器中断了，因此不能释放这个对象。A不能释放，其它所有进程都在等。结果当前桌面就半死锁了。之所以说是半死锁是因为还有5秒超时，要是没有超时时间的话，就是真死锁了。 知道了原因，解决方案就有了，两个方案任取其一： 新建一个桌面，在此桌面上进行其于本机的远程调试。 patch msctf.dll，把5000改成1. 即把push 1388h改成push 1。不过，这个方案需要禁用windows file protection。而且下回msctf.dll被哪个升级包升级一下又要重新改。 方案1每次都麻烦，方案2呢每升级完一次麻烦一次。不过出现这样的死锁的情况不多，暂时就用方案1好点。关于desk switcher这个软件也是有东西可以写的，且听下回分解。
本文是最初发在qzone上的，不懂如何用wordpress导入qzone的文章，也懒得研究了，反正qzone上也不多，就直接人肉导吧。 找到虚拟机的.vmx文件，打开后在文件尾加入以下三行： mks.enable3d = TRUE svga.vramSize = 67108864 vmmouse.present = FALSE 开虚拟机，运行dxdiag，可以看到d3d已经被打开。
某域名注册商，以下用C代替，还是清华出来的人搞的，有两个问题很让我无语。 第一个问题，发出来的邮件，标题编码不对。 编码被配成了so-8859-1，注意是so-8859-1，不是iso-8859-1，那个i字不知被谁给弄没了。 当然，实际上配成iso-8859-1也是不对的。因为它实际的标题编码是gbk。 为什么不把那个so-8859-1换成gb2312或gbk呢，现在它发到我gmail里的邮件，标题全部是长长的=AA=BB这样的乱码，唉。 另一个问题是，早几个月我注册某域名的时候，还可以用腾讯财付通付费。付费过程还比较正常，付完费就不正常了，招行专业版付费成功之后，打开一个ie，里面居然是www.domain.com/xxx/yyy…，我把ie关了去C网站上看，发现钱没有转过来，而财付通这边已经扣了，气得我立马发了个意见过去大骂。不过骂也不顶用啊，那时是晚上，就算是白天我的意见也不会立即被人看到，还是自己先想想办法吧。想起前面这个奇怪的url，后面那一串跟C网页一般的路径特像，会不会是。。。 我立即翻了下IE的历史记录，把这个url找了出来，把www.domain.com换成C的主页网址，然后呢，把整个串往IE地址栏一贴，一按回车，立即就出来个C的页面，告诉我成功接到付款。再登录C一看，钱已经到了。omg，问题在这里！要么财付通，要么C没有把配置配好，一个本来要填C域名的地方，还是默认的www.domain.com，所以C收不到最后的通知，因此不知道收到钱了。那到底谁错了呢？想想C连个email标题编码都配不好，那九成是它的问题了。 问题清楚了之后，我又跑到网页上提反馈的地方，回复了一下我之前提的这一条，告诉他们，你们配置错了，要如何如何。 过了几天之后，C到是回了封信，说看了LOG付款过程正常，是不是我IE设置有问题blabla的，靠，要不是我发现了这个秘密，自己访问了一下新的url，这个付款过程能正常吗。还问我是不是有问题，典型的无技术客服对白痴用户的那一套，就不要套到我身上来了。 这一次又买域名，倒好，连财付通都给关了，显然是用财付通有很多用户遇到问题了，C不得不给关了。怎么不早按我说的改一改配置呢，猪头们。 上次之所以选择财付通不选支付宝，是因为后者太慢了。不是网速慢，是sb淘宝的技术问题。我今天又花时间分析了一把为什么淘宝慢。总算整出来了，且听下回分解吧。
去掉了起动session的功能。 为了一个验证码启动session，有点太牛刀杀鸡了。 在高性能的服务器上，为了能支持得起更多的用户，一般是不用session的。 用session的也就移动这样的老大，架起服务器来好像不要钱似的，可以拼命架，因此移动的网页上有session。 尽管我这个blog还没有人来光顾，起session也没啥了不起的，但还是改成不启动session吧。 呵呵，试了一下评论，还挺好玩的，鼠标到框里才加载图片。就像qzone一样。 不过体验比qzone还是差一点。qzone的那个图片验证码显示在输入框上面，且是浮出来的， 不像我这个鼠标一点输入框，大小就变了。以后再改。先这么放着了。