<mithro> If anyone wants to help -- I have a whole bunch of small Python scripting tasks I could use help with
Ultrasauce has quit [Quit: No Ping reply in 180 seconds.]
Ultrasauce has joined ##openfpga
<openfpga-github> [Glasgow] whitequark reopened issue #35: Slew rate limiting resistors https://github.com/whitequark/Glasgow/issues/35
<openfpga-github> [Glasgow] whitequark commented on issue #35: Pretty sure we also need slew rate limiting on the *other* side of the level shifter because switching many inputs at once causes [glitches](https://github.com/whitequark/Glasgow/blob/a89f5a224449ddd5d1bf9e5f4e8b7e3bc2593bce/software/glasgow/gateware/fx2.py#L141-L145) on the FLAGn pins on the other side of the board. The apparently random timing of the glitches
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
rvense has quit [Ping timeout: 255 seconds]
rvense has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
steakpizza has joined ##openfpga
gnufan has quit [Ping timeout: 260 seconds]
<mietek> anybody used Upverter?
unixb0y has quit [Ping timeout: 256 seconds]
unixb0y has joined ##openfpga
steakpizza has quit [Ping timeout: 245 seconds]
steakpizza has joined ##openfpga
steakpizza has quit [Read error: Connection reset by peer]
gnufan has joined ##openfpga
<rqou> whitequark: do you know if A20 is really gone in Haswell+?
<sorear> > The functionality of A20M# is used primarily by older operating systems and not used by modern operating systems. On newer Intel 64 processors, A20M# may be absent.
<sorear> it still exists architecturally and has documented interactions with VT-x and TXT
<sorear> doesn't mean recent chips implement the option ofc
<rqou> yeah, via VLW right?
<rqou> hmm i wonder what happens when a VT-x guest attempts to mess with A20
<rqou> what layer of the stack would this be handled in?
<sorear> i guess the hypervisor catches the i/o port poke and then regenerates the gpa->hpa mapping
<rqou> and potentially has a bug? :P
<rqou> since even twiddling SS has caused significantly more than one CVE
digshadow has quit [Ping timeout: 265 seconds]
digshadow has joined ##openfpga
rohitksingh_work has joined ##openfpga
Bike has quit [Quit: Lost terminal]
m_w has joined ##openfpga
Lord_Nightmare2 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 260 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
Patater has quit [Ping timeout: 276 seconds]
Lord_Nightmare2 has joined ##openfpga
Patater has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 256 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
m_w has quit [Quit: leaving]
bitd has joined ##openfpga
Zorix has quit [Ping timeout: 276 seconds]
Zorix has joined ##openfpga
merskiasa has joined ##openfpga
<merskiasa> How would you write a piece of code to convert the FSK logic trace into a stream of bits? https://pastebin.com/QzLBCBQq https://imgur.com/a/7VPfnjj
<rqou> lol that (can be) hard
<merskiasa> rqou, how so?
<merskiasa> The first channel looks like the data captured from the FSK pin (data that will modulate the carrier).
<merskiasa> The second channel looks like a SPI data line, and the last one is likely the chip select line.
<rqou> depending on where the data comes from, the frequencies might be off a bit
<merskiasa> I have successfully captured the data that is transmitted over the air. It's easy to recognize because each message seems to start with a preamble (repetition of several "0" symbols and "1" symbols).
<merskiasa> garage remote
<merskiasa> used salea logic analyzer to sniff data between a PIC16F636 and a IA4221 chip (garage remote) https://imgur.com/a/ZPzkJ
<rqou> ah this is over wireless
<rqou> it's not a HDD/magstripe/some-other-mechanical-ish-process
<merskiasa> its sniffing
<merskiasa> between chips
<merskiasa> But not sure how to write a piece of code to convert the FSK logic trace into a stream of bits
<rqou> what is your final objective?
<merskiasa> rqou, https://imgur.com/a/Q6QLxzW (YardStickOne Specan Results)
<merskiasa> Garage code uses rolling code algorithm
<merskiasa> remote*
<merskiasa> rqou, Goal is sniffing the SPI communication between the PIC and the IA4221 (Doing so will also directly give you access to the TX frequency, baud rate, ...). From these codes, it may be possible to simply guess the rolling code algorithm if it's trivial enough.
<rqou> an, you're trying to break the codes?
<merskiasa> yes
<rqou> wait, i'm confused
<rqou> you're sniffing these captures from where?
<rqou> on the PCB of the remote?
<merskiasa> From using logic analyzer
<merskiasa> Yes
<rqou> usually these types of RF transceivers are "dumb"
<rqou> and you can ignore the whole "FSK" part and just look at the SPI commands between the microcontroller and the transceiver
<merskiasa> The following pins of the IA4221 should be hooked up to my logic analyzer (+ a common ground of course):
<merskiasa> SDI, data input of serial control interface (1)
<merskiasa> nSEL, Chip select input of serial control interface (3)
<merskiasa> FSK, Serial data input for FSK modulation (16)
<merskiasa> SCK, clock input of serial control interface (2)
<merskiasa> The SPI related signals (1, 2, 3) will give your information about the configuration of the radio while the FSK pin (16) will allow you to sniff the data that's actually transmitted over the air.
<merskiasa> PIC doesnt have SPI
<merskiasa> rqou, what do you mean?
<merskiasa> How would I do that
<merskiasa> Isnt that what im doing?
massi has joined ##openfpga
<azonenberg> Better question, is this really FPGA related? :p
<merskiasa> rqou, https://pastebin.com/QzLBCBQq load this .vcd file up in gtkwave
<rqou> it may end up being "pwn a chip" related
<daveshah> are we really aiming for "on topic IRC channel of the year award" anyway?
<rqou> merskiasa: usually on these type of transceivers you should be able to just probe the "FSK" pin
<rqou> when the pin is high one frequency is sent out and when it is low another frequency is sent out
<daveshah> The 4221 is just a transmitter
<merskiasa> daveshah, I know
<daveshah> basically just follow what rqou says
<merskiasa> rqou, I am probing the FSK pin (16)
<merskiasa> ?
<rqou> which channel is that?
<rqou> in your screenshot?
<merskiasa> Pin 16 on 4221
<merskiasa> first channel
<merskiasa> <merskiasa> The first channel looks like the data captured from the FSK pin (data that will modulate the carrier).
<merskiasa> <merskiasa> The second channel looks like a SPI data line, and the last one is likely the chip select line.
<rqou> channel 0 in your VCD?
genii has quit [Remote host closed the connection]
<merskiasa> yes
<rqou> what are the other channels?
<merskiasa> SPI data line
<merskiasa> chip select line
<rqou> are you sure this isn't just NRZI?
<merskiasa> it seems you didn't capture the SPI clock. That's why the software had troubles decoding the SPI data.
<merskiasa> I*
<merskiasa> rqou, how so?
<rqou> i see ~two different pulse widths in channel 0
<rqou> which usually makes me guess "some kind of self-clocking code"
<merskiasa> rqou, so how would I write code to convert the FSK logic trace into a stream of bits?
<rqou> step 1: figure out exactly what kind of self-clocking code it is :P
<merskiasa> HOw exactly?
<rqou> by guessing and seeing if it makes sense? typical RE process
<rqou> merskiasa: this is probably just manchester coding
<rqou> but i'm having trouble getting any of my usual tools to decode it for me
<rqou> ping azonenberg
<rqou> got a tool for this in your scopeclient?
<azonenberg> rqou: i have a 10baseT decoder that contains a manchester decoder but it's not usable standalone
<azonenberg> would probably be a 15-minute refactor
<rqou> lol, so same problem as sigrok
<azonenberg> i do plan to fix that
<azonenberg> Since the architecture is that of a filter pipeline
<azonenberg> it makes sense to be separate stages
<rqou> actually this isn't manchester
<rqou> it's probably some kind of NRZ
<rqou> so merskiasa, do you want to continue down the blackbox technique or do you want us to teach you some much more hardcore techniques? :P
<rqou> (obviously ymmv with these)
<rqou> merskiasa: the testpoints on the battery side are almost certainly ICSP, have you tried them?
Lord_Nightmare2 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 256 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
<rqou> merskiasa: if the PIC is protected, it may be vulnerable to power glitching (although none of us here have yet reported successfully duplicating this)
<rqou> azonenberg: do you have any ideas about how distributed ram is normally implemented?
<rqou> e.g. you can't have just 16 bits of distributed ram, can you?
<rqou> where would the control signals come from?
<sorear> how many fpgas do we have netlist recovery or netlist osint for?
<azonenberg> rqou: there's extra signals for it
<azonenberg> iirc in a xilinx chip, you use the lut inputs as A[3:0] or A[5:0]
<azonenberg> Q is the normal LUT output
<azonenberg> I don't know where D/CLK/WE come from
<rqou> sorear: afaik just xc2c32a
<rqou> azonenberg: well, that's the part i was wondering too :P
<azonenberg> rqou: um, we have ice40
<daveshah> azonenberg: ecp5 uses another LUT for them
<rqou> netlist recovery?
<azonenberg> daveshah: yes i think some xilinx parts do too
<azonenberg> rqou: oh you mean gate level, not bitstream level
<azonenberg> yeah just 2c32a
<daveshah> effectively it passes the write data and address and control signals through into the DPRAM
<rqou> that's what i assumed sorear meant
<rqou> oh wait, we have it for xc4000 too
<rqou> thanks ken schriff
<rqou> oh shit
<rqou> i hope that was supposed to be public
<rqou> well, it was presented at MTVRE, so i guess semi-public at least
<rqou> oh and i apparently cannot spell
<rqou> sorry ken shirrif
<rqou> what am i looking at?
<rqou> you should really try *) figuring out what kind of NRZ-like code it is *) try the testpoints
* sorear wonders about distributed ram, but also wonders about regular luts
<rqou> what about regular luts?
<sorear> how implemented. is it just a mux tree driven by the inputs selecting an output from 16/64 sram cells?
<rqou> probably
<azonenberg> most likely yes
<azonenberg> in particular, it's normally *not* a classical sram row decoder
<azonenberg> with sense amps etc
<sorear> how glitchy are fpga luts?
<azonenberg> because those are too bulky and dont make sense for only a few bits
<azonenberg> They're not guaranteed glitch-free
<azonenberg> FPGAs are not really meant for async logic
<azonenberg> sorear: normally in a "classic" SRAM you have a differential readout bus then a sense amp
<rqou> i have _definitely_ seen glitches in S3
<daveshah> yes, synthesis won't guarantee glitch free logic either
<azonenberg> meanwhile config cells, while they're still 6T SRAM
<azonenberg> will actually have one leg or the other of the inverter loop driving some logic
<azonenberg> The differential bus is still there, and used for writes as the chip loads the bitstream
<sorear> i've read most of your cs252 and whatnot materials, i have some basic idea what srams looked like when the last generation of teachers studied
<azonenberg> the smallest one i've looked at in any detail was spartan3a which is 90 nm
<sorear> i guess the bus is also used for readback?
<azonenberg> those are still textbook 6T H[-]H structures
<azonenberg> i have seen litho optimized sram in MCUs, and spartan6 and newer probably use it
<azonenberg> but i havent delayered any of those
<azonenberg> Yes, it's used for readback too
<sorear> is any of the spartan3a info public?
<azonenberg> I didnt do extensive RE
<azonenberg> i stripped one die to bare silicon
<sorear> what does "litho optimized" mean? custom cells with the textbook topology, or an entirely different circuit?
<azonenberg> there's optical photos on siliconpr0n
<azonenberg> Standard 6T topology but with all parallel lines
<azonenberg> on the poly layer
<azonenberg> no curves or 90-degree bends or anything
<azonenberg> More amenable to double patterning etc
<azonenberg> The nfets are a solid bus and the pfets look kinda like -_-_-_
<azonenberg> in a line alternating
<azonenberg> staggered like bricks
<azonenberg> The textbook 6T physical layout is the H[-]H pattern
<azonenberg> Which requires 2D rather than 1D features on the poly and STI layers
<azonenberg> i.e. arbitrary polygons vs just rectangles
<sorear> well you can't have a big rectangle of optimized sram because it needs to be mixed with muxes and fixed functions
<azonenberg> well yes
<azonenberg> But they may use the same litho optimized bit cell layout
<azonenberg> i'm not sure
<azonenberg> The xc2c32a has three different sram cell layouts in different parts of the die
<azonenberg> All look hand tuned for that location
<azonenberg> FPGAs in general are not standard foundry cells
<azonenberg> its mostly full custom
<azonenberg> if there's any autorouted standard cells it's in boot logic, hard IP, etc
<azonenberg> but the LUT fabric, routing, etc is likely going to be full custom
<sorear> i'd assume the fabric is done custom because it's so simple and repetitive, but boot/jtag/security/etc logic would still wind up synthesized
<sorear> yeah
<rqou> azonenberg: you should inject your comments about the coolrunner-ii security claims at this point :P
<azonenberg> rqou: i havent broken it yet
<azonenberg> I dont know for certain whats going on
<sorear> is that a flash/fuse part, flash/fuse+sram part, or sram-only part?
<azonenberg> eeprom+sram
<azonenberg> it's 2T EEPROM cells, not 1T flash
Miyu has joined ##openfpga
<sorear> what's the startup latency look like?
<azonenberg> It's pretty fast, sub millisecond iirc
<azonenberg> the eeprom is super wide
<azonenberg> in the 2c32a it's 260 bits x 49 rows
<azonenberg> So you load the entire fabric one row at a time
<azonenberg> as opposed to something like the spartan3an's, which were the competing nonvolatile FPGA
<azonenberg> Which was just a spartan3a with an atmel dataflash wirebonded on top of the die :p
<azonenberg> So it's still spi, but from in package
Hamilton has joined ##openfpga
<merskiasa> <rqou> merskiasa: the testpoints on the battery side are almost certainly ICSP, have you tried them? // which testpoints?
<merskiasa> can you highlight them for me
<rqou> they're labeled )V, TP4X, TP1X, TP3X
<rqou> *0V
<rqou> and probably one more under the sticker
<merskiasa> rqou, also the image check im getting decoded protocols
<merskiasa> "The initial (idle) state of the CLK line does not match the settings."
<merskiasa> I have a GoodFET42 that do ISCP programming
<merskiasa> also have a pickit3
<rqou> yeah, use a multimeter to try and match up the ICSP pins to the testpoints and then try a pickit3
<merskiasa> rqou, continuity mode?
<rqou> yeah
<merskiasa> i only hav linux tho
<merskiasa> im on linux*
<rqou> MPLABX supports linux?
<azonenberg> yes
<merskiasa> It doesnt supportt this
<merskiasa> PICkitâ„¢ 3 Standalone Programmer Application
<rqou> are you sure your wires are connected properly?
<merskiasa> 0.51778775SPIMOSI: '0' MISO: '128'
<merskiasa> decoded protocols
<merskiasa> ill show ou its a tight fit lol
<merskiasa> with the pins and connectors
<rqou> wut
<rqou> those aren't the wires for ICSP
<rqou> are you still trying to sniff the data or are you trying to dump the firmware like i suggested?
<merskiasa> sniff data
<merskiasa> thought thats what u asked for
<rqou> i really suggest you just try icsp
<rqou> try and extract the firmware
<merskiasa> Heart of Darkness attack?
<merskiasa> This is a newer PIC its patched that attack
<rqou> are you sure it's even read-protected?
<merskiasa> As the PICkit2 programmer system has an unbearableamount of layers, it seems difficult to modify its software stackto transmit the custom ICSP bulk erase and flash commandsneeded.A quick solution was to use a FTDI TTL-232R-5V-WERS-232 cable6to emulate a PIC programmer. These cablescontain a USB to serial interface connector, but exploit aunique feature of the included FT232R chip: all five cable endscan be freely
<merskiasa> configured as inputs or outputs. This mode iscalled Synchronous Bit Bang Mode7and allows to accuratelysimulate the programmer timing.
<merskiasa> its fuse bit are set
<merskiasa> check the datasheet
<merskiasa> it has keeloq too
<rqou> its fuse bits are definitely set?
<merskiasa> im pretty surer they are
<rqou> you should make sure
<merskiasa> its a rolling code garage
<rqou> sometimes vendors forget :P
<merskiasa> remote
<rqou> anyways, to fix your sniffing
<rqou> you really just need to guess what kind of NRZ-whatever it is using
<rqou> nothing to do with FSK
<rqou> basically compare with NRZI and all of the other forms and see if anything matches
<merskiasa> with a program?
<rqou> or a pencil :P
<rqou> i'm just too lazy to go do it
<merskiasa> what program or script does it?
<merskiasa> cbf with pencil :P
<rqou> i haven't found one that actually works
<merskiasa> easy to write a script?
<rqou> but basically i can see in your waveforms that there is a repeating pattern of 01010101 at the beginning of every transmission
<rqou> that's probably to sync up the receiver
<rqou> the particular bit patters hint at some kind of NRZ-whatever
<rqou> so every two bit widths (i.e. the total duration of one pair of those 01) encodes one actual bit
<rqou> if i load your waveform in sigrok it claims that every pair of 01 bits is 93 us
<merskiasa> rqou, of my new waveforms?
<rqou> the one you posted a vcd of
<rqou> QzLBCBQq on pastebin?
<rqou> anyways, my guess is that the coding they are using is the type where "no transition in the middle is 0, a transition in the middle is 1"
<merskiasa> rqou, load up this new one: https://pastebin.com/pTp9K4KJ
<merskiasa> this one i added the clock pin
<rqou> anyways, assuming i didn't mess it up, the first few bits of your old vcd are probably 1111 1111 1111 0101 0110 0111
<rqou> (or the inverse)
<merskiasa> rqou, try my new pastebin
<rqou> i assume channel 1 is now the data pin?
<rqou> yeah, it starts with the same bit pattern
<rqou> anyways, if you want to work on decoding this, i would recommend importing your vcd into sigrok pulseview
<rqou> and writing/modifying your own decoder
<merskiasa> for some reason pulseview doesnt work on my machine
<merskiasa> i use gtkwave
<rqou> well, yell at esden :P
<merskiasa> will gtkwave do?
<rqou> it's much more primitive
<rqou> doesn't really have a framework for implementing decoders
<merskiasa> damn any others?
<rqou> i've never used any others
<rqou> do you at least somewhat understand what i was trying to explain about how to decode the bits?
<merskiasa> <rqou> if i load your waveform in sigrok it claims that every pair of 01 bits is 93 us
<merskiasa> dont understand wehat you mean by that
<rqou> every transition starts with an alternating high-low-high-low pattern that repeats a whole bunch
<rqou> the total duration of one high and one low is 93 us
<rqou> which is probably the time it takes to send one "actual" bit
<merskiasa> can you screenshot me what your pulseview looks like
<merskiasa> oh i seee
<rqou> so basically you need to measure out 93 us intervals
<rqou> and if there's a transition (high->low or low->high) in the middle then it represents a 1 (or maybe 0)
<rqou> whereas if there isn't a transition it represents a 0 (or maybe 1)
<rqou> this is a reasonably common encoding scheme
<rqou> it allows the receiver to measure how fast the transmitter is transmitting bits by measuring the initial repeating high-low transitions
<rqou> and in then every "actual" bit has at least one transition in it (either in the middle or at the end of the interval)
<merskiasa> So what did you work out the bitstream to be?
<rqou> heh i only worked out those bits i pasted earlier
<rqou> since i'm about to go to bed
<rqou> it's super late here
<rqou> anybody else in a different timezone want to take over the explanation of NRZI and/or general "how to RE hardware" questions?
<rqou> daveshah?
<daveshah> sure
* rqou zzzzz
<daveshah> merskiasa: I agree with rqou this looks like NRZI
<daveshah> merskiasa: I think what you are dealing with is "NRZ-M" there
<merskiasa> this one better?
<daveshah> merskiasa: yeah, I think that looks ok too
<merskiasa> daveshah, { my $state = 0; sub nextbit { my ($bit) = @_; $state = !$state if $bit; return $state; } }
<merskiasa> Does that work in my case?
<daveshah> yes, I think that looks right
keesj has joined ##openfpga
m_w has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
genii has joined ##openfpga
Bike has joined ##openfpga
Hamilton has quit [Ping timeout: 260 seconds]
rohitksingh has joined ##openfpga
m_w has quit [Quit: leaving]
massi has quit [Remote host closed the connection]
m_w has joined ##openfpga
<kc8apf> FYI: I'm leaving Google at the end of the week. I'll continue working on FPGA things on my own.
digshadow has quit [Ping timeout: 256 seconds]
rvense has quit [Read error: Connection reset by peer]
rvense has joined ##openfpga
pie__ has quit [Ping timeout: 240 seconds]
<shapr> kc8apf: taking a break? or going elsewhere?
rohitksingh1 has joined ##openfpga
rohitksingh has quit [Ping timeout: 240 seconds]
<kc8apf> going elsewhere
Hamilton has joined ##openfpga
pie__ has joined ##openfpga
rvense has quit [Quit: leaving]
azonenberg_work has quit [Ping timeout: 260 seconds]
wpwrak has quit [Ping timeout: 240 seconds]
azonenberg_work has joined ##openfpga
pie__ has quit [Ping timeout: 264 seconds]
Hamilton2 has joined ##openfpga
pie__ has joined ##openfpga
Hamilton has quit [Ping timeout: 248 seconds]
rohitksingh1 has quit [Quit: Leaving.]
m_w has quit [Quit: Leaving]
wpwrak has joined ##openfpga
m_w has joined ##openfpga
m_t has joined ##openfpga
Hamilton2 has quit [Quit: Leaving]
digshadow has joined ##openfpga
pie__ has quit [Ping timeout: 264 seconds]
pie_ has joined ##openfpga
vup has joined ##openfpga
ym has quit [Remote host closed the connection]
digshadow has quit [Ping timeout: 268 seconds]
Miyu has quit [Ping timeout: 255 seconds]
bitd has quit [Ping timeout: 240 seconds]
ym has joined ##openfpga
pie_ has quit [Ping timeout: 264 seconds]
ZombieChicken has joined ##openfpga
specing has quit [Quit: ZNC - http://znc.in]
digshadow has joined ##openfpga
pie_ has joined ##openfpga
m_t has quit [Quit: Leaving]
Bike has quit [Ping timeout: 260 seconds]
Bike has joined ##openfpga
<balrog> doesn't seem like a synthesizer though
<rqou> yeah, known for quite a while
<rqou> doesn't seem complete nor designed for synthesis
<awygle> "aiming for 2002 compliance" seems odd in a project started in 2011
<awygle> that's really cool though, thanks balrog
specing has joined ##openfpga
ZombieChicken has quit [Ping timeout: 250 seconds]
ZombieChicken has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga