<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]
<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
<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
<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>
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>
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"