或
使用UltraEdit等二进制编辑工具打开数据库文件，通过查找“DBA”（二进制使用“44 42 41”），定位到底一个位置，注意观察这个区域，前面一般有“dbo”、“PUBLIC”，后面有“SYS”。这个区域就是ASA保存用户口令的数据段。把“SYS”之前四个空字符“00 00 00 00”之前到“44 42 21”之间的所有二进制数据，改为如下二进制数（代表SQL):
24 36 3BDF 7D B5 77 B2
82 45 67 6D C2 DB D6 E7 F2 64 28 C3 55 22 97 F5
6C F5 8C 0F 8C C5 71 BA 15 C9 5E BC 43 01 59 01
59 01 59 01 4E 01 4E 01 4E 17 00 00
改好后，保存数据库，DBA密码就是“SQL”了。当然还可以先建立一个测试数据库TEST,输好自已 DBA密码后，按以上方法查找到密码区，把密码值写入到要更改的数据库文相关区，即可随意更改成自已想要的密码了.以上方法 ASA5,ASA7通过
针对sqlite数据库文件，进行加密。现有两种方案如下:1.对数据库中的数据进行加密。
2.对数据库文件进行加密
1.uin怎么获取？
这个uin不是登录的帐号，而是属于内部的、程序界面上不可见的一个编号。
至于查看，最简单的方法就是登录web微信后，按F12打开网页调试工具，然后ctrl+F搜索“uin”，可以找到一串长长的URL，里面的uin就是当前登录的微信的uin。
还
有一种方法就是配置文件里，导出的微信目录下有几个cfg文件，这几个文件里有保存，不过是java的hashmap，怎么解析留给小伙伴们自己琢磨吧，
还有就是有朋友反应退出微信（后台运行不叫退出）或者注销微信后会清空这些配置信息，所以小伙伴们导出的时候记得在微信登陆状态下导出。博主自己鼓捣了一
个小程序来完成解析。
2.一个手机多个登录帐号怎么办（没有uin怎么办）
根
据博主那个解密的帖子，必须知道串号和uin。串号好说，配置中一般都有可以搞到，uin从配置中读取出来的时候只有当前登录的或者最后登录的，其他的几
个记录都没办法解密。网上某软件的解决方法是让用户一个一个登录后再导出。这个解决方法在某些情况下是不可能的，或者有时候根本不知道uin。
后来经过一个朋友的指点，博主终于发现了解决方法，可以从配置中秒读出来这个uin，这个方法暂时不透漏了，只是说明下这个异常情况。
3.串号和uin怎么都正确的怎么还是没办法解密
先
说说串号这个玩意，几个热心的朋友反馈了这个问题，经过博主测试发现不同的手机使用的不一定是IMEI，也可能是IMSI等等，而且串号也不一定是标准的
15位，可能是各种奇葩，比如输入*#06#出来的是一个，但是在微信程序里用的却是另一个非常奇葩的东西，这种情况多在双卡双待和山寨机中出现，经过严
格的测试，现在已经能做到精确识别，那几位热心的朋友也赠与了不同的代码表示鼓励。
4.计算出来了正确的key为什么无法打开数据库文件
微
信这个变态用的不是标准的sqlite数据库，那个帖子也提到了不是数据库加密，是文件的内容加密，其实是sqlcipher。官方上竟然还卖到
149$，不过倒是开放了源码，水平够高的可以自己尝试编译。google还能搜索到sqlcipher for
windows这个很好编译，不过博主不知是长相问题还是人品问题，编译出来的无法打开微信的数据库，后来改了这份代码才完成。
5.数据库文件内容是加密的，怎么还原
这
个是某些特殊情况下用到的，比如聊天记录删除了数据库中就没了，但是某个网友测试说数据库无法查询出来了，但是在文件中还是有残留的。这个情况我没测试
过，不过想想感觉有这个可能，就跟硬盘上删除了文件其实就是删除了文件的硬盘索引，内容还是残留在硬盘上可以还原一样，sqlite数据库删除的条目只是
抹去了索引，内容还存在这个文件中。
网上的都是直接打开读取，并没有解密还原这个文件成普通的sqlite数据库，使用sqlcipher
的导出方法也只是将可查询的内容导出。后来博主花了时间通读了内容加密的方式，做了一个小程序将加密的文件内容直接解密，不 *** 作修改任何数据，非数据库转
换，直接数据流解密，完全还原出来了原始的未加密的数据库文件，大小不变，无内容损失，可以直接用sqlite admin等工具直接打开。
6.已经删除的聊天内容可以恢复么
通过上述第5的方式还原出原数据后，经测试可以恢复。sqlite的删除并不会从文件中彻底删掉，而是抹掉索引，所以可以通过扫描原始文件恢复。前提是没有重装过微信。。。
两种加密方式的优缺点，比较如下：
一、对数据库中的数据进行加密
优点：
1.实现数据加密快速，只需添加两个方法
一是：对明文数据进行加密返回密文数据
二是：对密文数据进行解密返回明文数据
2.程序无需进行太大变动，仅在对数据进行添加，修改，删除，查询时。针对指定的表字段进行修改进行加密，解密的字段即可。
不足：
1.由于对数据进行了加密。所以为了看到明文，必须密文进行解密。因此会增加处理器的消耗。因终端手机的处理能力有限，可能会出现处理数据缓慢的现象发生。
2.仅仅对数据进行了加密，还是可以看到数据表的sql语句，可能猜测到表的作用。另外，如果没有对一个表中的所有字段加密，则可以看没有加密的明文数据。
需要做的工作：
1.无需考虑平台差异性，qt,android,ios都能快速的实现。只需在每个平台上，使用各自的语言，实现同样的加密，解密算法即可。
2.需要对加密算法进行了解，选择一种加密算法，进行实现。
二、对数据库文件进行加密
优点：
1.对整个文件进行了加密，用户通过编辑器看不到任何有用的数据，用户使用sqlite browser软件也无法打开文件查看数据，保证了数据安全。
2.进行打开数据库时，使用程序sqlite3_key(db,”********”,8)即可对文件解密，对数据表的 *** 作无需进行加密，采用明文即可。
不足：
1.需要修改sqlite的源代码，这个工作难度比较大。
2.需要对修改后的sqlite进行编译，需要对makefile有所了解，手动编写makefile文件，对源程序进行编译。因平台差异性，可能会造成某个平台无法编译生成动态链接库的可能。
3.需要对数据访问层代码进行修改，例如qt平台需要将以前对数据库 *** 作使用的QSqlQuery类，更改为使用sqlite3.h文件中定义 *** 作，对数据库 *** 作。其他平台也一样，都要做这一步的修改。
4.在程序编译时，要加入使用加密的动态链接库（linux为共享库.so文件）windows平台最容易，只需将所使用的dll文件copy到应用程序中即可。其他平台需要实验，看如何引入库,如果编译。
需要做的工作：
1.修改sqlite源代码，追加对数据库文件进行加密的功能。
2.编译含有加密功能的程序源代码，生成各自平台需要使用的库文件。
3.将加密sqlite库文件引入各自平台中，修改数据库访问层代码。
4.进行程序的部署，测试。
三、数据库加密原理
目前主流的数据库都采用了各种安全措施，主要包括用户认证、访问控制、数据加密存储和数据库 *** 作审计等措施。
用户认证：用户或者程序向数据库提供自己的有效身份z明，数据库鉴别用户的身份是否合法，只有合法的用户才能存取数据
库中的数据。用户认证是所有安全机制的前提，只有通过认证才能进行授权访问和审计。
访问控制：数据库管理系统为不同的用户分配不同的权限，保证用户只能进行授权的访问。目前，一些大型数据库(如Oracle 等)
都采用了基于角色的访问控制机制，即为用户授予不同的角色，如db—owner，security administrator 等，不同的角色允许对数据库执行不同的 *** 作。
数据库加密：用户认证以及访问控制对访问数据库进行了控制，但攻击者可能会利用 *** 作系统或数据库漏洞，或物理接触计算机，而直接接触数据库系统文件，从而可能绕过身份认证和存取控制而直接窃取或篡改数据库内容。对数据库中的数据进行加密是防范这类威胁的有效手段。
数据库 *** 作审计：监视和记录用户对数据库所做的各种 *** 作的安全机制，它记录并存储用户的 *** 作，用于事后分析，以检查导致数据库现状的原因以及提供追踪攻击者的线索。数据库的备份与恢复：当数据库发生不可恢复的故障时，可以将数据库恢复到先前的某个一致性的状态。
四、SQLite 加密
由于SQLite 是开放源码的，并且在其源码中预留了加密接口，我们可以通过实现其预留的加密接口实现口令认证和数据库加密以完善其加密机制。
1.口令认证
SQLite 数据库文件是一个普通文本文件，对它的访问首先依赖于文件的访问控制。在此基础上，再增加进一步的口令认证，即在访问数据库时必须提供正确的口令，如果通过认证就可以对数据库执行创建、查询、修改、插入、删除和修改等 *** 作；否则，不允许进一步的访问。
2.数据库加密
数据库加密有两种方式：
1)在数据库管理系(Data Base Management System，DBMS)中实现加密功能，即在从数据库中读数据和向数据库中写数据时执行加解密 *** 作；
2)应用层加密，即在应用程序中对数据库的某些字段的值进行加密，DBMS 管理的是加密后的密文。
前者与DBMS 结合好，加密方式对用户透明，但增加了DBMS 的负载，并且需要修改DBMS的原始代码；后者则需要应用程序在写入数据前加密，在读出数据后解密，因而会增大应用程序的负载。在此，通过实现SQLite 源码中预留的加密接口，实现DBMS 级的加密。
3.使用xxx-tea 算法加密SQLite 数据库
微型加密算法（TEA）及其相关变种（XTEA，Block TEA，XXTEA） 都是分组加密算法，它们很容易被描述，实现也很简单（典型的几行代码）。
TEA 算法最初是由剑桥计算机实验室的 David Wheeler 和 Roger Needham在 1994 年设计的。该算法使用
128 位的密钥为 64 位的信息块进行加密，它需要进行 64 轮迭代，尽管作者认为 32
轮已经足够了。该算法使用了一个神秘常数δ作为倍数，它来源于黄金比率，以保证每一轮加密都不相同。但δ的精确值似乎并不重要，这里 TEA 把它定义为
δ=「(√5 – 1)231」（也就是程序中的 0×9E3779B9）。
之后TEA 算法被发现存在缺陷，作为回应，设计者提出了一个 TEA 的升级版本——XTEA（有时也被称为“tean”）。XTEA 跟
TEA 使用了相同的简单运算，但它采用了截然不同的顺序，为了阻止密钥表攻击，四个子密钥（在加密过程中，原 128 位的密钥被拆分为 4 个 32
位的子密钥）采用了一种不太正规的方式进行混合，但速度更慢了。
在跟描述 XTEA 算法的同一份报告中，还介绍了另外一种被称为 Block TEA 算法的变种，它可以对 32
位大小任意倍数的变量块进行 *** 作。该算法将 XTEA
轮循函数依次应用于块中的每个字，并且将它附加于它的邻字。该 *** 作重复多少轮依赖于块的大小，但至少需要 6
轮。该方法的优势在于它无需 *** 作模式（CBC，OFB，CFB 等），密钥可直接用于信息。对于长的信息它可能比 XTEA 更有效率。
在1998 年，Markku-JuhaniSaarinen 给出了一个可有效攻击 Block TEA 算法的代码，但之后很快 David
J. Wheeler 和 Roger M.Needham 就给出了 Block TEA 算法的修订版，这个算法被称为 XXTEA。XXTEA
使用跟 Block TEA 相似的结构，但在处理块中每个字时利用了相邻字。它利用一个更复杂的 MX 函数代替了 XTEA 轮循函数，MX 使用 2
个输入量。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）