Overview

Nice job guys. I believe the 3.9 bootloader doesn't check the filler, in fact it doesn't even check the length of the filler, so thats yet another exploit into that bootloader.

i hope that somebody use this information for make a new unlock ... thanks a lot !!!!

I've looked into it a bit and exp(3) attack seems impossible for two reasons - first is just technical, but still valid and second is that for this attack to work, we need to have a control on way bigger number of "garbage" bits than everyone reported so far - slightly more than 2/3rds!

http://www.hackint0sh.org/forum/showpost.php?p=136709&postcount=30

The 0x2f 00 byte isn't ASN.1 its just the PKCS#1 marker to indicate the end of padding. It seems that pre 4.0 secpack they were using random packing (encryption packing) and then have switched to ff packing (signature packing).

Thanks leachbj, I've updated that info.

well, musclenerd can we restore original seczone if i've not back up

Hi jade...

The above info won't (as far as I know) help you do that. But I think you're in good shape though. Here's why...

Apple fixed the vulnerability that IPSF used to unlock the phone via the token at seczone+0x400. But they only did that on new iPhones with the 4.6 bootloader, which can't successfully run the IPSF unlock anyway.

Apple seems to have shown their hand with regards to bootloader changes. They're happy enough to ship out iPhones with newer bootloaders on them, but are understandibly reluctant to update bootloaders of iPhones already in the field. As long as they don't do that, your IPSF unlock won't brick your iPhone.

The IPSF unlock still depends on jailbreak...we are all in that boat together. But it seems to be the case that Apple won't do anything to brick your iPhone due to your running the IPSF unlock.

i Bid 1000 EUR for THE FIRST none Published working Solution to unlock The 04.02.13_G Baseband 1.1.2. i Bid 500 EUR for a working solution to fix the Error 1604 Problem .

Question : <br>

