I know how to make a .pkpass file using tools on my Mac and then zipping them up and signing them (using the signpass tool), but how could I edit the file during runtime in an iOS app?
I realize that in the Apple documentation, they want you to use a server for any pass updates / edits, but this is not what I am aiming to do (I realize the security issues there, and that is not the focus of this question).
How can I do this (I'm not asking for code)? In the documentation, this is the only mention (that I've seen) of actually manipulating the passes at runtime:
In a production environment, the signing and compressing would be part of the system that generates passes.
Any ideas on how this can be done? Are there any third party APIs that allow for this (I've checked out Passdock and Passsource, but Passdock doesn't have an Obj-C API and Passource isn't too clear).
As you already have said, Apple does not want you to create your own .pkpass files in an ios App. It is certainly possible to do so, Apple can't NOT allow you to include or fetch certificates although they can certainly reject your app if they want to.
You can adapt code from any number of articles/tutorials to build the various files, create the signature (probably the most arcane and difficult part), and create a .pkpass file in your app. Some of the code in the signpass app is probably reusable as is, if the frameworks it relies on are in the iPhone SDK.
Perhaps you could look at some the services that are already out there that offer pass generation with a high-level API that could be consumed from the phone.
This one, for example, which I present with no warranty or endorsement.
You won't be able to edit the .pkpass file, as it has been signed. If you change it, the signature will be invalid.
The only editing you can do is pre-pkpass generation. If you can create .pkpass files at runtime, you can edit them before signing. Otherwise, the only other option to edit them post generation using push notifications, but that only allows editing of particular fields.
Related
According to their website (http://www.gdpicture.com/products/managed-pdf/) you have the ability to extract fonts from a PDF file. However, I can't seem to find the functionality to do this. I have encountered several methods to add them, but none to extract them (and they don't show as embedded files). Has anyone tried to do this, or have experience with GdPicture?
Version: 14 (Current)
Disclosure: I am part of the ORPALIS technical staff that edits the GdPicture.NET SDK, that's why I know there's an ongoing communication about this already.
It is my understanding that you have a support case open for a merging issue relative to fonts and as you know, our development team is currently working on a fix that will solve it so I strongly recommend that you wait for them to finish.
There's no extraction of the embedded font as you might expect at the moment but the development team is also working on one, we will let you know as soon as it is available (it should be very soon).
You can get information about (already) embedded fonts using the GetFontCount, IsFontEmbedded, GetFontName and GetFontType methods.
You can also add new embedded fonts (of different types) using the AddFontFromFileU, AddStandardFont, AddTrueTypeFont, AddTrueTypeFontFromFile, AddTrueTypeFontFromFileU and AddTrueTypeFontU methods.
I was wanting to make an app similar to something like TextExpander, but I am not sure how you would intercept the text. As far as I can tell, I need to start with NSAccessability. Could anyone share some snippets, or at least point me in the right direction?
First off, you should be aware that, because of the sandboxing requirement, this isn't possible at all if you want to sell your app in the App Store.
If you don't intend to sandbox your app, you can use the NSEvent class method addGlobalMonitorForEventsMatchingMask: to create a global key event handler that gets called when keys are pressed in other apps (but not your own app, use addLocalMonitor... for that).
To actually insert snippets, like TextExpander, there are several ways. You can use the accessibility APIs, but that requires that the app(s) you're targeting support accessibility, which isn't always the case.
Another option is to use the Quartz Event Services (CGEvent) APIs which provide (among other things) a low-level method to simulate key events.
Edit: Nevermind. You're asking about Mac OS. I thought you were asking about iOS.
You should look at how TextExpander is used by other apps. The target app has to build in support for TE by making an object provided by TE a delegate of the text field. You can't run your code in someone else's app. They have to compile your code into their app. That's why there's a TextExpander SDK.
Once the TextExpander code is in the target app, the text field delegate gets the shared snippets by looking for snippets put into a shared pasteboard.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
iPhone/iPad App Code Obfuscation - Is it Possible? Worth it?
I have spent a lot of time on this and I couldn't able to find a perfect answer. That's why I decided to put my question here. I have an iPhone application and want to encrypt the code to prevent from class-dump or otool utilities. (Tools used to dump out the headers from executable). I would like to know is there any way to encrypt the source code or obfuscate the source code?
It's a lot more complicated than it might seem initially. Any tool that mangles method names has the potential to fudge up:
KVC compliance
The use of dynamically generated selectors
Nib file compatibility
Protocol conformance
Method inheritance
Obfuscation is just another layer to deal with; often obfuscation is easily reversed. It is not really possible to “encrypt” your classes because the Objective-C runtime and Cocoa framework won't know how to decrypt it. Anyone determined enough will eventually figure out how your program works.
Actually you can provide some obfuscation and tamper protection with specialist 3rd party tools. There are 2 companies, I know of, that provide tools or services to do this : Arxan and irDato.
Neither are cheap or accessible to small developers but if you are developing for a large corporation then you should consider them.
Obfuscation is done by mangling code paths and adding redundant instructions so as to confuse anybody trying to reverse engineer the code. Tamper protection is done by adding checksums to the code and embedding checksum checks within functions. You can create a network of interdependent checksums that makes it extremely difficult to bypass them. There are a few other things that can be done but you really need to talk to specialists in this area.
Further to the earlier answer, Apple does not encrypt the binaries but just signs them. It is fairly easy to reverse engineer and modify app binaries on a jailbroken device.
Apparently, according to this answer Apple encrypts iPhone binaries as a matter of course for all iPhone apps.
I'd stop worrying about it.
I'm currently using BWToolkit, does anyone know if there are any steps that need to be taken before submitting to the app store (as far as licensing)? Do I need to put any disclaimers anywhere etc? I know it's BSD licensed but I don't want to have my app rejected because I missed a simple legal step.. Any help?
I don't think that NSGod is right.
You may want to read this and/or that.
You are not going to like this answer.
You will not be able to use the BWToolkit.framework as-is. Some of its classes rely on private APIs which Apple has strictly forbidden for apps that are submitted to the app store.
For example, the developer ran a tool called class-dump on the AppKit.framework Mach-O object and generated the .h files for 4 secret classes: NSTokenAttachment (an NSTextAttachment subclass), NSTokenAttachmentCell (an NSTextAttachmentCell subclass), NSWindow (NSTimeMachineSupport), some additional methods on NSWindow, and NSCustomView.
I'm not that familiar with the inner workings of the framework, but depending on what classes you've made use of, it may be possible to create a custom build of the framework from the source that doesn't include the private APIs. Or, you could just include the source files for the classes you use in your project (provided of course that they don't rely on private APIs).
What particular classes did you make use of? If you used BWSplitView, you might look into using RBSplitView. (I talked to Rainer and have confirmed that there's no private APIs used in it, so you'd be okay).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
For a pet project, I develop a desktop application which requires API keys from several different webservices.
I've been going through and preparing this application to become open-sourced and run across the problem of what to do with those keys.
The problem is this: My understanding is that these API keys should not be visible to anyone using the application or viewing/modifying the source code. From the webservice's end, these API keys are used to identify applications accessing their API, and allow/block usage as appropriate. In most of the TOS's for receiving these keys it's actually explicitly stated that the keys must not be shared with the world.
Currently all my keys are hard-coded, but at I'm at an impasse as to how to handle the situation of private keys in an open-source application:
-If the keys remain hardcoded, they'll be publicly visible as soon as my source code is.
-I can't really omit the source file with the keys from the code distribution, since then
it won't compile. This technically solves the problem, but introduces a new, unacceptable
one.
-If I push the keys off to a .ini or other config file, and simply not include that file
in my public code repository, it would still have to be distributed with the binary of my application in order for the app to function, so my keys would be visible in the application distribution instead of the source distribution. Not an improvement. Any encryption gymnastics I attempted to utilize on this INI file would be adding the complexity for anyone attempting to modify my code.
So, with regards to my codebase (currently under Mercurial for version control), what's the best way to manage everything so that the code can be public, but my keys stay private?
Don't know what language you are using, but for example in C/C++ you'd add a include file with the API keys, and then leave it out of source control, instead add a bogus file with explicitly fake API keys. Most languages have one or the other way to include files.
Your app should use a config file. This config file is loaded at runtime and shouldn't affect compiling. The allows users to download a binary and still use their own api key.
As Kornel says, you can include an example config file with a fake API Key, in your source control.
Another option, you could talk to the people running the webservices and ask for one of two things.
A temporary key, that only works for limited functionality. That would let users see basic functionality of your app, but some people would never update the key and just use the basic stuff.
Talk to the webservices to see if you they will give you a special API Key for your application. The open source version would require users to enter their own. But your binary could use a standard one.
The thought of using a config for api key's, isn't new or unheard of. Bit.ly services do it. And all the open source applications I see that provide use with Bit.ly ask for your username and api key before you can use it.
This is no different?