Open xieqing520 opened 1 year ago
嗯,可以换其他zip库,这里就简单实现了
xieqing520 @.***> 于 2022年8月8日周一 09:44写道:
res混淆之后命名会有 R5.xml r5.xml, M6.xml m6.xml 这些 而当进行zipCopy 解压缩的时候,是先解压到window 再打包windows,打包的时候通过 new File()时 ,R5.xml r5.xml 实际变成了同一个进行打包
这是我加的log write R5 3620 write r5 552 R5 len 552 R5 res/R5.xml C:\Users\大明\Desktop\build.apk_temp\res\R5.xml r5 len 552 r5 res/r5.xml C:\Users\大明\Desktop\build.apk_temp\res\r5.xml 可以看到 解压写出的时候 长度 R5跟r5不一致 但是打包的时候 路径不一致却读的其实是一个文件 长度一样 导致app只要res混淆后 基本就是打不开app 闪退 用不了layout drawable等功能异常
把zipCopy修改一下,不经过解压、再压缩 这个步骤 `private static void zipCopy2(ZipInputStream zipInputStream, File outDir, ZipOutputStream zipOutputStream) throws IOException { final Pattern regex = Pattern.compile( "classes(\d) .dex" + "|META-INF/..(RSA|DSA|EC|SF|MF)" + "|AndroidManifest.xml"); final HashMap<ZipEntry, File> entryNameFileMap = new HashMap<>(); ZipEntry entry; while ((entry = zipInputStream.getNextEntry()) != null) { if (entry.isDirectory() || "".equals(entry.getName())) { continue; } if (regex.matcher(entry.getName()).matches()) { continue; }
try { byte[] fileEntry = FileUtils.read(zipInputStream); final ZipEntry zipEntry = new ZipEntry(entry.getName()); if (entry.getMethod() == ZipEntry.STORED) {//不压缩只储存数据 final long length = fileEntry.length; zipEntry.setMethod(ZipEntry.STORED); zipEntry.setCrc(calcCrc32(fileEntry)); zipEntry.setSize(length); zipEntry.setCompressedSize(length); } zipOutputStream.putNextEntry(zipEntry); zipOutputStream.write(fileEntry); zipOutputStream.closeEntry(); }catch (Exception e){ e.printStackTrace(); } }
}`
就可以解决了
— Reply to this email directly, view it on GitHub https://github.com/maoabc/nmmp/issues/42, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA27LV57J5DCH3U2GP54DUTVYBRAPANCNFSM553NZ7ZA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
zip处理还有那种不需要压缩的资源,在windows下好像也有问题,处理伪加密的apk也有问题。换其他zip库应该能更好的解决这些问题
zip处理还有那种不需要压缩的资源,在windows下好像也有问题,处理伪加密的apk也有问题。换其他zip库应该能更好的解决这些问题
直接不解压缩不就行了吗 原版字节集进行copy
嗯,解压到外部可以省略,应该可以去掉一些bug
没压缩的文件, 感觉也没必要再计算crc, 直接使用原来的, 也就不需要解压到字节数组. 之前重新计算crc是因为发现windows下一些文件解压后, crc会莫名其妙的变动. 现在看来这个估计也是因为不区分文件大小写导致的.
将就下,现在apk打包比早期那种简单的zip操作复杂。java默认的zip库好像也没法处理对齐问题,不压缩.so那种打包目前都做不到。
将就下,现在apk打包比早期那种简单的zip操作复杂。java默认的zip库好像也没法处理对齐问题,不压缩.so那种打包目前都做不到。
en
res混淆之后命名会有 R5.xml r5.xml, M6.xml m6.xml 这些
而当进行zipCopy 解压缩的时候,是先解压到window 再打包windows,打包的时候通过 new File()时 ,R5.xml r5.xml 实际变成了同一个进行打包
这是我加的log
write R5 3620 write r5 552 R5 len 552 R5 res/R5.xml C:\Users\大明\Desktop\build\.apk_temp\res\R5.xml r5 len 552 r5 res/r5.xml C:\Users\大明\Desktop\build\.apk_temp\res\r5.xml
可以看到 解压写出的时候 长度 R5跟r5不一致 但是打包的时候 路径不一致却读的其实是一个文件 长度一样 导致app只要res混淆后 基本就是打不开app 闪退 用不了layout drawable等功能异常把zipCopy修改一下,不经过解压、再压缩 这个步骤 `private static void zipCopy2(ZipInputStream zipInputStream, File outDir, ZipOutputStream zipOutputStream) throws IOException { final Pattern regex = Pattern.compile( "classes(\d)\.dex" + "|META-INF/.\.(RSA|DSA|EC|SF|MF)" + "|AndroidManifest\.xml"); final HashMap<ZipEntry, File> entryNameFileMap = new HashMap<>(); ZipEntry entry; while ((entry = zipInputStream.getNextEntry()) != null) { if (entry.isDirectory() || "".equals(entry.getName())) { continue; } if (regex.matcher(entry.getName()).matches()) { continue; }
就可以解决了