noobineer has quit [Read error: Connection reset by peer]
RaivisR_ has joined ##openfpga
RaivisR has quit [Ping timeout: 264 seconds]
eduardo_ has joined ##openfpga
eduardo has quit [Ping timeout: 260 seconds]
RaivisR_ is now known as RaivisR
RaivisR_ has joined ##openfpga
pie_ has quit [Ping timeout: 265 seconds]
RaivisR has quit [Ping timeout: 264 seconds]
RaivisR_ is now known as RaivisR
rohitksingh has joined ##openfpga
eduardo_ has quit [Ping timeout: 240 seconds]
eduardo_ has joined ##openfpga
<rqou>
azonenberg wtf you've used an ultramicrotome before? for what?
<azonenberg>
rqou: no but i'
bitd has joined ##openfpga
<azonenberg>
but i'm familiar with some embedding materials for microscopy in general
<azonenberg>
dig experimented with crystalbond a while ago for die lapping
<rqou>
ahh
rohitksingh has quit [Quit: Leaving.]
RaivisR has quit [Quit: Leaving]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
gnufan has quit [Ping timeout: 240 seconds]
gnufan has joined ##openfpga
gnufan has quit [Ping timeout: 268 seconds]
gnufan has joined ##openfpga
pie_ has joined ##openfpga
gnufan has quit [Ping timeout: 264 seconds]
gnufan has joined ##openfpga
gnufan has quit [Ping timeout: 240 seconds]
gnufan has joined ##openfpga
<marcan>
I may have just bought 12 GBAs off of yahoo auctions
<marcan>
I guess there's no escaping the project now :p
<pie_>
wut
<marcan>
and might bid on another set of 15 just for completeness
<marcan>
I want to image the GBA CPU
<pie_>
are you making the 1980s equivalent of skynet
<pie_>
oh
<pie_>
\o/
<marcan>
and hopefully pull a full netlist out of it
<pie_>
inb4 more die revisions than you have gba
<marcan>
nah, it's not *that* many and the 12 GBAs are originals, which should mostly have one of a few?
<marcan>
there are 6 chip revisions as far as I know
<marcan>
and it's definitely not the last one since that one is a different package (BGA)
<marcan>
and there may be fewer dies, with the only differences being package/pinout
gnufan has quit [Ping timeout: 260 seconds]
<marcan>
I think for these units it's going to be one of two revisions
<marcan>
I only really care about one (any single one) a priori, for delayering; it's more important to figure out the remaining common unknowns than individual revision differences
<marcan>
however I plan to do some blackbox testing with an FPGA board and for that I do plan to have a plug-in so I can swap out specific chips and figure out at least what the observable differences are
gnufan has joined ##openfpga
<pie_>
cool
gnufan has quit [Ping timeout: 268 seconds]
gnufan has joined ##openfpga
* whitequark
yawns
<whitequark>
i should really synchronize my sleep cycle with PDT
<whitequark>
rqou: what if there is no Vtg though
<whitequark>
you need to synthesize it
<whitequark>
awygle: lol the sysCLOCK doc
<whitequark>
lattice is pretty inconsistent between all of its appnotes indeed
xdeller has joined ##openfpga
soylentyellow has quit [Ping timeout: 265 seconds]
gnufan has quit [Ping timeout: 240 seconds]
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
[X-Scale] is now known as X-Scale
rohitksingh has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 276 seconds]
Lord_Nightmare has joined ##openfpga
gnufan has joined ##openfpga
kuldeep has quit [Ping timeout: 256 seconds]
kuldeep has joined ##openfpga
<q3k>
hum, anyone did any research on those cheap Air200/RDA8851/OpenLuat modules?
<q3k>
for $4 you get a GPRS modem, a custom 32-bit RISC (as far as I can tell), 8MB of RAM, ...
<q3k>
but the stock firmware just lets you use Lua on them, I'd like a Rust backend or something :)
<marcan>
27 minutes left on this other set of 14 GBAs... and the price is good
<marcan>
whitequark: hedgeberg has pointed out that I should try rosin for decapping and CMP for deprocessing, which sounds like a significantly safer idea than nitric and HF respectively
<marcan>
as in safe enough I can probably cook it up in my kitchen without having to set up a fume hood in the hackerfarm
<whitequark>
rosin for decapping doesn't work lol
<whitequark>
we tried it
<marcan>
oh, hm
<marcan>
where did that come from then?
<whitequark>
I don't know who came up with that idiotic idea, but there's no way it can work, and it doesn't
<whitequark>
I mean why would you expect it to even?!
<whitequark>
it's rosin. epoxy is only degraded by strong oxidizers. rosin isn't a strong oxidizer.
kuldeep has quit [Ping timeout: 240 seconds]
<marcan>
it's on hackaday and it points to a dead wordpress, it must be true!
<whitequark>
also, rosin fumes are quite awful
<whitequark>
you definitely do not want to do it indoors for any prolonged period oftime
<openfpga-github>
Glasgow-JTAG/master 9bda99c Andrew Wygle: Add MSOP-8 footprints to Glasgow repo....
<rqou>
but most of them don't get consistent servicing :P
<whitequark>
they need installation
<whitequark>
they don't really need any kind of servicing that involves a vacuum pump unless you fucked up installation, too
<awygle>
does HK cool one room at a time or try to cool entire buildings?
<rqou>
lol one room at a time
<rqou>
so every apartment building has a bajillion individual aircons
<rqou>
btw whitequark: opinions on oil diffusion pumps?
<whitequark>
rqou: if you ever let air into one you're looking at a week of pain
<rqou>
lol
<awygle>
ah i see. eveeryone i know who's ever interacted with the whole-building HVAC systems has the kind of fatalism you get from software engineers talking about ... say, fixing kicad :p
<rqou>
@nanographs did that recently
<whitequark>
yes
<whitequark>
that's where the "week" figure comes from :P
<rqou>
lolol
<rqou>
awygle: wait what's wrong with whole-building HVAC?
<whitequark>
I don't bother with oil diffusion pumps because turbopumps are cheap, with one exception
<whitequark>
if you're doing some dirty kinda process
<awygle>
rqou: it's impossible to get it right everywhere, especially if you want it to be quiet
<rqou>
hmm
<rqou>
most office buildings seem to work fine?
<awygle>
so you have "this corner of the building is freezing and this corner is boiling and hte conference room sounds like a jet engine"
<awygle>
"and also the unit on the roof freezes every six weeks" (that one might have just been us)
<rqou>
i have never had this problem except in our amazing-quality K12 schools
<q3k>
I've had this at the last office I worked in
<q3k>
from my experience it's especially common with open spaces
<awygle>
^ yes
<whitequark>
somehow MTR manages to cool its massive open spaces pretty uniformly
<whitequark>
but maybe that's MTR is staffed by competent engineers
<rqou>
lol
<whitequark>
that's because*
<q3k>
not to mention that some poor fucker (ie me) had to sit directly under the exhaust of the unit
<awygle>
just one more element of making the open office plan the horrible nightmare it is
<rqou>
but MTR had to be kindly asked by the HK gov to cool their spaces to a reasonable temperature instead of -Infinity degrees
<awygle>
i sit under a vent at work that's not well bolted to whatever it's supposed to be bolted to so there's a ~2Hz oscillation all day every day
<q3k>
awygle: the oscillation might actually be by design
<awygle>
i also sit next to a woman from a dilbert cartoon so, you know.
<awygle>
q3k: it's a metal oscillation, the vent tapping against something, not a "whub whub whub" air pressure oscillation
<q3k>
although 2hz is a lot for those built-in oscillation things
<q3k>
not to mention the hvac units sometimes became extremely loud
<q3k>
at one point in the day
<q3k>
because of some self-cleaning/self-maintenance/whatever procedure
<q3k>
which was programmed to happen at 6p or so
<q3k>
ugh. thank fuck I don't work in that building anymore
<whitequark>
awygle: sounds like you need a bolt cutter and a high-visibility vest
<rqou>
why have i never experienced any of these problems?
<q3k>
(marcan might also have something to say about the 1GC HVAC system :P)
<awygle>
rqou: because you're still in school lol
<rqou>
i've been in companies doing internships
<rqou>
they all seem to have HVAC working fine
<marcan>
ahahahahaha that thing
<rqou>
like i said, IME it's just our amazing (/s) K12 schools that have this problem
<marcan>
one day it started *screaming*
<marcan>
*randomly*
<marcan>
for like 5 minutes at a time
<marcan>
took them a week to figure out wtf the problem was
<whitequark>
so what was it
<rqou>
it doesn't help much that my high school was built as a failed experiment to make an open-plan school, and was then shoddily converted to a traditional design
<marcan>
that wasn't self cleaning
<rqou>
so the HVAC zones are all messed up
<marcan>
that was some valve issue
<marcan>
eventually they actually added thermostats so people could control the damn temperature
<marcan>
before it was centrally controlled, poorly
<q3k>
marcan: not sure how it was during your tenure, but during mine the controls would reset every night, anyway
<marcan>
oh that would happen, yes
<marcan>
but at least there *were* controls
<q3k>
marcan: so first step in the morning was walk up to the damn panel, sigh loudly, adjust temperature, roll eyes, go back to desk
<marcan>
when I started there were none
<rqou>
1GC?
<marcan>
it was complain to facilities if you wanted it changed
<marcan>
yes
<q3k>
rqou: google engineering building in DUB
<rqou>
ah
<whitequark>
lol
<whitequark>
google
<marcan>
also that HVAC system was *grossly* overpowered
<marcan>
I think they budgeted like 500W per person or something
<marcan>
which, just, no.
<rqou>
well, back in the day of power-hungry PCs with CRTs, maybe
<marcan>
so it was the usual "oh it's warm let me turn it down *instafreeze*"
<marcan>
that was a newly remodeled building
<whitequark>
that sounds like the control loop was shit
<rqou>
hey, supposedly "research-grade optimal-ish control" for HVAC is _hard_
<rqou>
(but a "works in reality" controller isn't)
<marcan>
the problem is the more powerful the units the higher the gradients they create, especially if they aren't really fighting against anything
<marcan>
q3k: btw, re: that ctf, did I ever give you my checkpw.sh?
<rqou>
hey q3k any progress on finding the tegra bug?
<rqou>
i'm getting pretty tired of the reswitched secrecy
<marcan>
"the" tegra bug?
<rqou>
but i don't have time to look into this
<marcan>
you think there's just one?
<marcan>
:P
Lord_Nightmare has quit [Excess Flood]
<rqou>
wtf
<rqou>
i don't see any obvious bugs
<q3k>
rqou: slowly reverse engineering
<marcan>
that ROM is swiss cheese
<rqou>
but the code is a huge mess
<marcan>
that bug has been independently found several times already
<rqou>
i know
<rqou>
i just can't find it because i suck
<q3k>
rqou: current state: 'import angr' because I don't trust hex-rays and I'm too lazy to reverse one critical path from arm assembly
Lord_Nightmare has joined ##openfpga
<rqou>
q3k: are you thinking it's a logic bug or a memory safety bug?
<rqou>
(i actually have no idea)
<q3k>
uh
<q3k>
I mean, memory safety bugs are usually due to logic bugs
<rqou>
well sure :P
<q3k>
there's a few things that I see and that I need to investigate, and they're different classes of bugs
<q3k>
for instance, the logic to decide the security level based on fuses/straps is extremely fucking hairy
<marcan>
you already know about the trustzone bug, right?
<rqou>
yeah, i don't care about that bug :P
<marcan>
but it's fun!
<rqou>
bootrom cold boot bugs are where it's at :P
<marcan>
"let's use AES-CBC and pretend a checkword at the end is a MAC!"
<marcan>
Xbox 1 style
<pie_>
whitequark, i see you got a new kawaii twitter pic
<rqou>
q3k: so i'm suspicious of the bct bad block table (because it's the only unsigned piece of data in the bct) but it might be a complete red herring
<marcan>
I love it when companies make the. same. fucking. mistakes. from. a. decade. ago.
<rqou>
i also can't find the code that actually reads it lol
<rqou>
maybe it's unused
<q3k>
rqou: it's not unused
<rqou>
lol
<rqou>
which function reads it? :P
<q3k>
it's complicated
<pie_>
^ thats your hint
<pie_>
now figure out how many meta levels of deduction that gets you
<q3k>
generally that rom tries very hard to read the bct from many spots while supporting fallback to different parts when bad blocks happen or signatures are fucked up
<marcan>
I *could* give a big hint but I won't (also it's not my bug :D)
<rqou>
q3k: i'm also very very suspicious of the function at 107CC0 because serious wtf is that code
<rqou>
but that also might be a red herring because i can't figure out what that function even does
<q3k>
ah yes
<q3k>
my idb calls it 'the_fuck'
* jn__
only has a sifive bootrom dump ;)
<rqou>
also seriously, why do all the "emulate code for the purpose of doing hax" tools _suck_?!
<rqou>
even unicorn engine which is apparently the new hypeness sucks
<q3k>
well, i'm not a fan of unicorn either
<q3k>
mostly due to the api
<rqou>
there's no obvious way to glue a gdb to it
<marcan>
unicorn is kinda fail yeah
<q3k>
but if you use it via idaemu it's okay
<rqou>
yeah, the api is hot garbage
<marcan>
oh *that* is what 107cc0 is
<rqou>
so what i've been wanting to do (except no time, thanks to schoolwork) is set up a daemon on the jetson that lets you r/w memory
<rqou>
and then hook the emulator up to this
<rqou>
apparently scanlime really really likes this technique
<marcan>
I love it when ARM functions get so big the compiler has to insert jumps to put constant pools in the middle
<sorear>
rqou: co-maintaining a qemu port for a while has put "rewrite the damn thing" firmly on my todo list
<marcan>
basically every hax I've done has involved some kind of IO/mem proxy
<marcan>
that's how I did all the register layout RE/experimentation on the wii
<rqou>
it seems like my problem with doing hax is that my tools _suck_
<marcan>
the wiiu HRESET glitch stuff was all a big python script talking over pseudoserial
<marcan>
on ps3 all the hypervisor reversing was from python talking to the ps3 via ethernet
<marcan>
we even ran the secure bootloader in the isolated SPE virtualizing all hardware from python on a computer
<sorear>
rqou: maybe if I can find two or three other people who hate all existing open-source DBT systems we can start discussing architecture
<q3k>
rqou: yes, taking the first step that 'okay, I need to invest time in tooling' is a big one
<marcan>
(because the cell lets you do that)
<marcan>
(yes really)
<marcan>
(you can run secure code and completely control its view of the outside world)
<q3k>
nice
<rqou>
what
<marcan>
yeah
<marcan>
SPE, please enter secure mode and load this sekrit encrypted and signed with per console key binary!
<marcan>
also I control all your DMA TLBs and can suspend execution and do whatever
<marcan>
also the bootloader (which is supposed to run on boot on bare metal) uses the same key as the metaloader (which isn't) so it just works the same
<rqou>
sorear: DBT?
<sorear>
dynamic binary translation
<rqou>
i don't want DBT
<sorear>
do you want a switch-loop emulator?
<marcan>
result: load bootloader, virtualize all I/O hardware, exploit stupid driver bug by presenting unexpected register behavior
<rqou>
i literally just want `while(1) { opcode = xxx; switch (opcode) {}}`
<rqou>
i just want it to not have any major bugs when interpreting things
<rqou>
q3k: i'm also very suspicious of the "failure analysis" fuse but i don't understand the logic fully and definitely don't want to "just" set it
<marcan>
have you found the bug in the FA mode loader yet?
<marcan>
that one is just sad :p
<rqou>
what
<rqou>
there's a FA mode loader?
<q3k>
I haven't even looked at the FA codepaths
<marcan>
that part of the bootrom isn'T even hidden
<rqou>
does the whole chip still work in FA mode?
<q3k>
just noticed that it jumps into it's own special UART loader
<marcan>
you can just read it out of /dev/mem on android
<marcan>
or whatever
Ultrasauce has quit [Ping timeout: 260 seconds]
<marcan>
(first 4K)
<marcan>
(IIRC)
<rqou>
i don't want to set it because i don't know what else can happen to the chip
<awygle>
whitequark: so kicad doesn't really support putting mask on top of the thermal vias for the cypress part
<q3k>
marcan: I mean, as far as I can tell, if you're in FA, it just jumps into a loader where it'll load and run anything unsigned, no?
<marcan>
well, kind of
<whitequark>
awygle: huh. that's... that seems bad
<marcan>
there is one check
<whitequark>
are you sure?
<marcan>
and there is a big fat giant stack smash to bypass it
<whitequark>
what if you put a circle on the mask layer?
<awygle>
whitequark: c4757p confirmed my suspicions
<awygle>
the problem is the mask layer is negative
<whitequark>
"c4757p" ?
<awygle>
a kicad developer active in #kicad
<whitequark>
that is obnoxious
<q3k>
marcan: yeah, the hwinfo check via the bct bbtable, but you can smash it earlier
<whitequark>
so what do we do
<awygle>
i have no idea who they actually are but they seem knowledgable
<awygle>
the problem is that the mask layer is a negative
<awygle>
so you can't add stuff to it
<q3k>
marcan: but blowing the FA fuse seems like cheating :P
<marcan>
q3k: no, in the UART loader, nothing to do with bct
<awygle>
what we'd need to do is turn off mask on the thermal pad
<awygle>
and draw the mask manually
<whitequark>
ah yes
<awygle>
that is also challenging because there's no keepouts in footprints
<awygle>
so you can't say "everywhere but here"
<q3k>
marcan: yeah, but the UART loader loads the first 24 bytes of the BCT, then the badblock table that's supposed to contain hwinfo
<awygle>
so it's gonna end up a big ugly mess
<q3k>
marcan: but the read length for the badblock table / hwinfo check is user-defined
<awygle>
with square or maybe octagonal via caps
<marcan>
the UART loader most certainly does not have anything to do with the BCT unless I completely missed something enormous :P
<rqou>
oh wtf how are you so fast
<rqou>
i still haven't even annotated the "read from uart" function yet
<q3k>
marcan: the address it loads to is the .data spot used for the BCT in other boot modes
<q3k>
marcan: and it kinda loads data there to be enough of a BCT so that later stages can interpret it at least somewhat
<whitequark>
awygle: hm
<whitequark>
idea
<q3k>
marcan: ie
<q3k>
uarta_print("Boot\n\r", 6, &a3);
<q3k>
nvtboot_handoff.version1 = 0x210001;
<q3k>
[...]
<q3k>
nvtboot_handoff.bootmode = 3;
<q3k>
etc...
<q3k>
well, fair enough, that's the handoff block, not the bct
<whitequark>
awygle: you can use an SMD pad that's only present on the mask layer
<q3k>
but earlier uarta_read(&g_bct, 24, &v15);
<whitequark>
awygle: btw don't forget to turn off thermal reliefs for pads
<awygle>
whitequark: yeah, i _can_ do that, but it doesn't solve the problem
<awygle>
because the mask is negative
<awygle>
so i can say "don't put soldermask here" but not "put soldermask here"
<whitequark>
ohhh
<whitequark>
oh screw that
<whitequark>
hm
<marcan>
q3k: I'm pretty sure this part of the code is reusing that RAM for something that has nothing to do with a BCT
<awygle>
whitequark: which pads do we not want thermal relief on?
<whitequark>
awygle: I found a way to do this
RaivisR has joined ##openfpga
<q3k>
marcan: it's both
<marcan>
yes, but it doesn't make any sense as a BCT in this context
<q3k>
marcan: ie, it's populating the nvtboot handoff, making that point to something that smells like a BCT
<whitequark>
awygle: you could make thick overlapping "graphic" circles and then merging them all into one big pad
<whitequark>
using "create pad from graphic shapes"
<q3k>
marcan: it makes to whatever parses it later, I guess
<q3k>
marcan: but w/e
<whitequark>
up to you if you want to do this
<whitequark>
I'm 100% fine with octagonal mask
<rqou>
anyways, i do remember reading back when i first got the jetson (waaay before switch came out)
<rqou>
that there was some references to a failure analysis mode that used the uart to load stuff
<rqou>
and i remember thinking "hmm, does this bypass secure boot?"
<rqou>
and i assumed "nah, it probably has to be correctly signed, right?"
kuldeep has quit [Ping timeout: 263 seconds]
<rqou>
marcan: oh wtf i see the big fat stack overflow now that i actually annotated the read function :P
<rqou>
wtf
<rqou>
that's bullshit
<rqou>
anybody got a spare $300 for me to test this experiment? :P
kuldeep has joined ##openfpga
<marcan>
it's not a stack overflow, it's more of a buffer overflow straight into the stack
<rqou>
yeah
<rqou>
sure
<rqou>
whatever
<rqou>
seriously though?
<rqou>
so much for "nah, FA mode has got to have some kind of sig checking"
<marcan>
now find the real bug given this taste of what the code quality is that you've just gotten :P
<rqou>
you know, i was _supposed_ to be porting math code to run on a potato
<rqou>
but this is more fun :P
<marcan>
I'm going to sleep :)
<awygle>
whitequark: one more issue with this
<awygle>
the 5x5 grid of thermal vias on a 50mil grid won't fit on the proposed footprint side
<awygle>
*size
<awygle>
and if i blow it up to the suggested pad size from evanshultz i'm concerned any vias between the exterior pads and the thermal pads won't fit
<awygle>
i could shrink it by 9 mil which would give a total clearance of about .66 mm
<whitequark>
I only have vias to ground there, no?
<whitequark>
which don't have clearance requirement to ground-connected EP
<awygle>
ah, i wasn't sure if that was true
<awygle>
no problem then
<whitequark>
I mean they already violate the keepout area of the EP
<q3k>
marcan: oyasumi
<whitequark>
awygle: also, LEDs
<whitequark>
where should we put LEDs and how many do we need
<awygle>
whitequark: towards the edge, and... four maybe?
<azonenberg>
rqou: timed HF only works for older processes
<azonenberg>
around 350 is the furthest i've had luck
<azonenberg>
And once you get down a few layers the surface is very uneven
Lord_Nightmare has quit [Ping timeout: 265 seconds]
<openfpga-github>
Glasgow-JTAG/master 9e0fde5 Andrew Wygle: Add modified Cypress symbol pointing to new FP.
<mithro>
whitequark: Because debugging USB on the fx2 itself is a pita, plus you need to have the fx2 hardware to do it
<whitequark>
fx2 hardware is cheap and widely available
<whitequark>
and iunno, so far I didn't even want printf while debugging
<whitequark>
maybe I'm more patient than you
<mithro>
whitequark: You are probably a better programmer then me
<whitequark>
mithro: well, I haven't really done a lot of fx2 work
<whitequark>
just wrote a new stdlib
<awygle>
whitequark: so what did you take away from my adc analysis? are we doing the op-amp thing or one of the slow voltage dividers?
<whitequark>
awygle: slow voltage dividers I think
<awygle>
mk
<whitequark>
doing it manually with opamps is a bit of a pain
<whitequark>
we'd need two, handle hysteresis...
<rqou>
q3k: i finally found the "debug output current state" function :P
<rqou>
maybe that'll help the RE
<mithro>
whitequark: know anyone who might be a glutton for punishment and the skills to add the fx2 USB stack for ucim (possibly for money?)
<q3k>
rqou: yeah, it seems like it can also act as a printf, but that probably got macro'd out
<whitequark>
mithro: you don't have that much money
mumptai has joined ##openfpga
<whitequark>
for the required level of skill
<whitequark>
at least, I know how much I would charge for it, and you don't have that much
<mithro>
whitequark: Probably
<awygle>
whitequark: it's lunchtime for me, i think that should be ~everything footprint/symbol wise but let me know if i'm wrong. not totally sure what to do with the footprint i just made for cypress, but i guess i'll open a PR...
<whitequark>
awygle: thanks!
<whitequark>
I'm going to finish off the board now and then I'll want you for review
<awygle>
whitequark: copy, sounds good
<rqou>
q3k: ok, cheating again, what function reads the bad block table?
<q3k>
rqou: it won't really help you if I told you
<rqou>
so you don't think that's where the bug is?
<q3k>
rqou: start from reset, build your way down the callstack
<q3k>
no, it's just that it relies a lot on state
<rqou>
hmm
<q3k>
which is constructed elsewhere
<rqou>
what part are you focusing on?
<q3k>
depends on the day
<q3k>
today I'm looking at RCM code again
<rqou>
i really don't think that's it
<rqou>
there's somehow an untethered exploit
<q3k>
well, once you have code exec via anything turning it into a persistent untethered exploit should be easy
<rqou>
why?
<q3k>
spoiler alert :P
<q3k>
there's a lot of code that depends on fuse state
<rqou>
yes, i know that
<q3k>
and iiuc, when you're running in bootrom you can just program them at will
<rqou>
yes
<rqou>
wait, no way
<rqou>
there's a bug in fuse state handling?
<q3k>
well, they're trusted
<q3k>
it's not even a bug
<rqou>
and it's not the FA fuse
<rqou>
wtf so i've been looking in the wrong places this whole time
<q3k>
i think so, I really haven't investigated that much
<q3k>
seriously, I'm just dicking about
<rqou>
i just assumed "yeah, fuse state parsing should be correct, right?"
<q3k>
my success rate is zero
<q3k>
why are you even asking me :D
<rqou>
because you're at least in this channel and willing to talk about it
<rqou>
how did they manage to f*ck up fuse state parsing?
<q3k>
I'd think you'd be better of REing the thing yourself
<rqou>
anyways, wtf
<rqou>
so the persistent exploit isn't even necessarily in parsing the boot data?
<q3k>
i don't know. I don't think so
<q3k>
what I'm looking for is a bug where I don't have to reflash the eMMC to get code exec
<rqou>
and then?
<q3k>
i'm sure there's bugs in the boot code parsing because it's complex
<rqou>
reprogram the fuses?
<q3k>
dunno, maybe
<rqou>
"boot code parsing"?
<q3k>
you're thinking this much more through than I am
<q3k>
s,boot code,boot configuration table,
<rqou>
you mean the bct or something else?
<q3k>
yeah
<rqou>
hmm
<rqou>
i wonder how many bugs the new soc rev will fix
rohitksingh has quit [Quit: Leaving.]
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
<q3k>
rumor has it nintendo will write their own bootrom
<rqou>
aka "not better"? :P
<q3k>
well, nintendo learned to write okay code
<q3k>
i trust it way more than the hellhole that is nv's bootrom
<rqou>
man i really need to f*cking graduate and start working on "real" hax
<rqou>
on that note, i'm going to put the tegra bootrom away and actually do the "port math to a potato" that i was supposed to be doing
<whitequark>
"Virtual BoardItem::Flip occurred, should not occur" stay classy pcbnew
<rqou>
lol
<whitequark>
...
<whitequark>
the FXMA108 datasheet misspells "PAD" as "DAP
<whitequark>
and then repeats that on the drawings
<rqou>
lolol
<awygle>
Design Access Pad
<whitequark>
(probably not)
<cr1901_modern>
That's the stuff I used to use to caulk the bathtub
<azonenberg>
lol
<awygle>
azonenberg: can you Recommend Me A Hot Air?
<rqou>
not azonenberg, but aoyue 852a++?
<azonenberg>
yeah i have an aoyue, not sure on the model but it's worked fine for me
<azonenberg>
it's a lot less critical in my experience than the chocie of iron
<awygle>
$$ :( but not unexpected
<awygle>
thanks azonenberg, rqou
Lord_Nightmare has quit [Ping timeout: 264 seconds]
noobineer has joined ##openfpga
<cr1901_modern>
awygle: Yea, the entry into reflow work is really kinda expensive. It's one of the reasons I've been resistant to going that path. But FPGA vendors don't care about hobbyists.
<cr1901_modern>
So I don't really have a choice anymore.
<whitequark>
hobbyists should get on with the times tbh
<azonenberg>
whitequark: +1
<awygle>
well, at least it's cheaper than RF
<azonenberg>
if you cant do bga you arent really a serious hobbyist these days
* whitequark
can't do BGA :P
<awygle>
yes, because what this hobby needs is more gatekeeping :p
<whitequark>
well not the iCE40 BGA parts anyway
<whitequark>
awygle: that's not really what i mean
<rqou>
not even the 0.8mm?
<awygle>
i get your points
<rqou>
awygle: gatekeeping?
<cr1901_modern>
whitequark doesn't like DIP
<rqou>
DIP sucks in every way
<whitequark>
yes, fuck DIP
<whitequark>
use SOIC at least
<gruetzkopf>
fuck through-hole
<rqou>
yeah, SOIC loses absolutely nothing
<azonenberg>
eeew soic
<rqou>
not even the ability to run traces between pins
<azonenberg>
too big, no benefits
<gruetzkopf>
i had to use DIP4 optoisolators for a project
<cr1901_modern>
Oh I've manage to screw up SOIC, so fuck all of you :)
<whitequark>
through-hole has uses... and they're all about connectors
<whitequark>
if you don't have mechanical forces acting on a component use surface-mount
<awygle>
optos are enormous
<awygle>
i love digital isolators
<rqou>
gruetzkopf: building a PSU? :P
<cr1901_modern>
I hate doing surface mount.
<gruetzkopf>
nope
<azonenberg>
yeah through hole only makes sense for mechanical support
<whitequark>
cr1901_modern: learn to do it then?
<gruetzkopf>
capturing 60V digital logic
<whitequark>
i'm way more productive with surface mount than through hole
<rqou>
gruetzkopf: WTF?!
<rqou>
is this for a train?
<awygle>
i do miss breadboards when doing smd, but that's it
<gruetzkopf>
trackside equipment
<whitequark>
i use breakout boards
<gruetzkopf>
i use perfboard for soic
Lord_Nightmare has joined ##openfpga
<whitequark>
i have a stack of these for every imaginable smd package
<cr1901_modern>
I can do it. Doesn't mean I like to.
<awygle>
i've done that
<awygle>
but i mostly don't bother
<awygle>
probably should more
<gruetzkopf>
and flipchip for fun stuff
<whitequark>
cr1901_modern: if you don't like it that means you can't do it easily which means you don't know well how to do it
<gruetzkopf>
dead-bug pcie ftw
<gruetzkopf>
(this leads to cursed images)
<cr1901_modern>
whitequark: And that's my point. It takes far more effort and it's expensive to learn how to do.
<rqou>
btw hey gruetzkopf when are you graduating?
<cr1901_modern>
B/c you screw it up you buy a new kit or PCB (or components)
<whitequark>
no you just rework it?
<gruetzkopf>
not sure :P
<awygle>
so many advanced degrees in this channel lol
<azonenberg>
quite honestly
<azonenberg>
i would rather stick a bga on a board and reflow it
<gruetzkopf>
this is germany, no huge expenses and hard deadlines
<awygle>
nobody hit B.S. and wanted to bail like me?
<rqou>
awygle: nah, only azonenberg
<azonenberg>
than solder half a dozen dips with a handheld iron
<whitequark>
^
<awygle>
rqou: you're getting an M.S.
<awygle>
or M something
<rqou>
not technically MS
<azonenberg>
place the part once, with tweezers, jiggle into place as much as you have to
<azonenberg>
then let the oven and surface tension do the work
<cr1901_modern>
azonenberg: Sure I don't blame you. I'd rather go that route too.
<gruetzkopf>
i'm in a B.Sc. course
<whitequark>
and soldering SMD passives absolutely beats soldering PTH passives
<whitequark>
you don't have to bend the leads
<gruetzkopf>
should have been done a while ago
<whitequark>
then see you bent them incorrectly
<whitequark>
bend them again
<azonenberg>
eeew lead bending and cutting
<azonenberg>
eeew
<rqou>
gruetzkopf: except you were lazy and a european :P
<whitequark>
cut this afterwards
<whitequark>
have components fall out of the board when you flip it
<gruetzkopf>
yes, it's also *much* cheaper for me to be a student
<whitequark>
have leads short towards adjacent solder blobs
<whitequark>
PTH rework is also quite obnoxious
* azonenberg
huggles a QFN
<whitequark>
with SOIC, just lift legs one by one until you get the entire chip off, this is *worst case*
<gruetzkopf>
yeah i much prefer manual 0402 over stupid thoughhole packages
* awygle
waits for the QFN-induced red flashes to subside
<cr1901_modern>
whitequark: This doesn't happen to me anymore, but when failing SMD the first few iterations (it took me a few tries) I would destroy a trace or pad while doing rework. So that's why I needed to buy more.
<whitequark>
ideally you take a small blob of chipquik and drag it across the edge of the package
<azonenberg>
awygle: what have qfns ever done to you?
<gruetzkopf>
i've done emergency bga soldering with nothing but a glass-surface stove
<azonenberg>
cr1901_modern: but it's not "my skill", reflowing bga is a pretty idiotproof process
<azonenberg>
especially if you use flux instead of paste
<azonenberg>
you dont even have to align the stencil
<azonenberg>
Put the part on and cook it
<azonenberg>
as long as your oven has some degree of temp control you can't overcook
<florolf>
< azonenberg > it's a lot less critical in my experience than the chocie of iron <- now i want to hear your recommendation for an iron
<azonenberg>
at which point literally the only possible failures are gross misalignment (more than a ball radius off) or undercooking
<whitequark>
yeah, the reason I don't use BGA for now is just because PCB layout is more obnoxious
<azonenberg>
the former can be easily checked with a microscope prior to cooking
<whitequark>
not assembly
<azonenberg>
the latter can be corrected by leaving it in longer
<awygle>
pavlina's point is exactly mine about gatekeeping. it's fine to explain that things are not as hard as they seem to boost people's confidence, but when it starts crossing over into "anybody who can't do this is an idiot" is when it becomes toxic
<rqou>
florolf: again not azonenberg but i use an old hakko 936
<azonenberg>
whitequark: i prefer bga fanout, you have bigger pitch
<rqou>
so old it's not even blue and gold :P
<azonenberg>
rqou, florolf: we have one of the new hakko fx-1000 (i think)? irons at work
<rqou>
is that curie point?
<azonenberg>
it's a curie point system, hakko's metcal competitor
<rqou>
nice
<azonenberg>
i love it and cant wait to get one for my own lab
<rqou>
i wish i had that
<cr1901_modern>
awygle: This
<rqou>
i use an aoyue 853a++ as a preheater and that also helps
<rqou>
except its control loop is completely useless
<azonenberg>
awygle: i'm not saying anyone is an idiot, i'm saying that all you have to do is follow the process at each step and you should get very good yield
<rqou>
i just end up running it open loop most of the time
<whitequark>
azonenberg: i think there's a mismatch in definition of "hobbyist"
<rqou>
also, iirc the old hakkos are technically not officially compatible with the new tips
<whitequark>
yours is "someone who is deeply committed to doing every step from start to end correctly, and will spend a lot of time ensuring that happens"
<cr1901_modern>
s/time/time and money/
<whitequark>
many people just want to get over the annoying electronics parts and do something they consider fun
<azonenberg>
whitequark: then i'd say they're a software hobbyist who happens to dabble in electronics
<azonenberg>
Which is different
<whitequark>
cr1901_modern: you're grossly overstating the costs of doing smd work, and mostly by your own fault
<gruetzkopf>
i wirewrapped a 19" 3U card-cage last week, AMA
<awygle>
there's a conservation of novelty aspect too
<whitequark>
you've chosen to get a $300 or whatever oven controller yourself, no one forced you
<whitequark>
i do reflow with a fucking blowtorch
<azonenberg>
cr1901_modern: I did fairly complex bga boards in a $20 walmart toaster oven
<cr1901_modern>
whitequark: Tbf, I didn't buy anything yet... :P
<azonenberg>
My $60 oven with a fan is a huge step up, i'll give you that
<cr1901_modern>
though that's indecision
<azonenberg>
But i did it on a student's income
<whitequark>
what azonenberg says
<rqou>
azonenberg: "set it to cookies" :P
<azonenberg>
rqou: exactly
<whitequark>
azonenberg: your "happens to dabble" is most people's "never going to achieve this level of skill professionally in a career"
<awygle>
If you haven't done embedded before you want to do the absolute easiest thing you can
<sgstair>
"PCBs are cookies for engineers"
<azonenberg>
awygle: then give said people an arduino
<azonenberg>
whitequark: my process is literally "turn to 'cookies' / 450F, cook until all visible solder melts, wait 30 sec, turn off heat, open door"
<azonenberg>
pretty, shall we say... cookie cutter? :p
<whitequark>
azonenberg: i'm referring to your design process
<azonenberg>
Oh
<awygle>
azonenberg: that's disingenuous. there's a huge space between an arduino and an FFG1156 and you know it.
<azonenberg>
I thought we were discussing soldering :)
<whitequark>
what awygle says
<whitequark>
but also awygle is not entirely correct either
<azonenberg>
awygle: that's what ft256 is for :)
<whitequark>
because there's tons of boards covering that space
<whitequark>
some of them literally arduino-compatible
<azonenberg>
Unlike ffg1156, it can be done on a typical hobbyist's budget
<awygle>
whitequark: fair
<azonenberg>
on 4 layer oshpark
<gruetzkopf>
i've started with the usual THT stuff and worked my way both ways in process technology
<whitequark>
that's what I meant by "hobbyists ought to get on with the times"
<azonenberg>
the new spartan-7s are even better, they have a 14x14 ball 1mm
<gruetzkopf>
4-layer has become CHEAP these last few years
<whitequark>
you don't need everyone personally being able to do 0.45mm pitch BGA
<azonenberg>
which can be fanned out on oshpark with even less effort than ftg256
<rqou>
cheap 6layer when :P
<azonenberg>
whitequark: yeah but 1mm? that's within most people's skill and budget
<awygle>
I don't approve of any "true Scotsman" argument, basically. Why do we need to define what a "real hobbyist" is?
<sgstair>
you can do FT256 even on 2 layers
<cr1901_modern>
>i do reflow with a fucking blowtorch
<cr1901_modern>
That's b/c you're whitequark. Or more specifically, you've been in a position where you can use a blowtorch safely. Or if you don't use it safely, you've evaluated the risks :).
<azonenberg>
sgstair: i know somebody who's done it on *one*
<azonenberg>
home etched pcb with no soldermask
<whitequark>
cr1901_modern: wat
<sgstair>
hah, one is pushing it
<rqou>
@pdp7 tells me that unfortunately not enough people would use a 6-layer service
<azonenberg>
i freely admit to not being that insane :)
<rqou>
basically just me, azonenberg, maybe lain, maybe whitequark
<awygle>
rqou: tried dirtypcb? They advertise it
<gruetzkopf>
<
<azonenberg>
awygle: doubt they do fr408 and good design rules
<azonenberg>
:p
<sgstair>
I'd use 6 layers if I could get it cheap
* awygle
would use it
<azonenberg>
And i'd be ok with a panel ever few months
<awygle>
azonenberg: 6/6 i think
<rqou>
great, so we've got 6 customers :P
<awygle>
Which isn't bad
<rqou>
um
<rqou>
oshpark 4layer is 5/5
<azonenberg>
awygle: 5/5 is what oshpark 4l had
<awygle>
Nobody needs 408 really
<rqou>
6 layer 4/4 for cheap when? :P
<awygle>
Although it's good
<sgstair>
4 layers is pretty good for almost everything though
<azonenberg>
awygle: it helps, i recall crunching the numbers for impedance without it
<azonenberg>
dimensions got dicey
<gruetzkopf>
i've accidentally done 4/3 on a cheap&cheerful 4layer process
<rqou>
i've heard you should be able to push oshpark 4l to 4.5/4.5
<rqou>
which will let you use 0.8mm bgas
<azonenberg>
yeah, meanwhile i go the other way
<azonenberg>
and use larger annular rings than their spec unless i am in a tight area
<azonenberg>
To improve yield
<sgstair>
hehe, I do 0.8mm bga on oshpark 4L at 5/5
<whitequark>
dirtypcbs used to have 5/5 but had poor yield
<awygle>
azonenberg: spacing is more important than dielectric for impedance
<sgstair>
breakout purely in vias
<rqou>
sgstair: i thought the problem is that traces won't fit between vias
<whitequark>
cr1901_modern: you really need to stop complaining and start soldering, tbh
<sgstair>
ah, I actually reduced the ball size to make traces fit, looks like
<gruetzkopf>
i need to check the pinpitch on the old sgi boards. they've dogboned ALL the pins on EVERY bga
<sgstair>
tight, though
<mithro>
I have found getting decent via size is much more problematic...
<gruetzkopf>
^
<awygle>
Just to finish off my thoughts on the previous topic, while I sympathize with it I don't support the "smd is so hard" attitude either. Ultimately you can't control the packages the vendors ship, so you have to decide what you want to do and get on with it. "if only" is a waste of time.
<awygle>
I just think we can make that point without being jerks
<sgstair>
I dare say multirow QFN is dying out because nobody got time for that
<rqou>
the "smd is so hard" frustrates me a bit because people keep designing boards (that i have to use for various reasons) that are PTH
<rqou>
sgstair: you're obviously not QCA :P
<awygle>
sgstair: and good riddance
<whitequark>
wtf is multirow QFN
<whitequark>
cursed package
<rqou>
QCA has a bunch
<rqou>
all router SoCs
<whitequark>
all the drawbacks of QFN but none of the benefits
<sgstair>
QCA?
<whitequark>
qualcomm atheros
<rqou>
qualcomm atheros
<awygle>
Qualcomm
<sgstair>
altera did for a while
<sgstair>
ah. Well Qualcomm is pretty much insane and drunk with power
<sgstair>
I hesitate to say they are making rational decisions
<rqou>
hey felix_, what happened to the ath10k work? :P
<awygle>
Maybe someday I'll do a board series of the same design at four or five "process nodes", along the lines of rqou's pedagogical crypto idea
<gruetzkopf>
ooh yeah qca stuff
<gruetzkopf>
i've modified quite a few plastic routers to add usb and pcie ports
<gruetzkopf>
definitly cursed package
<whitequark>
pcie?!
<rqou>
yeah, QCA has a lot of cursed SoCs
<whitequark>
awygle: hmm
<whitequark>
do we use identical color LEDs for everything
<gruetzkopf>
they usually have pcie for connecting a 5GHz radio
<whitequark>
or, do we rely on me definitely mixing them up during assembly
<gruetzkopf>
which is usually nonexistant on the <20€ stuff ;)
<sgstair>
heh
<awygle>
whitequark: the latter ideally
<whitequark>
I guess four green ones plus one red one is something I can manage
<whitequark>
opinions?
<whitequark>
red for error, green for power/activity
<awygle>
That's not bad. I'd have said yellow for activity but if you're concerned, green is fine.
<sgstair>
I like to make it obvious on the silkscreen what color the LED should be
<whitequark>
ok yellow for activity
<whitequark>
sgstair: they will be labeled
<whitequark>
hm should probably use a resistor network here
<rqou>
hmm, i never use resistor networks
<whitequark>
why
<rqou>
no particular reason
<rqou>
i just default to using discrete resistors and never decide to change to networks
<rqou>
random question: what's the current "canonical" crypto library for potato microcontrollers? (i need this for <redacted>, not for school)
<mithro>
I generally have discretes generally easily available to me and not networks...
<rqou>
^ this too
<sgstair>
in large designs I just prefer populating one part to 4 or 8
<awygle>
I do networks for termination but not leds because often they want to be different values due to different luminance curves
<whitequark>
hmm, that's right
<awygle>
I think I have a bunch of 22r networks
<gruetzkopf>
for which algos? and how potato?
<whitequark>
but do I care about luminance curves
<rqou>
gruetzkopf: ecdsa (preferably prime-field since nobody other than certicom seems to use binary fields), rsa, AES-GCM, SHA2, "djb-suite"
<rqou>
for cortex-m class devices
<whitequark>
I gueeeess let's aim for 250 mcd?
<whitequark>
awygle does that sound right?
<azonenberg>
awygle: for what
<azonenberg>
indicator leds?
<azonenberg>
thats awfully bright
<rqou>
gruetzkopf: also, what's the "canonical" library for PCs that gives you access to all of the low-level primitives needed for those crypto algorithms?
<azonenberg>
my standard indicator LED is 35 ncd
<whitequark>
nano?
<azonenberg>
mcd*
<azonenberg>
sorry
<whitequark>
okay hm
<azonenberg>
typo
<whitequark>
these will go under the case
<rqou>
e.g. "perform raw RSA op, do point doubling, add two curve points"
<azonenberg>
But still you're an OOM brighter
<whitequark>
so maybe 70?
<azonenberg>
whitequark: i also run them dimmer than full spec most of the time iirc
<whitequark>
hmm
<azonenberg>
They're 35 mcd @ 20 mA
<azonenberg>
i run closer to 5 mA
<azonenberg>
sometimes even 1-2
<whitequark>
well these are 430 mcd @ 20 mA
<azonenberg>
hundreds of mcd is approaching "small area illumination" rather than "indicator" territory
<whitequark>
don't blame me I literally chose the cheapest one
<whitequark>
LOL
<awygle>
I usually run 50-100
<azonenberg>
Like those blue LEDs on fancy PC cases
<whitequark>
now I know how those horrible blue LEDs get designed in
<rqou>
i usually just don't give a shit :P
<azonenberg>
rqou: crypto++ has a very footgun-friendly interface
<gruetzkopf>
i *hate* blue LEDs
<azonenberg>
if thats what you want
<whitequark>
they just choose the cheapest ones and run them at design current
<awygle>
Much more important is that they're the same brightness
<sgstair>
just PWM it, fix it in software
<rqou>
also, azonenberg is it just me or are SMD LEDs usually smaller than the package would indicate?
<awygle>
Nothing worse than a red you can't see and a blue that's blinding
<whitequark>
sgstair: don't have PWM on those pins
<whitequark>
so I'm kinda forced to look at curves
<rqou>
azonenberg: ugh C++
<sgstair>
:)
<azonenberg>
whitequark: 160-1446-1-ND
<rqou>
azonenberg: for the "footgun-friendly" version i want it hooked up to a scripting language
<gruetzkopf>
i often run those high-efficiency LEDs at sub-1mA in indicator applications
<whitequark>
mine is $0.14@1
<rqou>
oh wait wtf
<rqou>
azonenberg: i just looked at the feature list of crypto++
<rqou>
you weren't kidding :P
<azonenberg>
rqou: crypto++ has everything under the sun, at a low level
<rqou>
it literally has every single primitive ever
<rqou>
including all the ways to use them wrong
<gruetzkopf>
:D
<azonenberg>
i love using it to talk to "weird encrypted protocols you need to talk to whether secure or not"
<rqou>
so what about crypto for potato microcontrollers?
<azonenberg>
I would not recommend it for general purpose encryption use, however i do use their SHA routine sometimes if i need a general purpose hash
<azonenberg>
Since hashing is hard to do wrong and usually i dont need cryptographic security, just an identifier for some block of data
<whitequark>
gruetzkopf: wtf you aren't joking
<whitequark>
i AM going to run this green led at exactly 1mA
<whitequark>
well maybe a bit more
<azonenberg>
whitequark: yeah i use that LED i linked with a 470 ohm resistor off 3v3 pretty often
<azonenberg>
let me see what that comes out to...
<whitequark>
1.3?
<gruetzkopf>
i've done 500uA in a battery powered application
<gruetzkopf>
pushing it a bit, but surprisingly visible
<rqou>
"Furthermore, the library retains a collection of insecure or obsolescent algorithms for backward compatibility and historical value: MD2, MD4, MD5, Panama Hash, DES, ARC4, SEAL 3.0, WAKE, WAKE-OFB, DESX (DES-XEX3), RC2, SAFER, 3-WAY, GOST, SHARK, CAST-128, and Square."
<rqou>
goddammit
<azonenberg>
rqou: do they have ENIGMA?
<rqou>
nobody should ever use this library in production
<azonenberg>
rqou: i mean you *can* create a secure protocol with it
<gruetzkopf>
skipjack when?
<azonenberg>
But it's easy to use wrong :p
<rqou>
it's probably easier to use wrong than to use right
<azonenberg>
rqou: thats true of crypto in general
<azonenberg>
if i ever saw a client project linking to it i'd do a *very* thorough examination :p
<azonenberg>
libsodium is nice if you want a relatively footgun-resistant interface
<rqou>
i guess it's useful if you really wanted just the raw EC group operations
<rqou>
or something like that
<gruetzkopf>
is that the newer of those 2 libs?
<azonenberg>
rqou: yeah it's great if you're prototyping
<azonenberg>
or developing a new block cipher mode
<azonenberg>
etc
<azonenberg>
Or trying to mine some obscure cryptocurrency that is full of terrible design decisions? lol
<rqou>
lol
<gruetzkopf>
(or building stuff to talk to obscure hardware you cannot change)
<rqou>
azonenberg: so what library do you usually see on potatos?
<azonenberg>
yes, that's what i use it for at work sometimes
<azonenberg>
rqou: honestly, more often than not it's the vendor peripheral library for whatever crypto core the mcu has
<rqou>
ugh
<azonenberg>
whitequark: anyway 2V typical Vf... that's a drop of 1.3V across 470 ohms or 2.7 mA
<rqou>
and for asymmetric?
<azonenberg>
and that is very bright
<azonenberg>
like, not blinding blue but easily visible in a well lit office in daylight
<rqou>
azonenberg: what about for asymmetric crypto?
<azonenberg>
rqou: i cant recall seeing asymmetric on MCUs often enough for there to be a "usual", overall openssl is probably the #1 most common for that
<rqou>
lolwtf
<rqou>
no wonder embedded crypto is such a disaster
<azonenberg>
but thats on higher end embedded linux etc
<gruetzkopf>
one of the machines in my stack of weird architectures has a "AC present" LED which i use to light my room at night..
<azonenberg>
i dont see embedded asymmetric that often on low end (stm32 class) stuff
<azonenberg>
surprisingly
<rqou>
what
<rqou>
how do they work?
<azonenberg>
i saw one design that used an atmel ATECC smartcard chip
<rqou>
hardcoded keys?
<whitequark>
azonenberg: i mean
<azonenberg>
rqou: more often than not? yes
<whitequark>
i want it to be visible in a well lit office in daylight
<azonenberg>
let's see...
<azonenberg>
looking at the curves thats about 0.125x full brightness
<rqou>
azonenberg: ever see/use mbedTLS?
<azonenberg>
Which is 35 mcd
<azonenberg>
so 4.3 mcd
<whitequark>
the fuck
<azonenberg>
i'd shoot for around 5-6 mcd if you want "very visible" but not blinding
<sgstair>
ah yeah, for verifying signatures you don't have any data to leak
<whitequark>
i wonder if they make white LEDs
<azonenberg>
whitequark: lool
<rqou>
lol
<sgstair>
and you don't have any private information that could help an attacker.
<azonenberg>
sgstair: yeah i was stuck thinking signing for some reason
<felix_>
rqou: on the ath10k project: i'll be employing a student to write ida processor support for the microcontroller used in the ath10k chips. need to get some paperwork done for that, but then i'll hopefully can reverse engineer that stuff together with 1-2 other people
<azonenberg>
you could probably leak the hash of the data being verified thorugh a side chanenl
<azonenberg>
but you know that already
<rqou>
felix_: nice, awesome
<rqou>
azonenberg: so it should theoretically be "safe" for me to just roll a potato rsa?
<rqou>
for verifying only
<awygle>
Could you figure out how many bits into the signature it gets before failing or something like that?
<rqou>
this has to fit into e.g. your bootloader
<awygle>
That's not really how it works I suspect...
<azonenberg>
awygle: that was my thought, but i dont think that would be useful except in case of a hmac
<rqou>
even for hmac
* awygle
is a scrub
<rqou>
isn't the hash output supposed to be essentially random
<rqou>
?
<azonenberg>
no, with a hmac that's an instant-win
<sgstair>
awygle: yeah, not how it works. RSA has to complete before you know the outcome.
<azonenberg>
Because it calculates hmac(shared key, your data)
<azonenberg>
then compares to your provided signature
<rqou>
and?
<azonenberg>
all you have to do is leak that comparison result bit by bit
<rqou>
ah
<azonenberg>
then flip your signature bit by bit until it matches
<rqou>
ah, of course
<azonenberg>
With a public key signature i'm less sure this is viable
<azonenberg>
if you have padding it definitely is not
<sgstair>
yeah.
<azonenberg>
If unpadded, i think there are fun things you can do
<rqou>
yeah, so i just have to not pull a nintendo
<azonenberg>
but those are mostly at the signing side
<sgstair>
yes, please no nintendo antics
<rqou>
*) use memcmp
<rqou>
*) check padding
<rqou>
*) check padding, even if it doesn't start with a 1
<azonenberg>
rqou: dont use a memcmp
<rqou>
amidoingitright? :P
<rqou>
er, why not?
<azonenberg>
memcmp has variable run time
<azonenberg>
it early-outs on a mismatch
<rqou>
so?
<azonenberg>
Constant time on everythign is better
<sgstair>
shouldn't matter in this case, but in general yes
<azonenberg>
loop over bytes, bitwise OR the comparison result with a temp value
<azonenberg>
then check that value against zero
<awygle>
Constant time, time for you to go out to the places you will be from
<azonenberg>
so tmp |= a ^ b;
<sgstair>
need cryptmemcmp() in std library
<rqou>
but i don't care for this use case
<felix_>
rqou: i have no time to work on the ida processor support myself at the moment and i hope that that work might get him also into reverse engineering stuff to make better open source drivers and firmwares
<rqou>
azonenberg: still better than strncmp? :P
<felix_>
would be good if there was some good well designed and useable source reverse engineering framework though, but for now i just use ida...
<rqou>
just hope that ida doesn't blacklist chinese hacking groups and we'll be fine :P :P :P
<rqou>
i guess having an asshole sales team and randomly deciding to not sell people a copy still hasn't been good enough to prevent leaks :P :P :P :P :P
<awygle>
Didn't whitequark just do something with something they liked? Binary ninja or something?
<awygle>
Lots of somethings
<felix_>
i don't mind paying for support and updates, since the ida support is really good
<rqou>
it is?
<felix_>
iirc binary ninja is also closed source and has less platform suport than ida
<rqou>
i just kept hearing about some asshole who worked for hex-rays who would just occasionally refuse to sell people licenses
<whitequark>
binja is closed source, but has far better innards of the analysis engine than ida
<whitequark>
ida is shit
<whitequark>
it's also unobtainium
<whitequark>
they stopped selling personal licenses long ago
<rqou>
they did?
<whitequark>
yes they did
<rqou>
they still officially list them
<azonenberg>
if you work for an established company or are known in the community, its relatively easy to get
<whitequark>
well fuck that
[X-Scale] has joined ##openfpga
<azonenberg>
if you're a random person in hong kong, less likely
<whitequark>
they can choke on their precious license
<whitequark>
in fact, i hope they do choke
<felix_>
the ida support is awesome. i think all bug reports except one resulted in a fixed version within less than a week
<rqou>
so why do/did i keep hearing about some asshole sales guy?
<rqou>
e.g. see whitequark's comment above
<whitequark>
ilfak?
<whitequark>
he wrote it, not just a sales guy
<whitequark>
and sets the policy
<rqou>
i don't think it's ilfak
X-Scale has quit [Ping timeout: 260 seconds]
[X-Scale] is now known as X-Scale
<whitequark>
wtf, 1% resistors got *cheap*
<whitequark>
I am accidentally using 1% resistors for everything
<whitequark>
again selected purely on basis of cost
<felix_>
on good and bad support: have i already told my support horror story from when i bought a hex editor?
<rqou>
_bought_ a hex editor?
<felix_>
well, i need a hex editor that also runs on osx and is useable
<rqou>
for a while i ran "bless"
<sorear>
side channels are irrelevant for public key signature verification because the attacker has all of the information the legitimate algorithm has
<rqou>
but "bless" kept getting more and more broken over time because afaik it's abandoned
<sorear>
so you learn exactly nothing from a trace
<rqou>
sorear: that's what i figured
<rqou>
it's of course still vulnerable to fault injection
<sorear>
similarly for PK encryption (unless the cleartext is interesting)
<sorear>
ECDSA does a bunch of algebra, then checks an equality
<sorear>
so I think most faults will just result in a falsely rejected sig, not a falsely accepted one
<sorear>
it doesn't catastrofail like CRT RSA signing does
<rqou>
i thought ecdsa can catastrofail too?
<sgstair>
whitequark: are you sorting cost at qty 1, or something more sane like 100?
<felix_>
used ultraedit as hex editor maybe 15 years ago under windows and it was a really good hex editor. so two years ago i bought a current version and wanted to use that under osx. problem was that it has a rendering bug which makes that editor not very useful for me. wrote the support and they could reproduce the bug. nothing happened. wrote them again after half a year and the response was that they are
<felix_>
currently busy working on a new version. this year the new version was released, they want to charge for the update and the hex rendering is still broken. i mean when i buy a hex editor, i'd expect the hex view rendering not being obviously broken
<rqou>
lol
<sgstair>
felix_: awful
<felix_>
other hex editor i tried maybe 2 years ago was hex fiend and that only supported showing addresses in decimal, but not in hexadecimal. took me an hour to find out why some offsets didn't make sense
<sgstair>
I like to say software is hard, but it's not that hard!
<sgstair>
sigh
<felix_>
so yeah, i'm still looking for a good graphical hex editor. i need proper renddering and no flickering/tearing when quickly scrolling through a file
<rqou>
i currently use okteta
<rqou>
which "just works"
<rqou>
except for how it seems to constantly get "stuck" whenever debian sid upgrades something
<rqou>
because it seems to depend on a giant pile of libkf5* stuff
<rqou>
idk why this is constantly breaking
<felix_>
the bug in ultraedit was that when a byte is i think 0xAD, it doesn't render that byte in the right column and the next bytes move a place to the left. not sure how you can mess that up...
<sgstair>
whitequark: huh, there are some cheap 1% and 0.5% resistors on some values. Neat.
<felix_>
hm, last time i tried okteta it felt a bit sluggish
<rqou>
felix_: because 0xAD is a latin1 soft hyphen? :P
<rqou>
"whee, i don't understand character sets"
<felix_>
well, all other non-printable characters are replaced with a dot
<rqou>
(referring to the author of that hex editor, not you)
<felix_>
no, not in the text view, but in the hex view
<rqou>
oh what
<rqou>
wtf how
<felix_>
yeah, i don't know
<sorear>
rqou: signing can, although I think it's still safer than unprocted CRT RSA signing. verification is mostly fail-safe
<rqou>
yeah, i figured i _should_ be able to roll a public key _verification only_ lib without footgunning myself too hard
<rqou>
because apparently everything in this space kinda sucks for some reason?
<felix_>
anyway, i probably should stop ranting about things and clear my desk to put the 2 screens i bought last week on it, so i can work on some electronics tomorrow to make mithro and the apertus people happy :)
<whitequark>
sgstair: sorting by whatever mouser uses
<whitequark>
azonenberg: damn power planes are a lifesaver
<whitequark>
i'm never doing a 2L board again
<rqou>
so, when is oshpark going to do a 4l super swift? :P
<whitequark>
dunno, dirtypcbs already does
<whitequark>
oshpark is way too expensive for me
<rqou>
dirtypcbs is slooow
<whitequark>
um
<whitequark>
use their expedited service?
<whitequark>
their default one competes at cost, and it's still pretty fast
<whitequark>
you haven't seen "slow".
<awygle>
Yeah 4l boards are way better
<awygle>
I always think "oh this can be 2l" and then I look at the result and think "I am not proud of the shortcuts I had to take to make this work"
<azonenberg>
whitequark: lol
<azonenberg>
you've finally seen the light
mumptai has quit [Remote host closed the connection]
<azonenberg>
of course once you have several rails sharing one plane
<azonenberg>
trying to gerrymander them into a planar topology is fun
<awygle>
graph coloring
<awygle>
ugh. this weekend is not restful lol.
gnufan has left ##openfpga [##openfpga]
<rqou>
azonenberg: wtf that capture card @nanographs has is awful