很高兴和大家一起分享.netres对称加密的知识，希望对各位有所帮助。
代码混淆是apk加固的一个重要部分，res文件混淆也是代码混淆的其中一个工作，主要是混淆res文件夹下的layout的xml文件，混淆后如果打开就是乱码。
Java和.NET的系统类库里都有封装DES对称加密的实现方式，但是对外暴露的接口却各不相同，甚至有时会让自己难以解决其中的问题
DES加密
DES是一种对称加密(Data Encryption Standard)算法，以前我写过一篇文章：.NET中加密解密相关知识，有过简单描述。
DES算法一般有两个关键点，第一个是加密算法，第二个是数据补位。
加密算法常见的有ECB模式和CBC模式：
ECB模式：电子密本方式，这是JAVA封装的DES算法的默认模式，就是将数据按照8个字节一段进行DES加密或解密得到一段8个字节的密文或者明文，最后一段不足8个字节，则补足8个字节（注意：这里就涉及到数据补位了）进行计算，之后按照顺序将计算所得的数据连在一起即可，各段数据之间互不影响。
CBC模式：密文分组链接方式，这是.NET封装的DES算法的默认模式，它比较麻烦，加密步骤如下：
1、首先将数据按照8个字节一组进行分组得到D1D2......Dn（若数据不是8的整数倍，就涉及到数据补位了）
2、第一组数据D1与向量I异或后的结果进行DES加密得到第一组密文C1（注意：这里有向量I的说法，ECB模式下没有使用向量I）
3、第二组数据D2与第一组的加密结果C1异或以后的结果进行DES加密，得到第二组密文C2
4、之后的数据以此类推，得到Cn
5、按顺序连为C1C2C3......Cn即为加密结果。
数据补位一般有NoPadding和PKCS7Padding(JAVA中是PKCS5Padding)填充方式，PKCS7Padding和PKCS5Padding实际只是协议不一样，根据相关资料说明：PKCS5Padding明确定义了加密块是8字节，PKCS7Padding加密快可以是1-255之间。但是封装的DES算法默认都是8字节，所以可以认为他们一样。数据补位实际是在数据不满8字节的倍数，才补充到8字节的倍数的填充过程。
NoPadding填充方式：算法本身不填充，比如.NET的padding提供了有None，Zeros方式，分别为不填充和填充0的方式。
PKCS7Padding（PKCS5Padding）填充方式：为.NET和JAVA的默认填充方式，对加密数据字节长度对8取余为r，如r大于0，则补8-r个字节，字节为8-r的值；如果r等于0，则补8个字节8。比如：
加密字符串为为AAA，则补位为AAA55555;加密字符串为BBBBBB，则补位为BBBBBB22；加密字符串为CCCCCCCC，则补位为CCCCCCCC88888888。
.NET中的DES加密
对于.NET，框架在System.Security.Cryptography命名空间下提供了DESCryptoServiceProvider作为System.Security.Cryptography.DES加密解密的包装接口，它提供了如下的4个方法：
public override ICryptoTransform CreateDecryptor(byte[] rgbKey, byte[] rgbIV)
public override ICryptoTransform CreateEncryptor(byte[] rgbKey, byte[] rgbIV)
public override void GenerateIV()
public override void GenerateKey()
从.NET类库封装情况，加解密需要传入一个Key和IV向量。而且Key必须为8字节的数据，否则会直接抛异常出来，当使用ECB模式下，不管传入什么IV向量，加密结果都一样。示例代码如下：
public static string EncryptWithJava(string key, string str)
{
if (key.Length 8 || string.IsNullOrEmpty(str))
{
throw new Exception("加密key小于8或者加密字符串为空！");
}
byte[] bKey = Encoding.UTF8.GetBytes(key.Substring(0, 8));
byte[] bIV = IV;
byte[] bStr = Encoding.UTF8.GetBytes(str);
try
{
DESCryptoServiceProvider desc = new DESCryptoServiceProvider();
desc.Padding = PaddingMode.PKCS7;//补位
desc.Mode = CipherMode.ECB;//CipherMode.CBC
using (MemoryStream mStream = new MemoryStream())
{
using (CryptoStream cStream = new CryptoStream(mStream, desc.CreateEncryptor(bKey, bIV),CryptoStreamMode.Write))
{
cStream.Write(bStr, 0, bStr.Length);
cStream.FlushFinalBlock();
StringBuilder ret = new StringBuilder();
byte[] res = mStream.ToArray();
foreach (byte b in res)
{
ret.AppendFormat("{0:x2}", b);
}
return ret.ToString();
}
}
}
catch
{
return string.Empty;
}
}
由于为ECB模式，因此IV这里设置什么值都是可以的，当为CBC模式下，则需要设置为其他值，比如：public static byte[] IV = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08 }，才能正常加密解密。
JAVA中的DES加密
JAVA的javax.crypto.Cipher包下，提供了加密解密的功能，它的静态getInstance方法，可以返回一个Cipher对象，一般有public static final Cipher getInstance(String transformation)方法，transformation为：algorithm/mode/padding，分别表示算法名称，比如DES，也可以在后面包含算法模式和填充方式，但也可以只是算法名称，如为："DES/CBC/PKCS5Padding"，"DES"等。JAVA中默认的算法为ECB，默认填充方式为PKCS5Padding。Cipher的Init方法用来初始化加密对象，常见的有：
public final void init(int opmode, Key key, AlgorithmParameterSpec params) ，
public final void init(int opmode,Key key, SecureRandom random)，用SecureRandom时，一般用于不需要IV的算法模式，示例代码如下：
public static String encrypt2(String src) throws Exception {
SecureRandom sr = new SecureRandom();
DESKeySpec ks = new DESKeySpec(KEY.getBytes("UTF-8"));
SecretKeyFactory skf = SecretKeyFactory.getInstance("DES");
SecretKey sk = skf.generateSecret(ks);
Cipher cip = Cipher.getInstance("DES/CBC/PKCS5Padding");//Cipher.getInstance("DES");
IvParameterSpec iv2 = new IvParameterSpec(IV);
cip.init(Cipher.ENCRYPT_MODE, sk, iv2);//IV的方式
//cip.init(Cipher.ENCRYPT_MODE, sk, sr);//没有传递IV
String dest = byteToHex(cip.doFinal(src.getBytes("UTF-8")));
return dest;
}
当默认用DES，JAVA会用ECB模式，因此这里IV向量没有作用，这里，但当用CBC模式下，如果还是用SecureRandom，则每次加密的结果都会不一样，因为JAVA内部会用随机的IV来初始化Cipher对象，如示例代码，由于Cipher.getInstance("DES/CBC/PKCS5Padding")使用了CBC，因此我这里用的javax.crypto.spec.IvParameterSpec包下的IvParameterSpec来初始化向量IV：
Private final static byte[] IV = new byte[] {0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01};
总结
对于.NET和JAVA在使用DES对称加密时，需要大家指定一样的算法和填充模式，并且JAVA在写DES加解密算法时，还需要根据创建Cipher对象的不同，正确使用IV向量。在不同系统需要互相数据时，必须要明确的是加密算法，Key和算法模式，再根据不同模式是否需要IV向量，最后是填充模式
res是指资源文件（Resource file）。
所有可以从中读取出需要的资源的文件.netres对称加密，可以称之为“资源文件”。资源的类型可以是图片、音频、视频、文字资源.netres对称加密，或者其.netres对称加密他可以在计算机中展示的内容等等。由专门的程序接口去读取.netres对称加密，并在应用程序中根据需要向用户展示。
资源文件（狭义）.netres对称加密：
资源文件（具有 .res 文件扩展名）包含着无需重新编辑代码便可以改变的位图、字符串和其它数据。
例如，如果计划用一种外语将应用程序本地化，可以将用户界面的全部正文串和位图存放在资源文件里，然后将资源文件本地化，而不是将整个应用程序本地化。一个工程最多包含一个资源文件。详细信息 关于使用资源文件的详细内容，请参阅本章后面的“使用资源文件”和“国际发行”。
资源文件（广义）：
所有可以从中读取出需要的资源的文件，可以称之为“资源文件”。资源的类型可以是图片、音频、视频、文字资源，或者其他可以在计算机中展示的内容等等。由专门的程序接口去读取，并在应用程序中根据需要向用户展示。
资源文件的类型很多，不限制文件的后缀名。各个不同的软件系统，可以使用自己定义的资源文件类型。并采用自己的加密方式。资源文件中的资源是可替换的，替换之后，无需重新编译代码，即可实现视觉、听觉、文字等效果的改变。
更广义的资源文件，可以理解为凡是可以从中获得资源（所有类型）的文件（不管是实体文件还是计算机系统中的文件）。
智能化时代的到来涉及了各种核心算法，保护算法就能保障开发者权益，杜绝市面上各种山寨品，加密芯片恰好能起到很好的保护作用，如何选择加密芯片呢？KEROS加密芯片专注于加密领域十余年，行业首选。
1.安全性：采用国际通用AES256算法加密并同时通过KAS传送，除基本认证之外，利用2K安全EEPROM，用户可以自己管理密钥和数据，实现双重保护。
2.唯一性：以定制的方式为每一位用户单独定制“专属型号CID”，多用户之间算法不兼容，并且采用固化的方法直接将算法固化到晶圆上而无需烧入。
3.序列号：每颗芯片制造生产时具有5字节全球唯一SN序列号，每颗芯片SN都不会重复。
4.防抄特性：每颗芯片都有自己独特的密钥系统，破解单颗芯片只对这颗芯片对应的产品有效，对整个同类型的产品是无效的，依旧无法通过验证。而且KEROS采用ASIC方法设计，芯片内为纯逻辑电路，封装内有40多层逻辑电路整合了10万多个逻辑门，爆力刨片破解难度可想而知。
5.安全存储：用户可以将保密数据加密之后安全的存放到EEPROM中。.netres对称加密的介绍就聊到这里吧，感谢你花时间阅读本站内容。
本文标签：.netres对称加密
