2013年9月27日 星期五 晴

我总是被接到一些无头无尾的邮件，没有人告诉我上下文，然后就让我去做什么项目了。

这个D项目也不例外，去和客户谈的时候，我一无所知。见面聊了才知道，先前别的部门做了，我们部门移植了一下，客户是来让我们改bug的。

客户需求：

1. 最根本需求：客户有自己的内部通讯录，员工可以看到通讯录里人的名字，但不能看到电话号码。

2. 围绕着需求1，演变出不想让员工自行安装APK，比如360安全卫士等能截获号码看到。

3. 围绕着需求1，担心log能看到。

之前开发情况：

1. 只是把android Contact的位置偏移了一下，写到数据库里的都是明文的号码。

2. 在通话记录、短信里显示的是一个真实号码，其中中间几位被*来替代，比如138****8888。

有一些bug，比如拨通话记录里的A，不小心就拨成B就出去了。之前的代码，我一行都没看，bug有那么五六个，看起来比较烦。

我也是没事，于是给客户提了两条主要的意见:

1. APK安装，我们也不知道你哪些可以安装，哪些不能安装，所以我可以提供一个白名单接口，动态更新，由他们来决定要更新哪些APK。

我说我能做到这一条，客户已经喜出望外了。

2. 能否做一个网络通讯录？号码都在底层和网络这边加密和解密就好，本地不存储通讯录。

我是这样说服客户的：你看过《暗算》么？就是谍战片，那些通过电报或者电台里传输的，很多都是加密过的。如果你加密方式足够好，那之前的都可以不做了。

客户当然一时时接受不了的，他得想半天。不过他当场表示，我提出的更好，更具安全性。

我也是有私心的，我就是不想改那些bug，客户同意我把自带的Mms和Contact给去掉，那我只要实现了，就没有什么bug了。

从底层来改，修改的地方不多，比较简洁，也符合我的风格。

工作量不大，具体的一些工作如下：

一、分别在底层和网络服务器都加上加解密。

- 在framework比较靠近底层的地方(当然，modem才是通讯更底层的地方)，分别修改通话和短消息这几个地方。

事实上，我记得我只修改了5个文件，分别是发短信，收短信、来电、去电、Mms，分别在这些地方调用函数一下就可以了。

以来电为例：

来电--》framework层加密来电号码-》上层处理或者广播时会显示加密的号码--》客户APK截获

去电是一个反向的过程，原理是一样的。

- 加密后的号码，报给客户的APK，客户的APK用约定好的加解密算法来解密即可。

如果担心有人反编译APK，加解密算法可以用C来打包处理，实在不行就上传到他们的后台服务器处理好了。

- 加解密算法：

没有必要采用非对称加密算法，采用简单的对称加密算法就好。

加密的密钥可以由IMEI + IMSI + 独特密钥就好。

服务器上记录了每台手机的IMEI和IMSI号，离职的时候，禁用这个账号，对传上来的IMEI和IMSI不予理睬即可。

如果员工更换手机，那么IMEI就不起作用了，防止员工换手机吧。

如果员工更换了SIM卡，那么IMSI也不起作用了，防止员工换SIM卡去运营商营业厅打通话清单。

二、APK安装动态白名单

- 直接修改PackageInstaller.apk的源码，安装的时候加个条件判断，不符合条件就不能安装就行。这个条件，就是白名单，可以读取比如一个文件或者APK的preferenece等。

- 在framework里封杀adb安装的方式，这应该可以防止豌豆夹和91助手之类的安装吧。

- 客户要求干掉文件管理器。

- 考虑到的问题：其实apk安装的底层函数我没修改，如果有人直接调用函数直接安装的话，可能是可以的。

如果有人能获取root权限的话，可以直接push进去的，除非我连手机自带的adb也改了。

当然，有了上述的加解密算法，APK的动态白名单无足轻重，但我也可以后续在别的项目上使用。

现在我的斯玛特卡只有300多块钱了，有点怀念以往有几千块钱的时候挥金如土的样子，国庆在家写1~2篇专利好了，一篇专利1500元。专利其实很好写，你能写博客，稍微加工一下，主要是加解密的算法和过程写详细一点(审核专利的只看有没有重复的，如果算法重复，那就换另外一种算法就成，反正就强调新颖性、有价值之类的就好)，垃圾专利的钱还是很好骗的。