I have a need to handle various rar/zip files, in Objective-C. Ideally I'd like to be as flexible as possible in terms of rar/zip versions. I'd also like to be able to only extract certain files from the rar/zip files, after pulling out a list of the file contents.
If that wasn't enough, I'd like to be able to access and modify the zip comment.
Is this easily possible in objective-c? I've searched around a lot and found a lot of half-finished libraries that don't do everything I want, or only support rar up to version 2, or don't support extracting single files.
I know I could just use the command line unzip tool that ships with MacOS Panther and up, but this seems inelegant and doesn't help me with rar files, as no unrar application ships with MacOS by default.
Can anyone point me at a decent library that does one or the other of these two types of files, or a recommended best approach for dealing with this problem? I know that one option is to wrap the unrar source, and also wrap the zlib source, but this to me is a daunting task. If there's no other option I'll do it - any advice or guidance on this would be gratefully received.
Thanks!
Yes, doing that it's easy in objective C. For zip files just use ZLIB (it's already included in Mac OS X.
RAR is not that simple though. Look for a C library (not an Objective-C library). There will be way more C libraries for RAR handling than Objective-C ones. And you can use all C libraries you want within an Objective-C program.
Related
It is possible to extract executable files??
If it is what are the possible software may i use?
it depends how deep you want to dig into the executable and what kind of data you need from the exe.
As with all exe files you can analyse them on a low level. But I assume you want to have a high-level tool to get back the director files that were used to create the exe, right?
For the exe-file (the "projector" to use the appropriate director wording) there is no such tool known to me.
But very often the exe file is used together with files with extensions such as .dxr or .dir. Those are director files. DXR-Files are protected. But by importing them into director you can extract some of the cast memebers (graphics etc.) that are included. You need in-deep knowledge of lingo to do so.
You might also find .cst or .cxt files. Those are cast files. They can hold media, scripts etc. too. CXT are the protected versions. For these files the same is true as for the DXR and DIR files.
All in all - it is not easy and your chances are low to completly reveal all code and media. Most director programmer use the protected files for distributing their programs. Those do not allow to reveal all data included.
This Python script extracts Macromedia / Adobe Director movies and casts
from Windows and Mac executables.
https://github.com/n0samu/director-files-extract
I'm looking for a way to patch Mach-o Binaries, although I've come up short of possible (and not too tedious) ways of accomplishing this. I'm very familiar with hex editing and patching bytes by hand, although ultimately what I really need is a way to create a drag'n'drop method of doing this via a compiled Xcode Cocoa application.
Any example, or even better, an actual usable Xcode project template to get start would be very helpful.
If I wanted to do this kind of thing, I'd start with HexFiend. Then I'd look up the implementation of dyld and otool in the Darwin source repository and the Mac OS X ABI Mach-O File Format Reference
If you want to programmatically deal with the Mach-O file format to access load commands, segments, sections and more, you should use libMachObjC which is part of the class-dump project. The API is very easy to use.
Have a look at the deprotect tool source code for an example of reading a Mach-O file, patching some bytes and writing the modified file to disk.
In Mathematica, one can save intermediate results / the partial state of the workspace with Save (.m files) or DumpSave (.mx files）.
.m files are portable, but are very slow to load (with large data).
.mx files are fast to load, but are not portable between platforms/architectures.
Is there a way to save generic Mathematica expressions in a way that loading them is fast, and they're portable between platforms? Has anyone experimented with / benchmarked different methods to do this?
One possible solution is to save .m files (cross-platform), then convert them to .mx files when starting work on a new platform (a one-time operation). Is there a fully automatic way to convert .m files to .mx files?
From the posts Alexey linked:
str=OpenWrite[file,BinaryFormat->True];
BinaryWrite[str,Compress[expr],"TerminatedString"];
Close[str];
This is not quite as fast as using an mx file, but it is still very fast.
David Bailey
Another alternative seems to be WDX (Wolfram Data eXchange) which I am
using without problems on a variety of machines and which also seems to
be portable, can be used exactly like MX files, is binary, is documented
and thus I would consider officially supported. And it is used by the
data paclet functionality, so I guess it is reasonably performant and
well tested on all systems (an assumption which my experience does
support up to now).
(excerpt from answer by Albert Retey, also from Alexey's link)
But these do not work as Save/DumpSave does, in that it does not save the FullDefinition of expr, only the explicit value of expr.
I would like to test (and validate) an application that analyses executable files obfuscated with UPX, ASProtect, PECompact, etc... Does someone knows a place where I can find (dummy) samples apps obfuscated with different algorithms?
Many software use packers to compress/obfuscate their binaries. However, instead of searching for such already obfuscated applications, I think you can download packers and obfuscate some application by yourself. You can then use these packed binaries for testing/validating PE analyzer. Some of the well known packers are:
http://upx.sourceforge.net/
http://www.bitsum.com/pecompact.php
http://www.aspack.com/asprotect.html
I noticed that Apple started using zip archives to replace document packages (folders appearing as a single file in Finder) in the iWork applications. I'm considering doing the same as I keep getting support emails related to my document packages getting corrupted when copying them to a windows fileserver.
My questions is what would be the best way to do this in a NSDocument-based application?
I guess the easiest way would be to create a directory file wrapper, create an archive of it and return it in NSDocument's
- (NSFileWrapper *)fileWrapperOfType:(NSString *)typeName error:(NSError **)outError
But I fail to understand how to create a zip archive of the NSFileWrapper.
If you just want to make a zip file your format (ie, "mydoc.myextension" is actually a zip file), there's no convenient, built-in Cocoa mechanism for creating zip archives with code. Take a look at this Google Code project: ziparchive I don't believe a file wrapper will help in that case, though.
Since you cited iWork, I don't own iWork 09, but previous versions use a package format (ie, NSFileWrapper would be ideal) but zip the XML that describes the document's structure, while keeping attachments (like embedded media, images, etc.) in a resource folder, all within the package. I assume they do this because XML can be quite large for large, complicated documents, but compresses very well because it's text. This results in an overall smaller document.
If indeed Apple has moved to making the entire document one big zip archive (which I would find odd), they'd either be extracting necessary resources to a temp folder somewhere or loading the whole thing into memory (a step backward from their package-based approach, IMO). These are considerations you'll need to take into account as well.
You’ll want to take the data from the file wrapper and feed it into something like ziparchive.
Pierre-Olivier Latour has written an extension to NSData that deals with zip compression. You can get it here: http://code.google.com/p/polkit/
I know this is a little late to the party but I thought I'd offer up another link that could help anyone that comes across this post.
Looks like the ZipBrowser sample from Apple would be a good start http://developer.apple.com/library/mac/#samplecode/ZipBrowser/Introduction/Intro.html
HTH