First Block - One thing I like about the first block is the instruction ordering. Clearly instructions are ordered for best performance (by a compiler), not easiest reading. Instructions 10, 11, and 12 are a nice example of doing an ADD while the expensive LDR instruction burns through cycles and then storing the instruction on the stack. I should look into the cycle count of LDR.

1) STMDB R4!, {R4, R5, R6, R7, LR} - Instructions 1-3 are a standard function start, save off registers and make room on the stack
2) ADD R7, SP, #0xC
3) SUB SP, SP, #0x10
4) LDR R3, [PC, #0xF0]
5) LDR R2, [PC, #0xF0] - I believe is loading a large number likely a 64 bit number into two registers. The PC is being used to pull a constant that is in the instruction stream and dropping it into R2 and R3. The instruction 5 is getting the constant at the same location as instruction 4 but the PC has incremented by 4 (bytes).
6) STR R3, [SP, #0] - Then line 6 shoves the R3 value onto the stack.
7) LDR R3, [R0, #0x28] - So the value of R0 was passed as a function parameter? That plus 0x28 (Decimal 40) is loaded into R3. Note: R0-R3 are the registers used for parameter passing.
8) MOV R4, R0 - Then R0 is moved to R4. That is a parameter passed to the function and copied to R4. Probably for safe keeping.
9) STR R3, [SP, #4] - So now that new value from 7 is shoved on the stack.
10) LDR R3, [R0, 0x48] - R0 + 0x48 (Decimal 78) address stored into R3
11) ADD R6, R0, #0x28 - Yet again the R0 passed value is being used in conjunction with a constant to put a value in R6.
12) STR R3, [SP, #8] - The value from instruction 10 is stored on the stack.
13) LDR R3, [PC, #0xD4] - Looks like another constant is being grabbed at 0xD4 (Decimal 212) added with the PC and stored in R3
14) MOV R0, #0xD - This is a constant (13 decimal) place in R0 for the upcoming function call.
15) MOV R1, #0 - R1 is being cleared, or at the least a value of 0 for the upcoming function call is being readied.
16) LDR R5, [R3, #0] - This value comes from instruction 13, that constant from instruction 13 is now being used to get another value and store it in R5.
17) LDR R3, [R5, #0] - The value from instruction 16 is now used to fill R3 again.
18) STR R3, [SP, #0xC] - Value from instruction 18 loaded onto stack. Stack is full.
19) MOV R3, R2 - Move R2 value from instruction 5 to R3
20) BL #-0x54ED - Branch and Link (Basically calling a function with the parameters passed in R0-R3. Value is negative because it occurs some where (Decimal 21741 bytes?) earlier. Values available to the called function are from Instructions 14 (R0), 15 (R1), 5 (R2), 17 (R3). R2 and R3 have the same value.
21) LDR R3, [R5, #0] - The value from instruction 16 is used to recreate the value in R3.
22) CMPS R3, #1 - Value of R3 is compared to 1.
23) BEQ #6 - Branch if equal to 1 to 6.

Extracting your original seczone from an iPhone NOR dump

In this post secpack will refer to the key that unlocks the baseband for reprogramming. The secpack should match the firmware currently on the phone. This file is required for ieraser to work.

The seczone is the encrypted data that uniquely identifies your phone. This is the data that iphonesimfree.com (ipsf) replaced with zeroes in order to unlock the phone. This behavior is fine as long as Apple doesn't upgrade their software to check the RSA key, but I prefer the way the iphone-dev team is handling things in a reversible manner, so I want my phone's unique key back.

So to recover the data lost by ipsf you need one of the following:

• The cache file ipsf generated and left on your phone, if you have subsequently restored your phone it is gone
• A dump of the entire nor using a program like speedynor
• The geohot version of ipsf's unlock also left a nice file on your machine with the data needed to undo the process.

Since the only topic that isn't already well documented is the dump of the entire nor, I will cover this method.

