Is there any programmatic way to safely check whether if an epub file is DRM-protected (encrypted)?
I have found that there might be a rights.xml and an encryption.xml in the META-INF directory.
Does the existance of any or both of these files mean that the content is encrypted and if not, is there any other way to check?
(To be clear, I do not want to read ePubs with DRM at all, I just want to check whether they are encrypted or not.)
FWIW the Wikipedia epub article states
When present, DRMed EPUB files must contain a file called rights.xml within the META-INF directory at the root level of the ZIP container.
epubcheck as of v1.0 is reported to detect DRM-protection via the existence of encryption.xml and report an error. The epub3 spec says
An optional encryption.xml file within the META-INF directory at the
root level of the container file system holds all encryption
information on the contents of the container. This file is an XML
document whose root element is encryption. The encryption element
contains child elements of type EncryptedKey and EncryptedData as
defined by [XML ENC Core]. Each EncryptedData element describes how
one or more files within the container are encrypted. Consequently, if
any resource within the container is encrypted, encryption.xml must be
present to indicate that the resource is encrypted and provide
information on how it is encrypted.
The EPUB3 is vague on rights.xml, its meaning and whether it is mandatory for DRM'd files, so it might be best not to depend on it.
Related
I have a rails app that writes to a file in my admins view folder. It creates a new folder for each user and a text file containing sensitive information.
How do i take the root folder and make sure no one can access the files inside?
/app/views/admin/NameOfFolder
NameOfFolder is the folder I want to protect that has sensitive data. The NameOfFolder is based on the user it is made for.
You don't have to. Nobody can access anything in /app. Only files in public are directly accessible to the Internet.
That said, it's highly wrong to use flat files for data storage, and especially to contain sensitive information. It's also extremely wrong to write arbitrary data files into /app/views. That directory is for your viwes, not for data storage.
I'm trying to read and analysis iPhone backup files in Library/Application Support/MobileSync/Backup folder.
I use SQLite DB viewer to view the manifest.db:
Files TABLE structure
Files TABLE content
The filename is encrypted. And the file is blob type which I can't decide it's an image or text or documents.
How can I get the details of these backup? (Using Javascript would be best, or Swift).
The numbers and letters under fileID are the file names in the backup as in the folders with the manifest.db, and they correspond to the domain and relative path (duh). In iOS versions newer than 9.3.5, you can find the file itself in the folder named with the 1st 2 characters of the fileID. At the end of the relative path in the database it should have an extension. Use that as a hint to what program to use to open the file. Xcode for .plist etc. Ultimately it depends what you're looking for...
The blob in the blob column is a binary plist. You can parse it using a plist parser e.g. Property List Parsing
The blob appears to be base64 encoded, but I cannot figure out the type of the resulting binary blob. I've checked to see if it can be decrypted with openssl enc -aes-256-cbc -d decoded-string-as-binary-blob.datafile but I get back "bad magic." I've also tries all of the other AES encryption ciphers and block cipher modes, but no change. It could always be XOR'd with a value, but I haven't found an easy to test that theory.
I've developed an application and I need to remove my computer local path from the generated iPA file.
I did the following:
unzipping iPA file.
click on show package content.
open exec(appname.exec) file with text editor.
Now I can see some binary stuff, and strings with my computer local path (with my mac name).
I have to remove these paths from the exec file, due to security issues. How can I do so?
As Accessing Files and Directories says:
Although you can open any file and read its contents as a stream of bytes, doing so is not always the right choice. OS X and iOS provide built-in support that makes opening many types of standard file formats (such as text files, images, sounds, and property lists) much easier. For these standard file formats, you should use the higher-level options for reading and writing the file contents. Table 2-1 lists the common file types supported by the system along with information about how you access them.
You have many ways to save your data:
Specifying the Path to a File or Directory
Locating Items in Your App Bundle
Locating Items in the Standard Directories
Locating Files Using Bookmarks
You have chosen to Specifying the Path to a File or Directory,as #Droppy says
Firstly it will break the code signature and secondly it's time consuming and error prone.
You'd better choose to Locating Items in the Standard Directories
Here is why you should choose the way:
Locating Items in the Standard Directories
When you need to locate a file in one of the standard directories, use the system frameworks to locate the directory first and then use the resulting URL to build a path to the file. The Foundation framework includes several options for locating the standard system directories. By using these methods, the paths will be correct whether your app is sandboxed or not:
The URLsForDirectory:inDomains: method of the NSFileManager class returns a directory’s location packaged in an NSURL object. The directory to search for is an NSSearchPathDirectory constant. These constants provide URLs for the user’s home directory, as well as most of the standard directories.
The NSSearchPathForDirectoriesInDomains function behaves like the URLsForDirectory:inDomains: method but returns the directory’s location as a string-based path. You should use the URLsForDirectory:inDomains: method instead.
The NSHomeDirectory function returns the path to either the user’s or app’s home directory. (Which home directory is returned depends on the platform and whether the app is in a sandbox.) When an app is sandboxed the home directory points to the app’s sandbox, otherwise it points to the User’s home directory on the file system. If constructing a file to a subdirectory of a user’s home directory, you should instead consider using the URLsForDirectory:inDomains: method instead.
You can use the URL or path-based string you receive from the preceding routines to build new objects with the locations of the files you want. Both the NSURL and NSString classes provide path-related methods for adding and removing path components and making changes to the path in general. Listing 2-1 shows an example that searches for the standard Application Support directory and creates a new URL for a directory containing the app’s data files.
You cannot do it this way. Firstly it will break the code signature and secondly it's time consuming and error prone.
The correct approach is to not use the complete path in your code and instead use methods like NSSearchPathForDirectoriesInDomains to get the Documents folder, or whatever directory you want to use.
I am hosting a small fileserver, where users can upload documents from all around the world.
Due to problems in encoding (see otherquestion), I am asking myself if I should disallow users to upload (and on the other hand download) files not supported by CP1252 charset?
or otherwise; is it senseful to allow users upload documents with arabian or chinese letters in their filenames?
PS: they download the same file some time later (and it should have the same filename as uploaded)
You should be storing the files on disk using a randomly generated name, or let the file name be based on a hash of the file contents (good for deduplicating storage as well). You can save the original file name as meta data in a database together with all other meta data about the file (who uploaded it and things like that). Then you serve the file again using a PHP script which sets the original file name from the database in an HTTP header. This way you:
don't need to worry about file name sanitisation or duplication
file system encoding issues
storage duplication (if using a hash)
I think I'm missing something about mediafilesegmenter.
The docs say this about encrypting content:
The media stream segmenter available from Apple provides encryption
and supports three modes for configuring encryption. The first mode
allows you to specify a path to an existing key file on disk. In this
mode the segmenter inserts the URL of the existing key file in the
index file. It encrypts all media files using this key. The second
mode instructs the segmenter to generate a random key file, save it in
a specified location, and reference it in the index file. All media
files are encrypted using this randomly generated key. The third mode
instructs the segmenter to generate a new random key file every n
media segments, save it in a specified location, and reference it in
the index file. This mode is referred to as key rotation. Each group
of n files is encrypted using a different key.
http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html#//apple_ref/doc/uid/TP40008332-CH102-SW3
The docs say this about mediafilesegmenter:
The file segmenter performs the same tasks as the stream segmenter, but it takes files as input instead of streams.
http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/HTTPStreamingArchitecture/HTTPStreamingArchitecture.html#//apple_ref/doc/uid/TP40008332-CH101-DontLinkElementID_7
So, I'm guessing mediafilesegmenter has those three modes, just like mediastreamsegmenter does. I'm trying to use the second mode. Here's my command:
mediafilesegmenter -f encryptedSegmentsDirectory -encrypt-iv=sequence
-encrypt-key encryptedSegmentsDirectory/key.txt media.m4v
The result is .ts files and two m3u8 files, neither of which seem to reference key files. I get this response:
mediafilesegmenter: option `-encrypt-key' is ambiguous
Is there an example that shows how to do this successfully?
Also, HTTP Live Streaming seems to insist on serving key files over http:
You can serve key files using either HTTP or HTTPS. You may also
choose to protect the delivery of the key files using your own
session-based authentication scheme. For details, see “Serving Key
Files Securely Over HTTPS.”
I'd like to serve it on a local file on the iOS file system instead from a server. Is this possible? If not, would there any problem with serving it from a local web server?
Sorry if I missed something obvious - please feel free to just point me to the relevant documentation!
Doh - I got the switch wrong. It's -encrypt-key-file, not -encrypt-key. Sorry, everyone! I just needed to step away for a while.