<cyrozap>
It details going from GDSII->netlist/Verilog, and then simplifying that code and running it through an SMT solver to find the flag (this was for a CTF competition).
gnufan has quit [Quit: Leaving.]
<rqou>
right, we can probably achieve most of that with yosys
<rqou>
they cheated because they started with a GDS-II :P
<rqou>
now try starting with a folder of .jpgs and a .pto file :P
<cr1901_modern>
It's still cool
<cyrozap>
rqou: Sounds like a job for .-*-.-*-.nEuRaL NeTwOrKs.-*-.-*-. and .-*-.-*-.MaChInE lEaRnInG.-*-.-*-. :P
<rqou>
yes, i think digshadow can tell you all about those attempts
<cyrozap>
Also, re: doing this with Yosys: "What we need is a netlist - a description of all the electrical nets in the design and how they connect all the logic cells together. There's a few ways to go about this: 1) Use a commercial EDA suite (like Cadence or Synopsys) to perform netlist extraction. 2) Learn to use Magic VLSI. 3) [Build your own fucking birdfeeder](https://q3k.org/birdfeeder.pdf).";
<rqou>
yeah, we don't have the netlist extraction part yet
<rqou>
it's on the todo list :P
<cyrozap>
I'm just saying the author applied option 3 to the rest of the post as well, by building their own tools instead of just using Yosys. While I personally would have gone with Yosys because I'm familiar with it, there's something to be said for building the tools yourself as a learning experience.
<rqou>
ah true
<cyrozap>
So far, Yosys has been really good at simplifying the Verilog generated from PSoC PLD configs down to the original equations, which has saved me a ton of work because I don't have to do any simplification/minimization myself.
<rqou>
that's actually abc :P
<rqou>
but yeah, yosys is an amazing framework
<cyrozap>
Oh, well I'm using Yosys for the read_verilog etc. etc. write_verilog stuff.
<digshadow>
hmm thats actually an interesting point that there isn't a polished netlist extractor yet
<digshadow>
because there are a few tools that people use for ic reversing, but don't think there is general acceptance which to use
<rqou>
there are polished netlist extractors, but they're all commercial
<digshadow>
think sarayan's is the most popular though
<rqou>
they're used for LVS checking
<digshadow>
right I mean FOSS
<cr1901_modern>
Huh, sarayan isn't in this room
<cr1901_modern>
I wish SVG was conducive to multiple people editing without trampling each other's work.
<cr1901_modern>
(we tried w/ ym2151 and inkscape. It doesn't work exceptionally well.)
<digshadow>
cr1901_modern: and yes, most used is possibly "2 people"
<digshadow>
actually
<digshadow>
doesn't magic have some LVS?
<cr1901_modern>
what's LVS?
<rqou>
i've never actually used magic
<rqou>
layout-vs-schematic
<cr1901_modern>
ahh
<pointfree>
cyrozap: Speaking of which, I've been figuring out the inverting action at the portpins/dsi. I just ran through all possible combinations of PRT2_OUT_SEL0/1 and DSI5_DSIOUTT1 and recorded the output from the live hw. I was thinking maybe I should minimize the output of those + PRT2_PS (portpin states). It would give me an expression for the logic at the portpins. Probably simple enough to finish figuring out by
<pointfree>
visual inspection though.
<cr1901_modern>
digshadow: I use sarayan's tools, fwiw :P. For some metric of "use"
<cr1901_modern>
digshadow: like all tools intended for one person, it's difficult to actually use dietools
<digshadow>
cr1901_modern: right, point is nothing really reached critical mass there
<digshadow>
where it was made for others
<cr1901_modern>
digshadow: Jotego proposed making a GUI for a vectorizing-to-netlist workflow, but it didn't pan out
<cr1901_modern>
I think we both know why
<cr1901_modern>
(I agree w/ his ideas in principle, fwiw)
<digshadow>
heh
<cyrozap>
pointfree: So you'd just be minimizing a truth table? If you wrote it as a Verilog LUT, would Yosys be able to simplify that?
<pointfree>
cyrozap: Yes, just a truth table.
<pointfree>
cyrozap: I have an inkling that this may be the same inverting logic used by the PLD's on the input terms, just copy-pasted to the area of the dsi port interfaces. Although I could be totally wrong about that.
<pointfree>
cyrozap: Would you recommend it over blif?
<cyrozap>
pointfree: Verilog over blif? For the Yosys input? I only mentioned Verilog because I don't know the Yosys blif/ilang/json formats.
<rqou>
er, my recommendation is verilog for outputting and json for tool-to-tool interchange
<rqou>
yosys json isn't standardized, but it's much easier to work with than blif
<cyrozap>
pointfree: Also, I just checked, and Yosys _can_ simplify LUTs into logic equations.
<rqou>
ilang is even weirder and i don't know when i would use it right now
<rqou>
json = netlist, ilang = ast
<cyrozap>
rqou: Yosys JSON isn't documented anywhere, so I haven't used it for any of my tools.
<rqou>
it's a fairly obvious dump of yosys's internal data model
<rqou>
but yes, fair point
<pointfree>
Well is there a yosys source file documenting it?
<rqou>
there's a parse_json.cc somewhere :P
<pointfree>
thnx
<rqou>
there's also my rust code
<pointfree>
RE by logic synthesis..
<pointfree>
Your rust code?
<rqou>
i have a rust crate for working with yosys json files
<pointfree>
TIL even better
<cyrozap>
rqou: Also, I found Verilog to be easier to template. i.e., I can represent the PLDs as some SOP expressions in Verilog that I can then fill-in-the-blanks with the extracted configuration memory.
<rqou>
that's what i thought too originally
<rqou>
but then i wrote the code and found it easier to directly emit json
<cyrozap>
Hmm, maybe I'll revisit that, then.
ZipCPU|Laptop has quit [Ping timeout: 248 seconds]
promach_ has joined ##openfpga
digshadow has quit [Ping timeout: 248 seconds]
promach_ has quit [Quit: Leaving]
<pie_>
rqou, where do individual assembly instructions place in the chomsky hierarchy?
<pie_>
at first i thought theyd be context free, but then all that weirdass prefix stuff and heck knows, i didnt look into it much yet
<Bike>
what architecture?
<pie_>
* x86
<pie_>
( ARM, MIPS, ... )
<pie_>
well, for that question x86 specifially
<Bike>
i mean, encodings vary... mips instructions are probably pretty simple
<Bike>
x86 instruction encoding is apparently terrible
<Bike>
mips would probably be star-free, or maybe finite if you're being pedantic
<pie_>
x86 is one of the most complicated so id mainly be interested in that as a least common denominator i guess
<pie_>
i dunno if theres something esoteric that would need a higher level but eh
<Bike>
you could probably make one up that's not even decidable :p