Receiving weird "Best loading address"

[SZ87]

Apologies in advance, as I might have missed something.

I have a firmware binary (.bin format, ARMv6-M, Cortex-M0, LE) with a size of 0x322a0 that, upon running binbloom -f firmware.bin -e, then immediately following with binbloom -f firmware.bin -b, I receive Best loading address: fffdfe6a, which doesn't seem right.

Here's the full output for binbloom -f firmware.bin -b:

Loaded /home/user/firmware.bin, size:205472, bit:fffc0000, 0003ffff, nb_segments:16384, shift:18
End address:000322a0
Determining the endianness
Computing heuristics in big endian order:
Base: 00000000: unique pointers:1129, number of array elements:40654
Base: 00200000: unique pointers:382, number of array elements:224
40878
Computing score in little endian order:
Base: 00000000: unique pointers:1516, number of array elements:208048
Base: 20000000: unique pointers:561, number of array elements:236
208284
This firmware seems to be LITTLE ENDIAN
loaded 493 functions
Best scores for the loading address:
Base address:fffdfe6a, score:9
Base address:ffff6946, score:5

Best loading address: fffdfe6a
Saving function pointers for this base address...
Done.

Problems:

1. Obviously IDA will not allow me to load the firmware at that address as that's much larger than the size of the firmware. What happened? Fixed. Seemed to be running the tag_code() script incorrectly somehow.
2. When following your video here, I don't get the same output. For example, @44:20, notice the line Scanning with stride n. I don't have that. Would that be due to differences in architectures?

I've read over the readme a fair amount of times, but I'm not sure what I'm doing wrong.

Thanks for the assistance!

[virtualabs]

Hello @SZ87,

The code causing the text Scanning with stride n to be displayed has been commented out in the actual version of binbloom, so the fact you don't see it in the ouput is perfectly normal. However, the loading address found by binbloom seems weird, I have to admit. Binbloom is an automated tool that tries to find the correct loading address but it may get lost sometimes, depending on the firmware file. It is difficult to guess the cause of this output without having the firmware, but here are some possible reasons:

• your firmware may contain a lot of data binbloom interprets as valid pointers
• the provided list of potential functions is not correct (or partly incorrect)