Actually what I wanted to reduce is the number of tries required to find the byte swap pattern.
That's an interesting idea, but I don't think it will be practical.

I'm not sure how the camera starts to execute the code in DISKBOOT.bin (is it an unconditional jump or routine call, which should be able to return, right?).
I'm not sure (search for StartDiskboot and you can find the function that does the deed. It's sub_FF82905C in d10, but it goes through a pointer stored in data TCM whose value I don't know), but the diskboot is loaded on top of the OS data, so there won't be a functioning OS if it managed to return. If you could run a 4 byte diskboot it might be OK (since only 4 bytes of OS data would be trashed), but as I mentioned before there appears to be a minimum size for diskboot to run at all. Also the canon code clearly doesn't expect diskboot to return, so there's no reason to expect the OS to work correctly if it did.
I just tried the following diskboot:
.section .entry
LDR R3, =0xC0220130
MOV R2, #0x46
STR R2, [R3]
BX LR
This should turn on the red LED on my D10 and then return to whatever called it.
If the diskboot is padded to 10kb, it does: The camera hangs with the red LED on, requiring the battery be removed to turn it off. This means the code has run, but the return hasn't had the desired effect of continuing to run the OS (possibly because 10k of the OS data was trashed, or possibly because there isn't a valid conditions to return)
With only 1k bytes of padding, it doesn't turn on the LED. The camera is still crashed, since I have to take the battery out to get it to start again, even without the card, but the LED not getting turned on indicates the code didn't run at all.