Can I hide info.plist in a kext? or can I dynamic create info.plist for a kext?
I have a codeless kext where it only has info.plist, however, I dont want to expose info.plist to everybody so they can simply just copy my codes... so I was thinking either hide the info.plist or dynamically create info.plist while driver is loading or encrypt the entire kext?
You can't encrypt/obfuscate the Info.plist itself. It is part of the code signing process and requirement though, so it's not trivially modifiable.
You don't state it specifically, but I'm assuming there's some property in the I/O Kit Personality dictionary that you want to hide? Those properties can equivalently be set from code, specifically in the init() function of your driver class, unless they're required for matching. Note that any properties you've set are world-readable in the I/O Kit Registry at runtime though, so I suspect this isn't what you want.
If the information you're trying to hide is part of the matching conditions, for example you're attempting to hide product IDs of thus-far unreleased devices, you can, depending on your driver family's matching rules, probably implement this logic in code in the probe() function. I wouldn't make the matching rules in the Info.plist too broad though, or your kext will be loaded every time e.g. a provider with the given provider class turns up. This is unnecessarily inefficient.
Obviously, in both cases, your kext will no longer be codeless, but you can obfuscate to your heart's content in the C++/C/assembly code.
If you want a more specific answer than that, you'll need to be more specific in your question.
Related
I built a very simple minifilter driver as part of a lesson on minifilters. I've also read the minifilter documentation that Microsoft provides which is in the form of a PDF doc, as well as this reference. These guides explain how to set up a context and an instance. However, they do not explain why one would use a context and/or instance and what they are for. My very small filter driver used NULL for both context and instance and still operates, so I am wondering the use-case for these constructs.
There are many reasons why you would want to use contexts for files, volumes etc.. Certainly filters and even file-systems could operate without them, but the performance would be really bad.
Imagine this scenario: you are an AV (AntiVirus) and want to scan some files to check if they contain malicious code or not.
You register your minifilter and callbacks and now you are being called and you need to make a decision on a file as it is opened.
There are a few steps involved:
You query the file name and security context
You read the file contents
Alternatively hash the file with a SHA256 to see if it matches in your AV database for example
You check if the file is digitally signed, also part of your check
You parse the file's PE header if it has one to see what kind of file or executable it is to help you in your decision
You apply your policy on the file based on all the information above
Now let's assume the file is clean and goes away. If you cannot hold on to the information that you just learnt about the file, the next time the file is opened you will have to re-do it all over again. Your performance will suck, and your OS will crash and burn slowly to the ground.
This is where contexts come in handy.
Now that you have all this information about the file, you store all of it in your context that is then associated with this file. Next time you see the file you simply query its context and have all the information you need.
Of course some things will need to be updated, for example if you notice the file has been changed then you mark it as dirty and update as needed on the next Create or Cleanup callback.
Alternatively you could use a cache, where after the file is closed for good and the minifilter wants to free the context you have associated with the file you can save it yourself.
Now, the next time the file is opened you look for the context of the file ( NTFS support unique file ids for files ) and just associated it with your file and know immediately everything you need to know about that file
This is only one usage, but now you can think for yourself of many more scenarios where they are useful.
When I declare elements in the .sdef file for my scriptable application, I have the option to declare various accessors, like this:
<accessor style="id"/>
<accessor style="index"/>
However, I wonder what consequence these declarations have. So far, I could not make out any changes of behavior in my test scripts whether I add or remove accessors for index and id as long as I implement the necessary methods.
So, how do these affect anything? Are they only for documentary purposes, such as what is shown in the dictionary of the Script Editor?
Or does the scripting engine actually behave differently in certain cases depending on these declarations?
So far, I only noticed one behavior that affects them: Script Debugger appears to use them to decide how to browse values in its Explorer. But I doubt Apple added these declarations only for the purpose of this application.
AppleScript does not validate against these settings in your SDEF. However, other tools may. For instance, my Script Debugger application uses this information to control the object access options presented to the user in its Explorer viewers. Various AppleEvent bridges may also use this information to control the kinds of object access they provide to their host scripting languages. An example from the distant past was my JavaScriptOSA project which bridged AppleEvent access into JavaScript. It used the key form settings to control the keys one could use when accessing element objects.
I've read a lot of blog posts and SO-questions about Uniform Type Identifiers and how OS X handles file types. However, there are still some things I just don't get:
How are UTIs created by the system for each file? As a developer I passively declare a UTI for my file type but the system is responsible to assign the UTI for each matching file.
My current impression is that UTIs are created on-the-fly by the Finder according to the file extension.
Where are UTIs stored on the file system level? I've learned that the UTI can be displayed with the mdls command. Does that imply that the UTI is stored along the Spotlight meta data? What if Spotlight is turned off?
Is it correct that there is no API to manually add or change a UTI for a specific file?
There's actually not that much magic to it. You've asked several different questions, so I'll try to give you each of the answers:
How are UTIs created by the system for each file?
Launch Services maintains a database of all applications (and certain other types of bundles) on your Mac and relevant information declared in their Info.plist files. It updates this information automatically—I think it has a daemon monitor the file system to watch for changes to applications, but I don't know the details. What I do know is that you can ask a tool called lsregister to dump the entire database for you. In Terminal on Mountain Lion:
$ /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump
The various UTType functions also access this Launch Services database (although I'm not sure if they do it directly or if they communicate with some kind of daemon that does it for them).
Where are UTIs stored on the file system level?
Well, the actual Launch Services database seems to be located somewhere different on each Mac. On mine, it appears to be at /private/var/folders/mf/1xd7vlw90dj5p4z1r5f800bc000101/C/com.apple.LaunchServices-0371025.csstore. (At least, lsregister holds this file open while it's working; I'm not actually sure what's in it, but I assume it's the database.)
This is just a list of the declared UTIs, though. There is no UTI field attached to a given file. When you ask Cocoa for a file's UTI—through, say, -[NSWorkspace typeOfFile:error:] or -[NSURL getResourceValue:forKey:error:]—it actually extracts the path extension from the file name and then calls UTTypeCreatePreferredIdentifierForTag() to fetch the relevant UTI. (It's a little more complicated than that, because it's also looking at things like whether the path leads to a directory or device file or something, but that's the basic idea.)
Does that imply that the UTI is stored along the Spotlight meta data? What if Spotlight is turned off?
Spotlight does keep UTIs of files in its database, but that's just so it can quickly search and filter by type. Like everything else in the Spotlight index, this information is not canonical; it's just used to quickly search data that's actually stored elsewhere. If you turn off Spotlight, that's fine—nothing else depends on it.
Is it correct that there is no API to manually add or change a UTI for a specific file?
Yes, because that UTI is calculated at runtime from other information about the file. Changing a file's UTI makes about as much sense as changing the length of its name—you can't do it without changing the name itself.
So we recently shipped a document based application with an unfortunate oversight: the UTI for our main document type was left blank. We had a name for it, but the identifier was straight up empty.
Everything still worked great, but then we went to add another file type to the mix. The new file type is simply xml (conforms to public.xml). We set that up and dropped it into the document. This is when we caught our oversight on the first document type's UTI.
Now, if we so much as touch this document type, BOOM. The application can't read any files it has created of that type. We really want to clean this up, so what's the best way to do so?
My question is essentially:
How do you migrate your main document type in a document based application?
First, it's very difficult to debug this type of problem on the machine you're using to cut builds. The dynamic UTI system gets confused as to which app owns which files. To solve this issue, there is a command you can run in terminal to clear out the file associations on your system.
Next, we tackled the actual document types of our application. Ultimately, we want to support just two document types, our custom type and the xml type. However, we had to keep that empty, dynamically generated UTI that was shipped. In "Document types", we have three: the two we actually want to support and the legacy one we no longer want. For the first two, our application is an "Editor". For the legacy one, we changed it to "Reader".
Another thing that really helped our system out is using exported an imported UTIs. We told the system our application imports the XML type, and exports the two others.
We've done some pretty significant testing, including deployment, and this configuration works like a charm.
Can you dynamically assign CFBundleDocumentTypes to your Cocoa application? Meaning during run time can I assign more extensions for my app to handle.
Currently I set some extensions for my app to handle using CFBundleDocumentTypes in the Info.plist, but I would like to do this through code while the application is executing (during run time). Basically can I make Launch Services aware of new extensions without modifying the Info.plist file.
Thanks.
At the moment, there’s no public API1 for an application to dynamically (un)register document types with Launch Services during runtime.
Open Emu faces this very problem. Users are able to selectively download/install emulators, which are bundles whose Info.plist files define document types. Upon installing an emulator, the types defined in the bundle need to be part of the types as defined in the application Info.plist. Open Emu rewrites the application Info.plist in order to do so — see -updateInfoPlist in OEGameDocumentController.
Note that overwriting the bundle Info.plist is a violation of Mac App Store’s policy.
We have filed radars asking for runtime (un)registration of document types. I suggest you file another one, too, which should be closed as a duplicate of #2526726. Even if it’s a duplicate, it’s important to file it anyway so that Apple have an estimate of the number of people that need this feature.
1It might be possible via SPI, though. When I was looking into this, I stumbled upon _LSRegisterItemFromItemInfo() in Launch Services.