To be slightly pedantic (which may help you in this case), it's not on the internal main USB-disk flash. There's a separate 8MB SPI flash chip, that contains the coreboot bootloader, plus aboot 1 and aboot 2 (fallback), along with some "prefdl" and "fdl" images, which are basically chassis ID data like base MAC serial etc. There's a command in EOS that allows you to drill down on these sections of the SPI flash to only read or write certain bits (it's just a python script that uses flashrom underneath). It's helpful because the script contents show us all the offsets and sizes for different bits of the SPI flash. So anyway, "-numBytes=8388608" is the entirety of the SPI flash chipIt dumps 8MB of data from the beginning of the internal flash to /mnt/flash/image-dump.bin.
Do your switches boot to a point where you would even be able to write a correct flash image back to SPI? If not, you'll have to use a SPI flasher - thankfully (at least on my crow management board in a 7050qx-32s) arista included a SPI programming header for in-place programming, you just need to remove the management board from the switch to use it (otherwise it will try to backfeed the rest of the switch via the 3v line). I was able to use a $7 CH341a programmer off of amazon to read and write to the SPI flash:

I know I've sent at least 15 people firmware for your switch model at their request, later tonight I'll try and go through old PMs and ask a couple of them to run the dump command to get a usable image. If you can include a dump of your (corrupt) SPI flash I could also dig through the arista OS firmware blobs and try to find where they're kept and pull one out. Worst case, they do publish their coreboot and aboot sources, so we could also just build a fresh image