asciilifeform: not a terribly high quality dangle, took roughly a day to uncover.
asciilifeform: summary : google set up what is likely a deliberate bullshit dangle re the loader src; for reasons that are yet unclear
asciilifeform: !Q later tell phf other interesting observations: 1) loader is not the same as what appears in the src, in either 3.3 or 3.4 fw bin; not only key differs, but eggog strings, and possibly the rsa per se. 2) seems like : nowhere else in the fw is there any other routine which checksums/rsaverifies the cr50 fw , or references the rsa keyz at all other than to print keyid .
asciilifeform: mod6: by all indications you have a box with iron problem. in your place i'd get a fresh set of iron, rather than sinking sweat into interpreting randomly flipped bits as 'bug'
asciilifeform takes break, lets the red hot barrels cool...
asciilifeform: thing has roughly same uptime as its upstream isp.
asciilifeform: mircea_popescu: for comparison : the last time i reset 'zoolag' was to change ps. and the time before that -- to swap in the 'aggression' build
asciilifeform: unless dying hdd, etc, all bets off then.
asciilifeform: fwiw asciilifeform has not suffered this problem in many yrs, for box on uninterruptible power ( and resist the temptation to fiddle! no it ain't 'stuck', it stands up again by itself in coupla hrs ) -- no bitrot
asciilifeform: 'Note: early versions of the SoC would let us build and manually sign our own bootloaders, and the RW images could be self-signed. Production SoCs require officially-signed binary blobs to use for the RO bootloader(s), and the RW images that we build must be manually signed. So even though we generate RO firmware images, they may not be useful.'
asciilifeform: it remains possible that the loader crapola lives in some part of the rom that doesn't get updated and thereby not part of my bin image.
asciilifeform: however, after this, gets moar interesting:
asciilifeform: ( there's a rw and ro piece in each of the 2 redundant sections of the rom , and each contains a copy of rw key -- why? ask'em, not me )
asciilifeform: mircea_popescu: in other twists, not only is neither key in the cr50 fw image i have, but the verification routine does not correspond to the 'open' sores.
asciilifeform: it'd afflict 'soup instead of primes' keys as a class
asciilifeform: ( and whether this actually requires finding ~all~ of the prime factors , or not )
asciilifeform: mircea_popescu: it remains to be determined exactly how to go about signing with a key that doesn't have a mult inv. i suspect that in this puzzler also lies the answer to how the infamous 'mirrored' mods were fired in the field.
asciilifeform: the perplexing thing, supposing there is no eggog in my toolchain, that the mod dun have a multiplicative inverse, it is unclear to me how the fuckers could've signed with it
