Ok, I think I have the program figured out. This is bootflag.fir, which is the version that TOGGLES the boot flag to its opposite state, so that you can undo the mod if you want to. Here's what it does (leaving out the delays and most of the LED stuff):
1. It copies 52,224 bytes of code from firmware (ffff25f4 - fffff1f4) into ram (100000 - 10cc00). Not sure why, except maybe it needs to be executed from ram for some reason.
2. It creates two 128-byte buffers in ram - buf1 and buf2.
3. It fills buf1 and buf2 with zeros. (should)
4. It calls a subroutine at 1059b0 (ffff7fa4), feeding that routine the addresses of buf1 and buf2. This is the read_boot_flag routine.
5. It compares the value of the first three quads in buf1 with equivalent values at f8000000, and quits if there's any difference. I assume that's the actual address of the boot flags. So, it looks like the subroutine must copy those values to the pointer it is given (buf1). This then is a test to see if the right subroutine is at ffff7fa4. If it isn't, then presumably buf1 would still be zeros, or something else, but probably not the value of the boot flags at f8000000.
6, It then toggles the second quad of buf1 from 0 to -1, or from -1 to 0. This turns on, or off, the boot flag for CF.
7. It calls a subroutine at 10586c (ffff7e60), feeding it the addresses of buf1 and buf2, which I assume writes the buf1 values into the actual boot flags. We don't know how much more of buf1 and buf2 are involved in either the read or the write beyond the first three values of buf1.
8. Then it tests buf1 against the boot flags again, and if they match it turns on the blue LED and quits. If they don't, it turns on the red LED and quits - but at that point presumably some damage has been done since there's no telling what was at those subroutine addresses.
So it would seem that zeroing out buf1 and buf2 doesn't make any difference if you're dealing with firmware v1.0.3 and everything is where it should be. But it's important as part of the test - to make sure the uninitialized values in buf1 don't just happen to equal the values at f8000000 even if the firmware version or something else is wrong.
I think we need to do the firmware version test, and maybe even the first quad of those subroutines, before calling even the READ routine. Because if it's some other firmware version, you don't know what you're calling - it may or may not be destructive.
I should add that it appears that the scanled.fir program that most are using (and that the wiki specifies) does the first READ test but then ignores the result, except for which LED to turn on, and then proceeds to write the new boot flag even if the test failed. That's very dangerous, and is no doubt what caused the bricked cameras.
So, I found the "1.0.3" string in the 1.0.3 firmware update from Canon. How do we calculate where that's found after flashing the new version to the camera? We would need to know where the flasher code ends and the flashed code begins in the update file, and where the flashed code is flashed to. Do we know that?