PWNAGE + Bootloader + Warrenty?

Discussion in 'Pwnage and Winpwn Discussions' started by mclaurin10, Apr 26, 2008.

  1. mclaurin10

    mclaurin10 New Member

    Joined:
    Mar 18, 2008
    Messages:
    554
    Likes Received:
    11
    Device:
    iPhone 3G (Black)
    I remember reading somewhere that PWNAGE re-flashes the bootloader so that it will accept custom firmware - Is this true?

    If it is and I have to send my ipod back to apple will they be able to test the bootloader to see if I have ever PWNED my ipod?

    Can they plug it into some diagnostics machine that will tell them if the bootloader has been messed with?

    Obviously this will affect the warrenty, so kind of important - my ipod's headphone ackd dosent work anymore and I need to send it back but I already PWNED
  2. DJ Xander

    DJ Xander New Member

    Joined:
    Sep 15, 2007
    Messages:
    832
    Likes Received:
    8
    BootLoaders don't affect iPod Touches, only iPhones. This is because the iPod Touch lacks the second BootLoader that the iPhone has. So as long as you restore and set up as a new iPod, no, there is no way Apple can know. Guaranteed.
    1 person likes this.
  3. iAlexander

    iAlexander New Member

    Joined:
    Jan 2, 2008
    Messages:
    51
    Likes Received:
    1
    Device:
    iPod touch
    If you restore, you're effectively un-pwning your iPod. So that's all you need to do!

    Please Register or Log in to view images

    1 person likes this.
  4. jimbeam

    jimbeam Active Member

    Joined:
    Nov 19, 2007
    Messages:
    3,694
    Likes Received:
    12
    Device:
    iPhone 3G (Black)
    The iphone & ipod touch both have the same bootloader that is exploited in pwnage. If the ipod didn't have it there would be no pwning ipods. This is from the dev-teams. site it explains the proses.


    iBoot Patch

    One specific aspect of our attack that is worth examining more closely is the iBoot patch. iBoot is the last and most complicated bootloader on the devices, and is what actually loads up the kernel with device tree. However, Apple made the decision to keep all the PKE (Public Key Encryption) logic out of iBoot, instead putting it in the secure bootloader. Thus, iBoot actually jumps into the secure bootloader when it wants to verify the authenticity of an 8900 file. This makes it hard to directly patch out the RSA signature verification from iBoot, as it actually occurs in the secure bootloader. Simply killing the jump into the secure bootloader is impossible, as it also fills in other information iBoot needs to proceed.

    Because of the tight coupling between the secure bootloader and the higher-level bootloaders, Apple gave us a solution: the secure bootloader often needs to call functions in the higher-level bootloaders, but it has the problem of knowing where to jump, as functions move around in different revisions. To get around this, Apple made thunks out of the function calls, and makes the higher-level bootloaders patch the secure bootloader on the fly (in RAM) with the relevant jump addresses. They just copy the secure bootloader into RAM and blindly apply a list of patches to it. We exploited this pre-existing patching mechanism to patch out the RSA signature verification from secure bootloader.

    Here it is in more detail. If you really interested. Strait from the horses mouth.
    http://wikee.iphwn.org/s5l8900:pwnage
    1 person likes this.

Share This Page