现在的位置: 首页 > 综合 > 正文

猜sql server密码用sqlconnection的话cpu100%,内存只升不降。最后直接用odbc api解决。

2013年01月14日 ⁄ 综合 ⁄ 共 1820字 ⁄ 字号 评论关闭

猜sql server密码干什么。玩过黑克得都知道。

用c#做个猜sql server密码的程序,听起来挺简单吧。

sqlconnection类,构造连接字符串,然后try open()方法,如果没有catch到异常正常open了,那么说明密码猜对了,如果open有异常,那么如果是异常的number是10060/10061,那么连接不上,如果是18452则是不允许连接,如果是18456则是密码错误是吧,很简单吧。

 

但是事实却并没有这么美好。这样猜密码造成的结果就是cpu占用率100%,内存占用直线上升,甚至卡死机器。

 

这位说了,sqlconnection用完了close或者dispose了吗。

全加上了,一样。即使using(sqlconnection……)这种也一样。

而且肯定不是程序逻辑问题造成的,我尽量弄成最简单的几行了,我特意连递归都没用,直接本线程完了启动另一线程代替递归。

 

看着这样的程序应该是挺小的一个小玩意吧,偏偏他就这么大,内存呼呼的只升不降,真是百思不得其解

 

我用vs2010带的那个性能分析工具看了一下

cpu占用率高全都被sqlconnection.open()这句占了,内存也是因为这个,难道因为连接池还是什么?怎么关呢?

 

没办法,sqlconnection是不能用了,我想用system.data.odbcconnection吧,一样!!!

========================================

怎么办呢,要想不卡内存少,直接用tcpclient发送数据模拟sqlserver登录最好,但是我sniffer了一下,sql server连接好像那都是加密的是吧。

 

再就是直接用sql server驱动的api,看了一下是sqlsrv32.dll,不会用啊,还有一种是odbc32.dll里面的api也挺麻烦啊。

========================================

最后找了一个折中的办法,用ado

在vs里添加com引用Microsoft ActiveX Data Objects 2.0 Library,ado有好几个版本,选一个最低的吧,越低应该越快吧,反正就open一下就完了。

 

然后sqlconnection那里改成adodb.connection,是个接口而不是类,ado里没有类。

构造连接字符串多了一句。driver={SQL Server};

就是用sql server的驱动了

然后继续猜密码。

cpu占用依然很高,基本固定在70/80%左右,但是比sqlconnection那100%还是强多了,起码机器还能动嘛。

好处是内存,用ado,整个程序内存基本在30兆不动,而且open了我都不close,峰值才33兆,这比sqlconnection那动辄上到500、600百兆强老了,主要是看sqlconnection那内存哗哗的只升不降看着揪心啊。

========================================

用ado猜到密码后,下面就可以用sqlclinent命名空间的类去执行一些东西了

 

 

 

疑问:sqlconnection为什么只升不降?我对数据库非常不熟,听说有个连接池,听说即使close或者disopse也不会析构,而是放到连接池中等待再次连接,只有多了才会析构是吧。用sqlconnection的时候比如程序到了500兆了,突然一下子就降到200兆(疑似gc了),然后又哗哗的升了,是不是就是这么造成的呢。

 ==========================

 

下午找到了一个终极解决办法,用odbc32.dll的SQLDriverConnect这个api,这应该是除了直接用socket模拟sql server登录和直接用sql server驱动外,最高效的办法了。果然,cpu占用率比用ado又小了,内存占用也小了,只有20来兆了。但是用完了得用sqlfree**的api释放内存,不然内存也是只升不降。

 

但是奇怪的是,它返回的native error number,如果密码错误,是18456是一样的,但是如果“服务不能存在或被拒绝”这种本来应该返回10060或者10061的,但是sqlerror api却返回的是17,这个17号错误查询sql server文档的错误和事件参考(数据库引擎) > 数据库引擎错事件和错误 > 系统错误消息 > ,并没有这一号错误啊。

抱歉!评论已关闭.