Related
friends
I want to access email history from my iphone & also want notification when new mail receive.
Provide me source code snippet if possible.
Thanks,
In short: It is not possible with any of the documented APIs
Most of us have this question in our mind, “Can iPhones get viruses from Email?”. iPhones are highly secure, which is a known fact. Yet, there are certain possibilities where viruses can enter into the device through apps or email. Everyone’s idea of the iPhone is that it is entirely immune to malware (malicious attacks). Even iPhones get malwares when they are jailbroken. Protect your iPhone from other threats by taking sensible precautions.
For instance, your device might encounter phishing attacks more than iOS malware. Be careful while opening an email on your iPhone. Avoid opening junk mails, which could result in letting the virus into your iPhone. Do not open the email links that look suspicious. Even if you have opened some spam email on your mobile mistakenly, do not click any of the links given inside it. Lets quickly see things that indicate the presence of viruses in the iPhone.
These are the possible signs that indicate whether your iPhone is infected with malware, a virus or some other threat.
Encounter system warning frequently.
Advertisements popping-up often
Apps crashing
Incline in the mobile data usage
If you encounter these issues, then it might indicate the presence of a bug that requires to be deleted or updated. Sometimes, your phone might run out of memory space or the battery needs replacement. All these indicate the presence of a virus.
If targetting iOS 4, you can use the Data Protection APIs.
If you have 'Full' protection, does this encrypt the entire sandbox?
Specifically, If I downloaded say a .doc file to disk programatically will this be encrypted? Or is it only encrypted if I use the NSData data protection options?
It's only encrypted if you use data protection. See App States and Multitasking, and Protecting Data Using On-Disk Encryption.
My understanding is that you must use the data protection options. There was a WWDC 2010 talk on exactly this topic. See "Session 209 - Securing Application Data" which goes into detail. These videos are free and highly informative.
Login through developer.apple.com and then you can use the link in the page to get to the videos. FYI, the video contains all the example code you should need.
WWDC 2010 videos
if somebody were to jailbreak your device and bypass your passcode, information protected by the Data Protection API would remain encrypted and therefore inaccessible, since your passcode—the important piece of the decryption key, is not known.
Data Protection is enabled automatically simply by setting a passcode on the device.
The catch, however, is that the Data Protection feature only secures data in applications that have been specifically designed to use the Data Protection APIs.
In terms of built-in applications, that’s only the Mail app, and third-party apps that actually make use of the Data Protection features are surprisingly rare;
GoodReader and Box.net come to mind as good examples, but many other file storage apps such as Dropbox do not provide this support, meaning that your cached data is no more secure than your physical possession of the device.
This means that if you’re concerned about storing confidential data with secure encryption you will need to look to exclusively using third-party apps that support the Data Protection APIs.
It’s also important to keep in mind that any apps that use iCloud storage cannot use Data Protection, as the two are mutually exclusive due to the requirement for background synchronization of iCloud data when the device is locked.
Even GoodReader, for example, notes that documents you choose to store in the “iCloud” section of the app will not be protected by the Data Protection encryption.
Of course even Data Protection is only as secure as the passcode on the device. Using the Apple Configurator you can configure requirements for more complex passcode policies on devices to help improve security in this regard, as well as enabling an automatic erase of the device after a specified number of failed attempts.
Read more at
here
If I recall correctly, starting with iPhone 3GS, hardware encryption is on by default for data on the iPhone, and additional encryption is available if you implement -- though if you are distributing/selling through AppStore, and you're implementing your own custom encryption beyond what Apple provides, the terms of AppStore requires you to get US Dept of Commerce (if my memory is correct) approval because encryption is classified as munition.
A good starting document is http://www.apple.com/iphone/business/it-center/security.html
More info on this is available within (paid) iPhone Registered Developer website which for obvious reason, I couldn't reveal, and you'll have to discover/read yourself.
Hope the information helps, and please mark the response as answered if this helps, thanks.
Is it possible to provide a service in which one free trial is given to each device without the possibility of an individual being able to get multiple free trials on a single device. If its impossible, do you know of a way of making it difficult to obtain multiple free trials.
You can generate the license key based on the device's unique ID, the request date, and your own private key to create a license that is only valid up to certain date.
You application will verify that the license key is valid by decoding the license key with your public key, and comparing its expiration date and device ID. People can't forge a bogus request, since the license key is only valid for the prescribed date and a given device ID.
(hint: read about public-key cryptography)
However, it's not totally foolproof. A really determined attacker can root his device, and install a custom firmware which allows him to control identifier returned by "getDeviceId()". This isn't something that most people would be willing to do, most people would rather find an alternative free app or just buy the app rather than going through that route. Against crackers with that sort of determination and skills, there is not much you can do about.
Alternative avenue of attack would be to replace the public key you ship with the application with the attacker's private/public key combination, and he can potentially write a key generator that can generate license key for the forged application. You can make this attack difficult by self-verification of your own executable.
However, no security scheme is foolproof, java/android application can be reverse engineered and a determined hacker can forge your application and disable its license checks. The only foolproof way to prevent unauthorized usage of an application is to not distribute the application at all.
I imagine you could get 99% of the effect of a more complex scheme with a brain-dead-simple one: just store a file somewhere on the device that indicates that the trial has expired. Granted, tech-savvy users would be able to find and remove the file, but the vast majority won't bother - the device is an inscrutable slab of magic to them, meddling with the internal files might displease the tiny gnomes peddling furiously behind the screen.
You can make things more challenging by hiding the lock file, changing the name and location based on the device id - that way it's a lot more difficult for someone to share instructions on how to evade your trial scheme.
As the other answers have noted: no system is foolproof, there is always someone out there who is cleverer than you and who will relish cracking your scheme. The trick is to not waste your time giving this guy a mental workout and instead cater for the majority.
Sure, but you'll need to be set up to store device identifiers on your own server. On an iphone, you can obtain the UDID using
UIDevice *device = [UIDevice currentDevice];
NSString *uniqueIdentifier = [device uniqueIdentifier];
You might make a database call and acompare uniqueIdentifier to your stored list, ensuring that only one trial can be activated per device.
In android, getDeviceID() gives you a unique device identifier. check the documentation for more info on this.
If I am not missing something, my solution would be straightforward. I will make the expire the service provided by the app, not the app itself. This can be done by using some token mechanism like oAuth. (with an expiring token with a considerable lifetime, in this case your trial period). While the client registration process, I will create the request token as a function of android device id and the requested time. Checkout oAuth, it could be a hassle, but almost all major service providers use it.
How about storing the MAC address of wifi adapter? Possibly on you server and you app will query the server if that MAC is already registered.
WITH USER'S PERMISSION, on the first run of app, query the server if current device's MAC address is already registered? If not, store the MAC address on your server. If already registered, ask user to purchase the app in order to continue using.
This method can be supplemented by some cryptographic algorithms as suggested by Lie Ryan to provide additional security and locks and/or trial period.
I don't know much about iPhone but I believe that every iPhone has wifi adapter and every wifi adapter has unique MAC address. Also check the legal side of this solution as storing the MAC may raise privacy issues/concerns. So, before using this, check laws applicable.
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.
Including under which circumstances applications are rejected, and how much of a percentage Apple takes (widely distributed as 30%, though I can find no mention of it on their site).
Thanks!
Here you go: http://i.imgur.com/MgyH2.jpg
To be serious though, Apple has not published a definitive guide to the acceptance policy. It sometimes seems arbitrary and unfounded and even sometimes contrary to what they have provided as their pseudo-policy.
From the iPhone developer agreement section 3.3:
Any Application developed using this SDK must comply with these criteria and requirements, as they may be modified by Apple from time to time:
APIs and Functionality:
3.3.1 Applications may only use Published APIs in the manner prescribed by Apple
and must not use or call any unpublished or private APIs.
3.3.2 An Application may not itself install or launch other executable code by any
means, including without limitation through the use of a plug-in architecture, calling other
frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in
an Application except for code that is interpreted and run by Apple's Published APIs and builtin
interpreter(s).
3.3.3 Without Apple’s prior written approval, an Application may not provide, unlock or
enable additional features or functionality through distribution mechanisms other than the App
Store.
3.3.4 An Application may write data on a device only to the Application's designated
container area, except as otherwise specified by Apple.
User Interface and Data:
3.3.5 Applications must comply with the Human Interface Guidelines and other
Documentation provided by Apple.
3.3.6 Any form of user or device data collection, or image, picture or voice capture or
recording performed by the Application (collectively “Recordings”), and any form of user data,
content or information processing, maintenance, uploading, syncing, or transmission
performed by the Application (collectively "Transmissions") must comply with all applicable
privacy laws and regulations as well as any Apple program requirements related to such
aspects, including but not limited to any notice or consent requirements. In particular, a
reasonably conspicuous visual indicator must be displayed to the user as part of the
Application to indicate that a Recording is taking place.
SDK Agreement Page 5
Location Services and User Privacy:
3.3.7 For Applications that use location-based APIs or that collect, transmit, maintain,
process, share, disclose or otherwise use a user's personal information:
You and the Application must comply with all applicable privacy and data collection laws
and regulations with respect to any collection, transmission, maintenance, processing, use,
etc. of the user's location data or personal information by the Application.
Applications may not be designed or marketed for the purpose of harassing, abusing,
stalking, threatening or otherwise violating the legal rights (such as the rights of privacy and
publicity) of others.
For Applications that use location-based APIs, such Applications may not be designed or
marketed for real time route guidance; automatic or autonomous control of vehicles, aircraft,
or other mechanical devices; dispatch or fleet management; or emergency or life-saving
purposes.
Applications may not use any robot, spider, site search or other retrieval application or
device to scrape, retrieve or index services provided by Apple or its licensors, or to collect
information about users for any unauthorized purpose.
3.3.8 Applications that offer location-based services or functionality must notify and
obtain consent from an individual before his or her location data is being collected,
transmitted or otherwise used by the Application.
3.3.9 Applications must not disable, override or otherwise interfere with any Appleimplemented
system alerts, warnings, display panels, consent panels and the like intended to
notify the user that the user's location data is being collected, transmitted, maintained,
processed or used, or intended to obtain consent for such use. If consent is withheld or
withdrawn, Applications may not collect, transmit, maintain, process or utilize the user's
location data.
Content and Materials:
3.3.10 Any master recordings and musical compositions embodied in Your Application
must be wholly-owned by You or licensed to You on a fully paid-up basis and in a manner
that will not require the payment of any fees, royalties and/or sums by Apple to You or any
third party. In addition, if Your Application will be distributed outside of the United States, any
master recordings and musical compositions embodied in Your Application (a) must not fall
within the repertoire of any mechanical or performing/communication rights collecting or
licensing organization now or in the future and (b) if licensed, must be exclusively licensed to
You for Your Application by each applicable copyright owner.
3.3.11 If Your Application includes or will include any other content, You must either
own all such content or have permission from the content owner to use it in Your Application.
3.3.12 Applications must not contain any obscene, pornographic, offensive or
defamatory content or materials of any kind (text, graphics, images, photographs, etc.), or
other content or materials that in Apple’s reasonable judgment may be found objectionable by
iPhone or iPod touch users.
3.3.13 Applications must not contain any malware, malicious or harmful code, program,
or other internal component (e.g. computer viruses, trojan horses, “backdoors”) which could
damage, destroy, or adversely affect other software, firmware, hardware, data, systems,
services, or networks.
SDK Agreement Page 6
3.3.14 If Your Application includes any FOSS, You agree to comply with all applicable
FOSS licensing terms. You also agree not to use any FOSS in the development of Your
Application in such a way that would cause the non-FOSS portions of the SDK to be subject
to any FOSS licensing terms or obligations.
Cellular Network:
3.3.15 If an Application requires or will have access to the cellular network, then
additionally such Application:
Must comply with Apple's best practices and other guidelines on how Applications should
access and use the cellular network;
Must not in Apple's reasonable judgment excessively use or unduly burden network
capacity or bandwidth;
May not have Voice over Internet Protocol (VoIP) functionality using the cellular network.
Check out this thread about app store rejections: Reasons for rejecting iPhone application by Apple store
And yes Apple's cut is 30%
You need to be a registered developer. But the information is here.