加密库在不同位数下问题的定位与解决
促进解决问题的原因
- 因项目是做数据安全方面,所以对应业务模块的代码使用C++来进行实现,且以生成SO(动态)库拱Java来调用。在项目之前版本中并未涉及到针对64位环境的兼容,一直在Android的armabi与armeabi-v7a下使用。因Google市场在20190801之后更新GooglePlay必须提供支持64位动态库的要求,当时因未能明确定位问题而将这一问题拖拉了下来,因为不影响国内使用。
- 随着国内应用市场也明确要求强制支持64位的支持,具体如图:
- 故解决这个问题的优先级也被排在前列,本着养成的没有解决不了的问题的理念,专心的去深耕细挖,最终一定会解决。
定位问题的方法
- 首先将加密库所涉及到的C++代码进行简易化搭建,剔除业务只关心加密,然后进行Debug调试,通过在AndroidStuido中的LLDB(LowLevelDebugger)动态调试工具进行C++代码运行时内存数据的分析。如图:
- 比如查看ulkey这个字段在内存中的数值,通过命令 memory read --size 4 --format x --count 8 0x29a9e420,也可以简写为 memory read -s4 -fx -c8 0x29a9e420,实例如图:
1. size:表示的是每个展示的值所占的字节数,可以使用1、2、4、8等,但要与显示的数据匹配。
2. format:表示的是显示类型x表示16进制,也可以指定f(float)、d(int)、u(unsigned int)等。
3. count:表示的是显示数值的个数。
4. 0x29a9e420:表示的是要调试的内存地址值。
加密数值在32位与64位的比较
需注意的事项
- 进行真机调试环境时,需特别注意,在进行C++代码的动态调试时,需要清楚手机处理器的位数是32位还是64位,因为32位的手机虽能在armeabi-v7a的环境进行动态调试但不能在arm64-v8a的环境下动态调试,反之亦然。 所以这个特点需要注意,以免造成不必要的疑惑。相对配置如图:
排查与定位
- 根据加密规则来准备对应的测试数据,在这里我准备了一个16bit的文件,目的是为了查看在32位的环境下它的数值与在64位的有什么不同!测试数据如图:
- 测试数据准备好后开始执行加密过程的动态调试,通过在不同位数的手机的调试后,发现了持有加密数值的ulbuf变量有差异,ulbuf定义如图所示:
- 在执行SMS4F函数之前,
uint32 ulbuf[36]
的初始值在32位与64位都相同。ulbuf在32位执行SMS4F函数前的内存中数值如图:
ulbuf在64位执行SMS4F函数前的内存中数值如图:
- 在执行SMS4F函数之后的ulbuf在32位执行SMS4F函数后的内存中数值如图:
ulbuf在64位执行SMS4F函数后的内存中数值如图:
- 因为整体规则是以16byte(128bits)作为一个单位来进行的,ulbuf的定义为uint32(在宏定义为unsigned long int),且循环条件的定义为 i < 32。所以这块只需看前128byte就可以了。
解决与总结
- 在经过对比后,32位与64位在执行SMS4F函数后的ulbuf在原文0x52以后的明显不同,再通过代码 ulbuf[i+4] 发现每次执行SMS4F函数之前,是以4byte推动的。通过到这一步,明显发现uint32宏定义的unsigned long int有些猫腻,因为在32位与64位的环境下,它的数值分别是占4byte与8byte。之前的定义如图:
- 修改后的宏定义uint32如图:
通过前面步骤定位到核心问题,之前因配置64位处理器(arm64-v8a)的场景无法正常加解密的问题也自然迎刃而解。也发现了C/C++在AndroidStudio中出现异样的新的排查与解决思路,不单单只有查看Variables参数、Log等方案,还有通过LLDB利器来进行“疑难杂症”的定位与解析。
-
希望这篇文章对大家定位类似的问题有所帮助与启发,有什么不足与修改之处请留言告知,不胜感激。
久有凌云志,重上井冈山。千里来寻故地,旧貌变新颜。 到处莺歌燕舞,更有潺潺流水,高路入云端。过了黄洋界,险处不须看。 风雷动,旌旗奋,是人寰。三十八年过去,弹指一挥间。 可上九天揽月,可下五洋捉鳖,谈笑凯歌还。世上无难事,只要肯登攀。