To amuse myself this morning (and because I may end up having to write these back out), I read the .cube 32K header that the SOC guys are kinda ‘meh’ on. It contains a good bit of useful information, enough to load & understand the hypercube without the assistance of a .hdr file:
0×0000-0×15: 22 byte (apparently freeform ascii) header (?)
0×0016: 4-byte, samples/column 
0x001c: 4-byte, columns/plane 
0×0022: 4-byte, planes/cube 
0x1F15: Mystery; Similar but distinct per file; length ~ 1524B; Guessing this is the serialized form of a complex (MIDIS perhaps?) internal data structure.
0×2618: 0×00 here apparently means uint16 data, 0×01 means float32 data. I think.
0x38C3: [float 2.8446] repeats 768 times, identical per file (how pointless…)
0×4987: [int 1] [int 2] [int 3] [float 373.96] [float 4.981] [float .00259] These appear twice, defining wavelength data
0×5563: [int 1] [int 2] [int 3] [float 373.96] [float 4.981] [float .00259] They define the 0th through 2nd coefficients of a polynomial (see below)
0×8000: 32K offset, data begins
0x5863FFF: Last byte of file if uint16s.
It looks like the second definition (0×5563) of the wavelengths is the one that actually matters (this appears in a float-point cube written by MIDIS-CalIDS).
Some other junk that has no discernable significance; None of these appear in the MIDIS-CalIDS file:
0x0C7D: write 0x4B (‘K’)
0x54C3: write “None”
0×5513: write “None”
I’m missing (presumably it’s somewhere in the slab at 0x1F15) the BPP, which we (so far) know from first principles, but hardcoding is bad mmkay, and I’d like to be able to tell whatever reads it that this is in fact 16bpp data so I can use the full data size I’d be storing things back as. Why let bits go to waste?
The data slab is in the form of uint16s. Stride of 1 moves down (?) the current column, stride of Ny is next wavelength (ordered shortest to longest), stride of Ny*Nlambda advances row to right (?).
Regarding the chunk at 0x1F15: It’s definitely some sort of serialized structure or encoded metadata (the cube resolution appears at 0x1FE1), but it may have to do with the interface as well (115200 is encoded at 0x20AD – the serial interface’s speed)
More on 0×4987:
The three numbers give the first three coefficients in a polynomial expansion of wavelength incident on position x of the imaging plane (The exact equation is m λ / d = x / sqrt(x2+L2) for positive integer m, wavelength λ, grating spacing d, perpendicular distance from optical axis x and distance along axis L) such that labelling them c0-c2 and labelling the planes by integers n = 0 … 127,
λ(n) = c0 + c1*n + c2*n*(n-1)
This agrees with the .hdr files to the limit of the numbers printed therein.
More on 0×2618:
It appears that this flag may refer to data ordering as well. When it is set to 1, data are stored organized with x varying, then z, then y (while aquisition system cubes are stored with y varying, then z, then x).
Publishing this if, as absolutely nothing else, a reference for my future self.