I just was looking at some of the cracked applications. I want to know how can we encrypt our application from being cracked so easily. I also saw a video tutorial to crack the application using a simple software.
Is there any way to protect the paid app from crackers?
Many Thanks,
Nav
Implementing protection on your side is risky. You could detect a modified binary or disabled signature checking and disable some features (like Game Center), but there is a slight risk of penalizing and dissatisfying a real customer, which IMHO is worse. Focus on creating a great app instead, and you could convert a "pirate" to a customer.
There are some expensive libraries to protect the app.
But, in my opinion, since a pirated copy should not be treated as a lost sale, the price of such libraries it's not worth.
edit: i just found anticrack that has a reasonable price
Related
I am a member of a gliding club with 150 members, and we want to have our own iPhone app. Requiring a member login, the app would be usable only by members of the club, and it would be used by an estimated 20-30 people.
Is it even possible to disribute such an app to non-jailbroken iPhones? According to my research:
It wouldn't be accepted on the App Store due to "limited audience".
Even if we were able and willing to pay $300 for the enterprise distribution model, Apple would likely not accept us as a company.
Ad hoc distribution would be fine for us except for the expiration time associated with apps distributed in the manner.
Are we at a dead end?
Thanks.
Edit: In case anyone is wondering why I didn't just ask Apple directly: I did, and their answer was, "We are unable to advise you with respect to the Apple Developer Program that best fits your needs."
I'm not 100% on your question.
But depending on your requirement, pretty much everything you need can be achieved as a web app, with the correct coding behind it i.e. CACHE MANIFEST you could make the app function similar to the a native app, available offline and can be saved to any iOS device through the browser.
Give me a shout if you need more information.
Hope it helps
Gary
You could always try to make the app a little more "global"? Perhaps offer some free stuff for Joe Bloggs to use, but tucked away you have your real motive... that way you can get it released legitimately.
I've seen some real disasters in the app store that shouldn't have made it, and I'm sure Apples screening isn't as intense as we might think. (example: that flash light application, when pressing a sequence of buttons it would enable free tethering).
Best of luck!
Yup. You seem to have all the options laid out pretty clearly, and there's no other way to do it. Except developing for android, and just distributing the application freely and without arbitrary restrictions.
Sorry.
Ad-hoc distribution would give you about 90 days expiration time, i think, whereas enterprise would give you a year. Though gaining enterprise status in the eyes of apple is easier said than done.
Even if we were able and willing to pay $300 for the enterprise distribution model, Apple would likely not accept us as a company.
You don't have to be a company to apply for the enterprise account, you just need to be an organisation with a DUNS number.
I have a iPhone app which needs to have a self destruct option. This app is going to be use on sensitive locations and holds some algorithms which are not to be known by anybody except the iPod Holder.
What would be the most "complete" way of deleting the app?
I was thinking of some how writing zeros to the nib file. or the actual application.app but I believe this folders are write protected and sandboxed.
Anybody have any ideas of better ways to achieve this?
Elaboration (Taken from original poster's comments):
This is for a jailbroken iPhone.
These devices are going to be provided to military personnel this device falling into enemy hands would be the least of my concerns. It's going to have a button so wipe the app once the app is written to zero or better yet corrupted with garbage all over the "exe" the app has no way of working and it would require inspection of the iPod flash chip with equipment that i 100% know the wrong people wont have
If you are openly storing the code that contains this algorithm within your application, there's nothing stopping the "wrong people" from jailbreaking the device and copying the complete file structure of the device before you run your "wipe" process.
Additionally, if you are dealing with a U.S. Government customer, I doubt that they will approve of the purchase of a jailbroken device, given that the vendor of such a device has claimed that jailbreaking is illegal. Whether or not this will hold up in court, the government tends to be conservative in these matters and err on the side of caution. Because Apple is a large U.S. company and a vendor to the government, I wouldn't expect the government procurers to take the jailbreakers' side in this.
My recommendation would be to encrypt the particular algorithms within a file in your application's bundle, and require the user of this application to decrypt this file into memory with the correct (difficult) password. That way, even if the "bad guys" were to gain access to the application, they wouldn't have everything they need to access these algorithms and would have to brute-force the password on the encrypted portion. This could be done on a standard, non-jailbroken device.
The U.S. Army is rolling out iPods in the field, with custom applications on them, so I'm sure that you're not the first person facing this challenge. If this work is being funded through a Department of Defense SBIR grant (or similar), you may even be able to contact your contracting officer and see if they can put you in touch with people at the appropriate agency who may be able to help you out with this (or even determine if it an issue to begin with).
I'm going to go out on a limb here and say you may not want to use the iphone for this type of app. There are intentional limitations to this exact type of action on the iphone and in springboard. If you are doing something so sensitive that it can't fall into unauthorized hands my recommendation would be to use a different and more customizable/controllable platform.
Unless you're working from a jailbroken device, you're probably going to run into problems here.
Even if you can find a way to automatically delete the app, you're still running the risk of those algorithms getting into the wrong hands - you would essentially be running into the same problems that Apple has with jailbreaking - once the device is in someone else's hands, it only takes the proper amount of motivation for the data to be accessed.
The only way to secure your algorithms is to pass the data to a remote server and get the results. There's still a possibility of a security breach, but it's much, much lower.
I don't know how well this would work, but you could store the algorithm as a file inside the application bundle, run the algorithm from that file possibly using a scripting language or something, and delete that file if you need to.
The folders are sandboxed, but your application is in there. On my jailbroken iPhone I see that all the permissions are owned by mobile so I don't see any reason why you can't just overwrite all the files with zeroes and then delete them.
The application bundle is effectively read-only, perhaps you should store some of the information in an encrypted form somewhere on a network.
Even if you find a way to write over the app in the flash memory, you really aren't erasing the app. Flash memory chips use wear leveling algorithms to reduce writes to the same blocks and so when you write out zeroes they are typically written to a new block of memory and not to the same block used before, so you really aren't erasing anything. The data can still be recovered from the flash chip (by a pro).
Another option is to separate out the parameters of the algorithm so that the algorithm is no longer sensitive (or at least not usable) and provide the parameters encrypted in a file. Then provide the key to authorized users via the network and don't store that key into flash, only RAM. They would need to get the key every time they start the app. Only give the key to authorized users. Of course, you'll also need to encrypt that key for transmission over the network with another key... There are systems for doing this, don't invent your own, in any case you'll need a crypto expert to do this right.
I would use the built in encryption to store the data, with a key the user has to enter to decrypt it. Without the key it doesn't matter if the data blob is recovered from the device.
Is it possible to assign different identifiers to copies of an app downloaded from the app store that is hard coded into the application? Or is their anyway of permanently storing an identifier in the application bundle such that when it is copied, the key remains within the bundle?
EDIT: Ok, how about iTunes reciepts, can they be used to verify when it was downloaded as the user has to register their app with the server within say 5 hours of them downloading it.
thanks in advance
I'm assuming your goal here is to disable part of the functionality of your app by having a master list of bogus serial numbers somewhere. Unfortunately there is no per-copy serial number available, and if there were it would be the first thing the bad guys would change before posting your app for download.
Instead you'll need to detect whether your app bundle has been tampered with from within the app. See this question:
Reducing piracy of iPhone applications
You'll then need to decide how subtly or obviously you want to limit functionality. Probably the best solution would be to do something innocuous but slightly annoying that generates a specific kind of support request, at which point you can gently prod the deadbeat into considering buying a legit copy.
An approach with more false positives but potentially fewer false negatives would be to check if the app is running on a jailbroken device. The downside there is that jailbreakers may well have legitimately purchased your app, so you're alienating honest customers for little to no extra benefit.
For the app I'm working on, which has a big social/viral aspect (I hope), I've decided that potential deadbeats probably have enough honest friends to pay for the server cycles that they're stealing, and it's just not worth worrying about.
No, there's no way to do either of these. The closest you could come would be to store device IDs on a central server.
What kind of practices do you do when developing iPhone apps? For instance, do you write up a technical design document of any sort. Do you write down the design of your app at all? Do you implement a certain methodology agile/scrum/waterfall etc...? I'm just curious when working on projects like an iPhone app, what kind of best practices do people use or do people just go at it?
I've worked on a few iPhone apps, and I've found this workflow works pretty well:
Figure out what the app is going to do. Create a one sentence description of the app that embodies what you're trying to do. If you can't explain the core functionality in one sentence, people won't get it!
Create interface mockups for each screen of the app on paper, and then in Adobe Fireworks. Fireworks' native file format is PNG, so it's easy to create images for use in the actual app later.
Figure out how you're going to architect your app using Model-View-Controller and the other iPhone app design patterns (delegates, dataSources, etc...). Don't try to do something other than MVC. The whole SDK is built around MVC!
Start coding! I usually start with the bare functionality first. For a drawing app, I implement the drawing controller and the important drawing views (color picker, etc..) first. I back things up to an offsite SVN repository as I go using Versions (I haven't had much luck with the repository support in Xcode)
Distribute a beta version of the app to a group of AdHoc testers. This helps a lot. Getting the app in the hands of a few extra people really helps isolate usability issues and bugs that are hard for a single developer to find.
Repeat until satisfied and Apple approves :-)
I haven't done much with iPhone development, but its irrelevant. I wouldn't consider it any different from any other developmental process.
The process is different for each case, some have at it and others follow their development methodologies.
As one who is about to dabble in his first iPhone app, I don't think there is any one methodology that rules over any other. You can apply any of the techniques you mention to an iPhone app, just like any other development effort.
A key thing about iPhone apps, or any Apple related development effort, is that Apple sort of forces you to follow certain design guidelines. That is good in some ways (less to concern yourself with) and bad in others (restrictive).
Also, Objective-C and Cocoa Touch can also lend itself to certain ways of programming.
Now, specifically for me, as a sole developer, I will probably:
Jot down high level features of what I want to be included in the first version
Do an interface mockup (either on paper or with a software tool)
Jot down some key objects and functions (psuedo-code)
Set up a source control mechanism (I think this is key)
Start going at it
Possible repeat of any or all of 1-3 :-)
I prefer to start with small proof-of-principle projects to test out different capabilities of the device that I need for my final product. This is especially important on a mobile device like the iPhone, because hardware limits on memory, processing power, graphics, or display size can render some ideas impractical. It's best to know that your application won't work as you imagined after only a couple of days of playing around, rather than after a month of development.
John Geleynse and others at Apple advocate starting your design with a single sentence that describes your product and its intended audience, and building everything around that mission statement. I've found that this works extremely well for determining what features to incorporate or leave out of a product, particularly on the iPhone. Having a simple core product description at the center of your design is also extremely helpful when you need to explain this product to others in your later marketing efforts.
Aside from that, I've found that iterative development incorporating lots of testing and user feedback has worked for me on every platform I've developed for.
What does it mean that I have to "apply"? Can day say: "No, we don't like your nose. Do something else!"? Did they do that in the past?
I've been investing now two full months worth about 20.000 USD on learning for iPhone programming, and I didn't apply yet...
I've never heard of them rejecting an application for developer license. But I've heard plenty of stories of them rejecting code. That's the much larger risk with Apple's stranglehold on the iPhone marketplace.
There is no reason for them not to accept you as a iPhone developer. There is no situation that I know of where they have denied the application provisioning for testing out on the iPhone. They can and will deny your app submission to the app store in some cases. Usually those cases include:
Using copyrighted assets which you do not have a license for
Competing with one of their apps (mail client was the only one I know of)
No value added (yet another "flashlight" app - pretty rare)
Opening the iPhone to scripting attack through download.
Does not conform to their UI guides
The last of these is the trickiest. A friend of mine had his app rejected because he used a UI widget in an unexpected way. This is pretty subjective IMO but they did tell him exactly why they denied it and accepted it when he fixed the issue.
Also about the 20,000, I can't agree here. In addition to learning and bettering yourself as a programmer, you are assuming that you would be paid for every off hour you spend learning - not very realistic.
Apple has a right to not accept your app at their wish, so you have to take a risk.
Yes they could. That's the risk behind developing for any tightly locked down environment.
Of course in practice they are unlikely to reject you for no reason.
And you're already taking a gigantic risk by investing $20k into iPhone development. I can't help wondering if this is a saturated market, although there have been a few well publicised success stories, everybody and his dog are now working on a bejeweled clone, and lets face it, even people who buy iphones are going to be looking a reduction in spending on pointless trivia soon with the market the way it is