刚看到这个的时候就尝试了一下,嗯,很成功,重启了~~
对比正常的jpeg文件:
一个典型的数据格式为:
JPEG SOI : FF D8 // 图片起始
JPEG APP0:0xFFE0 //
APP0 SIZE:1D 23 //当前标记的长度
JFIF Flag:JFIF // JFIF 标识
VERSION:// 版本号
ATTRIBUTION: // 长宽、DPI等信息
JPEG APP1: FF E1
APP1 Size : 1C 45 // 注意:前面这三个WORD都是big endian的
EXIF Flag : 'Exif', 0, 0
---------
TIFF : // TIFF格式的EXIF数据
---------
JPEG APPn: FF En // APPn 标记,可选
DQT :0xFFDB //Define Quantization Table,定义量化表
SOF0:0xFFC0 //Start of Frame,帧图像开始
DHT:0xFFC4 //Difine Huffman Table,定义哈夫曼表
SOS:0xFFDA // Start of Scan,扫描开始 12字节
压缩数据
JPEG EOI : FF D9 // 图片结束
压缩数据
JPEG EOI : FF D9 // 图片结束
开始猜测是否是由于缺少了结束标记导致的,于是我找了一张图。
去掉了最后的结束标记,事实证明并没有导致崩溃,但是却意外发现,如果只删除最后的结束标记会导致微信安卓版无法发送图片,并且安卓自带的相册无法显示图片。
如果发送给朋友则会直接发送失败,一致卡在0%。
并且这个图无法发布到朋友圈。
图片的这个样式其实在网络状态较差的情况下还是挺容易发现类似的现象的,如果网络有问题图片在加载的过程中就会出现只显示一半的情况。那么实际这个图的原始大小应该远大于1.5m应该是丢失了部分数据。按照画面比例实际丢失的数据大约有2/3。但是至于为什么崩溃猜测可能和系统解析jpeg的库有关,昨晚想调试下,结果发现下载的支付宝咂壳不完整,monkeydev无法正常编译安装,手头也没越狱的设备只好作罢。
猜了一下可能的原因:
图片格式要求jpeg,
数据长度
图片的宽高
上午的时候收到消息说现在可以随意构造图片了, 并且发了个图过来。试了一下确实同样会导致重启。对比了一下发现两个图片的数据头部是一样的,也就是说后来的这张图与最开始的图除了图片的数据不一样其他的数据都是一样的。现在还不知道具体是在解析那些数据的时候出现了问题,但是可以肯定的一点是,基于这个文件头可以构造别的图片了。
由于jpeg包含了分辨率,位深度, 单位分辨率相关信息,所以在构造这个图片的时候要保证数据来源图片的分辨率和原始图片的一致:
如果不一致可以使用ps等软件进行格式和分辨率转换。
两者一致之后剩下的工作就比较简单了,就是替换图片的scandata字段。该字段从FFDA(偏移850h)开始,到结尾的FFD9(偏移18CFF0)结束.
建议使用010 editor来进行处理,找到要替换数据的scandata字段,复制,粘贴到旧文件的scandata字段,删除18CFF0之后的数据保存即可。
测试图片链接:http://hlzjc.gdcyl.org/kindeditor/attached/image/20170627/2017062715330265265.jpg
合成之后的效果:
并且这个数据并不是必须是真实的数据,直接权0填充掉scandata也是可以的:
这样一个能让iOS重启的图片就做好了,如果有条件可以找个iOS设备调试下看看具体的崩溃地址,这个崩溃太及时了,系统没有办法记录app的崩溃日志,所以要看崩溃日志貌似也只能调试,等再有时间了拿真机去调试下看看。
具体图片请查看看雪的附件
参考链接: https://blog.csdn.net/shelldon/article/details/54144406
原始地址:https://bbs.pediy.com/thread-251582.htm
1 comment
随便来逛逛,好久没来了,