Page 1 of 4 1234 LastLast
Results 1 to 10 of 36
Discuss What "irreparable" damage means in terms of phone hacking at the General - Hackint0sh.org; First off, some disclaimers (they may mean something to you, they might not): 0) My ...
  1. #1
    Senior Professional Array

    Join Date
    Jul 2007
    Posts
    151
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    16

    Default What "irreparable" damage means in terms of phone hacking

    First off, some disclaimers (they may mean something to you, they might not):
    0) My focus in school was towards embedded systems and computer architecture.
    1) I am not in the phone unlocking business.
    2) I am not in the business of making phones, but kinda wish I was because it'd be cool trying to make the ultimate phone.
    3) I did not participate in the unlocking of the iPhone.
    3a) I don't have any intention on joining the unlocking effort. I mean... in a past post, I already mentioned I'm back to using my e815 already and cancelled my AT&T contract.
    4) I was involved in the community effort to get a Verizon Motorola E815 (CDMA phone) to run the Bell Mobility provider firmware in order to gain some pretty kick ass features for a verizon phone. Much of my focus was towards understanding why simply flashing the bell firmware onto the verizon phone resulted in a brick even though the hardware was the same.

    The first and last point there is where I source the majority of the information I'm about to present.

    Generally, a phone consists of two major components:
    1) General CPU to run the UI. (The ARM chip that apps run on.)
    2) CPU to run the cell radio. (also known to most people as the baseband here)

    In more complex phones, there are:
    3) A bluetooth module, which is a computer in and of itself.
    4) A wifi module, which is a computer in and of itself.
    5) A camera, which is typically supported by the general CPU because it's so much easier to just build the support in.

    Depending on the design of the phone, these can all be physically in the same chip package. Check out Qualcomm's line for some pretty well integrated phone chipsets. But those last 3 parts doesn't this really matters much to us.

    What's important is that your general CPU and your baseband is essentially the same relationship as your laptop and a dialup modem. Whether you're talking about my E815, your Palm Treo, your Nokia N85, or your iPhone, it's the same thing. Think of your iPhone as an iPod Touch with a modem. Because that's really what it is. I mean, heck, it even understands Hayes-AT commands.

    For conveinence, I'm going to talk about these two parts of your iPhone as the iTouch (OSX/screen/etc) and the baseband (the modem).

    Now that you understand that, let's talk about the baseband. The baseband is a small computer that runs software to control the radio attached to it and deal with cell phone signals. When calls, text messages, data comes in, it handles what it needs to negotiate with the network, and then forwards the necessary info along to the iTouch. These notifications then cause the iTouch to launch the app necessary, connect to the serial port to the modem, and then retrieve the text message or set off the ringer or whatnot.

    If your baseband is missing, the iTouch half should be able to simply power up and not have network access. It's really the same as unplugging your modem from your computer.

    Because the baseband is what controls access to the network, it's where unlocking has to happen. Now, there's two ways to go about this:
    1) you enter the correct secret code through the serial port, and then the baseband goes "oh, okay, sure, I'll unlock." Then it writes what it needs to flash, and you're all set.
    2) you forcibly change the contents of the baseband flash chip. Either by using JTAG hardware, removing the chip and writing to it using some other piece of hardware, or by exploiting the baseband firmware to cause it to write where it normally wouldn't.

    Number 1 is what we wish we could do.
    Number 2 is what we're actually doing.

    So what's wrong with writing to the baseband flash directly? Lots of things can go wrong. Doesn't mean they will, but can. For the moment, I'm guessing that Apple tried doing an update and found that something did go wrong, we just don't see it. And then they published the "just a warning folks..." and people freaked out thinking it's Apple's fault.

    So you're thinking "Now wait a sec... can't we just write everybody back and it'll be alright? I mean we have write access to the chip via exploit, etc...." And I'm here to say, "that'd be nice wouldn't it? but uh. no. things don't work that way."

    The E815 "monster" (the biggest one) firmware file has the following parts:
    1) Mini bootloader - tiny piece of code which tells the general CPU how to start loading code and find the real bootloader.
    2) Bootloader - larger piece of code that prepares the USB, prepares the serial ports, lights up the screen, verifies the firmware checksum, checks to make sure all the hardware works before startup. It's like your PC's BIOS or Mac's EFI/OpenFirmware. If you're in the bootloader, you also have the option for the computer attached through USB or Serial to send you a "ramloader" which is really just a flashing utility.
    3) Firmware - the firmware for the general CPU. It's like your OS install. Like OSX with no configuration set and no apps. On the iPhone, it'd be the kernel and a bunch of drivers like IOKit, BluetoothManager, etc.
    3a) The firmware file for the baseband - On the e815, it's integrated into the general firmware since Qualcomm designed a chipset which has the baseband and general CPU closely tied together. On the iPhone, it's those eep/etc files people keep talking about.
    4) Embedded File System - all the files that the firmware runs to make the UI all nice and stuff. On the iPhone, this would be the Apps folder, the branding, the language files, etc.
    4a) flex_file.s - This "flex file" is some config info for the baseband. The E815's main firmware (3) will take this file on startup and write some config data to the baseband's flash area and then erase the file once it's done. It's actual contents I don't understand all of, but it looks to me like it's basically like what you'd find in a SIM card. (a phone book which isn't used by the E815, and possibly a few bits of information to help it connect to the cdma network better.)

    So that's what a flash that for most users, does the E815 equivalent of "factory restore." Except for a rare few people, this erases pretty much everything and writes it all new.



  2. #2
    Senior Professional Array

    Join Date
    Jul 2007
    Posts
    151
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    16

    Default

    Now... considering this file is the same for everybody, there's obviously something amiss since if that was everything on a phone, we'd all have perfectly identical phones and we couldn't tell them apart. So...where's the IMEI/ESN?

    Still on the phone in an area only the factory should write to because it'd cause quite a mess if people started changing this info.

    What else is on the phone in that area? Factory calibration data.

    What is factory calibration data?

    Glad you asked! There's a variety of stuff important your phone's operation that can't be made identical each and every time a phone comes off the assembly line. Every clock chip won't run perfectly in sync. Every wire won't be the exact same length, so the radio tuning might be different. Every thermistor/heat sensor for the battery recharge won't provide the exact same value for the same temperature. Some memory chips might not be the same brand and have different config flags. Your iPhone has a 8gb and a 4gb version, there could be a value stored in the early part of flash to tell it how much to start up with. A checksum for the factory calibration data is probably here too. Lots of important stuff.

    You can probably tell why this is pretty darn important. Afterall, the temperature sensor for the battery charger? If that's severely wrong, the battery could be dangerously hot and the phone wouldn't know it, causing a fire and lawsuits. And the radio tuning attributes? If your radio circuitry is out of tune, your reception will be poor, causing the radio to think it needs to turn up the power. This causes you to be exposed to more radiation than necessary, your speakers to sound funny with all the ticking, and your battery life to suck. And the FCC can come lay the smackdown on both you and the manufacturer. You don't want that.

    If you lose this data, you can't copy it from another phone because it'll probably be the wrong settings. It's game over unless you can somehow put it through the calibration process, which of course will require special machinery. (Afterall, how do you calibrate something without a known good reference?)

    It gets better... or worse, depending on how you look at it.

    The process to write to firmware in general is pretty hairy.

    Checksums are important everywhere because you have to be pretty sure you know what you wrote. If a future version of the baseband firmware requires Flash blocks to have the correct checksums, then they could refuse to boot or reflash unless those corrupt blocks are fixed. There's no way you can argue that checksums are a bad idea. (by the way, if 1.1.1 and its corresponding baseband firmware actually does cause bricking, I'm betting checksums failing will be involved. No, I don't believe 1.1.1 will cause massive bricking of phones. Do I believe 1.1.1 will cause a small group of iPhones to brick? Yes; afterall if you've read this far, I hope you understand how little we know about the effects of the unlock process.)

    Flash generally has to be written to in blocks. (because both NOR and NAND types require the erase to happen in blocks) That's just the way it's designed. It makes designing chips (a difficult task) less difficult. You have to make sure if you're writing into a block where you want to retain the data, you combine it with your new data and write it back.

    So, if a section of your firmware data overlaps with some factory-provided data, doing the write incorrectly can cause some of it to get lost or filled with garbage. Since if we're not using bbupdater, who knows whether or not we got it right? I don't. I haven't read the source code for the unlock apps.

    Oh oh! Speaking of which, if you're not using the proper flashing utility, you could be stepping on the bootloader as well.

    Overwriting the code that controls your startup is risky because if it doesn't work, how do you start yourself to fix it? That final reboot is fatal because your flashing utility isn't in memory anymore.

    Ever seen a PC get hit by a virus which overwrote the flash chip where the BIOS is? It's the same thing if you were updating your BIOS and then a squirrel jumps into the power transformer down the block, causing a power outage while you're flashing.

    Yeah, it's a very large brick. You'd be impressed if responded to the power button. but you'll still see only a black screen. Lucky for those people, you can typically run the flash utility on another similar PC, and swap flash chips just before the flashing process starts. This works because once the flash utility has been loaded into RAM, your PC doesn't depend on the Flash (since while you're writing to it, it's obviously incomplete and useless).

    You can't do this on a phone. In fact, in many phones, RAM and Flash are in inside the same black plastic shell on the board.

    If you corrupt the baseband's bootloader, what then? Your baseband's bricked. You can't start it up to reflash cuz it has nothing to start up with. When bbupdater talks to the serial port to do the flash and nothing is there to hear the message, it's obviously a dead end. (so all you people asking about making a custom bbupdater to fix bricking, this here is why nobody's answering) You can't swap the chip cuz it's not in a socket. You're only way to write to it is through JTAG or any factory provided in-circuit programming facilities..... which is usually JTAG anyways. If anybody out there feels like figuring out JTAG for the iPhone, that'd be awesome. But for all you people with bricked phones, it doesn't help you if you don't have JTAG hardware anyways.

    So in short, yes, attempting to unlock your iPhone can easily cause it to be in a irreparable state. You don't need Apple to tell you that. You can see it already with the unlock failures in the forums.

    Will Apple try to purposefully brick your phone? No. That'd be the most retarded PR move ever. Big enough to kill the company, not just iPhone.
    Can an Apple updater brick your phone without it being on purpose? Yes.
    Can Apple do something to prevent an existing iPhone from ever bricking on update? No.

  3. #3
    Respected Professional Array

    Join Date
    Aug 2007
    Location
    Paris, France
    Posts
    533
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    34

    Default

    Extremely enlightening discussion and analysis. I've been waiting to read such details for months. Your treatment of an otherwise “complex” subject was very clear indeed. Thanks for that!

    Having read what you've written, the question that begs to be asked is “are any of the unlocks that are currently available today able to sustain a flash of the BB that may come as a result of a FM update AND can Apple actually produce an unlock that is permenant?"

    Apple aside for the moment, my understanding of the two software unlocks is as follows: the Dev Team’s unlock reflashes a modified version of the BB, whereas IPFS reprograms some part of the EEPROM prior to reflashing the BB with a clean version of it.

    IPFS recently stated on their website that their unlock is DISTINCT and unlike any other unlock available on the market. Do you believe that this is just hype or is their claim justifiable? Assuming that their claim is justifiable, what have they discovered and what do you think they have done?

    Finally, in order to do business in many European countries and receive local regulatory sign-off (i.e. OFCOM, ARCEP, REGTP), Apple was no doubt asked to demonstrate without a reason of a doubt their ability to unlock the phone and this unlock, logic states, is no doubt permanent and cannot be undone as the result of a FM upgrade w/ a full BB flash. Since you have identified the BB as the place where the unlock has to happen – and I’m sure that we’ll all agree that this is the case – how would Apple be able to make the claim that they can permanently unlock the phone after X years with operator Y if said unlock is not resistent to future BB flashing. They couldn't. It would therefore appear that the real unlock is found elsewhere and that what the Dev Team and others have done (???) is nothing more than a very effective workaround with a limited life span and the their efforts will consist of playing a horrible game of "cat and mouse" to borrow Steve Jobs' words until such time as the real unlock is found?

    Regarding the HW unlock/TSIM solutions, can these be considered as permanent unlocks?
    Last edited by Snowbird; 09-27-2007 at 04:26 PM.

  4. #4
    Board Hero Array gaz919's Avatar

    Join Date
    Sep 2007
    Posts
    1,124
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    65

    Default

    I think a good eeprom change might be the trick the dev team should look into it more, eeprom changes would stay after new firmware, as log as the offsets stay the same for that area

  5. #5
    Senior Professional Array

    Join Date
    Jul 2007
    Posts
    187
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    16

    Default

    I think geohot cracked JTAG - http://iphonejtag.blogspot.com


  6. #6
    sam
    sam is offline
    Chief of Administration
    iPhone Dev Team
    Array sam's Avatar

    Join Date
    Jun 2007
    Posts
    1,852
    Post Thanks / Like
    Downloads
    35
    Uploads
    277
    Rep Power
    10

    Default

    Thats a nice summary but the baseband and it's layout inner working is a bit more complex. The sGold2 is a very advanced version of what was discribed here. I will try to give a short overview on the methods later today in this thread.

  7. #7
    Senior Professional Array

    Join Date
    Sep 2007
    Posts
    481
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    32

    Default

    Quote Originally Posted by sam View Post
    Thats a nice summary but the baseband and it's layout inner working is a bit more complex. The sGold2 is a very advanced version of what was discribed here. I will try to give a short overview on the methods later today in this thread.
    Please do, I would love to understand the method too. For Gaz, even though the modified EEPROM settings might stay after firmware, doesn't mean the setting will work with the BB anymore, right?

    If IPSF could write to the EEPROM before flashing to the bb with the 1.1.1 fw, we might get another unlock?

    But as most people concern is what if we can't even pass through the activation part.

  8. #8
    Newbie Array

    Join Date
    Sep 2007
    Posts
    2
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    0

    Default Unlocking Vs. Jailbreak/iBrickr Issues

    Wow! Excellent overview of a complex issue. I have a simple question in relative terms.

    This refers to those who have unlocked their iPhones from the AT&T carrier. I am still using AT&T, but have used iBrickr to Jailbreak my phone to add apps, ringtones, themes... What are my most likely risks and recommended ways to avoid damage to my iPhone?

    I'm dedicated to keeping my mods at the cost of never updating if necessary (not in Apple's best interests, and maybe not mine either). My daughter is more cautious.

    Thoughts?

  9. #9
    Senior Professional Array

    Join Date
    Sep 2007
    Posts
    481
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    32

    Default

    Correct me if I am wrong, but you are pretty safe because jailbreak doesnt write anything to the baseband, in terms of the OP explanation it will be on the General CPU level (OS level) hack.

  10. #10
    Respected Professional Array

    Join Date
    Aug 2007
    Location
    Paris, France
    Posts
    533
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    34

    Default

    Quote Originally Posted by sailhome1 View Post
    Wow! Excellent overview of a complex issue. I have a simple question in relative terms.

    This refers to those who have unlocked their iPhones from the AT&T carrier. I am still using AT&T, but have used iBrickr to Jailbreak my phone to add apps, ringtones, themes... What are my most likely risks and recommended ways to avoid damage to my iPhone?

    I'm dedicated to keeping my mods at the cost of never updating if necessary (not in Apple's best interests, and maybe not mine either). My daughter is more cautious.

    Thoughts?
    With the exception of the FM upgrade failing and you having to restore (normal behavour for a jailbroken/modified phone), I think that it's safe to assume that you're fine. This said, all those nice applications, ringtones, etc., may become a thing of the past post migration.

    This having been said, you never know, and it's for this reason that you should hold-off upgrading until such time as we all understand what the new FM does, since what you've done may interfere with something that Apple will be doing and this could cause a conflict of sorts. It would be much better to remove the problem apps/modifications that could case conflicts after the numerous warnings that will appear on this site beforehand, as opposed to learning what they are the hard way.

    My personal thoughts are that even unlocked phones will go unharmed, however I just don't know what will happen to the unlock. I guess we shall see.
    Last edited by Snowbird; 09-27-2007 at 07:20 PM.


 

 
Page 1 of 4 1234 LastLast

Similar Threads

  1. MacNN: Mossberg: Win 7 means Mac no longer "much better"
    By hackint0sh in forum Latest Headlines
    Replies: 0
    Last Post: 10-08-2009, 07:30 PM
  2. Replies: 17
    Last Post: 04-21-2008, 02:25 PM
  3. HAPPY NEW "iPHONE HACKING" YEAR!
    By hansanrg in forum iPhone "2G" (Rev. 1)
    Replies: 1
    Last Post: 01-01-2008, 06:05 PM
  4. Replies: 2
    Last Post: 10-27-2007, 12:36 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Powered by vBulletin®
Copyright © 2014 vBulletin Solutions, Inc. All rights reserved.
Search Engine Friendly URLs by vBSEO
(c) 2006-2012 Hackint0sh.org
All times are GMT +2. The time now is 08:45 PM.
twitter, follow us!