junrar / junrar Goto Github PK
View Code? Open in Web Editor NEWPlain Java unrar library
License: Other
Plain Java unrar library
License: Other
Hello my used in code
try{
Junrar.extract("/storage/emulated/0/Download/rarlng_android.rar", "/storage/emulated/0/Download/");
}catch(Exception e){
Toast.makeText(getApplicationContext(), e.toString(), Toast.LENGTH_SHORT).show();
}
End app me Error not The file is not extracted
If you can help me and send me a Java code, I can extract it in the file path. Thank you. I am waiting for your reply.
Describe the bug
When initializing an archive to read its headers :
try (InputStream fi = FileHelper.getInputStream(context, file); BufferedInputStream bis = new BufferedInputStream(fi, BUFFER)) {
Archive input = new Archive(bis);
}
Junrar loads the whole RAR file into memory (see screencap below), which isn't shocking in a desktop environment, but causes issues in a mobile environment (Android) where resources are more scarce. Some of my users gets OOM crashes because of that, when trying to read big files.
Stracktrace after an OOM for a 510MB RAR file
Fatal Exception: java.lang.OutOfMemoryError: Failed to allocate a 528 byte allocation with 63984 free bytes and 62KB until OOM, target footprint 536870912, growth limit 536870912; failed due to fragmentation (largest possible contiguous allocation 443285504 bytes) at com.github.junrar.io.RandomAccessInputStream.readUntil(RandomAccessInputStream.java:106) at com.github.junrar.io.RandomAccessInputStream.read(RandomAccessInputStream.java:72) at com.github.junrar.io.RandomAccessInputStream.readFully(RandomAccessInputStream.java:93) at com.github.junrar.io.SeekableReadOnlyInputStream.readFully(SeekableReadOnlyInputStream.java:51) at com.github.junrar.io.RawDataIo.readFully(RawDataIo.java:75) at com.github.junrar.Archive.readHeaders(Archive.java:312) at com.github.junrar.Archive.setChannel(Archive.java:178) at com.github.junrar.Archive.setVolume(Archive.java:675) at com.github.junrar.Archive.<init>(Archive.java:128) at com.github.junrar.Archive.<init>(Archive.java:157)
Memory monitor when loading a 285MB RAR file with the code snipped above
NB : loading happens twice because my code calls it twice 😉
Expected behavior
Junrar should only load what's useful in memory (e.g. headers, binary data of files to unrar), not the entire file.
File
Same on any RAR file
Environment (please complete the following information):
From List contentDescriptions = Junrar.getContentsDescription(testDocuments), can I get an input stream for a specific contentDescription?
In my case, making an Archive with 1. and then iterating through the files finds N number of files, but using 2. and iterating through finds 4N files.
InputStream inputStream = new FileInputStream(file);
final Archive archive = new Archive(inputStream);
final Archive a = new Archive(new FileVolumeManager(file));
The iteration is along the lines of:
while (true) {
FileHeader fh = a.nextFileHeader();
if (fh == null) {
break;
}
String path = fh.getFileNameString();
if (path.toLowerCase().contains("some_text")) {
try {
// Do something
} catch (IOException e) {
// Do something else
}
}
}
It's plausible that when using a InputStream, the next file header from the archive ends up being null one sooner than it should be.
I have rar archive (http://qsp.su/index2.php?option=com_sobi2&sobi2Task=dd_download&fid=460&format=html) When i try to extract it on android:
public static boolean unrar(Context context, DocumentFile rarFile, File gameDir) {
try (InputStream in = context.getContentResolver().openInputStream(rarFile.getUri())) {
try (Archive archive = new Archive(in)) {
FileHeader fileHeader;
while ((fileHeader = archive.nextFileHeader()) != null) {
final FileHeader fh = fileHeader;
extractEntry(
fh.getFileName(),
fh.isDirectory(),
gameDir,
out -> archive.extractFile(fh, out));
}
return true;
}
} catch (Exception ex) {
logger.error("Failed to extract a RAR archive", ex);
return false;
}
}
private static void extractEntry(
String entryName,
boolean entryDir,
File gameDir,
ThrowingStreamWriter writer) throws Exception {
String normEntryName = entryName.replace("\\", "/");
if (entryDir) {
createDirectories(gameDir, removeTrailingSlash(normEntryName));
return;
}
File parentDir = getParentDirectory(gameDir, normEntryName);
String filename = getFilename(normEntryName);
File file = createFile(parentDir, filename);
try (FileOutputStream out = new FileOutputStream(file)) {
writer.accept(out);
}
}
@FunctionalInterface
private interface ThrowingStreamWriter {
void accept(FileOutputStream stream) throws Exception;
}
}
I get an exception:
02-20 01:39:42.903 32078 431 E Quest Player:ArchiveUtil: com.github.junrar.exception.CrcErrorException
02-20 01:39:42.903 32078 431 E Quest Player:ArchiveUtil: at com.github.junrar.Archive.doExtractFile(Archive.java:594)
02-20 01:39:42.903 32078 431 E Quest Player:ArchiveUtil: at com.github.junrar.Archive.extractFile(Archive.java:534)
Please fix this issue,because winrar for windows extract it without any problems.
Describe the bug
Unpack.window
is null during Archive.extractFile()
if the archive is solid, which results in a NullPointerException
.
Stacktrace:
java.lang.NullPointerException: Attempt to write to null array
at com.github.junrar.unpack.Unpack.unpack29(Unpack.java:249)
at com.github.junrar.unpack.Unpack.doUnpack(Unpack.java:116)
at com.github.junrar.Archive.doExtractFile(Archive.java:587)
at com.github.junrar.Archive.extractFile(Archive.java:534)
...
This seems to be a result of Unpack.init()
only called when hd.isSolid()
return false
, and Unpack.init()
seems to be the only wait to intialize Unpack.window
which is used unconditionally in Unpack.unpack29()
.
junrar/src/main/java/com/github/junrar/Archive.java
Lines 682 to 684 in 178fd7e
To Reproduce
Use junrar to extract a file inside a solid archive, such as https://www.rarlab.com/themes/RARaddin_48x48.theme.rar .
In my case I'm using my own app Material Files to reproduce but I think any user of this library should encounter the same issue.
Expected behavior
Solid archives should be extractable and shouldn't cause a NullPointerException
.
File
https://www.rarlab.com/themes/RARaddin_48x48.theme.rar
Environment (please complete the following information):
Additional context
请问这个问题怎么解决!
The project has not been very well maintained over the past years, i would like to make it easier to contribute.
I have setup a branch modernize
to perform all the work needed:
commitlint
/ husky
semantic-release
to JCenter and MavencentralPeople who need Java 6/7 will still be able to use version 4.0.0
.
As mentioned here it would make sense to carve out the VFS functionality into a separate jar.
Because the main project is unmaintained there is a lot of fragmentation.
Lots of forks with different improvements https://github.com/edmund-wagner/junrar/network/members
It would be nice to scan them and reproduce improvements on this fork.
Describe the bug
A carefully crafted RAR archive can trigger an infinite loop while parsing the file. This could be used to mount a denial of service attack against services that use junrar.
To Reproduce
InputStream inputStream = new FileInputStream("path/to/these/files");
final Archive archive = new Archive(inputStream);
while (true) {
FileHeader fileHeader = archive.nextFileHeader();
if (fileHeader == null) {
break;
}
archive.extractFile(fileHeader, OutputStream.nullOutputStream());
}
Expected behavior
Infinite loop.
File
loops.zip
Environment (please complete the following information):
Additional context
These files can trigger the same while loop mentioned in this issue.
Describe the bug
Error unpacking large file(>2G).
To Reproduce
When unpacking a large file(>2G),The program will report an error.
Expected behavior
I want to be able to unzip large files.
File
If possible, please attach or provide a link to the RAR file.
On line 124 of RandomAccessInputStream.readUntil() function ,the 'length' variable is int, wen the file length is large then Integer.MAX_VALUE, the 'length' variable whill be negative, then the program will not read the content.
Environment (please complete the following information):
Additional context
Function RandomAccessInputStream.readUntil() put what you read in a vector, when the file is too large may happen OOM.
Describe the bug
He there .
I am trying to extract some rar files here is an example
The file was successfully extracted but i got this error
com.github.junrar.exception.CrcErrorException
at com.github.junrar.Archive.doExtractFile(Archive.java:591)
at com.github.junrar.Archive.extractFile(Archive.java:531)
at com.github.junrar.LocalFolderExtractor.extract(LocalFolderExtractor.java:52)
at com.github.junrar.Junrar.tryToExtract(Junrar.java:180)
at com.github.junrar.Junrar.extractArchiveTo(Junrar.java:154)
at com.github.junrar.Junrar.extract(Junrar.java:54)
at com.github.junrar.Junrar.extract(Junrar.java:46)
at ixidev.shamela.data.filedownloader.FileDownloaderKtTest.extractRarFile(FileDownloaderKtTest.kt:73)
at java.lang.reflect.Method.invoke(Native Method)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at androidx.test.internal.runner.junit4.statement.RunBefores.evaluate(RunBefores.java:80)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at androidx.test.internal.runner.TestExecutor.execute(TestExecutor.java:56)
at androidx.test.runner.AndroidJUnitRunner.onStart(AndroidJUnitRunner.java:395)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:2204)
And here is my code is an Instrumented test on Android studio
@Test
fun extractRarFile() {
val bookId = 151016
val appContext = InstrumentationRegistry.getInstrumentation().targetContext
val inputStream = appContext.assets.open("$bookId.rar")
val tempFolder = File(appContext.cacheDir, "$bookId")
tempFolder.deleteOnExit()
tempFolder.mkdir()
Junrar.extract(inputStream, tempFolder)
val extract = tempFolder.list()!!
assertEquals(extract.size, 1)
}
Expected behavior
The rar file contain a file with Arabic name, I thing the error comes from here
File
rar file
Environment (please complete the following information):
Thanks
Hi. We are receiving this information in System.err:
[ESMTPS004] WARN com.github.junrar.Archive - Support for rar version 5 is not yet implemented!
[ESMTPS004] WARN com.github.junrar.Archive - exception in archive constructor maybe file is encrypted, corrupt or support not yet implemented
com.github.junrar.exception.UnsupportedRarV5Exception
at com.github.junrar.Archive.readHeaders(Archive.java:353)
at com.github.junrar.Archive.setChannel(Archive.java:198)
at com.github.junrar.Archive.setVolume(Archive.java:778)
at com.github.junrar.Archive.<init>(Archive.java:148)
at com.github.junrar.Archive.<init>(Archive.java:177)
....
Is it possible to disable this logging?
Describe the bug
Not all projects depends on LoggerFactory
. Such general purpose library should not force to using any library that not strictly necessary for work.
To Reproduce
junrar
dependency onlyArchive
class: new Archive(new File("file.rar"))
Expected behavior
Object must be created, no exceptions expected
Environment (please complete the following information):
When decopressing multi part file, if the last file in xxx.part1.rar has no data in next volume, there will not go on decompressing xxx.part2.rar
There are different, mutually excluding licenses on some files GPL (/junrar/src/main/java/com/github/junrar/Volume.java).
Not sure how to solve this.
Many parts of the code need refactor, but first tests must be added to ensure the code still functions as expected.
I'm sorry, byt #11 is not enougth for complete Hadoop based unrar soultion.
Output folder should also be something like org.apache.hadoop.fs.Path.
And one another thing; sometimes we have a huge .rar file, where only 10% of packaged files should be unpacked. It will be great if we could have some filtering capabilities. Like Stream, so that we can iterate it and filter, map elements to OutputStream, and unpack only filtered files.
And, if we can have #2 implemented as mapping function from FileHeader to OutputStream, then we probably can implement #1 using this function only.
The current implementation doesn't work when trying to extract a multipart archive from a stream.
It should be possible to have it working, but it would require to provide all of the the input streams in order.
Describe the bug
Reading an archive with an empty file is throwing an IllegalArgumentException.
To Reproduce
try (final var archive = new Archive(Path.of("file.rar").toFile())) {
while (true) {
final var fileHeader = archive.nextFileHeader();
if (null == fileHeader) {
break;
}
final var outputStream = new ByteArrayOutputStream();
//archive.extractFile(fileHeader, outputStream); // OK
archive.getInputStream(fileHeader).transferTo(outputStream); // IllegalArgumentException: Pipe Size <= 0
System.out.println(outputStream);
}
}
Expected behavior
Should return an empty InputStream instead of throwing an IllegalArgumentException.
File
file.rar.zip
(need to extract the ZIP file to get the RAR inside)
Environment (please complete the following information):
Additional context
None
Hi @andrebrait ,
i feel like #76 introduced a bug around FileHeader
times.
I'm running ArchiveTest.ExtendedTimeTest
and i get different mtime
depending on the default timezone:
Timezone: Asia/Kolkata
mtime as Date: Wed Feb 23 10:24:19 IST 2022
mtime as FileTime: 2022-02-23T04:54:19.1915433Z
Timezone: America/Los_Angeles
mtime as Date: Wed Feb 23 10:24:19 PST 2022
mtime as FileTime: 2022-02-23T18:24:19.1915433Z
Timezone: Europe/Amsterdam
mtime as Date: Wed Feb 23 10:24:19 CET 2022
mtime as FileTime: 2022-02-23T09:24:19.1915433Z
Timezone: America/Sao_Paulo
mtime as Date: Wed Feb 23 10:24:19 BRT 2022
mtime as FileTime: 2022-02-23T13:24:19.1915433Z
Here is what rar
command line gives me for that file:
Name: files/test/short-text.txt
Type: File
Size: 22
Packed size: 22
Ratio: 100%
mtime: 2022-02-23 10:24:19,191543300
ctime: 2022-02-23 10:34:59,759754700
atime: 2022-03-02 18:45:18,694091100
Attributes: ..A....
CRC32: 8A3BE83B
Host OS: Windows
Compression: RAR 1.5(v29) -m0 -md=128K
However in the test comment i see:
Original timestamps:
MTime: 2022-02-23T09:24:19.191543300Z
CTime: 2022-02-23T09:34:59.759754700Z
ATime: 2022-03-02T17:45:18.694091100Z
which is different from what the rar
CLI gives me.
FileTime
doesn't have a timezone AFAIK, and thus should be timezone insensitive.
What do you reckon?
When running mvn test
with Maven 3.5.2 and Java 8 only the unit tests in the SimpleTest class are executed. The other tests in the JUnRarTestUtil and JunrarTests class are ignored.
I spent quite some time understanding the current organization of the code, here is what i have gathered so far:
Junrar
class which provides only static
methods. Those methods can be considered as helper methods, and remove the need to instantiate the Archive
class.Archive
class, which provide more fine-grained operations, for example to get access to the FileHeader
s directly, or to use the UnrarCallback
to monitor progress, or to have more details on the archive's option, like encryption, solid, etc.On the other side, there are 2 interfaces Volume
and VolumeManager
that helps (via their implementation for File
and InputStream
) to handle RAR archives spanning multiple files.
One problem i have is that some of the Junrar
methods and Archive
constructors accept a VolumeManager
as argument, de-facto exposing this interface in the public API, which means the implementation are also leaking in the client.
Given that both FileVolumeManager
and InputStreamVolumeManager
are just wrappers around File
and InputStream
, those should not be exposed in the public API, which should instead take the native File
(or String
as path) and InputStream
arguments.
It seems most if not all classes are public
at the moment. The underlying implementation should be made private as much as possible.
Hello,
I came across a NullPointerException from the Archive
class which I wanted to bring to your notice. I believe this is happening on a corrupt file or an unsupported version (not really sure)
The problem happens on the file when reading headers, BaseBlock.getHeaderType()
one of the Bytes that it comes across is a 0, hence it returns a null
.
In the Archive
class, there is a switch
case based on the return value from above in the method readHeaders
. The switch case throws a NullPointerException
, I think handling the NPE and returning a RarException would be a better thing to do from here.
I'm attaching a file which can reproduce the issue. The rar in question is inside the zip.
Thanks,
I'm about to fork and use this library on an Android 10 project where all file I/O has been rewritten to use DocumentFile
instead of plain Java File
. We did that in order to work with the Android SAF and comply to scoped storage security constraints.
Thing is, I do know how to change the code to replace File
with DocumentFile
but I have no idea how to properly integrate these changes into the library's structure without introducing Android dependencies that would certainly break stuff for "pure Java" users.
I'd like to ask to those who are familiar with this lib (and with Gradle) what would be the cleanest way to do that. Is there some new module / structure we could set up in Gradle ?
Hello junrar community! Open Source Technology Improvement Fund is piloting out helping critical projects like junrar with their security needs. We have some resources dedicated to helping improve security posture and tooling. I wasn't sure how best to reach out. Please let me know if this sounds interesting and who to connect with. Thank you in advance!
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior.
Expected behavior
A clear and concise description of what you expected to happen.
File
If possible, please attach or provide a link to the RAR file.
Environment (please complete the following information):
Additional context
Add any other context about the problem here.
I am a bit confused about which is the minimum Java version requirement for Junrar. The version in the pom.xml for the maven-compiler plugin is Java 6 (source and target) but the apache-vfs dependency states that the minimum Java version for 2.2 is Java 7 (see https://commons.apache.org/proper/commons-vfs/).
Was the version of apache-vfs raised on purpose to require Java 7 for Junrar and the changes for the maven-compiler-plugin forgotten or did this happen on accident?
Describe the bug
In 7.5.0, the parser is stopping earlier than it did in 7.4.1 without throwing an exception. The exception is logged, but the client has no idea that there was a problem with the file.
To Reproduce
Iterate through the entries...
Archive rar = new Archive(tis.getFile());
if (rar.isEncrypted()) {
throw new EncryptedDocumentException();
}
FileHeader header = rar.nextFileHeader();
while (header != null && !Thread.currentThread().isInterrupted()) {
//DO STUFF
header = rar.nextFileHeader();
}
Expected behavior
Please throw the exception or continue parsing the file as happened in 7.4.1.
File
The file is part of our large regression corpus tests over on Apache Tika. We grabbed this file from Common Crawl. It is possible that it is truncated. My Ubuntu package utility does not like the file. It may actually be corrupted. We were able to get quite a bit more data out of it with 7.4.1.
https://corpora.tika.apache.org/base/docs/commoncrawl3/3X/3X4JRZZ4TQ2GK4QQDQEXMFCVLM3FM5I4
Environment (please complete the following information):
Additional context
Decompiler shows the issue in Archive#setChannel:
try {
this.readHeaders(length);
} catch (UnsupportedRarV5Exception | CorruptHeaderException | BadRarArchiveException | UnsupportedRarEncryptedException var6) {
logger.warn("exception in archive constructor maybe file is encrypted, corrupt or support not yet implemented", var6);
throw var6;
} catch (Exception var7) {
logger.warn("exception in archive constructor maybe file is encrypted, corrupt or support not yet implemented", var7);
}
The exception is:
WARN [main] 19:50:32,239 com.github.junrar.Archive exception in archive constructor maybe file is encrypted, corrupt or support not yet implemented
java.lang.ArrayIndexOutOfBoundsException: 55
at com.github.junrar.io.Raw.readShortLittleEndian(Raw.java:104) ~[junrar-7.5.0.jar:?]
at com.github.junrar.rarfile.FileHeader.<init>(FileHeader.java:192) ~[junrar-7.5.0.jar:?]
at com.github.junrar.Archive.readHeaders(Archive.java:439) ~[junrar-7.5.0.jar:?]
at com.github.junrar.Archive.setChannel(Archive.java:198) ~[junrar-7.5.0.jar:?]
at com.github.junrar.Archive.setVolume(Archive.java:778) ~[junrar-7.5.0.jar:?]
at com.github.junrar.Archive.<init>(Archive.java:148) ~[junrar-7.5.0.jar:?]
at com.github.junrar.Archive.<init>(Archive.java:161) ~[junrar-7.5.0.jar:?]
at org.apache.tika.parser.pkg.RarParser.parse(RarParser.java:75) ~[classes/:?]
at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:281) ~[classes/:?]
at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:281) ~[classes/:?]
at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143) ~[classes/:?]
Describe the bug
On https://search.maven.org/artifact/com.github.junrar/junrar/7.5.2/jar the pom contains a link to UnRar License which returns 404 ( https://github.com/junrar/junrar/LICENSE.md )
To Reproduce
search online in the maven repository.
Expected behavior
The link to the license file in the pom should absolutely be a valid link (i.e. https://github.com/junrar/junrar/blob/master/LICENSE ). Ideally it would be a permalink to the github hash or tag associated with the release so that licensing on old versions are not misrepresented in the future if there is a change to the license. (i.e. https://github.com/junrar/junrar/blob/v7.5.2/LICENSE )
File
Not applicable
Environment (please complete the following information):
Web/browse/build
Hi, I would like to help integrate this project into Google oss-fuzz.
It is a fuzzing service Google provided for automatically testing important open-source repositories.
I've submitted an integration PR to oss-fuzz.
The integration contains the scripts and fuzzers for testing this project.
Are you happy to support this integration?
Additionally, can you provide your email? It will be used to notify you when oss-fuzz found bugs of this project.
Describe the bug
Using inputStream to decompress some huge files causes OutOfMemoryError。
the code like:
InputSteam inputStream = new FileInputStream(file);
Archive arch = new Archive(inputSteam);
All code is run in thread,The reason seems to be readHeaders() method will never reach EndArcHeader on Archive.java.
To Reproduce
NA
Expected behavior
NA
File
http://1pan.top/page/5fa5358d4243e72091c9c7c4
click:"获取下载链接"
Environment (please complete the following information):
Additional context
Describe the bug
Special characters in filenames are not recognized anymore. It was fixed in #34 but the problem is present again in last versions.
To Reproduce
final var file = Path.of("issue.rar");
Junrar.getContentsDescription(file.toFile()).forEach(System.out::println);
Exception in thread "main" com.github.junrar.exception.CorruptHeaderException: Invalid filename: ?.txt
at com.github.junrar.rarfile.FileHeader.<init>(FileHeader.java:170)
at com.github.junrar.Archive.readHeaders(Archive.java:450)
at com.github.junrar.Archive.setChannel(Archive.java:199)
at com.github.junrar.Archive.setVolume(Archive.java:811)
at com.github.junrar.Archive.<init>(Archive.java:149)
at com.github.junrar.Archive.<init>(Archive.java:170)
at com.github.junrar.Junrar.createArchiveOrThrowException(Junrar.java:121)
at com.github.junrar.Junrar.getContentsDescription(Junrar.java:76)
Expected behavior
Should print テ.txt
.
File
issue.zip (extract to get the RAR file)
Environment
There is no one actively maintaining this project.
If anyone who is using this library in an active project have interest in taking over let me know.
Junrar just throws exception (there) when trying to extract from such archive.
Is there any plans to support it?
How to compress ?
When I unrar a .rar file , I got a exception. "exception in archive constructor maybe file is encrypted or currupt", but the rar file is not encrypted , I used winrar.exe version is 5.6, 5.5.
On attempt to extract rar archive version RAR5 the archive is locked.
Version 3.1.0, call:
File arch = new File(archive);
File dest = new File(destination);
Junrar.extract(arch, dest);
Exception stack:
Support for rar version 5 is not yet implemented!
exception in archive constructor maybe file is encrypted, corrupt or support not yet implemented
com.github.junrar.exception.RarException: unsupportedRarArchive
at com.github.junrar.Archive.readHeaders(Archive.java:282)
at com.github.junrar.Archive.setFile(Archive.java:153)
at com.github.junrar.Archive.setVolume(Archive.java:631)
at com.github.junrar.Archive.(Archive.java:123)
at com.github.junrar.Archive.(Archive.java:100)
at com.github.junrar.Junrar.createArchiveOrThrowException(Junrar.java:91)
at com.github.junrar.Junrar.extract(Junrar.java:33)
On attempt to delete the archive, the exception is thrown:
java.nio.file.FileSystemException: The process cannot access the file because it is being used by another process
exception:
java.lang.NoClassDefFoundError: Failed resolution of: Ljava/nio/file/attribute/FileTime;
at com.github.junrar.rarfile.FileHeader.(FileHeader.java:203)
solution:
the java.time package was added only in API 26.
https://developer.android.com/reference/java/time/package-summary
And for prior versions, you can use org.joda.time.LocalDate
There's a situation when i encrypted file with winRAR and select the "show password" button on the operation UI(as snapshort.bmp), when extract content from the file(test.rar), it throwed the RarException but the "PipedOutputStream out" parameter has been assigned the wrong value which is encrypted content.
while another encrypted file without selected the "show password" button, when extract it(1534240020.rar), it also thowed RarException but return nothing.
There behavied different at line 191 in ModelPPM decodeInit routine when it begin to unpack the file. But i don't know the reason.
使用fileHeader.getFileNameString()
获取FileName中文会乱码,而使用
fileHeader.getFileNameW()
就不乱码
I have a .rar archive in Hadoop hdfs file system. There is no such thing as java.io.File there.
Above bug occurs when unrar a rar file.The code is copyed from the repository example.
Describe the bug
A carefully crafted RAR archive can trigger an infinite loop while parsing the file. This could be used to mount a denial of service attack against services that use junrar.
To Reproduce
String encodedString = "UmFyIRoHAM+Qcw4AAAAAKgAAAAAXF3QggE4ASwEAACICAAADZXUl9710qkIdNC4ApIEAAF9fTUlDT1NYXC5fYXBwbGUpdG91Y2gtaWNvbi03MC1wcmVjb21wb3NlZC5wbmcJ3RFMy9WBV2REVHpele6iC2cnv5JltbeqElgNF1pFjxFEQOWXhHq2ScsnIV5jb21wb3NlZC6Qcw4AAAAAKgAAAGREVA+VZ3qi7l4nv5Jly7W3qhJYDZDaRcURs78ajbZ7SWjLJyFah8afvQIAAADEvXYBRXwAQAUBBgAAAAAAAC/jZmlgun4oIP1Z4AG7ybwKgFwrlLrUKiSxjkiGPQFX/wAAL/8A////////+SVUCUzV3REly4FXZEReVHqV7qJYZyezxAAAAAAAAL+SZbVft6ruqo0QWkWPEUSMA5dA5QCE+3q2AAAAAAAAAgBJyyMhXocAAAAAAIefGkfCXwV8FHoKlbPhXgA//O5fgDAhAQAAAAAAAABuZphoBm71hnkO4GbmYGm6fs7f/VkAAAACAAFXqLsj6Xd3d3d3d3d3d3dgd3d3d3d3d3d3d3d3V3d3d3d3d3d3d3d3d3d3d3d3d3dzd3V3d3fTd3d3OJIAAABSAHIhGgcAz5BzAAANAAAAAAAAABcXdHkASwEAACICAAAD////////////////////+////////z1ldSV3dw==";
byte[] decodedBytes = Base64.getDecoder().decode(encodedString);
InputStream inputStream = new ByteArrayInputStream(decodedBytes);
final Archive archive = new Archive(inputStream);
while (true) {
FileHeader fileHeader = archive.nextFileHeader();
if (fileHeader == null) {
break;
}
archive.extractFile(fileHeader, OutputStream.nullOutputStream());
}
Expected behavior
Infinite loop.
File
loop-913d3158487310b1b4b74086ab888f5ed56a8493.zip
Environment (please complete the following information):
Additional context
It seems this PoC can reach [this while loop] (
junrar/src/main/java/com/github/junrar/unpack/vm/RarVM.java
Lines 227 to 629 in dc3d299
With the recent work on dev
branch we can decrypt password protected archives, but not yet encrypted archives.
@sunny-shu i think i have found where the salt for the header encryption is located. I have found this website that talk about it (it's in french). The 8 byte salt is located just after the Main Header block. They also have working python code for decryption which confirms the location of the salt.
I think we should refactor the code a bit, because the decrypt code is bundled inside DataComprIO
. Ideally we should split the read code from the channel and the decryption code. Decryption code should be moved to crypt
package in my opinion.
The code in DataComprIO
should look more like: (pseudo-code):
For the Archive class it's a bit more complex, because there are a lot of read
operations in the readHeaders
method. I was thinking we could use a thin wrapper around the channel
to provide transparent decryption.
What do you think?
how can i unrar with password
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.