加密

1. BASE64 Base64是网络上最常见的用于传输8Bit字节代码的编码方式之一，大家可以查看RFC2045～RFC2049，上面有MIME的详细规范。Base64编码可用于在HTTP环境下传递较长的标识信息。例如，在Java Persistence系统Hibernate中，就采用了Base64来将一个较长的唯一标识符（一般为128-bit的UUID）编码为一个字符串，用作HTTP表单和HTTP GET URL中的参数。在其他应用程序中，也常常需要把二进制数据编码为适合放在URL（包括隐藏表单域）中的形式。此时，采用Base64编码具有不可读性，即所编码的数据不会被人用肉眼所直接看到。（来源百度百科） java实现代码： package com.cn.单向加密;import sun.misc.BASE64Decoder;import sun.misc.BASE64Encoder;/* BASE64的加密解密是双向的，可以求反解. BASE64Encoder和BASE64Decoder是非官方JDK实现类。虽然可以在JDK里能找到并使用，但是在API里查不到。 JRE 中 sun 和 com.sun 开头包的类都是未被文档化的，他们属于 java, javax 类库的基础，其中的实现大多数与底层平台有关， 一般来说是不推荐使用的。 BASE64 严格地说，属于编码格式

Zabbix 实现Server和windows的Agent通信加密 理论知识请看zabbix官方文档： https://www.zabbix.com/documentation/4.0/zh/manual/encryption 本次实验，使用OpenSSL进行加密。 1.编译Zabbix支持加密 Zabbix使用TransportLayerSecurity (TLS) protocol v1.2进行加密，为了让Zabbix支持加密功能，在源码编译安装时必须要链接到下面三个加密库中的其中一个。 mbed TLS：早期也叫PolarSSL，目前仅支持1.3.x版本。注意不支持2.x版本。 GnuTLS：支持v3.1.18及更高的版本。 OpenSSL：支持v1.0.1及更高的版本。 根据你的选择，configure脚本可以使用下面的某个选项： --with-mbedtls[=DIR] --with-gnutls[=DIR] --with-openssl[=DIR] 例如： ./configure--enable-server --enable-agent--with-mysql --enable-ipv6 --with-net-snmp--with-libcurl --with-libxml2--with-openssl 在编译安装Zabbix的不同组件时可以使用不同的加密库

接下来我们将介绍另一种简单适用的防止 apk 反编译的技术 - 对apk进行伪加密。 一、 伪加密技术原理 我们知道 android apk 本质上是 zip 格式的压缩包，我们将 android 应用程序的后缀 .apk 改为 .zip 就可以用解压软件轻松的将 android 应用程序解压缩。在日常生活或者工作中，我们通常为了保护我们自己的文件在进行压缩式都会进行加密处理。这样的方法对于 android apk 同样适用。原理很简单，在 zip 的文件格式中有一个位用来标示该 zip 压缩文件中的文件是否被加密，我们只要找到该标志位将其置 1 就可以实现我们的目的。而 android 的包安装服务（ PackageManagerService ）在进行 apk 安装时并不关心这个加密位（暂时我们就这么叫它吧）可以进行正常的安装并且也不会影响 apk 的运行。 二、 zip 文件格式 zip 的文件格式通常有三个部分组成：压缩文件源数据、压缩目录源数据、目录结束标识。这三个部分中和我们说的加密位有关的是压缩目录源数据部分，我们接下来详细介绍这一部分。 压缩目录源数据部分记录着所有的压缩目录源数据。其结构如下： Central directory file header Offset Bytes Description [18] 译   0 4 Central directory

经过了忙碌的一周终于有时间静下来写点东西了，我们继续介绍android apk防止反编译技术的另一种方法。前两篇我们讲了加壳技术(http://my.oschina.net/u/2323218/blog/393372)和运行时修改字节码(http://my.oschina.net/u/2323218/blog/396203)，如果有不明白的可以查看我的博客的前两篇中关于这两种技术的介绍。接下来我们将介绍另一种简单适用的防止apk反编译的技术-伪加密。 一、伪加密技术原理 我们知道android apk本质上是zip格式的压缩包，我们将android应用程序的后缀.apk改为.zip就可以用解压软件轻松的将android应用程序解压缩。在日常生活或者工作中，我们通常为了保护我们自己的文件在进行压缩式都会进行加密处理。这样的方法对于android apk同样适用。原理很简单，在zip的文件格式中有一个位用来标示该zip压缩文件中的文件是否被加密，我们只要找到该标志位将其置1就可以实现我们的目的。而android的包安装服务（PackageManagerService）在进行apk安装时并不关心这个加密位（暂时我们就这么叫它吧）可以进行正常的安装并且也不会影响apk的运行。 二、zip文件格式 zip的文件格式通常有三个部分组成：压缩文件源数据、压缩目录源数据、目录结束标识

经过了忙碌的一周终于有时间静下来写点东西了，我们继续介绍 android apk 防止反编译技术的另一种方法。前两篇我们讲了加壳技术( http://my.oschina.net/u/2323218/blog/393372 )和运行时修改字节码( http://my.oschina.net/u/2323218/blog/396203 )，如果有不明白的可以查看我的博客的前两篇中关于这两种技术的介绍。接下来我们将介绍另一种简单适用的防止 apk 反编译的技术 - 对apk进行伪加密。 一、 伪加密技术原理 我们知道 android apk 本质上是 zip 格式的压缩包，我们将 android 应用程序的后缀 .apk 改为 .zip 就可以用解压软件轻松的将 android 应用程序解压缩。在日常生活或者工作中，我们通常为了保护我们自己的文件在进行压缩式都会进行加密处理。这样的方法对于 android apk 同样适用。原理很简单，在 zip 的文件格式中有一个位用来标示该 zip 压缩文件中的文件是否被加密，我们只要找到该标志位将其置 1 就可以实现我们的目的。而 android 的包安装服务（ PackageManagerService ）在进行 apk 安装时并不关心这个加密位（暂时我们就这么叫它吧）可以进行正常的安装并且也不会影响 apk 的运行。 二、 zip 文件格式

3DES （或称为Triple DES）是三重 数据加密算法 （TDEA，Triple Data Encryption Algorithm）块密码的通称。它相当于是对每个 数据块 应用三次DES 加密算法 。由于计算机运算能力的增强，原版DES密码的 密钥 长度变得容易被暴力破解；3DES即是设计用来提供一种相对简单的方法，即通过增加DES的密钥长度来避免类似的攻击，而不是设计一种全新的块 密码算法 。 package com.qk365.utils; import java.security.MessageDigest; import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.spec.SecretKeySpec; import com.sun.org.apache.xerces.internal.impl.dv.util.Base64; @SuppressWarnings("restriction") public class EncryptUtils { private static final String Algorithm = "DESede"; // 定义加密算法,可用，DES,DESede,Blowfish /** * 3des解码 * * @param value

quick-cocos2d-x是用lua脚本来写的，而lua是明文形式，如果不对脚本进行处理，那么我们所写的代码将可能暴露给别人（apk和ipa都是简单的zip包装）。 quick-cocos2d-x框架为我们提供了一个可编译和加密代码的工具compile_scripts.sh（ 目前只提供了mac版 ），它位于quick-cocos2d-x/bin/ compile_scripts.sh 。下面将对其进行详细的介绍。 一、安装luajit lua脚本的编译是通过luajit来执行的，如果你之前没有安装过luajit的话，运行compile_scripts.sh会出现下面的提示： 下面将介绍如何安装luajit。 1、运行<path>/quick-cocos2d-x/bin/install_luajit.sh ， <path>为你具体的路径 ，请自行替换 。 这个时候会执行luajit的构建操作。 2、完成构建之后将进行安装，安装之前会叫你输入系统账户密码，如下图： 3、之后就是安装过程了，完成之后会出现下图这样的界面： 恭喜你完成了第一步。 二、示例 我们先来运行一个示例吧。这个将帮助你了解编译的过程。 我们做的很简单，就是把代码编译成一个zip包，并把它放置到res目录下（framework_precompiled.zip也在此目录）。 1、 在bash下

加密，是以某种特殊的算法改变原有的信息数据，使得未授权的用户即使获得了已加密的信息，但因不知解密的方法，仍然无法了解信息的内容。大体上分为 双向加密 和 单向加密 ，而双向加密又分为 对称加密 和 非对称加密 (有些资料将加密直接分为对称加密和非对称加密)。 双向加密大体意思就是明文加密后形成密文，可以通过算法还原成明文。而单向加密只是对信息进行了摘要计算，不能通过算法生成明文，单向加密从严格意思上说不能算是加密的一种，应该算是摘要算法吧。具体区分可以参考： (本人解释不清呢 …… ) http://security.group.iteye.com/group/wiki/1710-one-way-encryption-algorithm 一、双向加密 (一)、对称加密 采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密。 需要对加密和解密使用相同密钥的加密算法。由于其速度，对称性加密通常在消息发送方需要加密大量数据时使用。对称性加密也称为密钥加密。 所谓对称，就是采用这种加密方法的双方使用方式用同样的密钥进行加密和解密。密钥是控制加密及解密过程的指令。 算法是一组规则，规定如何进行加密和解密。因此对称式加密本身不是安全的。 　　 常用的对称加密有：DES、IDEA、RC2、RC4、SKIPJACK、RC5、AES算法等

最近因为一些项目的安全性需要将数据库加密，一开始想到的就是先将数据库通过AES加密，然后运行时再解密，另一种是将数据库里的内容加密。 很快这两种方案都是不理想的，第一种加密方式形同虚设，第二种，如果加密的字段是要查找数据就变得麻烦。 所以第三种方案就是在内存里解密，在网上查到SQLITE是支持加密的， 所以就根据网上的指导一步步地将SQLITE编译成支持加密的。 那下一步就是怎样做成SDK去方便使用？第一个念头就是将原生的数据库使用方式移植过来，但做起来比开始想像的难了点，但最终也在修修补补中完成了移植工作。一开始是使用Android2.2的数据库模块源码，但运行时会经常有一些问题出现，后来使用Android4.0的数据库模块源码就解决了这些问题，当然，在开始是在Android4.0源码编译时，在Android4.0以上的手机运行是没问题，但在Android4.0以下就会报错。所以逼不得意就将Android4.0数据库模块移到Android2.2源码目录下编译，当然少不了要解决版本兼用的一些问题。 Android原生是不支持数据库加密的，所以要想加密数据库就需要使用其它的方式。而这个SDK是从原生Android4.0源码里单独移植SQLITE模块，并将这个模块编译时加入加密方法，因为SQLITE源码中是有加密的接口，所以移植时就只需将这个预编译参数加入和一些文件即可。

我想关于AES算法大家应该都已经了解了，我就不多介绍了。这是本人第一次写技术博文，如果有不对之处欢迎大家指正，共同讨论，一起学习！ 之前在项目上用到AES256加密解密算法，刚开始在java端加密解密都没有问题，在iOS端加密解密也没有问题。但是奇怪的是在java端加密后的文件在iOS端无法正确解密打开，然后简单测试了一下，发现在java端和iOS端采用相同明文，相同密钥加密后的密文不一样！上网查了资料后发现iOS中AES加密算法采用的填充是PKCS7Padding，而java不支持PKCS7Padding，只支持PKCS5Padding。我们知道加密算法由算法+模式+填充组成，所以这两者不同的填充算法导致相同明文相同密钥加密后出现密文不一致的情况。那么我们需要在java中用PKCS7Padding来填充，这样就可以和iOS端填充算法一致了。 要实现在java端用PKCS7Padding填充，需要用到bouncycastle组件来实现，下面我会提供该包的下载。啰嗦了一大堆，下面是一个简单的测试，上代码！ package com.encrypt.file; import java.io.UnsupportedEncodingException; import java.security.Key; import java.security.Security; import javax