[Galaxy Tab  Android Development] jiminitaur:
So I was reading that post about the guy who will fix bricked taps via JTAG, and thinking about how some it's necessary when the bootloader binaries don't flash properly.

This seemed to suggest to me that the download mode code is stored in memory, making it's method of interfacing with the memory controller and USB port subject to analysis through ARM disassembly.

I postulated that it would not only be academically entertaining to take a peek at such technomagic, but that it might be possible to produce a template bootloader that could serve as a basis for custom bootloaders across all devices, similar to the role CWM fills in recovery, and CM fills for the Android OS.

I reckoned a custom bootloader would not only complete the holy trinity of device operation, it would solve woes across all androids by enabling a common flashing protocol (no more ODIN, Heimdall, QPST, etc), and allowing focus on replacing locked bootloaders instead of exploiting them.

Of course, I wouldn't be able to verify my hypothesis without getting my hands dirty, so I whipped out the ol' IDA Pro and popped open the EA24 boot.bin and pressed 'c'.

God bless IDA Pro. I had beautiful ARM assembly just waiting to be learned (I'd previously only worked with Intel 8050 & PIC), but very quickly I realized that I wasn't going to get far in my analysis without information beyond the ARM instruction set reference.

Here's why:

Reason 1:

The registers are preloaded with data before the bootloader executes.

ROM:00000000	ANDEQ R0, R0, R0,LSL#16
ROM:00000004	ANDLE R0, R2, R0,LSR#11
ROM:00000008	ANDEQ R5, R2, R5,ASR LR
ROM:0000000C	ANDEQ R0, R0, R0,ROR#4
ROM:00000010	B	loc_30

Not only are the initial instructions skipped if the status flags are wrong, but registers 0, 2 & 5 are being compared and modified without the bootloader loading data into them. I initially suspected obfuscation, but the loader is tiny (only 1.5k of data is non-null) and the flow of code is pretty straightforward. It boots, checks some registers, and possibly takes action before waiting in a loop, (I assume in anticipation of a watchdog/shutdown interrupt firing).

So problem 1 is that I don't know how the registers look or what affects them before the bootloader is executed.

Reason 2:

The memory addressing seems to reference numbers that can't be direct memory addresses. Problem 2 is that without understanding how those addresses are interpreted, I can't understand the operation of the loader.

ROM:00000030	LDR R0, =0xD00374C0
ROM:00000034	LDR R1, [R0]
ROM:00000038	LDR R2, =0xE010A000
ROM:0000003C	LDR R3, [R2]
ROM:00000040	LDR R2, =0xE010C034
ROM:00000044	LDR R4, [R2]
ROM:00000048	TST R3, #0x80000
ROM:0000004C	MOVNE PC, R1
ROM:00000050	TST R3, #0x40000
ROM:00000054	BEQ loc_60
ROM:00000058	TST R4, #2
ROM:0000005C	MOVNE PC, R1

So what's happening here (correct me if I'm wrong):

R1 = Memory Value [0xD00374C0] //Decimal Addr: 3,489,887,424
R3 = Memory Value [0xE010A000] //Decimal Addr: 3,759,185,920
R4 = Memory Value [0xE010C034] //Decimal Addr: 3,759,194,164

Followed by some potential jumps.

The thing is, a Sprint tab, for which this bootloader is designed, only has 2GB of internal memory, so all three address are completely out of range. This makes sense considering that ARM devices might have more than 4GB of memory. Some sort of register based memory context switching has to be in place.

Googling ARM memory mapping brings up info about mapping coprocessor registers and IO into the address space. The custom 8085 I previously worked with did something similar with its touchscreen sensors, so I'm not surprised.

With that in mind, the code would make sense if it is checking the external buttons before deciding whether to jump to the value in R1 (which has to be a real memory location to be put in PC). The tests are performed on the value in R3, so that could be the register that stores hardware button states, but R4 is also tested, so it could be only one or two of the buttons are in R3, or its some other state entirely (perhaps related to the mysterious coma semi-brick).

Regardless, it would be a fools errand to keep crawling through the assembly without better reference material on the initial state of the registers and how the memory is laid out. I was hoping that someone could can locate reference material or offer their insight, as it's been a difficult search on my own.