In some cases there is the need to be able to recognize a custom firmware either from the host MCU or by analyzing a firmware image .bin file. This article gives a couple of ideas on how to do that, while the chance is taken to provide some information about an image's CRC checksums.

At boot, the module will always send out an event (dumo_evt_system_boot) carrying the firmware version and build number. This is the principal way to recognize the firmware release and the SDK that was used to generate the firmware running in the module, but it does not tell anything about possible different custom firmwares that were generated with the same SDK.
One possible additional way for your host MCU to retrieve the custom version of a custom firmware of yours currently installed in your module, is to store such version number in the Firmware Revision String characteristic that you would add under the Device Information service.
This is a characteristic defined by the spec (see https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.device_information.xml) and the value stored in such characteristic via the gatt.xml can be read at any time by the host MCU with the BGAPI command dumo_cmd_gatt_server_read_attribute_value(handle,0)
You might enter the new characteristic into your gatt.xml under the <service uuid="180A"> tag as below:

  <characteristic uuid="2A26" id="fw_rev">
    <properties read="true" const="true" />
    <value>my_utf-8_string</value>
  </characteristic>

In the BGAPI command above you will then use the characteristic's handle number (not the UUID / handle number is revealed in the file called "constants" being generated by the bgbuild.exe according to the id="..." inside the <characteristic> tag) to retrieve the firmware custom version number which was in fact hardcoded into the firmware via the gatt.xml and its Firmware Revision String characteristic at the time the firmware was built.

As for recognizing that a particular .bin image file corresponds to a custom firmware of yours, you can consider the last bytes of the image: they contain the CRC checksums for the image and are unique for every different firmware, so you could have a table matching one (or more) of the CRC checksums and a firmware revision, and then use the checksum(s) to recognize which custom firmware of yours a certain image file corresponds to.
More in detail, an image file contain three CRC checksums that are verified at boot, one for the firmware, one for hardware configuration, and a third for imported files like SDP records and BGScripts. These are found in the last bytes of an image, starting at address 0x1efd8, and easily recognized in a HEX editor as they start at the border of the 0xFF bytes.
Here is an example of what you will find at the end of the .bin file starting from the address of 0x1efd8:

00 00 00 00 --> Address of fw segment
88 AF 01 00 --> Size of segment
7A BD 78 E8 --> CRC32 of segment
88 AF 01 00 --> Address of hw segment
8A 00 00 00 --> Size of segment
F4 53 64 85 --> CRC32 of segment
14 B0 01 00 --> Address of files segment
C7 01 00 00 --> Size of segment
B1 2A 91 CD --> CRC32 of segment
03 00 00 00 --> 3 segments defined

So, all in all, taking one of the CRC checksums or all the information above should provide you with a good unique identifier revealing which of your custom firmwares an image file corresponds to.
A few additional pieces of information follows. The segment addresses above are relative to the chipset flash memory boundary address of 0x8001000 (0x1000 in the firmware image, where bootloader uses 0x0 to 0xfff) - About the CRC checking of the three checksums, this is performed by the bootloader at boot, and in case of failure the module will automatically enter the BGAPI-based DFU mode.