类似下面的，在服务端直接读取服务端的zip包，然后通过http发送到另外一个服务端。
 
public void test(){
    //直接读取zip包
    File file = new File("XXXX.zip");
    FileInputStream fis = new FileInputStream(file);
    //直接上传
    HttpUtils.doPostFile(fis);
}
 
可以这样发送zip包吗？现在的问题就是发送了，但是回传的url下载zip，下载的zip是不完整的，也解压不了，在服务端生成的zip数据上是没有任何问题的，求大佬教教

 
展开全部
 
Java原生解压缩API是无法操作中文的32313133353236313431303231363533e4b893e5b19e31333335323431,你的问题在于没有判断是否是目录或者文件，如果你把目录当成文件写到磁盘，肯定不对package org.xdemo.superutil;
 
import java.io.BufferedOutputStream;
 
import java.io.File;
 
import java.io.FileInputStream;
 
import java.io.FileOutputStream;
 
import java.io.IOException;
 
import java.io.InputStream;
 
import java.io.OutputStream;
 
import java.util.zip.CRC32;
 
import java.util.zip.CheckedInputStream;
 
import java.util.zip.ZipEntry;
 
import java.util.zip.ZipInputStream;
 
import java.util.zip.ZipOutputStream;
 
/**
 
* 文件解压缩
 
* @author 
 
* 252878950@qq.com
 
 
*/
 
 
public class ZipUtils {
 
 
/**
 
 
* 文件解压缩 注意 不能有中文文件名
 
 
* @param zipSrc zip文件路径
 
 
* @param dest 解压的路径，无需以“\\”或者“/”结尾
 
 
* @throws IOException
 
 
*/
 
 
public static void unzip(String zipSrc,String dest) throws IOException{
 
 
//为了适配不同操作系统的文件路径的分隔符
 
 
String systemSeparator=System.getProperty("file.separator");
 
 
System.out.println(systemSeparator);
 
 
CheckedInputStream cis=new CheckedInputStream(new FileInputStream(new File(zipSrc)), new CRC32());
 
 
ZipInputStream zis=new ZipInputStream(cis);
 
 
ZipEntry ze=null;
 
 
FileOutputStream fos=null;
 
 
byte[] buffer=new byte[1024];
 
 
int length=0;
 
 
if(!new File(dest).exists())new File(dest).mkdirs();
 
 
while((ze=zis.getNextEntry())!=null){
 
 
String fileName=dest+File.separator+ze.getName();
 
 
//都替换一遍省心
 
 
fileName=fileName.replace("\\", systemSeparator).replace("/", systemSeparator);
 
 
if(fileName.lastIndexOf(systemSeparator)!=-1)new File(fileName.substring(0,fileName.lastIndexOf(systemSeparator))).mkdirs();
 
 
if(fileName.lastIndexOf(systemSeparator)==fileName.length()-1)continue;
 
 
System.out.println(fileName);
 
 
fos=new FileOutputStream(fileName);
 
 
while ((length=zis.read(buffer))!=-1) {
 
 
fos.write(buffer, 0, length);
 
 
}
 
 
fos.close();
 
 
}
 
 
zis.closeEntry();
 
 
zis.close();
 
 
}
 
 
}
 

处理步骤：
 
1：选择——添加到压缩文件
 
 
2：选择——自定义
 
 
3：在压缩分卷大小中填入你分包后，每个压缩包的最大大小（单位：mb，gb）
 
 
 
 4：结果
 
 
然后就可以但单个当个文件传输了
 
5：解压（选择——解压到“CentOS-7-x86_64-DVD-2009”）
 
必须都在同一个文件夹中，全部选择，再选择解压
 
 
 
 
 6：完成
 
 
 
 
 
 
 
 

 
文章目录
 
1. 压缩包隐写
2. CTF中常见的压缩包套路（这些套路也不一定是单独出现，大多数情况都是组合出现的）
一，利用进制转换隐藏信息
二，作为冗余信息隐藏在其他文件中，将压缩包提取出来。
四，掩码攻击。
五，ZIP伪加密。
六，明文攻击。
七，CRC32碰撞。
八，文件修复
九，冗余信息拼接。
十，注释隐藏密码
   
  
 

 
1. 压缩包隐写
 
  实际上压缩包本身并不具备隐藏信息的功能，但由于在CTF竞赛中，经常出现压缩包与隐写术结合在一起的题目，
  所以我们需要掌握在CTF竞赛中有关压缩包的题目的常见考察方向及分析手段。
 
