ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
unixb0y has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
GuzTech has quit [Ping timeout: 240 seconds]
azonenberg_work has quit [Ping timeout: 246 seconds]
azonenberg_work has joined ##openfpga
emeb has quit [Quit: Leaving.]
<azonenberg_work>
qu1j0t3: "I can think of people who are capable of detecting this sort of modchip hack. I cannot think of a reason why a due diligence audit of a server would go down to that level."
<azonenberg_work>
Yes, i agree with that
<azonenberg_work>
i am very curious how these things were allegedly located
<azonenberg_work>
I've done pentests of custom hardware to pretty extreme detail
<azonenberg_work>
but never a commodity pc mobo
<qu1j0t3>
there's really nothing here to grab on to
<azonenberg_work>
I mean, if i saw fishy network activity or something
<azonenberg_work>
that pointed me to dig deeper on a clean OS install
<azonenberg_work>
yes, i would keep digging
<azonenberg_work>
And i would go down to the hardware if i had to
<rqou>
I'm going to be really mad if this turns into badbios v2
<azonenberg_work>
rqou: inb4 dragos was their anonymous source
<azonenberg_work>
:p
<rqou>
azonenberg_work: at some point i want to build some of these implants just for lulz
<azonenberg_work>
I think he isn't though, i reached out to him earlier today to ask if he had a line on where i could get some of this allegedly compromised hardware
<azonenberg_work>
and he did not
<rqou>
I'm sure the media would be thoroughly entertained if we actually implemented this
<azonenberg_work>
rqou: me and a coworker built exactly this implant (SPI MITM -> RCE) to break secure boot on [redacted]
<azonenberg_work>
Which had a TOC/TOU bug
<rqou>
lol
<azonenberg_work>
Read flash, compute sha256, calculate rsa signature on it
<azonenberg_work>
read flash again, copy to ram, execute
<rqou>
lolfail
<azonenberg_work>
we cheaped out and just had two flash chips
<azonenberg_work>
and muxed CS#
<rqou>
heh, classic modchip trick
<azonenberg_work>
But a MITM that actively forwarded the data and hex-edited the firmware on the fly is 100% doable
<jn__>
[other redacted] has a check signature, jump into flash partition thing, i think
<azonenberg_work>
rqou: and if you see my last couple of tweets
<jn__>
(i don't have the relevant hardware and haven't dug into enough code yet)
<azonenberg_work>
i calculated, based on the size of some of the recent WLCSP16 cortex-m0 MCUs
<rqou>
afaik there's no secure boot on the BMC anyways
<azonenberg_work>
you can fit 4 KB of flash plus a bunch of SPI and pattern matching logic into an WLCSP the size of an 0402 passive ,comfortably
<azonenberg_work>
4 KB should be enough to patch unauthenticated remote DMA into an IPMI binary
<azonenberg_work>
It would need to be an asic, i couldnt find a stock chip like that
<azonenberg_work>
But it's technically feasible
<azonenberg_work>
Actually, an ice40 ultralite might work for a PoC
<azonenberg_work>
Not a ton of storage, but it's a pre-existing solution that could mitm flash
<azonenberg_work>
just hex-edit a string or something
<azonenberg_work>
1.4 x 1.4 mm
<azonenberg_work>
WLCSP-16
<rqou>
azonenberg_work: no otr right now
Bike has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
<sorear>
could do a rolling hash comparison, and then redirect to a separate wlcsp flash
<azonenberg_work>
sorear: yeah i was thinking a single chip
<azonenberg_work>
pass through
<azonenberg_work>
then when you see the magic byte sequence / hash / whatever
<azonenberg_work>
replace the following N bytes from internal memory
<azonenberg_work>
then go back to passthroguh
<azonenberg_work>
byte sequence vs hash would probably be more stable to small firmware changes
<sorear>
Does the UL have internal config flash?
<awygle>
you could probably do it with a silicon interposer
<awygle>
or other multi die package technique
<azonenberg_work>
awygle: yes, and an intelligence agency has that kind of budget
<azonenberg_work>
i dont :p
<azonenberg_work>
Which is why the PoC would just be a simple string substitution
<rqou>
azonenberg_work homecmos when? :P
<sorear>
"two stray 0402s" doesn't seem like it would attract that much more attention than "one stray 0402"
<rqou>
yeah, we should just build this PoC
<rqou>
I'm sure journalists will be amused
<awygle>
yes, a UL would be a decent poc
<awygle>
somebody add icestorm support
<awygle>
it's seriously like an 8h project while simultaneously watching (dubbed) lucky star/ohshc
<rqou>
uh
<awygle>
sorear: yes, it does
<awygle>
have nvcm
<TD-Linux>
is there an attiny or something in wlcsp-6
<rqou>
not sure, but there is definitely one in sot23-6
<rqou>
so you can probably special-order it if necessary
<TD-Linux>
why am I asking when I have digikey to answer all my questions
<awygle>
I feel like if you're restricted in memory you can get more done with an fpga than a processor
<awygle>
based on essentially nothing
<TD-Linux>
microcontrollers have embedded flash
<TD-Linux>
which automatically makes them way more suited to this
<rqou>
iirc attiny is kinda a pain to set up for mitm
<rqou>
you can definitely pull it off though
<rqou>
i don't remember if it has a slave-mode SPI controller
<rqou>
some of them are master only and hacked onto a uart
genii has quit [Read error: Connection reset by peer]
<azonenberg_work>
TD-Linux: i tweeted that part a while ago as a plausible example
<azonenberg_work>
not that i would build an implant with it
<azonenberg_work>
but that it was pretty small and had plenty of flash
<azonenberg_work>
thus proved you COULD build an implant asic a quarter of the size with 4KB of flash, two lanes of fast spi, and some sophisticated patter nmatching
<sorear>
how much ram?
<azonenberg_work>
the mcu has 32kb flash and 8kb ram
<azonenberg_work>
Extrapolating down and assuming most of the die is memory and the CPU is pretty small
<azonenberg_work>
all of the stuff you need for a pretty sophisticated implant would fit in a die the size of an 0402 passive
m4ssi has joined ##openfpga
<kc8apf>
BMC flash is 50-60Mhz iirc
<kc8apf>
It will work down to 20 or so unlike Intel chips that have a narrow window
<azonenberg_work>
kc8apf: yeah but you cant force the bmc to downclock right?
<azonenberg_work>
you have to live with whatever SCK it provides
<azonenberg_work>
there's no stretching capability
<azonenberg_work>
So as a MITM you deal with that
<kc8apf>
Keep in mind that both Google's Titan and Microsoft's Project Cerberus are MITM in exactly this way but to enforce integrity
<zkms>
kc8apf: how do you mean, what's MITM'd by what?
<kc8apf>
azonenberg_work: depends on the BMC. Aspeed speed is externally strapped. Nuvoton starts at a slow speed to read a config from flash that sets correct speed
<kc8apf>
zkms: Titan and Cerberus sit between host CPU and BIOS flash and/or BMC and BMC flash
<kc8apf>
Reads are untouched but writes are filtered and signature checked
<azonenberg_work>
kc8apf, zkms: well i personally was talking about a hypothetical backdoor chip
<kc8apf>
Both also are tied into reset and can prevent CPU from booting until flash signature has been verified
<azonenberg_work>
that sat between the BMC and BMC flash
<azonenberg_work>
and tampered with the IPMI firmware on the fly
<zkms>
kc8apf: ahh ok.
<kc8apf>
azonenberg_work: right. Titan and Cerberus are real examples of MITM for a different purpose
<kc8apf>
They demonstrate it is possible to MITM reads at normal BIOS bus speeds with careful coding on custom micros.
<azonenberg_work>
yeah, that much i knew already
<azonenberg_work>
i assumed an implant would be an asic just to cut die area and make it more concealable
<azonenberg_work>
i mean there might be an arm core
<azonenberg_work>
But it would be a custom die without extra bond pads bulking it up
<kc8apf>
I'd be surprised to see it at the "tip of pencil" size
<azonenberg_work>
My math says it can be done
<azonenberg_work>
2x3 ball WLCSP, 0.35mm or so
<azonenberg_work>
or equivalent
<azonenberg_work>
What threw me off in this case was that it looked like some kind of ceramic filter
<azonenberg_work>
Putting an IC inside a ceramic package without visible seams would be hard (unless it isnt actually ceramic)
GuzTech has joined ##openfpga
<azonenberg_work>
as sintering the ceramic normally requires high temperatures that the die wouldnt survive
<kc8apf>
Ugh. I screwed up this FTDI design. I followed the bus-powered reference design but I have self-powered txd/rxd.
<kc8apf>
So when the cable is unplugged from USB, it draws from the txd/rxd and they hold at odd levels
<kc8apf>
I'm quite certain the photos are of a random part
<azonenberg_work>
You dont think they have anything to do with the actual implant?
<azonenberg_work>
(if there even is one)
<whitequark>
azonenberg_work: marcan had some guesses on twitter
<kc8apf>
The server boards might be
<azonenberg_work>
oh? didnt see that thread
<kc8apf>
qrs found a clear shot of the area on the board where the implant was claimed to be found
<whitequark>
azonenberg_work: apparently the real SM boards have some kinda magnetic soldered on top of a SO-8
<whitequark>
which is... lolwhat?
<whitequark>
i see how that would be *ideal* for an implant
<kc8apf>
It was on an alternate footprint for one of the flash parts
<marcan>
my current working theory is they got told they "looked like a signal conditioning coupler" and googled that and stumbled upon ceramic RF couplers
<marcan>
and made up all the photos and details around that
<marcan>
but *this* is also something that fits that description, and *actually* can be found on server motherboards, and it would be trivial to make an SO-8 masquerade as it: https://twitter.com/marcan42/status/1047938864579469312
<kc8apf>
A bit hard to tell if it was BMC or host flash though.
<marcan>
kc8apf: BMC
<marcan>
I did the research on that
<marcan>
the big chip is always BMC on supermicro mobos, they always have that pattern but on some boards they're on opposite sides
<marcan>
this makes sense, because the BMC needs a lot more flash
<kc8apf>
Right. It was a 256Mb part but that board is spec'd for 128Mb host flash
<marcan>
yup
<azonenberg_work>
side note
<kc8apf>
Just some of the traces went off oddly
<azonenberg_work>
If the BMC flash is physically removed
<azonenberg_work>
What happens?
<marcan>
depends on the design
<kc8apf>
Not much
<azonenberg_work>
does the board still boot and post and you just lose IPMI?
<azonenberg_work>
or is it bricked
<marcan>
some systems pass through the BIOS via the BMC
<marcan>
those will definitely be fucked
<marcan>
some don't, and then I guess it depends on how coupled the BMC is with the boot process
<marcan>
I know for a fact (some) Dell servers will reboot, but hang, if the BMC is wedged
<azonenberg_work>
case in point: i have a supermicro box that i don't use IPMI on
<azonenberg_work>
And it has a socketed soic flash next to an aspeed bmc
<marcan>
SOIC8 or SOIC16?
<azonenberg_work>
16 iirc
<marcan>
sounds like BMC flash, try it and tell us? :)
<kc8apf>
Intel reference designs use an external mux for host flash arbitration and power/reset signals get put through a clever loopback GPIO bank on the BMC
<azonenberg_work>
well there are two socketed flashes
<azonenberg_work>
one near the cpu area that looks like a bios
<marcan>
yeah
<azonenberg_work>
this one looks ike its for the bmc
<marcan>
it seems supermicro boards sometimes have sockets and sometimes don't
<azonenberg_work>
Given the massive distance from bmc to bios flash
<kc8apf>
Quanta follows Intel designs closely. Those will boot just fine with a bricked BMC
<azonenberg_work>
i conjecture bios doesnt go throguh it
<marcan>
yup
<azonenberg_work>
the system is in a box right now during my move
<azonenberg_work>
But even if this whole thing turns out to be nothing
<azonenberg_work>
I will probably try pulling the bmc flash since ipmi is just another bit of attack surface
<marcan>
yeah, if you don't use the BMC and there is no impact, no reason to have that thing alive
<azonenberg_work>
if it boots i'll leave it off
<azonenberg_work>
i forget server mobos have all that stuff in them :p
<kc8apf>
That looks like a classic Intel reference design
<marcan>
I'm glad they do, it means I can server-admin a LAN party from halfway across the world via a 3G VPN :P
<azonenberg_work>
marcan: lol
<azonenberg_work>
meanwhile i am planning to, for unrelated reasons
<kc8apf>
There's probably a cpld somewhere that has the mux in it
<marcan>
except when a server randomly dies
<marcan>
as it did this time >_>
<azonenberg_work>
there is a lattice cpld
<marcan>
refuses to even start to POST
<kc8apf>
That's the one
<azonenberg_work>
i think a machxo?
<kc8apf>
Intel loves that
<marcan>
speaking of server admin, just for the record, you can fully license Avocent/HP KVM network switches for KVM-over-IP with.... developer tools.
<kc8apf>
It has the BIOS SPI mux and some glue logic around power up signals
<azonenberg_work>
marcan: anyway i am planning to lock down my new lab to the point that the internal R&D network has no internet access whatsoever, except possibly ssh to github or a few other whitelisted locations
<marcan>
let's just say they have a "touch a file to fully license" backdoor, and an incredibly insecure PHP interface with an obvious endpoint that has a path traversal vuln
<azonenberg_work>
lolol
<azonenberg_work>
i already had it set up so that email, irc, general browsing, online banking, and social networking lived in separate VMs on another box
<kc8apf>
So, yes. It should boot without the BMC. It will probably drive the fans at full speed though
<azonenberg_work>
so all i have to do is add a firewall rule to block all outbound traffic from the R&D vlan except TCP 5900 to the DMZ
<kc8apf>
Probably could get OpenBMC up on it pretty quickly though
<azonenberg_work>
kc8apf: i dont want openbmc, the thought was that if there is such an implant on the thing
<azonenberg_work>
if it has no firmware to patch
<azonenberg_work>
the implant probably is neutered
<azonenberg_work>
i doubt it has enough memory to duplicate the whole ipmi stack
<azonenberg_work>
it just hot-patches a little bit
<kc8apf>
OpenBMC without a gpio map can still run the fans
<azonenberg_work>
So if the BMC is stuck in reset, any screwing with the spi bus wont hurt me
<kc8apf>
Openbmc and AMI MegaRAC are worlds apart
<azonenberg_work>
i guess it probably wont be binary patchable at that point, but still
<marcan>
you could just write protect the flash
<marcan>
at least then there's no persistence
<kc8apf>
Hot patching ipmi is complicated in both cases
<azonenberg_work>
marcan: i dont think it writes to flash
<marcan>
oh you mean if there's a chinese style mitm implant
<marcan>
sure
<azonenberg_work>
this is likely just a "pass through all reads except 0xfoo - 0xbar"
<kc8apf>
Meh. Just use the OpenBMC kernel and use your BMC as an extra server
<azonenberg_work>
exactly
<marcan>
but I highly doubt those would survive a complete swap to openbmc anyway
<marcan>
kc8apf: :D
<azonenberg_work>
yeah but holding the bmc in reset is easy, safe, and effective :p
<marcan>
if you're okay with jet engine fans :P
<azonenberg_work>
i dont actually know what the state of the fans on that box is
<azonenberg_work>
how loud, how many, etc
<azonenberg_work>
the UPS drowned them out most of the time
<marcan>
if it's anything like all the servers I've used, it's a fucking jet engine by default until the BMC figures out the sensors and fans work and it can go into sane mode
<azonenberg_work>
with its beefy fans (online double conversion fairly well loaded)
<marcan>
and then how loud sane mode is... varies widely between brands
<azonenberg_work>
This is a workstation
<azonenberg_work>
so a big tower case
<marcan>
but the bootup state is universally fucking loud
<marcan>
that might be slightly different then
<azonenberg_work>
i do know that i had one 4U system years ago that i ran for my professor
<azonenberg_work>
i swear the reason it was so slow to POST is that it was radioing Albany Tower for takeoff clearance
<kc8apf>
Just don't run the host CPUs with a BMC firmware that doesn't set the PROCHOT GPIO to a known state
<marcan>
is that all there is to it?
<azonenberg_work>
i had it running onpen on my desk to test
<marcan>
what actually does fan mgmt?
<kc8apf>
BMC
<azonenberg_work>
It blew papers off a desk on the other side of the room
<marcan>
so then without any BMC code they'd default to full, right?
<marcan>
btw: my Threadripper motherboard has an inline switch for PROCHOT :D
<marcan>
MOAR OVERCLOCKING
<kc8apf>
Only if external hardware is there to drive them fill when the pwm is missing
<kc8apf>
PROCHOT is a different story. It's just a GPIO that the BMC drives. If left floating, odd things happen
<marcan>
is that the throttling thing?
<kc8apf>
Yup
<marcan>
is it an open-drain bus?
<marcan>
I seem to recall it being an I/O or something
<marcan>
yeah some random intel doc says it's bi-directional
<kc8apf>
Intel has PECI to ask about temps and power
<marcan>
yup
<kc8apf>
AMD added a similar thing on threadripper
<kc8apf>
Previously AMD just have you a diode
<kc8apf>
Anyway, all temp sensors go to the BMC over i2c. BMC has dedicated fan tach+pwm peripheral to manage 12 or so fans
<kc8apf>
Mainline kernel has drivers my team wrote for that and other wonky BMC peripherals
<marcan>
neat
<kc8apf>
Time for bed
<TD-Linux>
I'm still trying to figure out cool things to do with my server that has openbmc
<TD-Linux>
marcan, lol is that what that is? my asrock threadripper board has a switch on top that was apparently overclocking related
<marcan>
yeah, lol
<TD-Linux>
the threadripper is the first time I've built a desktop since 2005 and a lot of stuff is different
<TD-Linux>
it also seems to turn on/off/on in first start when standby power is removed. not sure what's up there
<Prf_Jakob>
TD-Linux: My Intel workstation does the same, seems to be something workstation MBs do.
<keesj>
we talked about this before. why would I source or drain my leds from the FPGA?
<whitequark>
keesj: context?
iximeow has quit [Quit: Lost terminal]
<TD-Linux>
usually cmos drivers can sink more current than they can source
<keesj>
well I am still working on my 20 leds project driven by an fpga. the current of the leds will be 2mA and the buffers of the choosen FPGA can handle 8mA. I am wondering if I should let the FPGA drive the leds (e.g. put the anode on the FPGA or use the FPGA to sink the current)
<whitequark>
sure, that's fine
<keesj>
I think.. I need some context now. what is fine? TD-Linux appears to say it would be "more better" to sink
<whitequark>
in your case it makes no difference
<TD-Linux>
^
<whitequark>
TD-Linux: btw I haven't seen asymmetrical CMOS drivers in a while, i think people just make one FET larger now?
<whitequark>
not according to datasheets anyway
<TD-Linux>
whitequark, yeah I guess that would make for high speed data lines
iximeow has joined ##openfpga
<keesj>
ok I will pick one
<TD-Linux>
now that you mention it, the last time I remember this on a datasheet is ye olde PICs
<TD-Linux>
*asymmetrical max currents
<whitequark>
TD-Linux: i remember that standard cells all now use asymmetrical FETs from talking to azonenberg i think?
<whitequark>
and i've looked at currents too
<whitequark>
so that's a logical conclusion
<TD-Linux>
it makes sense from an engineering point of view, if you're limited by slew rate you'd want them to be equal
<TD-Linux>
and likewise if you are using a slower slew rate for EMI you still want them to be equal
<whitequark>
yep
<TD-Linux>
box of glasgow parts is here
<TD-Linux>
think I'm going to print out the bom on paper and tape parts to that to mail them out
<whitequark>
sweet
<zkms>
nice
<whitequark>
TD-Linux: how many people did eventually want one
indy has quit [Read error: Connection reset by peer]
<TD-Linux>
4. which is great because I ordered 5
<whitequark>
right, i guess not that many people want to assemble smt
<TD-Linux>
probably a lot more would like preassembled ones, but I wasn't willing to do that many
<whitequark>
understandable, i think it's a pain in the ass too
<TD-Linux>
maybe when I finally put together a reflow oven
<whitequark>
just... need to iterate to revC
indy_ has joined ##openfpga
ondrej3 has left ##openfpga ["Leaving"]
<TD-Linux>
if you want to shill revc a bit harder, including it in pictures when you re stuff would help :)
<Ultrasauce>
ya i'm down for an assembled one when one of you does a run
<Ultrasauce>
unassembled is a bit too much of a ~project~ rn
<zkms>
how do i assemble one of those
<TD-Linux>
I'll livestream assembling mine on tuesday when the pcbs finally arrive
<keesj>
all sounds cool
<TD-Linux>
I don't think it'll be too hard though. the passives are 0603 with the fat kicad pads
<whitequark>
TD-Linux: revC doesn't exixst yet
<whitequark>
TD-Linux: yeah i specifically chose the hand soldering footprints
<TD-Linux>
whitequark, yeah I know
<TD-Linux>
yeah. they are excessive for 0805 but nice for 0603
<whitequark>
awygle: can we add pullups on every pin for revC?
<whitequark>
maybe 10k...
<whitequark>
just so you can plug in i2c and have it "just work". not even very fast, just some degree of work
<whitequark>
awygle: seems like it'd need a FET and a resistor, because of Vio
<whitequark>
pulldowns would be easier but there are tons of interfaces with open-drain pins
<whitequark>
and i don't recall any i wanted with open-source
<whitequark>
... open-source lol
<TD-Linux>
it feels like there should be level translators with that built in
<whitequark>
hell no
<whitequark>
level translator landscape is kind of desolate
<whitequark>
we have exactly one we can use on revC
<whitequark>
in the entire semiconductor industry
<TD-Linux>
rip
<TD-Linux>
btw I didn't put any delays on my 74lvc245 direction pins and it seems to work "fine"
<TD-Linux>
should probably scope the power though at some point
<whitequark>
oh sure, transients like that wouldn't be easily visible
* TD-Linux
is maybe a bit cautious from working on 20kw motor drives where those were... quite easily visible (and audible)
<Ultrasauce>
what's a little crowbar among friends
<s_frit_>
TD-Linux: what is this board you are making?
<TD-Linux>
next project after this might actually be a motor controller
<TD-Linux>
got a torque transducer, motors, vescs, and some v-rail is on the way. ever wonder if ultra cheap hobbyking rc motors meet their specs? now I'll know
<s_frit_>
In what world are these C-Bus cards used? Is there another name for the form factor? i'm having trouble googling
<prpplague>
usually you can add a note in the fab drawing as to where they can/can't put fab numbers on the silkscreen
<prpplague>
most of the time it isn't really an issue, but certainly putting it in a serial number box is annoying
<awygle>
TD-Linux: who'd you use for the fab? i feel like you told me this once and i forgot
<Zorix>
apparently if you use jlc if you put a text saying jlcjlcjlc somewhere on the board they will use that
<awygle>
that's cool. if it's per-board and not per-panel i'd happily let them serialize my boards for me.
<whitequark>
TD-Linux: ok so if you want to assign serials without assembling the board
<whitequark>
you can do `glasgow factory --help`
<whitequark>
that just generates a new serial as text
<whitequark>
when it's assembled you give it as --serial=
<whitequark>
awygle: so i had an evil idea
<awygle>
whitequark: oh goody
<TD-Linux>
awygle, pcbway. it's only the 2nd time I've used them, and 1st for 4 layer
<whitequark>
i should put a ECC secure element on the board, and state in the repo that only support requests signed with the board serial number with the secure element certificate get free support
<prpplague>
TD-Linux: is that your twitter account?
<TD-Linux>
yes
<whitequark>
if you made a board yourself but want support from me, you can get a support key or something
<TD-Linux>
you're making a critical mistake here
<prpplague>
TD-Linux: yea, if you put in the comments section when you order at pcbway, you can tell them where they can/can't put the manufacturing fab number
<TD-Linux>
and that's offering support
<whitequark>
well
<whitequark>
depnds on the cost?
<prpplague>
TD-Linux: what's the system you are doing the c-bus joystick for?
<TD-Linux>
pc-98
* prpplague
is not familiar with that
* prpplague
seachers
<awygle>
whitequark: i am not opposed to this in theory but have some practical concerns. in particular, which ecc secure element, and is there documentation for it
<gruetzkopf>
for me they've always worked out good positions on their own
<gruetzkopf>
like under big DIN connectors
<whitequark>
awygle: yes
<whitequark>
atmel makes ATECC which is about $1
<whitequark>
and it is fully documented
<rqou>
why bother with all this?
<awygle>
oh, cool
<prpplague>
TD-Linux: nec pc-98?
<whitequark>
rqou: don't wanna do free support
<awygle>
(microchip nee atmel)
<TD-Linux>
prpplague, correct
<rqou>
just don't do support?
<prpplague>
TD-Linux: ahh dandy
<whitequark>
if you got a board from me, you automatically "support further development", which is proven by the ECC chip
<rqou>
hmm i guess
<whitequark>
if I decide not to bother, idk, can just not populate it? another piece of junk on I2C
<TD-Linux>
prpplague, probably best known for the first 5 touhou games
<whitequark>
big deal
<rqou>
oh it's i2c
<whitequark>
sure
<rqou>
not serial smartcard
<whitequark>
it's real easy to use
<whitequark>
lol no
<whitequark>
i think i can make it work in a day or two tops
<awygle>
same difference really
<rqou>
yeah whatever then
<awygle>
whitequark: are you sure this is documented? i don't see like, a command set
<gruetzkopf>
throw on a SIM800E and M2M sim :P
<rqou>
inb4 china totally knows how to clone atecc chips
<TD-Linux>
as cool as the ecc chip idea is, I still think signed serial plus online "scratch off" is more practical if you want to achieve that
<rqou>
gruetzkopf no
<gruetzkopf>
still need to play with the reclaimed sim800 we have around
<whitequark>
TD-Linux: i don't want to run any secure infra
<whitequark>
i want atmel to do that for me and i want to not have a website
<whitequark>
p sure this is worth $1 per board
<whitequark>
further, if anyone *else* wants to do the same, they don't need like, another website
* whitequark
shrugs
<prpplague>
TD-Linux: pcbway is my "go-to" place for non-mission-critical prototypes
<TD-Linux>
I have friends that have had good luck with really weird pcbs from them.