05-08 17:28:12.125 E/--------------(24311): 2131362643
05-08 17:28:12.125 E/--------------(24311): 2131362571
05-08 17:28:12.125 E/--------------(24311): 2131362576
05-08 17:28:12.125 E/--------------(24311): 74
05-08 17:28:12.125 W/ResourceType(24311): Bad string block: string #14 is not null-terminated
在看了三个字符串实际内容时,发现 sql_CreateDB
的字符串刚好是长度最长
的! 那么理论上无论在哪里调用 getString(R.string.sql_CreateDB)
都将会触发崩溃.
实际测试后,将该代码放入Activity里再调用,的确是崩溃了.而且Java层应用的UncaughtExceptionHandler
也捕获不了此类底层错误.
经过手工边界值测试,发现当XML里的string里存储的字符长度最大值为:
[√正常]<= 10922 个中文字符一
[×崩溃]>= 10923 个中文字符一
[√正常]<= 10922 个中文字符一
+ 1个英文字符A
[×奔溃]>= 10922 个中文字符一
+ 2个英文字符A
[×奔溃]>= 10922*3=32766 个英文字符A
+ 2个英文字符A
[×奔溃]>= 34000 个英文字符A
[√正常]<= 10922*2=21844 个英文字符A
+ 1个英文字符A
[√正常]>= 10922*3=32766 个英文字符A
+ 1个英文字符A
short 占用内存空间2个字节,也就是16个二进制位。 表示负数时,最高位为符号位(负数的符号位为1),最高位为符号位(正数的符号位为0),最大的正数为0111 1111 1111 1111 即2^15 - 1 = 32767
看到这个数字于是一个大胆的猜测浮现脑中:
VIVO为了解决Android的某个类似堆栈溢出的安全问题,在2018-04-01
打了一个对应的安全补丁
影响的代码因为是在 libandroidfw.so
文件里
影响的范围应该就是 nativeGetString
时的允许的最大字符串长度
个人猜测:原本未修复前,这个最大字符串长度应该是没有设置的,所以才出现类似堆栈溢出
的漏洞.
最大字符串长度
类型被有意或者无意改为了 short
类型?? 为什么呢?? 为了节约内存?? 节约内存也不应该在"安全补丁"里处理吧?
现在修复之后,将其设置成了某个值,字符串长度大于这个值时就返回null
于是APP从最底层就崩溃了.