I have written a Java program to zip files and to unzip them in an unzipping C program called Junzip.
https://github.com/jokkebk/JUnzip. I'm able to unzip the file using 7zip file extractor. But when using C Junzip, its not unzipping.
But when I'm unzipping the file, which was zipped using normal file compressor, I'm able to unzip it using the same jUnzip library.
Author of the JUnzip library here, just came across this question. Did I understand correctly that .zip files made by your program unzip correctly with 7zip, but not with JUnzip, whereas JUnzip seems to be able to uncompress .zip files made by others?
Without further info, it's hard to say if there's a .zip feature you are using that JUnzip does not support, or if there's a bug in JUnzip. One possible reason is that the library and junzip.exe only supports a limited set of compression methods, namely Deflate that is supported by zlib library it uses. The code base is rather small so you could probably add a few debug statements to see where it goes wrong.
You can check out https://codeandlife.com/2014/01/01/unzip-library-for-c/ for some details regarding JUnzip.
Related
Curiosity is one of my personal keys. I got a folder of an executable c application, this folder include many files some are files.so , files.ini and other files.lz and I decided to try do some kind of reverse engineering, so I have used a reverse engineering online tool for the files.so and files.ini are already opened via notepad as we all know, but now my problem is about opening files.lz, which i already know that it contains libraries to be used for functions on files.so
This is what i want to know and to have some help in it how can I decompress it via a desktop tool or even an online tool?
Should be Lzip.
When you are in the linux-world, one very usefull commands is file:
$ file myFile.lz
myFile.lz: lzip compressed data, version: 1
I have gcc in my Win8 path and can compile C files from the Windows command prompt which is great and I have been compiling regularly in this way but just now I have been looking at creating a makefile to use and compile with.
My first makefile failed as I created makefile.txt but when I removed the file .txt extension the compile worked successfully with the make command at the cursor in cmd console.
The makefile then has no file extension and my query is how the xxxx does this work? Windows obviously knows what this file is and uses it with gcc to compile but how/why? This leads on to another question ...are there other files made with no file extension that do stuff on Windows (or other OS)? I'm perplexed and intrigued and would appreciate a technical explanation if possible.
Thanks.
EDIT...Sat 291114
I am working through Learning C the hard way by Zed Shaw and this image shows Ex2 creating a makefile on my Win8 PC..
It works because the make program is written to look for files named makefile, not files named makefile.txt.
Extensions are important on Windows so that Windows can guess what "type" of file it is, so if you tried to open that file Windows could guess at what program should be used to open it.
However, this is really a problematic solution. First, just because two files have an extension of "foo" doesn't mean both are the same type of file; there's no central authority of file extensions (that I'm aware of) to guarantee there are no conflicts. Second, just because a file has an extension "foo" doesn't mean the contents are of that type: I'm sure you're familiar with viruses and scams where a file of one type is created with a different extension to trick Windows into running an unexpected program.
On traditional UNIX-based systems the "type" of a file is usually derived from the contents of the file, not the extension. There are some obvious exceptions, for example source files are all plain text files so they have the type of code it is (C, C++, Java, Python, etc.) marked by the extension. But on UNIX systems, for example, programs do not have .exe extensions: for example it's just make, not make.exe. Also a shell script doesn't have to end in .bat or .com: it can be just named foo as well if you want. For executable files the operating system looks at the first two bytes of the file to tell what kind of executable it is. For scripts the first two bytes must be #!: then the operating system knows it needs to run an interpreter (like the shell, or Python, or whatever) for the script.
For non-executable files like JPG or whatever, programs can determine their type by examining the contents. Most file types have some format to their content that can be used to say "this is a JPG file", "this is a MP3 music file", etc.
I am confused a bit about .bin files. Basically in Linux we use elf, .ko type of files for upgrading the box or to copy in it . But, while upgrading a NAND flash in router or any Networking Gaint products why always .bin files is preferred. Is this is something like converged mix of all the OS related files. Does it possible to see the contents of a bin file. How to play with it. It is something like contents of BootROM. How is is prepared? How do we create and test on this. How Linux support for this. Any historical reasons behind this?
Speaking about routers, those files are usually just snapshots of a router's flash memory, probably compressed and with some headers added. Typical things are a compressed squashfs image or simply gzip'ed snapshot of memory.
There is no such thing as .bin format, it's just a custom array of bytes and every vendor interprets it in some vendor-specific way. Basically this extension means “it's not your business what's in the file, our device/software will handle it”. You can try to identify (thnk, reverse-engineer) what's actually in those files by using file utility or just looking at those files through a hex editor and trying to guess what's going on.
Firefox store its default configuration information in omni.jar (older version) or omni.ja (later versions). Both omni.jar and omni.ja just are zip file format. So we can use many programs/libraries to compress or decompress them.
I want to get some default information of Firefox. So I must read some file in those omni file. I have used 7zip program to see the content of omni or MiniZip/Zlib library to read omni in my program.
With later version, omni.ja, it is read well. But with older versions, MiniZip cannot open the omni.jar file. Then I use 7zip to open those file: omni.ja was ok, omni.jar was fail. But with some other program, ex: WinRar, WinZip, ... both omni file is opened well.
I was google and get some information: with older version, Firefox has created the omni.jar file (a zip file format) with no zip standard. blah blah. But why WinRar or WinZip can read.
Anyone can help me to get MiniZip read omni.jar file with no error?
Thank you very much.
The solution is pretty simple: Your "old" omni.jar is broken. My omni.jar starts with PK.
I suggest to download Firefox from the official archive once more.
[EDIT] It seems that different builds of Firefox use different tools to built the ZIP archive. The en-US version uses a ZIP-like format which doesn't start with PK. While in theory the file format is valid (it contains data followed by the list of entries), almost no tool really supports this format (so WinZIP and WinRAR are the exceptions).
This intention is reflected by the rename of omni.jar to omni.ja: It's not encrypted, it's just a ZIP format that isn't widely supported and the US Firefox developers don't want to change this.
The other developers (for example for the de version) use official tools to build the omni archive so those versions can be modified with any tool.
You will need to find a way to update the archive using WinZIP / WinRAR or you need to download the original firefox sources and add your patches to the build process.
I want to essentially make it so that you never need to unzip/unrar any files. Currently, I have a Dokan filesystem which can do it given a specific zip file but I wanted to know how I can make it apply to all files. Meaning, I want to be able to compile a program that has "fopen("test.zip/1.jpg", "rb");". I think that a Shell Extension would work for dynamically loading the file into the filesystem IF I were browsing in the shell explorer but that doesnt help me with the fopen example. Any ideas?
What you want to do can be used with help of file system filter driver, which would track directory enumeration requests and report directories in place of ZIP files. Then this driver would create virtual files and take the data from ZIP archives. Quite a lot of kernel-mode work, I should say. And file system filter driver is not a file system driver, so dokan won't help you at all.