BlogJava-<b>www.nangeblog.com</b> -随笔分类-项目经验http://www.blogjava.net/magicdoom/category/22015.html<h1>一斛酒 品人生沉浮 平常心 造万千世界 人生天地之间 若白驹之过隙 忽然而已</h1>zh-cnTue, 18 Mar 2008 11:27:43 GMTTue, 18 Mar 2008 11:27:43 GMT60逆向某半脆弱水印的dll接口成功http://www.blogjava.net/magicdoom/archive/2008/03/18/187061.html南哥南哥Tue, 18 Mar 2008 10:49:00 GMThttp://www.blogjava.net/magicdoom/archive/2008/03/18/187061.htmlhttp://www.blogjava.net/magicdoom/comments/187061.htmlhttp://www.blogjava.net/magicdoom/archive/2008/03/18/187061.html#Feedback0http://www.blogjava.net/magicdoom/comments/commentRss/187061.htmlhttp://www.blogjava.net/magicdoom/services/trackbacks/187061.html最近偶然得到某公司的水印的DLL，但是没有接口文档。里面的导出函数也不清楚。
好久没搞逆向了，正好拿来练练手。
先用ViewDLL这个小工具，查看DLL的导出函数，但是只能看到函数名，里面的参数和类型都不清楚。
但是这个DLL有点特殊，花了点功夫才搞明白，原来并没有导出函数名称，而是通过函数的序号来调用的。
然后祭出IDA反汇编了这个DLL，可以初步得到导出函数的原型。IDA得到的参数个数和顺序是对的，但是参数的类型确不一定正确，有不少指针类型的都被识别为int的。
该DLL自带了一个DEMO，通过OD来动态跟踪相关的值，得到大部分的参数类型。
然后vc写了小程序进行测试，经过多次的调试，并进行了一定的猜想，最终获取完整的API。


南哥 2008-03-18 18:49 发表评论
]]>数据执行保护引起的一个怪问题http://www.blogjava.net/magicdoom/archive/2007/07/28/132961.html南哥南哥Sat, 28 Jul 2007 04:21:00 GMThttp://www.blogjava.net/magicdoom/archive/2007/07/28/132961.htmlhttp://www.blogjava.net/magicdoom/comments/132961.htmlhttp://www.blogjava.net/magicdoom/archive/2007/07/28/132961.html#Feedback0http://www.blogjava.net/magicdoom/comments/commentRss/132961.htmlhttp://www.blogjava.net/magicdoom/services/trackbacks/132961.html
 查了下OCR SDK的开发手册，手册中到是提到了这个问题，给出的解决方案是把DLL和exe都放在同一个目录下，二我当前就是这么做的。奇怪的，再测copy了DLL测试DLL本身并无损坏。把DLL都copy到system32下面也一样无济于事。把当然的路径加到系统的path里面，也无效。怪事了，某非设置path要重启之后才能生效。还好现在是下班时间，把服务器重新启动了下。

重启之后立刻弹出N个对话框，ocr.exe因为遇到问题被系统数据执行保护关闭。TNN的原来是数据保护惹的祸。到数据保护里设置为只为系统进程和服务启用，再次重启果然解决问题了。这让我想起以前在安装一些InstallAnywhere打包的程序时也会遇到问题就好似数据执行保护引起的。

把程序开起来进行识别，确发现识别数量一多就会报某某内存地址不能read的错误。kao，真是一bug刚灭一bug又起啊。调了半天也没有结果，算了先回去睡觉，明天再解决。
  第二天，也就是今天 呵呵，在msn向一个同事（VB高手）请教，他也说可能是数据执行保护的问题。我又查看了下程序的日志，突然来了灵感，发现出错的有规律，有的错误是在识别同一份文件时发生的，查了下原来这份图片是png格式的，测试了下果然是png不能识别。问题解决，特写本篇blog记录下。


