asciilifeform: mircea_popescu: the 2nd key ( http://phuctor.nosuchlabs.com/gpgkey/620344B54A5B77C0D59A9A430097097B0A13758B9902F0593BBF0C7929F4F857 ) stood. i therefore suspect that i did not make any mistake in conversion.

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: ( and whether this actually requires finding ~all~ of the prime factors , or not )

asciilifeform: aha

asciilifeform: it'd afflict 'soup instead of primes' keys as a class

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: ( mega-surprise )

asciilifeform: BingoBoingo: details will take a while to pry out.

asciilifeform: lolwaat

asciilifeform: so, meanwhile : finds : key id's seen in http://www.loper-os.org/pub/c101pa/c101pa_unlock_nodice.txt , lead to pay dirt,

asciilifeform: 1) the pubs thrown earlier in phuctor ( seen in e.g. https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_v3.4/chip/g/loader/verify.c#17 ) dun appear anywhere in fw 3.4

asciilifeform: 2) the RW key, corresponding to 'RW keyid: 0xde88588d(prod)' , appears , and is identical to what lives in https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_v3.4/util/signer/cr50_RW-prod.pem.pub

asciilifeform: http://p.bvulpes.com/pastes/t16fl/?raw=true << dump of RW key ☟︎

asciilifeform: this in turn , is found in 4 places in the rom , http://p.bvulpes.com/pastes/dqhNR/?raw=true ( labels mine , offsets preserved )

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: however, after this, gets moar interesting:

asciilifeform: http://p.bvulpes.com/pastes/corod/?raw=true << the RO pubkey. (labels mine, offsets original). does not appear to be posted publicly anywhere. ☟︎

asciilifeform: stored in presumably same bass-ackwards form as the RW.

asciilifeform: the last bit of wtf, is that there dun appear to be anyffing corresponding to the published loader

asciilifeform: in particular, the '0xcafebabe' magicturd in https://github.com/coreboot/chrome-ec/blob/b9f5a3d6baae84950f5ff0c4f7c588e55944818a/chip/g/loader/main.c#L102 , dun appear at all in the bin

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: in other lulz, https://github.com/coreboot/chrome-ec/blob/b9f5a3d6baae84950f5ff0c4f7c588e55944818a/chip/g/config_chip.h#L135 >>

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: for today this'll be all.

asciilifeform: oh , for compleeetness, http://loper-os.org/pub/c101pa/cr50.bin.prod << the 0.3.4 cr50 fw currently installed in my box. ( the offsets above, are valid for it)

asciilifeform: phf: nein, i flashed it in earlier, recall

asciilifeform: overwrote factory 0.3.3

asciilifeform: so as to get a known turd

asciilifeform: https://github.com/coreboot/chrome-ec/blob/48d6891db8b5b2b0825136f6f9013a110b2a98da/util/signer/create_released_image.sh << moar re the layout of the fw. apologies for l0gz clutter.

asciilifeform: phf: https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_v3.4/chip/g/build.mk#10 << see

asciilifeform: ( spoiler : CFLAGS_CPU+=-march=armv7-m -mcpu=cortex-m3 )

asciilifeform: it's an arm7 m3 with a few custom i/o regs and some iron for crypto accel ( strictly hashing & symmetric , all else in soft )

asciilifeform bbl

asciilifeform: http://btcbase.org/log/2018-06-23#1829030 << hey mod6 is this the same box as in the last coupla similar threads, with the questionable hdd ? ☝︎

asciilifeform: http://btcbase.org/log/2018-06-23#1829041 << mircea_popescu has it , index is the only piece that actually bitrots ( bdb was written by the maliciously retarded ) ☝︎

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: unless dying hdd, etc, all bets off then.

asciilifeform: http://btcbase.org/log/2018-06-23#1829051 << lobbes didja determine what proggy (e.g. apache?) it was that actually fell down ? ☝︎☟︎☟︎

asciilifeform: meanwhile, for fyootoor ref, http://btcbase.org/log/2018-06-23#1829003 >>>> http://phuctor.nosuchlabs.com/gpgkey/2F5EC26698365939D499561F385A39A4217604DEB38913D71AFD135B28009DAF ☝︎☟︎

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: thing has roughly same uptime as its upstream isp.

asciilifeform: !Q later tell phf http://btcbase.org/log/2018-06-22#1828933 >> http://btcbase.org/log/2018-06-23#1829007 >> https://github.com/coreboot/chrome-ec/blob/master/chip/g/signed_header.h >>>>> http://www.loper-os.org/pub/c101pa/ro_signature.txt ( not the only 1, but illustrative ) ☝︎☝︎

