论怎么保护.net程序的数据库连接代码

[cn2719691]

看过很多.net程序，不管怎么扰乱，怎么调用c语言写的类库来加密，都可以通过反编译软件，直接调用程序的部分代码来获取数据库连接代码。大家有好的思路吗？

[cn2719691]

抛砖引玉 1，. net程序入口判断下参数数量，如果数量为0（直接启动）则提示由启动器启动，退出。 2，启动器由go语言编写（其它也可以，主要是对付反编译），数据库连接代码和. net程序的md5值保存在启动器里。 3，启动器运行时检查. net程序的md5值（判断是否被更改），符合要求时再以参数方式启动. net程序。

[cn2719691]

考虑过用windows消息传递，怕被hook，也考虑过用udp来传递，还是怕被抓包。目前没听说过通过参数启动程序会被获取的情况，请大家多多指教。

[ziqi0716]

架构上来解决啊 数据库访问权限放到服务端,服务端自己保存数据库信息.客户端仅能通过接口访问数据,数据库信息拿不到

[cn2719691]

引用 3 楼 ziqi0716的回复:

架构上来解决啊 数据库访问权限放到服务端,服务端自己保存数据库信息.客户端仅能通过接口访问数据,数据库信息拿不到

谢谢回复 写成3层倒是能解决，但是自己写的服务层肯定不如数据库ado.net连接成熟稳定，我之前写过类似的服务，结果在大数据的时候经常出现莫名其妙的错误，可能水平不够吧。不知道大虾有没有好的建议？

[三楼の郎]

引用 4 楼 cn2719691 的回复:

[quote=引用 3 楼 ziqi0716的回复:]架构上来解决啊 数据库访问权限放到服务端,服务端自己保存数据库信息.客户端仅能通过接口访问数据,数据库信息拿不到

谢谢回复 写成3层倒是能解决，但是自己写的服务层肯定不如数据库ado.net连接成熟稳定，我之前写过类似的服务，结果在大数据的时候经常出现莫名其妙的错误，可能水平不够吧。不知道大虾有没有好的建议？[/quote] Socket通信，数据库的1433、1521、3306这些端口干嘛使的，本质不仍旧是Socket通信吗。自己写个服务端程序扔服务器上用来接收客户端发送的SQL指令，服务端通过ADO.Net查数据库结果序列化后传回客户端，客户端再反序列化就好了，客户端与服务端之间加上登录验证，如果你这个软件带账户登录的可以结合到一起，这样客户端就只需要存服务端的IP和端口就OK了，剩下就是处理好链接超时和多线程的问题。 当然搞成B/S系统，或者服务端使用诸如WebAPI、WCF、WebService什么的都是可以实现

[三楼の郎]

若干年前曾经搞过一个服务端用来下发加密后的数据库连接字符串，客户端启动后先连服务端取得连接字符串，解密后直接连数据库，这种方式简单粗暴不过安全性比较差，而且通常情况下数据库服务器有白名单只能通过指定服务器访问，如果你的数据库没有这方面的限制也可以考虑一下，至少比直接把数据库登录账户存客户端强点

[极客诗人]

赞同#3， 生产库的端口基本是不对外暴露。 至于测试库，无所谓了~

[以专业开发人员为伍]

一个真正的 c/s 架构软件，你的重点应该是开发企业 server，通过自定义通讯方式来让 client 与 server 进行业务通讯。但是许多业余爱好者只学习了一点简单界面窗体与关系数据库的“增删改查”，也就是其实是单机软件开发，只是调用关系数据库的 c/s 驱动，而自己没有开发企业级 s 端系统。 这就好像只会一个毫无技术含量的“煮方便面”，如果想靠这个“技能”开一家饭店，怎么可能呢？

[以专业开发人员为伍]

引用 4 楼 cn2719691 的回复:

[quote=引用 3 楼 ziqi0716的回复:]架构上来解决啊 数据库访问权限放到服务端,服务端自己保存数据库信息.客户端仅能通过接口访问数据,数据库信息拿不到

谢谢回复 写成3层倒是能解决，但是自己写的服务层肯定不如数据库ado.net连接成熟稳定，我之前写过类似的服务，结果在大数据的时候经常出现莫名其妙的错误，可能水平不够吧。不知道大虾有没有好的建议？[/quote] 关系数据库驱动为什么要“自己写”呢？根本不需要。 这主要是你没有开饭店的所需要的厨房技术的心理准备，你认为厨师技术都不如“煮方便面更稳定”，所以你在找一个方便面圣杯。

[cn2719691]

不是所有应用都要搞得像互联网应用一样的，用途不同，没有高并发，没有效率的简单应用，主要是要快速开发，就1到2天时间，不会去考虑那么复杂的，也不会。

[兔子-顾问]

你可以尝试对连接字符串进行对称加密，保存文件，稍微增加破解难度，至少直接搜索不到连接字符串，每次连接字符串读取本地文件，或程序资源，执行解码获得明文再使用。