The node board hex files can easily be pulled from the game .spk file. Just extract the Linux image from them using the pyhton script from here. In the game directory there are these files for GoT 1.34: coil4node-LPC1112_101-0_19_1.hex
coil4node-LPC1112_201-0_19_1.hex
coil4node-LPC1313-0_19_1.hex
game
image.bin
lcdnode-LPC1113_302-0_19_1.hex
pinnode-LPC1112_101-0_19_1.hex
pinnode-LPC1112_201-0_19_1.hex
pinnode-LPC1313-0_19_1.hex

"game" is the elf executable, that can be dissected using IDA. There is the update routine, the node board list and the firmware suffixes inside. What I have not yet understood is which the files for the same MCU type goes to which boards (xx-LPCyy-101-zz or 201).
And there is the risk that these firmwares might not be the complete content of their flash and there is another bootloader in there which is NOT in the spk.. However node boards dying during updates speaks strongly against that - and also speaks against Stern using NXPs bootloader/protocol.
Regarding the NXP bootloader, has anybody with a broken node board ever tried replacing the MCU and just plugging it back in?

You can also check out some more details on spike from the other scripts in the firmware, notably the /etc/init.d/ directory has game, game_monitor and update files which are just shell scripts for the startup. In there you can also see that the spike node bus is just a plain simple UART...
Note that if "game" isn't there, startup continues to a pretty large "spike menu". I wonder what that is?

Thanks for the info! Yup, then they use a custom update mechanism. Maybe the original NXP bootloader does even listen on the node bus uart, but that does not seem fit to talk to it with the other nodes in between.
However if the programming port is present on the node boards as @russdx said, then you could try flashing the MCU via JLink or some other ARM programmer with one of the hex files from the update archive. Still don't know if 101 or 201 is the right one, but chances are they are for different revisions of the boards. I have not yet disassembled and compared them, but judging from the hex files there are differences, but most of the content is identical. Maybe there is a revision printed on there? Also the filenames indicate that the 4 driver nodes were also made with the LPC1313..

They go to 0x1000, which leaves the first 4kB and the interrupt vectors untouched. The BootROM 0x1fff0000, so I guess there is a Stern 1st stage loader in front of the image that does not get updated.
So unless someone with a spare node board and a JLink or other SWD ARM programmer sees if they can readout this first flash block (read access to flash page 0 or the whole flash can be disabled in the mcu), we'll probably have to wait what the mysterious Stern support pack will bring..

Since it's just for one time use and pretty compact the ribbon connector would not be such a bad choice for a programming header. All it's got to do is provide a way to flash the basic bootloader a few times, either initially (if they dont get the ICs preprogrammed with it) or for in house repairs. The real game firmware can be updated via the node bus anyway.. If Stern takes this service and repairability project seriously they should release this basic bootloader too (and to sw tool to get it to flashing mode) to allow us to do the same.

Depends on how their bootloader works. Normally I would expect it to wait a certain time for a magic command that can send it to flash mode before starting the main firmware. In that case the right cable and software to send that command and the hex file should do. However normally I would expect a bootloader to verify the main flash contents by signature or at least checksum before starting it too...

Yup. I wouldn't be surprised if the two were in fact wired in parallel. The bottom pads for quick programming/testing in the factory, the ribbon connector for later service access.