Very good .
A small word of warning/advice.
The bootsector (which is not anymore a bootsector, as it is multiple sectors) or PBR (Partition Boot Record) or more properly VBR (Volume Boot Record) on a NTFS filesystem is *always* 16 sectors or 8192 bytes.
On a FAT32 filesystem it can be 1 to 3 sectors depending on a number of factors, and - to further complicate the matter - some formatting utilities (including the standard MS ones) make a backup of the (3 in this case) sectors to sectors 6,7,8 and if the filesystem was created under 2K/XP and later, some code will be in the 13th sector (sector 12), and if the FAT32 was made in ReactOS on the 15th sector (sector 14).
Usually (but it depends as said on a number of factors) when the FAT32 filesystem is created a number of sectors greater than 16 are marked as "reserved", and since these sectors (past sector 12 or 13th sector or in the case of ReactOS sector 14 or 15th sector) are blank, the assumption that 16 sectors do represent a restorable boot code is generally speaking "good enough".
Two issues are however possible in theory:
1) the backup of the boot record on sectors 6,7 and 8 is non-present or not updated to the "main,current" boot record
2) the formatting was made very "tight", with "peculiar" tools and non-standard settings and a number smaller than 16 reserved sectors was used, in this case when you image the first 16 sectors the copy may include one or more sectors from the FAT.
Issue #1 is not a real issue, since the backup of the boot record is never used if not in some very rare case of filesystem recovery.
Issue #2 is generally not an issue on "populated by automatic tools" USB sticks, as the FAT present in the very first few sectors is normally never modified (but you never know).
So, for FAT32 to make sure that your copy/image of the boot record is actually "100% restorable" you should check that the field at offset 14 (0x0E), two bytes, is equal to or bigger than 0x0010 (the field is the one corresponding to "reserved sectors".
You can use a hex/disk editor (or grub4dos or any bootsector viewer) to check the file, 99.99% of cases the value will be bigger, I just checked a similar USB stick and the value is in hex view 22 00 that is read as 0x022=34 decimal.
If you want to perform this check and don't know how to do it, post and I'll give you instructions.