<kanzure>
i don't see what decapping would help with in this case
<Sanky>
signed with a key we don't have
<kanzure>
i mean, the instruction set is probably known
<kanzure>
and with no roms there's no way to test whether or not the emulation actually works
<azonenberg>
anyway, judging by those specs you're probably looking at 65nm or smaller
<azonenberg>
Which is not a trivial project
<Sanky>
shrug, I'm not actually involved in the project I linked
<azonenberg>
for starters that means SEM time
<kanzure>
yes i imagine an SEM would be involved
<azonenberg>
and while i know how to use them, and have access to several, they're not exactly cheap
<Sync>
I guess there are cheaper attack vectors
<azonenberg>
the low-end one, which probably doesn't have sufficient resolution for 65nm stuff, is $45/hr for academic users
<kanzure>
i might have someone with access to a SEM but does it need to be on-site of the decapping?
<azonenberg>
the nice Zeiss in the cleanroom is $188.50/hr
<azonenberg>
and is the one you'd likely need to get this kind of resolution
<azonenberg>
The depackaging is trivial
<kanzure>
ok cool that's pretty cheap
<kanzure>
so what, 10 hours?
<azonenberg>
Would be hard to say
<azonenberg>
the other thing is you'd need to delayer
<azonenberg>
and analysis of the images would take a long time
<kanzure>
i assume analysis would be "upload the images to the interwebs, write some software, hope someone else is interested enough to figure this out too"
<azonenberg>
'the images' is a LOT of data
<kanzure>
a few terabytes?
<azonenberg>
also consider the time it takes to do each exposure
<azonenberg>
2048x1536 frame at slow scan is likely to be close to a minute per image
<azonenberg>
maybe more
<azonenberg>
let's say you want your smallest features to be 10 pixels so 65nm =10px comes out to 6.5nm/pix or about a 13 micron field of view, cut that down to about 10 microns of unique image per field since you need some overlap
<azonenberg>
so 10x5 just to be simple for estimates
<azonenberg>
that's 50 square microns of unique content per image, one minute per image
<azonenberg>
typical OMAP is about 60mm^2
<azonenberg>
60 million square microns for the whole die
<azonenberg>
that's around a million images
<Sync>
that is not viable
<azonenberg>
and that's for one layer of the chip
<azonenberg>
it'd come out to around 2.9TB of data per layer
<azonenberg>
about two months of SEM time if you use an optimistic ~6 second per frame exposure time, its likely to be al ot more
<azonenberg>
so yes, full chip imaging is nontrivial
<azonenberg>
Normally you're interested in a tiny fraction, say security bits
<Sync>
and then someone would have to reverseengineer it
<azonenberg>
so you can get a firmware dump
<azonenberg>
or you want to study the process technology in use
<azonenberg>
or look at the SRAM cell design
<azonenberg>
cloning an entire chip to netlist is nontrivial
<Sync>
yeah huge fun
<azonenberg>
now, the numbers i gave are probably off by a bit compared to what a nice profesisonal shop like chipworks could do
<Sync>
especially with newer chips that are designed with security in mind
kristianpaul has quit [Ping timeout: 252 seconds]
<azonenberg>
they do get full-chip images at transistor resolution
<azonenberg>
my guess is they have modified SEMs that can do automatic step-and-repeat with continuous scan
<azonenberg>
kind of like e-beam litho in reverse
kristianpaul has joined #homecmos
<azonenberg>
with one of those you could probably cover a full die at 1;1 resolution in the same time it'd take to e-beam a mask
<azonenberg>
so maybe a day or so per layer
<azonenberg>
Then you have to polish down and repeat
<azonenberg>
luckily the top layers are bigger feature sizes so you can do those faster
<azonenberg>
But then you have to register all of the images and analyze them which is nontrivial
<azonenberg>
to give you an idea of scale, me and my friend are working on two chips now to practice - the RSA SecurID and a 24C EEPROM made by ST
<Sync>
azonenberg: yes they have such SEMs
<kanzure>
i would probably spin up some ec2 servers to do the image analysis and dumping to netlist
<azonenberg>
both are maybe 10mm^2 and giant ~1 micron process technology
<Sync>
if you have multiple chips you just polish to all layers you need and pop them into the revolver
<azonenberg>
we have full chip images at full resolution of each
<azonenberg>
(optically)
<azonenberg>
optical imaging of a chip of that size takes us most of a day per layer
<azonenberg>
using automated step-and-repeat
<azonenberg>
and once you have the resulting gigapixel-sized image you need to crunch it, we're still working on automated tools for that
<azonenberg>
degate isnt reliable enough in our experience
<Sync>
degate worked pretty good for me
<kanzure>
oh i didn't expect something like that to exist
<azonenberg>
it's segfaulted a lot for me
<Sync>
but I only tried it on some sample images I found
<azonenberg>
when working on real data from the SecurID
<azonenberg>
i forget what version i've used, not sure if its any more robust now
<Sync>
ha my pu tubing arrived
<azonenberg>
plutonium? do i want to know?
<azonenberg>
this is not #homenukes
<Sync>
polyurethane :P
<azonenberg>
...oh
<azonenberg>
:p
* azonenberg
is a tiny bit less scared now :P
<Sync>
where the fuck would one get _tubes_ out of plutonium
<azonenberg>
i have no idea, i thought you meant like round bar stock or something
<azonenberg>
or reactor fuel pellets
<Sync>
they'd compliment my neutron counter nicely
<soul-d>
im celebrating with some fresh old coffee that my fpga vga code works :)
<azonenberg>
soul-d: lucky you
<azonenberg>
i'm staring down a deadlock :p
<azonenberg>
its sort of a race condition i guess, two clock domains are each running state machines and using handshake-based synchronizers to exchange data
<azonenberg>
if one tries to transmit and the other wants to receive, and the two operations overlap
<azonenberg>
they get stuck each waiting for the other to ACK
<azonenberg>
i need to split them into two state machines so i can do full duplex
<azonenberg>
(two per clock domain)
<soul-d>
yeah was some nasty things like clock being actualy a bus so it warned just somewhere about pin not having exact location
<azonenberg>
o_O
<soul-d>
but since it's a dev kit with loaded pin assignments im used to 400 warnings :P
<azonenberg>
in other news i have CMake working nicely with the Xilinx toolchain
<soul-d>
and ignoring them
<azonenberg>
so i can compile firmware, PC-side software, RTL simulations, and FPGA bitstreams with one "make" command :D
<Sync>
pneumatic quick connects ftw :)
<soul-d>
im using altera since i own 3 dev kits now and had orded some chips to
<azonenberg>
yeah, i have one xilinx dev board plus several that i made myself with xilinx chips
<azonenberg>
in any case i should probably get going since it's almost 12:30 and i want to grab lunch before my 14:00 class
<azonenberg>
(and i'm not even on campus yet)
<soul-d>
k, have a nice one :)
lekernel__ has quit [Ping timeout: 246 seconds]
lekernel has joined #homecmos
pbdq has joined #homecmos
soluvio has joined #homecmos
lekernel has left #homecmos ["Konversation terminated!"]
pbdq has quit [Ping timeout: 255 seconds]
soluvio has quit [Remote host closed the connection]
joehot has joined #homecmos
<azonenberg>
So i just found some obsolete masks someone here had made at laserlab
<azonenberg>
going to pop them under the microscope and look at mask quality
<soul-d>
fried my brain trying to think about how to do char rom / display memory
<soul-d>
i made it synthesyze somthing now lets see what ;) a line :P ah wel still displays somthing from some mem so can't complain much