How to iCloud unlock an iPad or iPhone?
A lot of people seem to be asking this question. So, let’s explore if there are any solutions to the iCloud unlock problem.
Apple’s iCloud Lock: What is it?
Let’s examine what exactly is an iCloud lock. When you use an iPhone or iPad, a big part of that experience is using iCloud. You may not even know it. You may not know how much iCloud you are actually using (which is how Apple likes it) as it is heavily integrated into every Apple device. The iCloud service uses your Apple ID to gain access. Your Apple ID consists of your username (an email address) and a password. You can enable extended security features like two factor authentication, but for simplicity, I will discuss devices using only a standard login ID and password… nothing fancy.
iCloud is Apple’s cloud network services layer that support service synchronization between devices like calendaring, email contacts, phone data, iMessage, iCloud Drive, Apple Music, iTunes Playlists, etc. As long as your Apple ID remains logged into these services, you will have access to the same data across all of your devices. Note, your devices don’t have to use iCloud at all. You can disable it and not use any of it. However, Apple makes it terribly convenient to use iCloud’s services including such features as Find my iPhone, which allows you to lock or erase your iPhone if it’s ever lost or stolen.
One feature that automatically comes along for the ride when using iCloud services is an iCloud lock. If you have ever logged your iPhone or iPad into iCloud, your device is now locked to your Apple ID. This means that if it’s ever lost or stolen, no one can use your device because it is locked to your iCloud Apple ID and locked to Find my iPhone for that user (which I believe is now enabled by default upon logging into iCloud).
This also means that any recipient of such an iCloud locked device cannot use that device as their own without first disassociating that device from the previous Apple ID. This lock type is known as an iCloud lock. This type of Apple lock is separate from a phone carrier lock which limits with which carriers a phone can be used. Don’t confuse or conflate the two.
I should further qualify what “use your device” actually means after an iCloud lock is in place. A thief cannot clean off your device and then log it into their own Apple ID and use the phone for themselves. Because the phone is iCloud locked to your account, it’s locked to your account forever (or until you manually disassociate it). This means that unless you explicitly remove the association between your Apple ID and that specific device, no one can use that device again on Apple’s network. The best a would-be thief can do with your stolen phone is open it up and break it down for limited parts. Or, they can sell the iCloud locked device to an unsuspecting buyer before the buyer has a chance to notice that it’s iCloud locked.
Buying Used Devices
If you’re thinking of buying a used iPhone from an individual or any online business who is not Apple and because the iCloud lock is an implicit and automatic feature enabled simply by using iCloud services, you will always need to ask any seller if the device is iCloud unlocked before you pay. Or, more specifically, you will need to ask if the previous owner of the device has logged out and removed the device from Find my iPhone services and all other iCloud and Apple ID services. If this action has not been performed, then the device will remain iCloud locked to that specific Apple ID. You should also avoid the purchase and look for a reputable seller.
What this means to you as a would-be buyer of used Apple product is that you need to check for this problem immediately before you walk away from the seller. If the battery on the device is dead, walk away from the sale. If you’re buying a device sight unseen over the Internet, you should be extremely wary before clicking ‘Submit’. In fact, I’d recommend not buying used Apple equipment from eBay or Craigslist because of how easy it is to buy bricked equipment and lose your money. Anything you buy from Apple shouldn’t be a problem. Anything you buy from a random third party, particularly if they’re in China, might be a scam.
Can iCloud Lock be Removed?
Technically yes, but none of the solutions are terribly easy or in some cases practical. Here is a possible list of solutions:
1) This one requires technical skills, equipment and repair of the device. With this solution, you must take the device apart, unsolder a flash RAM chip, reflash it with a new serial number, then reassemble the unit.
Pros: This will fix the iPad or iPhone and allow it to work
Cons: May not work forever if Apple notices the faked and changed serial number. If the soldering job was performed poorly, the device hardware could fail.
Let’s watch a video of this one in action:
2) Ask the original owner of the device, if you know who they are, to disassociate the iDevice from their account. This will unlock it.
Pros: Makes the device 100% functional. No soldering.
Cons: Requires knowing the original owner and asking them to disassociate the device.
3) Contact Apple with your original purchase receipt and give Apple all of the necessary information from the device. Ask them to remove the iCloud lock. They can iCloud unlock the device if they so choose and if they deem your device purchase as valid.
Pros: Makes the device 100% functional.
Cons: Unlocking Apple devices through Apple Support can be difficult, if not impossible. Your mileage may vary.
4) Replace the logic board in the iPad / iPhone with one from another. Again, this one requires repair knowledge, tools, experience and necessary parts.
Pros: May restore most functionality to the device.
Cons: Certain features, like the touch ID button and other internal systems may not work 100% after a logic board replacement.
As you can see, none of these are particularly easy, but none are all that impossible either. If you’re not comfortable cracking open your gear, you might need to ask a repair center if they can do any of this for you. However, reflashing a new serial number might raise eyebrows at some repair centers with the assumption that your device is stolen. Be careful when asking a repair center to perform #1 above for you.
iCloud Locking
It seems that the reason the iCloud Lock came into existence is to thwart thieves. Unfortunately, it doesn’t actually solve that problem. Instead, it creates a whole new set of consumer problems. Now, not only are would-be thieves stealing iPads still, they’re selling these devices iCloud locked to unsuspecting buyers and scamming them out of their money. The thieves don’t care. The only thing this feature does is screw used device consumers out of their money.
Thieves
That Apple thought they could stop thievery by implementing the iCloud lock shows just how idealistically naïve Apple’s technical team really is. Instead, they created a whole new scamming market for iCloud locked Apple devices. In fact, the whole reason this article exists is to explain this problem.
For the former owner of an iPad which was stolen, there’s likely no hope of ever getting it back. The iCloud lock feature does nothing to identify the thief or return stolen property to its rightful owner. The iCloud lock simply makes it a tiny nuisance to the thief and would-be scammer. As long as they can get $100 or $200 for selling an iCloud locked iPad, they don’t care if it’s iCloud locked. In fact, the fact that this feature exists makes no difference at all to a thief.
It may reduce the “value” of the stolen property some, but not enough to worry about. If it was five finger discounted, then any money had is money gained, even if it’s a smaller amount than anticipated. For thieves, the iCloud lock does absolutely nothing to stop thievery.
Buyers
Here’s the place where the iCloud lock technology hurts the most. Instead of thwarting would-be thieves, it ends up placing the burden of the iCloud lock squarely on the consumer. If you are considering buying a used device, which should be a simple straightforward transaction, you now have to worry about whether the device is iCloud locked.
It also means that buying an iPhone or iPad used could scam you out of your money if you’re not careful. It’s very easy to buy these used devices sight unseen from online sellers. Yet, when you get the box open, you may find the device is iCloud locked to an existing Apple ID. At that point, unless you’re willing to jump through one of the four hoops listed above, you may have just been scammed.
If you can’t return the device, then you’re out money. The only organization that stands to benefit from the iCloud lock is Apple and that’s only because they’ll claim you should have bought your device new from them. If this is Apple’s attempt at thwarting or reducing used hardware sales, it doesn’t seem to be working. For the consumer, the iCloud lock seems intent on harming consumer satisfaction for device purchases of used Apple equipment… a market that Apple should want to exist because it helps them sell more software product (their highest grossing product).
Sellers
For actually honest sellers, an iCloud lock makes selling used iPad and iPhone devices a small problem. For unscrupulous sellers, then there is no problem here at all. An honest seller must make sure that the device has been disassociated from its former Apple ID before putting the item up for sale. If an honest seller doesn’t know the original owner and the device is locked, it should not be sold. For the unscrupulous sellers, the situation then becomes the scammer selling locked gear and potentially trafficking stolen goods.
It should be said that it is naturally assumed that an iCloud locked device is stolen. It makes sense. If the owner had really wanted the item sold as used, they would have removed the device from iCloud services… except that Apple doesn’t make this process at all easy to understand.
Here’s where Apple fails would-be sellers. Apple doesn’t make it perfectly clear that selling the device requires removing the Apple ID information fully and completely from the device. Even wiping the device doesn’t always do this as there are many silent errors in the reset process. Many owners think that doing a wipe and reset of the device is enough to iCloud unlock the device. It isn’t.
As a would-be seller and before wiping it, you must go into your iPad or iPhone and manually remove the device from Find my iPhone and log the phone out of all Apple ID services. This includes not only logging it out of iCloud, but also logging out out of iTunes and Email and every other place where Apple requires you to enter your Apple ID credentials. Because iOS requires logging in multiple times separately to each of these services, you must log out of these services separately on the device. Then, wipe the device. Even after all of that, you should double check Find my iPhone from another device to make sure the old device no longer shows up there. In fact, you should walk through the setup process once to the point where it asks you for your Apple ID to confirm the device is not locked to your Apple ID.
This is where it’s easy to sell a device thinking you’ve cleared it all out, but you actually haven’t. It also means that this device was legitimately sold as used, but wasn’t properly removed from iCloud implying that it’s now stolen. Instead, Apple needs to offer a ‘Prep for Resell’ setting in Settings. This means this setting will not only wipe the device in the end, but it will also 100% ensure an iCloud unlock of the device and log it out of all logged Apple ID services. This setting will truly wipe the device clean as though it were an unregistered, brand new device. If it’s phone device, it should also carrier unlock the phone so that it can accept a SIM card from any carrier.
Apple makes it very easy to set up brand new devices, but Apple makes it equally difficult to properly clear off a device for resale. Apple should make this part a whole lot easier for would-be sellers. If need be, maybe Apple needs to sell a reseller toolkit to scan and ensure devices are not only iCloud unlocked, but run diagnostic checks to ensure they are worthy of being sold.
If you like what you’ve read, please leave a comment below and give me your feedback.
↩︎
Software Engineering and Architecture
Here’s a subject of which I’m all too familiar and is in need of commentary. Since my profession is technical in nature, I’ve definitely run into various issues regarding software engineering, systems architecture and operations. Let’s Explore.
Software Engineering as a Profession
One thing that software engineers like is to be able to develop their code on their local laptops and computers. That’s great for rapid development, but it causes many problems later, particularly when it comes to security, deployment, systems architecture and operations.
For a systems engineer / devops engineer, the problem arises when that code needs to be productionalized. This is fundamentally a problem with pretty much any newly designed software system.
Having come from from a background of systems administration, systems engineering and devops, there are lots to be considered when wanting to deploy freshly designed code.
Designing in a Bubble
I’ve worked in many companies where development occurs offline on a notebook or desktop computer. The software engineer has built out a workable environment on their local system. The problem is, this local eneironment doesn’t take into account certain constraints which may be in place in a production environment such as internal firewalls, ACLs, web caching systems, software version differences, lack of compilers and other such security or software constraints.
What this means is that far too many times, deploying the code for the first time is fraught with problems. Specifically, problems that were not encountered on the engineer’s notebook… and problems that sometimes fail extremely bad. In fact, many of these failures are sometimes silent (the worst kind), where everything looks like it’s functioning normally, but the code is sending its data into a black hole and nothing is actually working.
This is the fundamental problem with designing in a bubble without any constraints.
I understand that building something new is fun and challenging, but not taking into account the constraints the software will be under when finally deployed is naive at best and reckless at the very worse. It also makes life as a systems engineer / devops engineer a living hell for several months until all of these little failures are sewn shut.
It’s like receiving a garment that looks complete, but on inspection, you find a bunch of holes all over that all need to be fixed before it can be worn.
Engineering as a Team
To me, this is situation means that software engineer is not a team player. They might be playing on the engineering team, but they’re not playing on the company team. Part of software design is designing for the full use case of the software, including not only code authoring, but systems deployment.
If systems deployment isn’t your specialty as a software engineer, then bring in a systems engineer and/or devops engineer to help guide your code during the development phase. Designing without taking the full scope of that software release into consideration means you didn’t earn your salary and you’re not a very good software engineer.
Yet, Silicon Valley is willing to pay “Principal Engineers” top dollar for these folks failing to do their jobs.
Building and Rebuilding
It’s an entirely a waste of time to get to the end of a software development cycle and claim “code complete” when that code is nowhere near complete. I’ve had so many situations where software engineers toss their code to us as complete and expect the systems engineer to magically make it all work.
It doesn’t work that way. Code works when it’s written in combination with understanding of the architecture where it will be deployed. Only then can the code be 100% complete because only then will it deploy and function without problems. Until that point is reached, it cannot be considered “code complete”.
Docker and Containers
More and more, systems engineers want to get out of the long drawn out business of integrating square code into a round production hole, eventually after much time has passed, molding the code into that round hole is possible. This usually takes months. Months that could have been avoided if the software engineer had designed the code in an environment where the production constraints exist.
That’s part of the reason for containers like Docker. When a container like Docker is used, the whole container can then be deployed without thought to square pegs in round holes. Instead, whatever flaws are in the Docker container are there for all to see because the developer put it there.
In other words, the middle folks who take code from engineering and mold it onto production gear don’t relish the thought of ironing out hundreds of glitchy problems until it seamlessly all works. Sure, it’s a job, but at some level it’s also a bit janitorial, wasteful and a unnecessary.
Planning
Part of the reason for these problems is the delineation between the engineering teams and the production operations teams. Because many organizations separate these two functional teams, it forces the above problem. Instead, these two teams should be merged into one and work together from project and code inception.
When a new project needs code to be built that will eventually be deployed, the production team should be there to move the software architecture onto the right path and be able to choose the correct path for that code all throughout its design and building phases. In fact, every company should mandate that its software engineers be a client of operations team. Meaning, they’re writing code for operations, not the customer (even though the features eventually benefit the customer).
The point here is that the code’s functionality is designed for the customer, but the deploying and running that code is entirely for the operations team. Yet, so many software engineers don’t even give a single thought to how much the operations team will be required support that code going forward.
Operational Support
For every component needed to support a specific piece of software, there needs to be a likewise knowledgeable person on the operations team to support that component. Not only do they need to understand that it exists in the environment, the need to understand its failure states, its recovery strategies, its backup strategies, its monitoring strategies and everything else in between.
This is also yet another problem that software engineers typically fail to address in their code design. Ultimately, your code isn’t just to run on your notebook for you. It must run on a set of equipment and systems that will serve perhaps millions of users. It must be written in ways that are fail safe, recoverable, redundant, scalable, monitorable, deployable and stable. These are the things that the operations team folks are concerned with and that’s what they are paid to do.
For each new code deployment, that makes the environment just that much more complex.
The Stacked Approach
This is an issue that happens over time. No software engineer wants to work on someone else’s code. Instead, it’s much easier to write something new and from scratch. It’s easy for software engineer, but it’s difficult for the operations team. As these new pieces of code get written and deployed, it drastically increases the technical debt and burden on the operations staff. Meaning, it pushes the problems off onto the operations team to continue supporting more and more and more components if none ever get rewritten or retired.
In one organization where I worked, we had such an approach to new code deployment. It made for a spider’s web mess of an environment. We had so many environments and so few operations staff to support it, the on-call staff were overwhelmed with the amount of incessant pages from so many of these components.
That’s partly because the environment was unstable, but that’s partly because it was a house of cards. You shift one card and the whole thing tumbles.
Software stacking might seem like a good strategy from an engineering perspective, but then the software engineers don’t have to first line support it. Sometimes they don’t have to support it at all. Yes, stacking makes code writing and deployment much simpler.
How many times can engineering team do this before the house of cards tumbles? Software stacking is not an ideal any software engineering team should endorse. In fact, it’s simply comes down to laziness. You’re a software engineer because writing code is hard, not because it is easy. You should always do the right thing even if it takes more time.
Burden Shifting
While this is related to software stacking, it is separate and must be discussed separately. We called this problem, “Throwing shit over the fence”. It happens a whole lot more often that one might like to realize. When designing in a bubble, it’s really easy to call “code complete” and “throw it all over the fence” as someone else’s problem.
While I understand this behavior, it has no place in any professionally run organization. Yet, I’ve seen so many engineering team managers endorse this practice. They simply want their team off of that project because “their job is done”, so they can move them onto the next project.
You can’t just throw shit over the fence and expect it all to just magically work on the production side. Worse, I’ve had software engineers actually ask my input into the use of specific software components in their software design. Then, when their project failed because that component didn’t work properly, they threw me under the bus for that choice. Nope, that not my issue. If your code doesn’t work, that’s a coding and architecture problem, not a component problem. If that open source component didn’t work in real life for other organizations, it wouldn’t be distributed around the world. If a software engineer can’t make that component work properly, that’s a coding and software design problem, not an integration or operational problem. Choosing software components should be the software engineer’s choice to use whatever is necessary to make their software system work correctly.
Operations Team
The operations team is the lifeblood of any organization. If the operations team isn’t given the tools to get their job done properly, that’s a problem with the organization as a whole. The operations team is the third hand recipient of someone else’s work. We step in and fix problems many times without any knowledge of the component or the software. We do this sometimes by deductive logic, trial and error, sometimes by documentation (if it exists) and sometimes with the help of a software engineer on the phone.
We use all available avenues at our disposal to get that software functioning. In the middle of the night the flow of information can be limited. This means longer troubleshooting times, depending on the skill level of the person triaging the situation.
Many organizations treat its operations team as a bane, as a burden, as something that shouldn’t exist, but does out of necessity. Instead of treating the operations team as second class citizens, treat this team with all of the importance that it deserves. This degrading view typically comes top down from the management team. The operations team is not a burden nor is it simply there out of necessity. It exists to keep your organization operational and functioning. It keeps customer data accessible, reliable, redundant and available. It is responsible for long term backups, storage and retrieval. It’s responsible for the security of that data and making sure spying eyes can’t get to it. It is ultimately responsible to make sure the customer experience remains at a high excellence standard.
If you recognize this problem in your organization, it’s on you to try and make change here. Operations exists because the company needs that job role. Computers don’t run themselves. They run because of dedicated personnel who make it their job and passion to make sure those computers stay online, accessible and remain 100% available.
Your company’s uptime metrics are directly impacted by the quality of your operations team staff members. These are the folks using the digital equivalent of chewing gum and shoelaces to keep the system operating. They spend many a sleepless night keeping these systems online. And, they do so without much, if any thanks. It’s all simply part of the job.
Software Engineer and Care
It’s on each and every software engineer to care about their fellow co-workers. Tossing code over the fence assuming there’s someone on the other side to catch it is insane. It’s an insanity that has run for far too long in many organizations. It’s an insanity that needs to be stopped and the trend needs to reverse.
In fact, by merging the software engineering and operations teams into one, it will stop. It will stop by merit of having the same bosses operating both teams. I’m not talking about at a VP level only. I’m talking about software engineering managers need to take on the operational burden of the components they design and build. They need to understand and handle day-to-day operations of these components. They need to wear pagers and understand just how much operational work their component is.
Only then can engineering organizations change for the positive.
As always, if you can identify with what you’ve read, I encourage you to like and leave a comment below. Please share with your friends as well.
↩︎
Random Thoughts - Randocity! 
leave a comment