Ⅰ 高手进 破译 局域网 sql Server密码
运行此类的命令可以使用：开始、运行；
里边输入SQLServerSniffer.exe
1433
c:\1.txt
前提你需要将SQLServerSniffer.exe
拷贝到SYSTEM32文件夹下，或者你的命令为：
X:\XXXX\SQLServerSniffer.exe
1433
c:\1.txt
_就是要加上相对路径
Ⅱ 请问局域网内怎么访问另一台服务器上的SQlserver数据库
1.是局域网环境不？是/否
2.收费软件通过什么方式访问数据库？配置还是软件写死了？
3.收费岗亭有无对数据库主机的访问权限？有/无
4.以上问题若都是第一个答案，在新机器上安装一个sql客户端后，那么只需要知道主机数据库的IP和端口，一般sql默认端口为1433，再开启远程访问服务即可。
Ⅲ SQL SERVER到底是如何实现数据共享在局域网中如何来实现资源共享
安装sql server客户端，每个人分配用户名密码就可以了，它的共享和windows共享不是一个概念，它就像个仓库，可以给读、写、改的权限。
Ⅳ 不制作证书是否能加密SQLSERVER与客户端之间传输的数据
Microsoft Network Monitor
这是微软提供的网络抓包工具
虽然它是微软提供的，但所有的协议parser解析代码全部都是开源的，采用其支持的特有脚本语言编写，易理解、易扩展；
它自带协议parser比较全面，同时有一个开源社区提供持续支持；
另外，它也提供API帮助我们开发自己的网络抓包、协议分析工具。
针对TDS协议解析需求：
Network Monitor自带TDS协议解析器和UI比较友好
Network Monitor自带TDS协议解析器在解析和结果展示方面更全面，以下是一个画面片段，显示了一个SQL Batch包。
先了解一下SQLSERVER的加密阶段
一共有两个阶段
在认证阶段，SQLSERVER会使用自生成的自签名证书，加密客户端发过来的登陆用户名和密码
在数据传输阶段，如果不使用证书，那么数据是使用明文在网络上进行传送的
大家可以看一下这篇文章：
SQL Server 连接加密 (1) -- SQL Server connection encyption
网上有很多制作证书的教程，但是制作证书都比较麻烦，客户端和服务器端都要弄很多东西。
详细制作证书的过程可以参考园子里的这篇文章：
在SQL Server 2005 中开启SSL(图文结合)
当然这篇文章不是讲解这个network monitor抓包工具的，所以轻轻带过就算了
那么，不制作证书怎么加密传输的数据啊？？？？
答案就是：同样使用在认证阶段的自生成的自签名证书
详细步骤：
步骤1：在SQLSERVER服务器端这边设置强行加密
步骤2：重启SQLSERVER，只有重启SQLSERVER设置才能生效
步骤3：打开network monitor，新建一个capture
步骤4：启动capture，开始捕获
步骤5：在客户端这边连上服务器端的SQLSERVER，然后你会在network monitor里的看到SSMS这个进程已经出现在Network Conversations窗口
步骤6：选中他，你会在Frame Summary窗口看到帧信息
步骤7：如果你在服务器端开启了“强行加密”，那么收到的数据包都会是加密的
大家在Protocol Name这一栏看到的是TLS协议，而不会是TDS协议
步骤8：查看帧数据
步骤9：如果没有加密的明文数据，network monitor就能够查看出来，并且Protocol Name这一栏显示的是TDS协议，因为数据包并没有使用TLS协议进行封装
TIPS：当关闭了SSMS的查询窗口之后，连接还是存在的
很多人会问，关闭了连接，怎么连接还存在，客户端为什么还会跟服务器端进行通信？？？？？
实际上，这个是客户端的连接池机制，客户端不断发送keep alive数据包给服务器，下次有同样的连接进行重用了，不需要再进行三次握手o(∩_∩)o
总结
本人介绍了不使用制作证书的方式来对传输的数据进行加密的方法，实际上设置客户端而不设置服务器端也是可以的
不过设置客户端比较麻烦，还需要在连接字符串里加上encrypt属性设置为Yes
设置服务器端和设置客户端的加密的区别
服务器端：所有的连接都是加密的
客户端：只是设置了加密的那个连接是加密的，其他没有设置加密的连接依然是明文传输数据
当然，使用SQLSERVER自生成的证书安全性是不及自己制作的证书的安全性高！！
相关连接：
加密与 SQL Server 的连接
使用自签名证书加密的 SSL 连接不提供强安全性。它们容易在传输中途受到攻击。在生产环境中或在连接到 Internet 的服务器上，不应依赖使用自签名证书的 SSL。
始终要对客户端应用程序与 SQL Server
连接时传输的凭据（在登录数据包中）进行加密。SQL Server
将使用可信证书颁发机构颁发的证书（如果可用）。如果未安装可信证书，则在启动实例时 SQL Server
将生成自签名证书，并使用自签名证书对凭据进行加密。自签名证书有助于提高安全性，但它不提供针对通过服务器进行的身份欺骗的保护。如果使用自签名证书，
并且 ForceEncryption 选项的值设置为“是”，则将使用自签名证书对通过网络在 SQL Server
和客户端应用程序之间传输的所有数据进行加密
Ⅳ sqlserver 2000 局域网连接问题
确定是否可以连接到sqlserver数据库.(可利用odbc等连接方式)
检查sqlserver的安全验证模式(混合验证或windows验证),如果用户使用sqlserver分配的用户名密码(例如sa),混合验证模式必须打开
Ⅵ 局域网连接不到数据库
可以通过本地机的数据提供者直接访问数据库，sqlserver 是提供了网络访问功能的dbms系统。无需重写winsock。
使用ado，在连接字符串中把服务器地址/用户名/密码写入就可以直接访问数据库了。
Provider=sqloledb;Data Source=[hostname];Initial Catalog=[dbname];User Id=[username];Password=[password];
更换服务器地址就需要重写连接字符串，不过可以把这类敏感信息加密到2进制文件中，在程序中动态调用。常见方法是使用配置文件的多服务器镜像，则更换服务器后可以从其他来源获得新服务器信息。
但是不推荐这种做法，打破了一般聊天程序的体系结构。之前你说的方法是一般分布式程序的常见做法，有很多现成方案可用，也无需从socket开始写。
Ⅶ 3.局域网中的 MSSQL 服务器在什么情况下能够被 SQL server Snifer 嗅探到
摘要 您好，您的问题我已经看到了，正在整理答案，请稍等一会儿哦~
Ⅷ 如何设置SQL SERVER才能保证只有局域网才能访问
1开始——>Microsoft
SQL
Server
2008——>配置工具—zd—>Sql
Server
配置专管理器——>
Sql
Server
网络配置——>MSSQServer协议属——>
禁用TCP/IP协议
2开始——>Microsoft
SQL
Server
2008——>配置工具——>Sql
Server
配置管理器——>
SQL
Native
Client
10.0
配置——>客户端协议——>禁用TCP/IP协议
Ⅸ winsock局域网间的连接问题，，，。。。。
问题应该是处在这
Winsock1.Connect
Command1.Enabled = False
Do
DoEvents
Loop Until Winsock1.State = sckConnected Or Winsock1.State = sckError
在你自己机器上连接的时候是不存在网络延迟的，所以基本跳过了连接后的循环，而到了你朋友机器上的时候变有了网络延迟，你的Do循环是非常占用CPU使用率的所以导致上面的Connect命令出现问题，也就是winsock的state永远不会达到条件。你可以将连接放入一个Timer控件里来解决这个问题，比如你设置timer每500毫秒执行一次连接（当然先判断Winsock是否是正在连接或已经断开连接）如果连接N次还没连接上那就是网络问题了，应该很少有网络延迟超过3000毫秒吧。
Dim Ci as Long
Private Sub Timer1_Timer()
On Error Resume Next
Ci = Ci + 1
If Form1.Winsock1.State <> 7 And Form1.Winsock1.State <> 6 Then
Form1.Winsock1.Close
Form1.Winsock1.Connect
ElseIf Form1.Winsock1.State = 7 Then
Ci = 0
Form1.Timer1.Enabled = False
MsgBox "连接成功"
Exit Sub
End If
If Ci = 6 Then
Ci = 0
Form1.Timer1.Enabled = False
MsgBox "连接服务器失败，请稍后重试", vbOKOnly, "提示"
End If
End Sub
以上原因纯属个人猜测，你试一试，如果不行告诉我，再一起研究一下
Ⅹ MsSQLServer是如何加密口令的
SQL SERVER的口令到数据库存储的加密方法，也是让人怪异的。其过程如下：
在获得网络解密密码的口令以后在
005F9D5A处call SQLSORT_14，实现一个转换为大写口令缓冲进行保存。
然后在004def6d处调用一个函数取出数据库中的加密的PASSWORD，其形式如下：
2个字节的头0x0100(固定）
4个字节的HASH加秘KEY
20个字节的HASH1
20个字节的HASH2
如我取出的一个例子：
fx:0x0100 1751857F
固定 补充KEY HASH1 HASH2
口令是：123456
SQL首先用4个字节的HASH加秘KEY补上其两处口令的缓冲，一个为大写，一个为小写。然后其加密过程如下C函数
CryptAcquireContextW(&hProv,NULL,L("Microsoft Base Cryptographic Provider v1.0"),1,0xf0000000);
CryptCreateHash(hProv,0x8004,NULL,NULL,&hhash);
CryptCreateHash(hProv,0x8004,NULL,NULL,&hHash);
005F9DFE：
CryptHashData(hhash,passwdbuf,0x12,NULL);passwdbuf是小写的passwd缓冲区,然后附加一个KEY，如上例子就是对
{'1','2''3''4''5''6',0x17,0x51,0x85,0x7F}这样的一个字串进行HASH加密
CryptHashData(hHash,PASSWDBUF,0x12,NULL);PASSWDBUF是大写的passwd缓冲区,然后附加一个KEY
005F9E3E：
CryptGetHashParam(hhash,2,&passwdout,&outlen,0);取出passwdbuf是小写的passwd的加密值
CryptGetHashParam(hHash,2,&PASSWDOUT,&OUTLEN,0);取出passwdbuf是大写的passwd的加密值
这两个相加就是真正的数据库中的PASSWORD加密字段
为什么说以上方法是脆弱的呢？其实其真正的加密长度生成只有20个字节。
小写口令的HASH1+大写口令的HASH1拼接的40位HASH值的安全度还不如一个直接20位的HASH值来得安全。因为大家都知道这两个值的因果关系，
提供给了解密者更多的信息。
如因为其算法一样，如果HASH1=HASH2，就可以判断口令肯定是未使用字母，只使用了数字和符号的口令，如上取出的123456口令的HASH，两个HASH完全相等。
就是使用了字母，其知道补充的KEY，算法，两个加密字串的关系，其解应该也是大大的简化了。
当然我没研究过加密算法，只是感觉上这种加密方式真是不安全，呵呵，希望解密算法的高手指点。