openssl.so和ffrt.so异常日志分析

1、打点日志,内部测试随意操作,无规律复现路径

2、日志打点,内部测试每天都会上报很多条如下错误日志libcrypto_openssl.z.so和ffrt.so

#00 pc 0000000000000000 Not mapped 
#01 pc 000000000025b718 /system/lib64/chipset-pub-sdk/libcrypto_openssl.z.so(CRYPTO_cbc128_decrypt+184)(262fd948f225e89863dd46850b1a4367) 
#02 pc 00000000002e0f30 /system/lib64/chipset-pub-sdk/libcrypto_openssl.z.so(ossl_cipher_hw_generic_cbc+92)(262fd948f225e89863dd46850b1a4367) 
#03 pc 00000000002de5ec /system/lib64/chipset-pub-sdk/libcrypto_openssl.z.so(ossl_cipher_generic_block_update+720)(262fd948f225e89863dd46850b1a4367) 
#04 pc 0000000000233fd0 /system/lib64/chipset-pub-sdk/libcrypto_openssl.z.so(EVP_EncryptUpdate+124)(262fd948f225e89863dd46850b1a4367) 
#05 pc 0000000000031110 /system/lib64/platformsdk/libcrypto_openssl_plugin_lib.z.so(eeda3c1f0176487f599c3420dc12c16f) 
#06 pc 0000000000017174 /system/lib64/module/security/libcryptoframework_napi.z.so(beb8788a27ad70787054446df89fb1cb) 
#07 pc 0000000000046b44 /system/lib64/platformsdk/libace_napi.z.so(NativeAsyncWork::AsyncWorkCallback(uv_work_s*)+160)(15323f6b38ce55cb85735db8a46a80ef) 
#08 pc 0000000000012a30 /system/lib64/platformsdk/libuv.so(uv__ffrt_work+32)(972b0646dcdc978e7c3837094ac9a5f9) 
#09 pc 000000000002d298 /system/lib64/chipset-sdk/libffrt.so(ffrt::CPUWorker::Run(ffrt_executor_task*, int)+396)(c7e58f79a3d7fa0118fc6956a4c33efd) 
#10 pc 000000000002dd44 /system/lib64/chipset-sdk/libffrt.so(ffrt::CPUWorker::RunTask(ffrt_executor_task*, ffrt::CPUWorker*, ffrt::CPUEUTask*&)+152)(c7e58f79a3d7fa0118fc6956a4c33efd) 
#11 pc 000000000002da24 /system/lib64/chipset-sdk/libffrt.so(ffrt::CPUWorker::Dispatch(ffrt::CPUWorker*)+316)(c7e58f79a3d7fa0118fc6956a4c33efd) 
#12 pc 000000000002d8d4 /system/lib64/chipset-sdk/libffrt.so(ffrt::CPUWorker::WarpDispatch(void*)+24)(c7e58f79a3d7fa0118fc6956a4c33efd) 
#13 pc 000000000019e928 /system/lib/ld-musl-aarch64.so.1(69c411c51b88a02a77ccd4ba672bb6f1) 
#14 pc 000000000009d3f8 /system/lib/ld-musl-aarch64.so.1(69c411c51b88a02a77ccd4ba672bb6f1) 

日志分析过程

1、分析异常栈

崩溃位置libcrypto_openssl.z.so(#04->#00)

04行、算法库libcrypto_openssl.z.so调用OpenSSL EVP_EncryptUpdate执行加密操作,但是在OpenSSL内部调用栈中(#01)出现了CRYPTO_cbc128_decrypt函数,这个函数是执行解密操作的。

2、OpenSSL调用原理

OpenSSL内部的加解密上下文中有个enc标记,值为1表示加密,0表示解密。

因此怀疑加解密上下文没有完成初始化,enc值还是0,因此内层调用到了解密函数。

3、可能性分析

Cipher.init函数是异步实现,如果业务没有等init完成,就调用Cipher.update函数,就可能会出现相同的异常栈。

日志分析结论

1,异常原因:加密操作执行了解密函数

2、可能异常的操作:初始化函数Cipher.init异步未结束调用了加密操作

调试建议

请确认下调用init时是否加了await或是否执行完异步init后才调用了update

开发者反馈

1、init接口,b当成同步方法使用了

2、init接口前加 await 后,待观察后续是否上报类似错误

3、无此类问题出现、问题解决

根因总结

CryptoFramework.init是异步接口,伙伴在开发时开发当成同步接口使用,导致没有初始化完成就使用加解密操作抛出异常crash。

HarmonyOS
2024-05-28 22:34:32
浏览
收藏 0
回答 1
待解决
回答 1
按赞同
/
按时间
koarla

init接口前加 await 、返回之后再调用Cipher.update函数

分享
微博
QQ
微信
回复
2024-05-29 23:44:20
相关问题
是否有预编译的 OpenSSLso 文件?
93浏览 • 1回复 待解决
ArkTS .so交互的问题
142浏览 • 1回复 待解决
ArkTSNative如何动态加载、卸载so
1918浏览 • 1回复 待解决
通过configuration配置调试so
674浏览 • 1回复 待解决
HarmonyOS 有没有日志分析平台?
145浏览 • 1回复 待解决
HarmonyOS libuv.so崩溃
195浏览 • 1回复 待解决
HarmonyOS har包引用so问题
469浏览 • 1回复 待解决
关于 SO 文件的使用问题
176浏览 • 1回复 待解决
如何调试引用的外部so
742浏览 • 1回复 待解决
HarmonyOS so的热修复能力
471浏览 • 1回复 待解决
如何减小编译产物so大小
377浏览 • 1回复 待解决
so加固支持的混淆逻辑
564浏览 • 1回复 待解决
如何引用其他工程编译的so
306浏览 • 0回复 待解决
在Camkelist配置so后,编译报错
668浏览 • 1回复 待解决
ArkTS项目如何调用已有SO库?
836浏览 • 1回复 待解决
如何在Native层加载so
1066浏览 • 1回复 待解决
HarmonyOS 如何适配自己的so库?
471浏览 • 1回复 待解决