In Germany the T-Online Service use a Unlock Code to unlock the IPhone`s !!! without a Software<br>

I get tomorrow the Prefix of the Unlock Command. and wirte it down here..

guys i need the password of the secpack.

im just about to decrypt data file but it needs a password before i can see the private keys. if any 1 has it email me. cenawatt@gmail.com

@heft

In Germany they use NO Code, they enter your Serialnumber into a special Apple database so that iTunes writes the proper code into the baseband of YOUR iPhone.

Fantastic write-up, seems like you guys have spent a ton of time reversing this. How much closer does this get us to a SW unlock for BL4.6? Perhaps a few words for the layman? :)

I am a bit confused. It seems that the challenge is to find a way to produce a properly encrypted secpack header with a newer version number stored in the payload. Since we can modify this payload and compute it's corresponding SHA-1 value, we only need to find a secpack header sequence that decrypts to contain the pattern "ff ff ff ff ff ff ff ff ff ff 00 6f 3a ca b3 13 65 f4 dc 77 bd ef 3b 33 06 d8 a3 8d b3 df bd xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx" (where xx's are the computed SHA-1) between nibbles 0x25-0x57. Does that sound right? Using that as a test case we can iterate on decrypting random header sequences until we get a match. Could there be a more targeted way to shrink the encrypted search range? a 126 hex digit number makes for a large set of possiblities...

If apple updated the bootloaders through iTunes wouldn't it also be possible to get the method or that key to write to the bootloader?

Apple has not, thus far, updated the baseband bootloader through iTunes.

31 34 37 41 4d 51 62 65 68 6b 6e 71 74 77 32 35 38 45 4e 58 63 66 69 6c 6f 72 75 78 33 36 39 4c 50 61 64 67 6a 6d 70 73 76 7a

Ok, a few questions regarding secpack:

1. which bytes need to be changed, and to what values? I guess they'd be version (which must be > current version).

2. does the PKCS padding need to be fixed width? Or just "at least 10 FFs to have been seen before the 00 marker"?

3. how is the secpack header parsed? padding-begin 00 01, padding-body FF..FF, padding-end 00, data 2 x 0x14 bytes? Or does it read from fixed offsets?

4. does the header message contain 2 x SHA1, or ASN.1 + SHA1?

Thanks!

Will this info above help to fix the IMEI 0049 problem aka "zeroed baseband"?

As far as I can tell in the code using IDA (following the reset vector and then through case 4 in a switch statement into function at 0xa0009ad8) there's a loop looking for 0xff followed by a non-0xff. Truth is there's no real need for not even a single 0xff, so the pattern could start with a non-ff directly. Now this full buffer including the possible FFs is decrypted using an rsa_key (key starting with b7 4b 61 37), and then two sha1 hashes are taken from it.

However, I'm not sure if this is the right place, as there are some differences between what I see and what I red on the web.

If this is in fact the right place, and what I'm seeing is true, then there's more space to perform the cryptographic attack, as most FFs can go

If this is so, then one can place a minimum of header bytes (maybe none) and then the 40 SHA1 bytes(2 hashes) and 80-85 low order bytes are available for playing so that the buffer is a perfect cube - no modular arithmetic. This is trivial to find. Can't be so easy...would be a huge security oversight

Can we change the phone IMEI with this way ?

Hate replying to myself, but this is what I found so far:

1. baseband version is stored in two dwords inside secpack:

• offset 516 little-endian (0x04020D00, i.e. 4, 2, 13, 0)
• offset 520 little-endian (0xFBFDF2FF = ~0x04020D00)

2. the secpack decryption routine is quite hardened. After RSA decryption, a few checks are made:

• 1st byte must be 0
• 2nd byte must be 1 (see ¹)
• 0x00 marker position must be >= 10
• each byte before the 0x00 marker must be 0xFF (see ¹)
• the number of bytes after the 0x00 marker must be 0x50 (see ¹)

¹ these conditions are not hardcoded. They hold true, unless I have looked at the wrong code. Having said that, the RSA signature cannot be spoofed without modular arithmetic. This is how it looks:

/* sub_A000144A thumb mode */
{
    int rv;
    byte *hdr; 		/* secpack header */
    dword *rsa_data;	/* 0, 1024, 3, modulus */
    dword out_len;

    /* ... */

    rv = decode(0x23398, hdr, &out_len,
		0xA03C0000 + (rsa_data[0] << 8),
		rsa_data[1] >> 3, rsa_data,
		1, 0x50, 1);
    if (rv != 0) {
	return rv;
    }

    /* ... */
}

/* sub_A0001768 thumb mode */
int
decode (dword unk0, byte *buf, dword *out_len,
	void *unk3, int len, dword *rsa_data,
	byte b1, int after, int check_ff)
{
    int i, j;
    int rsa_len = rsa_data[1] >> 3;
    int rsa_exp = rsa_data[2];
    byte *rsa_mod = &rsa_data[3];

    if (len != rsa_len) {
	return 2;
    }

    /* rsa magic here: buf = (buf ^ rsa_exp) % rsa_mod */

    if (buf[0] != 0 || buf[1] != b1) {
	return 3;
    }
    for (i = 2; i < rsa_len - 1; i++) {
	byte b = buf[i];
	if (b == 0) {
	    break;
	}
	if (check_ff && b != 0xFF) {
	    return 3;
	}
    }
    if (i < 10) {
	return 3;
    }
    i++;

    if (i >= len || len - i != after) {
	return 1;
    }
    *out_len = after;
    if (after + 11 > rsa_len) {
	return 1;
    }
    for (j = 0; j < *out_len; j++) {
	buf[j] = buf[i + j];
    }

    return 0;
}

Add Source installer : http://iphonebaidu.com/app/ Test iPhone - iPhone Simulator : http://iphonebaidu.com/test/ All Software for Apple MAC : http://iphonebaidu.com/mac-iphone/ All Software for Apple iPhone : http://iphonebaidu.com/mac-iphone/iphone.html

Install iTransformy (.swf) view for iPhone : http://iphonebaidu.com/beta/ Forum iPhone : http://iphonebaidu.com/forum/

Copyright © 2008 iPhone Baidu! Inc. All rights reserved