2. CTF中常见的压缩包套路（这些套路也不一定是单独出现，大多数情况都是组合出现的）
 
  （1） 利用进制转换隐藏信息

  （2） 作为冗余信息或隐藏信息藏在其他文件中，一般是图片

  （3） 简单密码爆破

  （4） 字典爆破/掩码攻击

  （5） 伪加密

  （6） 明文攻击

  （7） CRC32碰撞

  （8） 文件修复

  （9） 冗余信息拼接

  （10）注释隐藏密码4. ZIP文件格式
 

 ZIP文件一般分为 数据区 与 目录区。
 数据区的开头标识为 504B0304 ，而目录区开始的标识为 504B0102，
 以下两图以上面图片显示的压缩包为例，对文件格式进行解析。
 
 
 
一，利用进制转换隐藏信息
 
打开下载的文件，进入demo_1,浏览flag.txt。
 
分析字符串就会发现，这一长串字符串是十六进制字符串，尝试十六进制解码，这里我使用的是Python进行解码，虽然输出了一堆乱码，但是我们还是能看见存在敏感字符“flag.txt”。
 
其实根据字符串的开头“504B0304”就可以判断这串符串是ZIP压缩文件的十六进制值。（这个涉及到ZIP文件格式的详解，会在后面的伪加密中详细解释，只需记住这是ZIP文件的文件标识头，为固定值。）
判断为压缩包后，将其保存为ZIP文件。可以编写脚本进行十六进制解码后保存为ZIP文件，也可以直接使用winhex，这里我使用winhex进行保存。打开winhex后，新建一个空文件，将十六进制字符串复制，右键点击winhex的十六进制数据区，选择“Edit”->“Clipboard Data”->“Paste”->“ASCII hex”，保存为ZIP文件即可，如下图。
 
保存后就可以正常解压了。
 
二，作为冗余信息隐藏在其他文件中，将压缩包提取出来。
 
简单的隐藏在图片后面，即制作图种。（打开文件夹demo_2，其中flag.jpg为已经隐藏了压缩包的图片，timg.jpg为原图片，heetian_LSB.png为使用了LSB算法隐藏压缩包的图片）
 
 
如何实现：使用windows的copy命令即可
 
 2. 使用winhex打开“flag.jpg”，就会发现在jpg图片的结束标识“FFD9”之后，就是ZIP文件的文件标识“504B0304”，而且可以看到flag.txt字样。
 
 3. 解决方式：直接将图片后缀名改为zip，即可解压。
 
 
若是使用隐写算法隐藏在图片中，则需要借助相应的工具，这里以LSB隐写算法为例。
 使用StegSolve找到隐藏的信息。
 
 
 这样就可以解压出来了
 
 三，简单密码爆破
使用工具进行爆破，一般需要爆破的压缩包密码不会复杂，大部分情况都是纯数字，这里使用ziperello对压缩包进行爆破。
打开ziperello，选择要解密的压缩包。
 
点击右下角的“NEXT”，然后选择暴力破解。
选择字符集，一般比赛中使用到爆破的，都是纯数字的密码，且长度较短。
再次“NEXT”，开始爆破，很快密码就爆破出来了。
 
