[Verizon Samsung Galaxy S III] Ralekdev:
I think I'm about 2 weeks late with this, but like Adam I've also been dealing with the hassles moving.

Here's some info that will get you started looking at the bootloader files in IDA

Each of the bootloader files (sbl1, sbl2, sbl3, tz, rpm, aboot) have a 40 byte header that has info we'll need later

struct sbl_header {
int load_index;
int flash_partition_version;	// 3 = nand
int image_source_pointer;	// This + 40 is the start of the code in the file
int image_dest_pointer;	// Where it's loaded in memory
int image_size; // code_size + signature_size + cert_chain_size
int code_size;	// Only what's loaded to memory
int signature_addr;
int signature_size;
int cert_chain_addr;	// Max of 3 certs?
int cert_chain_size;
}

This is located at the very beginning of the file for sbl2, sbl3, aboot, tz, and rpm, and at 0x280C in the sbl1.

The signature and cert_chain aren't loaded into memory, but they're checked by the previous loader.

For reference, the load order of these bootchain files is:

sbl1
sbl2
tz
rpm
sbl3
appsbl (aboot)

This following was written based on IDA 6.3, but it should be almost exactly the same if you're using the 6.1 leak

First you open the file in IDA

In the "Load a new file" dialog, it'll just show up as "Binary file".

Change the processor type to "ARM processors: ARM" and hit the Set button.

Hit "Processor options", then "Edit ARM architecture options", and change the radiobutton from ARMv6 to Any. Failing to do this will prevent IDA from disassembling some instructions.

Hit Ok, Ok again, and Ok a third time to close the "Load a new file" dialog.

Now you'll be presented with dialog that allows you to customize the loading of the file.

ROM start address: put the value found in the sbl_header.image_dest_pointer (for example, aboot.img is 0x88E00000).

Rom size: put the value from sbl_header.code_size

Loading address: put the image_dest_pointer value

File offset: put 40 (0x2850 for sbl1) since we want to start after the sbl_header structure, and then hit Ok

You may want to add a ram section too, starting at image_dest_pointer+code_size and let it be 0x20000 or so bytes

You may get a popup about ARM/THUMB instruction modes, but generally its detection is good enough that you'll never need to manually adjust the T segment register.

It'll then warn you that it doesn't know where to start analysis, but we do so hit Ok.

Put the cursor at the very first byte (Should be right under where it says CODE32), and hit C to analyze that as code. That's the entry point for the binary

From there you can follow the jumps the program makes looking at the B/BX/BL/BLX instructions, and you can hit C anywhere you think there might be code for it to analyze that area.

If you don't know ARM that well, I'd suggest hitting Options -> General, and tick the "Auto comments" box. That will put a comment out to the side of each instruction explaining what it's doing

Let me know if you have any other questions

Now I've got a few questions

Is there a wiki anywhere I could throw info on? Seems like a waste if I don't share some of the things I find, but they aren't always related to the bootloader so I didn't feel like they were appropriate for this thread.

Is there a more recent Odin3 leak than 3.07? The reason I ask is that the odin handler in aboot seems to be able to handle more than what the 3.07 software can do