南哥 2007-07-28 12:21 发表评论
]]>一只‘大虫’终于被抓出来了http://www.blogjava.net/magicdoom/archive/2007/04/26/113934.html南哥南哥Thu, 26 Apr 2007 14:19:00 GMThttp://www.blogjava.net/magicdoom/archive/2007/04/26/113934.htmlhttp://www.blogjava.net/magicdoom/comments/113934.htmlhttp://www.blogjava.net/magicdoom/archive/2007/04/26/113934.html#Feedback4http://www.blogjava.net/magicdoom/comments/commentRss/113934.htmlhttp://www.blogjava.net/magicdoom/services/trackbacks/113934.html
这套系统在该地方刚上线没多久，有用户反应有不少条码提示无流水匹配。我在排除了条码方面的原因后，到后台的数据库中查看，在业务主表中存在相关记录，图像记录的最终存储表中没有记录表示图像没有发布，排除了重复扫描图像的可能性。但是在流水信息表中却找不到该条码对应的流水信息，这个就奇怪了。正常情况是应该存在有对应的流水信息才对，因为因为主表中已经存在相关的记录了。流水删除也是在正常发布后才会进行的。

仔细分析下，有可能的原因有两个，一是外部系统调用接口保存时出错。另外就是程序什么地方出差把流水记录删除了。 仔细检查了下保存接口的代码，发先保存操作是放在同一个事务里操作的，所以不大可能。那么分析下日志看看是不是什么地方误删除了，因为删除更新操作在日志中都有记录。分析日志时又遇上了麻烦，日志文件好多个，每个都几M的，日志中还混杂了正常的删除操作，要靠肉眼查找，岂不麻烦死了。想用正则表达式，但是好像很难写出来。就编个小程序来解决了，操起VC6.0写了小程序分析结果居然都是正常的删除操作。

从逻辑上来考虑，这种情况是不大可能出现的了，和几个同事交流后也是无果。有同事提起以前遇到过更怪的，每天阳光射进来的时候系统就会死机，结果最后原因居然是服务器太烂，阳光照上去散热不好而死机，听起来像个笑话。

被这个问题困扰了好久，发生的时间和数据好像都没什么规律。真不知道从何下手了。
偶尔一天，查看系统的参数配置表时，发现问题所在了，原来b/s程序的后台居然有个自动清理的线程，这个线程会删除过7天没匹配的流水数据。我晕啊，居然是这鸟原因，害的搞了好多天，绞尽了脑汁，我靠我靠。



南哥 2007-04-26 22:19 发表评论
]]>系统调优一则http://www.blogjava.net/magicdoom/archive/2007/04/04/113486.html南哥南哥Wed, 04 Apr 2007 15:11:00 GMThttp://www.blogjava.net/magicdoom/archive/2007/04/04/113486.htmlhttp://www.blogjava.net/magicdoom/comments/113486.htmlhttp://www.blogjava.net/magicdoom/archive/2007/04/04/113486.html#Feedback1http://www.blogjava.net/magicdoom/comments/commentRss/113486.htmlhttp://www.blogjava.net/magicdoom/services/trackbacks/113486.html分析原因，根据客户的实际情况，首先排除了并发量过大的问题，其次因为图像的文件并不大，平均一页也才几十K左右，又是在内外的环境下，所以排除网络的因素。
再者考虑上线一年会不会是磁盘上存储了大量的小文件导致磁盘碎片很多，远程连接上文件服务器查看一下，磁盘碎片并不多，这个原因也被排除了。
其他会是什么方面的原因呢，想了会，突然想到会不会是数据库的问题，一查浏览图像前会执行两条sql语句，把两条sql语句单独拿出来执行，果然是这个原因。一查表的记录数已经有78万条记录了，查查对应字段的索引，晕，居然这这张表的字段都没建索引，难怪会慢了。将两个查询次数最多的字段加上索引，果然速度回复到正常的水平。看来以后对数据库的索引也要重视起来。
文章来源:http://magicdoom.blogspot.com/2007/04/blog-post.html

南哥 2007-04-04 23:11 发表评论
]]>