四，掩码攻击。
 
 
掩码攻击的意思，就是已知这个压缩包的密码格式，比如已知它的密码长度为六位，前三位为小写字母，后三位为数字，又或者已经知道这个六位长的密码第三位为“a”，其它位置有数字也有小写字母，根据这些已知的条件，来构造一个符合已知条件的字典，将所有可能的结果列出来，进行爆破。
 
 
进入“demo_4”，先查看readme.txt。得到如下信息
 
 
打开ziperello，选择要解密的文件，第二部选择“基于模板的破解”。
 
 
根据所得的信息构造符合条件的模板，如图所示，“a”，“A”，“#”分别代表一个字符集，也可以双击左边的字符集窗格构建自定义的字符集。密码模板中的“a#A#a#”就是符合已知条件的密码格式。
 
 
开始爆破后，很快便得到解压密码。
 
 
五，ZIP伪加密。
 
 
根据实验开始前的预备知识，我们已经知道ZIP文件格式中存在两个加密标志位，前面的加密标志位为数据区的加密标志位，后面的加密标志位为目录区的加密标志位。所谓伪加密就是修改目录区的加密标志位，使本来没有加密的ZIP文件，在解压的时候，需要用户输入密码来进行解压，但是这个密码又是不存在的。
 
 
我们以同一个压缩文件的无加密、伪加密、真加密三种形式来做比较，如图，红色框为数据区加密标志位，绿色框为目录区加密标志位。从图中的比较我们可以知道，真加密的ZIP文件，两个加密标志位应该都表示加密（一般为前面一位数为奇数即可表示为加密），无加密的ZIP文件，两个标志位均表示没有加密，而伪加密则只有目录区的加密标志位表示为加密（为什么只有目录区呢，我们可以测试，只将数据区的加密标志位改为奇数，选择解压文件时，会发现他还是没有加密的）。
 
 
所以，在判断一个压缩文件为伪加密之后，只需将其目录区的加密标志位前面一位改为奇数即可。
 
 
进入“demo_5”文件夹，解压“flag-伪加密.zip”会发现需要我们输入密码才能解压，使用winhex打开“flag-伪加密.zip”，将图示的0908改为0808（只要将9改为偶数即可）。
 
 
 
此时便可以正常解压
 
 
六，明文攻击。
 
 
明文攻击是一种较为高效的攻击手段，大致原理是当你不知道一个zip的密码，但是你有zip中的一个已知文件（文件大小要大于12Byte）时，因为同一个zip压缩包里的所有文件都是使用同一个加密密钥来加密的，所以可以用已知文件来找加密密钥，利用密钥来解锁其他加密文件。在压缩文件时输入的密码，首先被转换成3个32bit的key，所以可能的key的组合是2^96，如果用暴力穷举的方式是不太可能的，除非密码比较短或者有个厉害的字典。压缩软件用这3个key加密所有包中的文件，所有文件的key是一样的，如果我们能够找到这3个key，就能解开所有的文件。如果我们找到加密压缩包中的任意一个文件，这个文件和压缩包里的文件是一样的，我们把这个文件用同样的压缩软件同样的压缩方式进行无密码的压缩包（这里可以通过比较压缩后文件的CRC32值来判断，如果一样，则使用的是同样的压缩方式和软件），得到的文件就是我们的Known plaintext（已知明文）。用这个无密码的压缩包和有密码的压缩包进行比较，分析两个包中相同的那个文件，抽取出两个文件的不同点，就是那3个key了，如此就能得到key。两个相同文件在压缩包中的字节数应该相差12个byte，就是那3个key了。虽然我们还是无法通过这个key还原出密码，但是我们已经可以用这个key解开所有的文件，所以已经满足我的要求了，得到其中加密的其他文件。更详细的原理请读者自行谷歌。
 
 
进入“demo_6”文件夹，文件夹中存在一个加密的压缩包“明文攻击.zip”和一个“已知明文.jpg”，双击点开压缩包，即可看见压缩包中也存在一个“已知明文.zip”。
 
 
我们对“已知明文.jpg”进行无加密的压缩，然后对比两个压缩文件中“已知明文.jpg”的CRC32值，如果一致，就可以进行明文攻击，如果不一致，则换一种压缩方式继续比较。
 
 
使用工具进行明文攻击，这里使用AZPR进行明文工具。
 
 
 
 
 
攻击成功，得到其他的加密文件。
 
 
七，CRC32碰撞。
 
