As par my app requirement, there is a couple of scenarios that I need to handle.
Scenario 1: To avoid piracy, I want to include some piece of code, whose job is sending both IMEI and Serial number of IPhone.
Scenario 2: At server side, I've a database, which has a list of both IMEI and Serial No info. Here I wanna validate both IMEI and Serial numbers. If both are not matched then I can make sure that the app is pirated.
Idea seems good. But I don't know how to handle these two scenarios in my app.
Any help is greatly appreciated.
This isn't something you can do with the iPhone SDK. The iPhone's IMEI or the serial number are not accessible via any API. Also an iPod Touch doesn't even have an IMEI.
Your idea is flawed too. How would you have gotten the IMEI and serial number into your servers database prior to app sending you the details? You can't get these details during purchase because its handled by the App Store and you can't get at that.
If the app was pirated, it would send you the IMEI and serial number anyway, so you can't rely on the app sending them the first time it's run because that would offer absolutely no protection against piracy at all.
The only option you have is to rely on Apple's fairplay DRM. Even though it has been cracked, and there are pirates, it's something you just need to deal with...
Related
I'm unable to figure out why there are random codes being shown in various places on this website. It doesn't happen on other websites. It also doesn't seem to happen on Android devices. It doesn't happen when connected to WiFi. On one iPhone with iOS8 it doesn't have it, but on another it does. On another iPhone with IOS7, it has it. I can't make any sense out of the codes. Any ideas?
See image here: http://i.stack.imgur.com/IdblN.png
http://arstechnica.com/security/2014/10/verizon-wireless-injects-identifiers-link-its-users-to-web-requests/
As your comment suggests you might be seeing a tracking ID from your ISP, AT&T in this case.
Verizon uses the UIDH field which identifies someone to Ad services. It is essentially double-dipping, when the customer is also the product. Not to mention some website receives this header, combines user-provided data with the field, then selling this to someone else... Easiest data-collection strategy of their lives.
I am a beginner iOS developer and I am trying to build an app which tracks the users SMS (Number) and Call data (Minutes/day) only but have no clue which framework to use. CoreTelephony is of no use as per my knowledge. Any help would be appreciated!
Call Statistics and SMS Statistics are handled by the cell carrier, but are also recorded by the phone and are visible in the settings application. However, there is no way for your app to access this information (as far as i know). It would be a privacy concern and probably won't ever be available. Im sure there is a way to do it on a jailbroken device, but it sounds like thats not what you want. What exactly does your app do?
I'm trying to develope an iphone application which helps for filtering spam text messages.
But I don't know how to hook text messages.
Please help me.
You just can't. iOS API as of today does not give you access to text messages. Not to read them, not to send them, not to filter them. Sorry to break you bad news.
If your phone is jailbroken, you could do it by accessing the SQLITE database where text messages are stored. But you definitely won't be able to distribute your application through AppStore.
In order to do what you are trying to do, you are going to need to hook into the API. It is possible to jailbreak an iPhone without it being identified as 'jail-broken', though it's a bit tricky and a single screw up can deem your HID jailbroken for life.
If you're attempting to make a program usable for any user, this is not the method you want to use.
The only way this would be possible, is through a virus.
So I'm making an app where I want the users to be able add, edit and rate content, but I do not want to force them to register. Instead I was planning on just using their device id or device token to identify them. I'm planning on making both an iPhone and Android version, so I'm looking for a general solution, but the iPhone version has higher priority, so an iPhone specific solution would also be welcome.
The problem is that I don't want just anyone to be able to use my web service by sending a phony device id or someone else's device id.
How would the client prove to the server that it is providing the correct device id?
In theory, you cannot. A device ID is not particularly secret, and in most cases, it can be easily spoofed. As for Android, there's no reliable device ID on that OS at all - see the gory details here: Is there a unique Android device ID?
All you can rely upon is security by obscurity - hoping that no one will be determined enough to reverse-engineer the code and analyse the authentication protocol. And not disclosing the code is not an option - you are distributing the app after all.
That said, one not-particularly-secure auth method would be - send the device ID and a hash of device ID concatenated with a secret, hard-coded in the client code string (the shared secret). The service would contain a copy of the secret, recalculate the hash (using the device ID provided) and match the hashes. Not breakable by protocol analysis, only by digging in the code for the secret. Vulnerable to replay attacks though. Feel free to obfuscate the secret in the code - e. g. combine it together from parts stored in separate places right before use.
For a stronger solution, authenticate users, not devices. This is up to your customers, and depends on the nature of the business.
I am no Android expert but the IMEI code I think is unique for the device. I dont know though how you can read it and transmit it.
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.