asciilifeform takes break, lets the red hot barrels cool...

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: !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: summary : google set up what is likely a deliberate bullshit dangle re the loader src; for reasons that are yet unclear

asciilifeform: not a terribly high quality dangle, took roughly a day to uncover.

asciilifeform: never!111

asciilifeform: the only even mild surprise is the sheer pile of echafaudage

asciilifeform: pretty great lolcow, btw, that d00d. spilled what he thought was a carefully incomplete pile of beans to 'get asciilifeform to waste months making debug cable', i suspect, didn't quite expect us to get a working one in 1wk

asciilifeform: since his monumental 'nobody has the keys!' gem, all i saw of him was that 1 time he popped in here and drooled for coupla min.

asciilifeform: btw i did figure out the http://btcbase.org/log/2018-06-22#1828757 matter -- their key format reserves 1st 4bytes for 'keyid' . but the lulzimplementation pictured in the (useless, doesn't seem to occur in the bin) published 'loader', treats the key as starting there . as i currently understand, couldn't actually work as written, barring some mathematical curio ☝︎

asciilifeform: http://btcbase.org/log/2018-06-22#1828901 << this kind of thing was a multi-week headache for asciilifeform the last time he had to actually uncork the launch codes and move coin; and i expect that it will only ever get worse ☝︎

asciilifeform: possibly the 2nd dumbest thing shitoshi did, after the mining algo -- the coin fragging nonsense.

asciilifeform: ben_vulpes: absolutely, this has been a sore spot of asciilifeform's since day1

asciilifeform: http://btcbase.org/log/2016-03-16#1434267 << see also oldthread ☝︎

asciilifeform: lol!

asciilifeform was aiming to nail down from what derives what, rather than flooding phf, lel

asciilifeform: the other interesting bit ( from asciilifeform's disasm of the 3.4 fw) is that there doesn't seem to be any pinning of the keys! ( i.e. i can't currently find any reason why it wouldn't eat a rw-fw update signed with a variant key, so long as said key is stuffed in where expected)

asciilifeform: nao this is imho hard to swallow ('submarine with screen door') and so currently i'm assuming that i simply missed something. will have to test, at any rate.

asciilifeform: ben_vulpes: if changing the semantics, i recommend new names ( new commands )

asciilifeform: eliminate possibility of confusion with old , or reactor meltdown if new trb is plugged into a scriptolade harness meant for old, etc

asciilifeform: e.g. 'sendbtc to=<destaddr> change=<chgaddr> [from=<optionalfromaddr_0,optionalfromaddr_1,...,optionalfromaddr_n>]'

asciilifeform: or some other name, but idea being that it must be 1) impossible to confuse it with old 2) keywords ~named~, no order dependency plox

asciilifeform: srsly we have enuff pistols that fire from 2 ends. time for a normal one.

asciilifeform: ben_vulpes: dun forget fee=<...>

asciilifeform: and not optionally, but errytime.

asciilifeform: upstack : http://btcbase.org/log/2018-06-23#1829075 << for the record , it withstood (not much surprise) phuctoring (incl. fermat etc) ☝︎

asciilifeform: not thick, this is so

asciilifeform: ben_vulpes: funnily enuff, ~this very item~ is how asciilifeform got mired in attempt to bolt a lisp onto trb

asciilifeform: 'this arg parser, with all of the eggog handlings/safeties already weighs 85% of lisp interpreter...'

asciilifeform: writing parsers in overflowsanddanglingpointers-lang is braindamaged.

asciilifeform: ( btw, this does not appear to be in the l0gz as-such, so asciilifeform will note : c was an evil thing from ~birth~. on machines so impoverished that 'c is necessary', oughta be writing in asm; on machines where not necessary -- well, obvious )

asciilifeform: this reminds me, not long ago asciilifeform picked up a little chinese toy, item shaped like tennis raquet but the wires are charged to 4000v and connect to (small) cap; a sort of mechanized fly swatter, they pop, little blue plasma burst, vapour. nominally. so then , having used it, later i see a most peculiar insect, did not immediately realize what it is, never having seen before. looked closely, turns out -- fly head + front legs ☟︎

asciilifeform: , still waking along, mostly torso-less and wingless...

asciilifeform: *walking

asciilifeform: mm pretty satisfying, swinging that thing through cloud of mosquito