CRC32:CRC本身是“冗余校验码”的意思，CRC32则表示会产生一个32bit（8位十六进制数）的校验值。在产生CRC32时，源数据块的每一位都参与了运算，因此即使数据块中只有一位发生改变也会得到不同的CRC32值，利用这个原理我们可以直接爆破出加密文件的内容，但是CRC32值也存在被碰撞的可能，也就是会出现内容不一样但是CRC32值一样的情况，所以利用CRC32碰撞的方法得知压缩文件的内容，一般是在被压缩的文件很小的情况下，在CTF中一般为4个字节。
 
 CRC简介
 
在数据传输过程中，无论传输系统的设计再怎么完美，差错总会存在
这种差错可能会导致在链路上传输的一个或者多个帧被破坏(出现比特差错，0变为1，或者1变为0)，
从而接受方接收到错误的数据。
为尽量提高接受方收到数据的正确率，在接收方接收数据之前需要对数据进行差错检测，
当且仅当检测的结果为正确时接收方才真正收下数据。
检测的方式有多种，常见的有奇偶校验、因特网校验和循环冗余校验等。
循环冗余校验是一种用于校验通信链路上数字传输准确性的计算方法（通过某种数学运算来建立数据位和校验位的约定关系的 [1]  ）。
发送方计算机使用某公式计算出被传送数据所含信息的一个值，并将此值 附在被传送数据后，
接收方计算机则对同一数据进行 相同的计算，应该得到相同的结果。
如果这两个 CRC结果不一致，则说明发送中出现了差错，接收方计算机可要求发送方计算机重新发送该数据。

在计算机网络通信中运用CRC校验时相对于其他校验方法就有一定的优势。
CRC可以高比例的纠正信息传输过程中的错误，可以在极短的时间内完成数据校验码的计算，
并迅速完成纠错过程，通过数据包自动重发的方式使得计算机的通信速度大幅提高，对通信效率和安全提供了保障。
由于 CRC 算法检验的检错能力极强，且检测成本较低，因此在对于编码器和电路的检测中使用较为广泛。
从检错的正确率与速度、成本等方面，都比奇偶校验等校验方式具有优势。
因而，CRC 成为计算机信息通信领域最为普遍的校验方式。
 
进入“demo_7”文件夹，文件夹中存在四个加密的压缩包，并且有一定的命名顺序，readme.txt文件中表明被压缩的文件中的内容为base64编码的字符串。可以看见每个压缩文件内的文件大小均为四个字节，即文件内容为四个字节长度的字符串。
所以使用CRC碰撞的方法循环碰撞出所有压缩文件的内容并按顺序拼接即为最终的答案，运行目录下的CRC32.py脚本，最后会生成一个flag.txt文件，文件的内容即为最终的答案。
关于对脚本的解释，都在代码的注释中。
 
八，文件修复
 
 
这个常见的套路也是跟文件的格式有关，一般都是修改ZIP文件的开始标识，使得在解压文件时产生错误，无法解压。
 
 
进入“demo_8”文件夹下，尝试解压 “flag.zip”，会报错。
 
 
使用winhex打开这个压缩文件进行查看，会发现文件头有些异常，从预备知识中我们知道ZIP文件的头部标识为“504B0304”，且为固定值，所以我们将其修改回来，即可进行正常解压。
 
 
九，冗余信息拼接。
 
 
从预备知识中我们知道，ZIP压缩文件目录结束标识位为“504B0506”，且通常带有18字节（在预备知识中我们将每个偏移量视作一位，也是一个字节）的冗余数据，总共长度一般为22个字节，所以这个套路就是将隐藏信息分为多片隐藏在多个压缩包的结尾。
 
 
进入“demo_9”文件夹下，有四个压缩文件，解压后文件内容为空。使用winhex打开这些压缩包，发现每个压缩包的最后都有三个字节的冗余数据。
 
 
 
将这些冗余数据复制取出（选中多出来的数据，右键选择Edit -> Copy Block -> Normally），拼接后得到base64字符串，解码后得到答案。
 
 
十，注释隐藏密码
 
进入“demo_10”文件夹下，双击打开flag.zip，会发现旁边多出了一个注释框，而这个注释框只有在这个压缩文件存在注释的情况下才会显示。
 
但是并没有看见注释框中有什么内容，尝试下拉右边的下滑条，发现先一个字符串。
猜测为压缩文件的解压密码，复制输入到密码框中，成功解压。