Back before the first unlock came out I used speedynor's older brother that took forever to run. I had dumped this file because I was wanting to looking into it at some point but hadn't gotten around to it. Lucky for me, because ipsf claimed a full unlock, but what they did was exploit a flaw in the RSA key system. I first pulled just the seczone from the file using dd. dd if=dump of=seczone.bin skip=0x3FA000 count=0x2000 bs=1 is the relevant section. If you open the seczone.bin file in hexdump -Cv you will notice that up to 0x100 are all FF, and your key starts at 0x400 and goes to 0x480. An ipsf seczone will have zeroes from 0x400 to 0x453. So I took this seczone.bin dump to a Windows PC and ran geomaker.exe against it which generate a secpack.bin_loader file. The geomaker application is unfortunately Windows only, but I managed to run it in wine. Geomaker makes what seems to be a special bootloader that restores the RSA key. I also grabbed a copy of ieraser v2 and the revirgin software. I was using a different version of the firmware than the one mentioned in most other articles, and things weren't going well with iUnlock so I used ieraser first. Then I flashed it to 03.14.08_G which came from the 1.0.2 release of iPhone OS. Once I had 3.14.08_G on the phone I ran iUnlock and everything went perfectly.

Extracting your iPhone bootloader

After jailbreaking your phone, install SSH and copy over speedynor from iPhone elite. It will dump your NOR into a file called geodump. SCP back geodump and run dd if=geodump of=bootloader.bin count=0x20000 bs=1. This should drop the bootloader from your phone to the bootloader.bin file.

Generating an iPhone secpack

A secpack is a little piece of data that is required to update the baseband on your iPhone. The file is 2048k in size and can be generated using the ICE*.{eep,fls} files that come in the Apple iPhone restore download. Once you have this file in place you can use a tool like ieraser to wipe your baseband, and then apply new baseband software using bbupdate. For a full description of what a secpack contains you might appreciate this blog post on secpack authentication.

Download one of the ipsw files from Apple. For example the 1.1.4 firmware from Apple. The ipsw file which is normally downloaded by iTunes before your phone is upgraded or restored is actually just a zip file with a different extension. Some browsers will unzip the file automatically which is sort of annoying.

You will need to visit the iPhone elite downloads section and procure 8900decrypter, and vfdecrypt (optional). These two programs will decrypt the dmg files within the ipsw zip file. 8900decrypter is the only tool necessary for getting to the ICE files. This program will decrypt any 8900 type file encrypted with the key 0x188458A6D15034DFE386F23B61D43774. iPhone elite description of 8900decrypter.

Why you shouldn't buy tickets from Expedia

I love buying tickets online, mainly because exploring fare options is so easy. However, when it comes to actually purchasing the ticket buy directly from the airline, don't buy through an agent like Expedia.

In addition to the fact that buying a ticket from Expedia almost always makes your fare less flexible, or reduces it frequent flyer value with the airline, correcting a mistake with them is incredibly difficult.

Recently I bought a roundtrip ticket from DFW to SFO, and realized I made the mistake of returning on Saturday, not on Sunday. There cute little calendar uses the label S for both Saturday and Sunday. Well upon the realization I had fouled up, Mari called to pay the change fee and I went to class. A few minutes later she called me and said, "Expedia canceled the old ticket for free and issued a correct one since it was within 24 hours." Great I thought since I had just got a speeding ticket for doing 43 in a 30.

So fast-forward a month and Mari is calling in to make sure she was meal listed as Vegetarian, only to find she has no plane ticket. Mister Nice Guy at Expedia had canceled our reservation, but did not make a new reservation. This is when I find out she was told by Mister Nice Guy that the confirmation number was the same as the old one, which in hindsight made zero sense. So here it is two days before the flight with two Magnetic Fields tickets, a non-refundable booking at a boutique hotel, and no plane tickets.

It should be no surprise that Expedia didn't step up and solve the problem, after several levels of management, we got a $200 coupon towards a new $1100 flight. The two original tickets were $450 together. So twice the original airfare when it would have been more cost effective to pay the change fee in the first place.

I usually search for tickets on sites like Expedia, but buy plane tickets through the airlines website because the change restrictions are usually slightly more flexible. The age of the travel agent is over, and I should have remembered, the most you get by buying a ticket through an agent is another level of incompetent customer service.