erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
nerozero has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
wingsorc has quit [Ping timeout: 252 seconds]
Haohmaru has joined #openocd
wingsorc has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
<borneoa_>
PaulFertser: hi Paul, build.openocd.org did not triggered the clang build after my last merges yesterday. I just login to trigger the build manually but there is a red banner "Jenkins is going to shut down". Is it normal?
PsySc0rpi0n has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
<PaulFertser>
borneoa_: no, not normal.
<borneoa_>
PaulFertser: can I trigger the build, or should I wait?
<PaulFertser>
borneoa_: I'd try to trigger
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
erhankur has quit [Remote host closed the connection]
merethan_ has joined #openocd
erhankur has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
merethan_ has quit [Remote host closed the connection]
merethan_ has joined #openocd
merethan_ has quit [Remote host closed the connection]
merethan_ has joined #openocd
<kaichiuchi>
PaulFertser: i have returned
<PaulFertser>
kaichiuchi: welcome back
<kaichiuchi>
okay, i'm going to try attaching via gdb now
<PaulFertser>
kaichiuchi: is that connecting to a normally running target?
<kaichiuchi>
yes
<kaichiuchi>
if I hook this up to IAR it works no problem
<kaichiuchi>
if I hook absolutely nothing up to it it works no problem
<PaulFertser>
So the firmware stops running the moment you start OpenOCD?
<kaichiuchi>
yes
<kaichiuchi>
and I don't think we're doing any fancy protection whatsoever
<PaulFertser>
Hm, and if you attach with GDB and use "file /path/to/your.elf" and do "backtrace"?
<kaichiuchi>
standby
<kaichiuchi>
(this might take me a bit as I had readout protection enabled, which is part of the test)
<PaulFertser>
kaichiuchi: why do you need to attach a debugger if readout protection is enabled?
<kaichiuchi>
okay, in short we're testing to see if we're vulnerable to readout protection being defeated on STM32Fx MCUs
<kaichiuchi>
so I flashed our unit and turned on readout protection, and the exploit code is calling for OpenOCD
<kaichiuchi>
unfortunately, openocd is encountering double faults
<kaichiuchi>
so now I need to disable readout protection, reflash, and *then* gdb
<kaichiuchi>
because of course, gdb can't read anything with readout protection enabled.
<PaulFertser>
Then you can assume it's not vulnerable without tweaks :)
<kaichiuchi>
this doesn't explain why when attaching in IAR it doesn't complain
<PaulFertser>
Yes, that's still a mystery.
<karlp>
does IAR _do_ anything though? oir is it jsut "not complaining" ?
<karlp>
this might be just a presentation difference?
<kaichiuchi>
good question
<kaichiuchi>
here's what I know from a high level: openocd says "double fault" resetting doesn't work at all, IAR I can just hook it up, hit "go" and it works
<kaichiuchi>
obviously, that doesn't answer the question but it's all I know at the moment
<kaichiuchi>
hhe
<kaichiuchi>
heh*
<PaulFertser>
kaichiuchi: are you physically glitching the target or is exploit software-only?
<kaichiuchi>
this unit is an STM32F4 but the trouble begins *long* before we try the exploit
<PaulFertser>
kaichiuchi: but that's for a different family
<kaichiuchi>
yes
<kaichiuchi>
but i've been ordered to try and test it anyway
<PaulFertser>
RDP is implemented differently ythere
<PaulFertser>
Why can't you just assume f4 readout protection can be bypassed for real cheap using voltage glitching and that's it?
<kaichiuchi>
look
<kaichiuchi>
these things are not my call whatsoever
erhankur has quit []
<PaulFertser>
Huh?
<kaichiuchi>
what I am doing now, the reason for me being here, is because I've been told to try and get openocd to connect to our unit
<PaulFertser>
I mean if we know all stm32 families are vulnerable to a relatively cheap and simple well-known attack why would anyone bother?
<kaichiuchi>
i don't disagree
<kaichiuchi>
i'm only doing what I was told to do so I can continue to put bread on the table
<PaulFertser>
That f1 attack won't work on f4, that's already established...
<kaichiuchi>
it probably won't
<kaichiuchi>
listen, I agree with everything you're saying
<kaichiuchi>
but this isn't a hobby project
<PaulFertser>
So can OpenOCD connect when readout protection is not enabled?
<kaichiuchi>
this is "please help me so I can give something, anything to my boss"
<kaichiuchi>
i'm testing that now
<kaichiuchi>
yeah, heh, readout protection kills it
<karlp>
what does "IAR I can just hook it up, hit "go" and it works" "works" mean in that sentence? that you can read out your code? or that it doesn't complain?
<kaichiuchi>
i can read out the code, doesn't complain, and I can debug like anything else
<kaichiuchi>
but I think this is partially my fault
<PaulFertser>
Read the code with IAR when readout protection is active?
<kaichiuchi>
yeah, that's my bad
<kaichiuchi>
too stressed out
<kaichiuchi>
both work of course when readout protection isn't enabled
<karlp>
so. to summarize. everything is as expected, thanks for everybody's time?
<kaichiuchi>
probably, looks like STM32F4 is doing what it's supposed to do
<kaichiuchi>
so, summarize: yes sorry
<kaichiuchi>
:(
<PaulFertser>
But tell your boss there's a relatively cheap hardware attack.
<karlp>
no problem :) jus don't want to keep chasing anything.
<kaichiuchi>
PaulFertser: yeah, which is even worse
<karlp>
no, it's simple.
<karlp>
you stopw asting time trying to reproduce irrelevant sw attacks.
<karlp>
and focus on the rest of the system not assuming that readout protection is reliable.
<kaichiuchi>
the real crux of the problem is we're using STM32F1s for a major product
<kaichiuchi>
and.. people are nervous
<karlp>
didyou make a system where people breaking one device break the entire ecosystem? no? then don't worry.
<karlp>
yes? then you alreadyd had problems, nothing's changed :)
<kaichiuchi>
yeah pretty much
<kaichiuchi>
that's my take on it
<PaulFertser>
kaichiuchi: just do not count on RDP, that's it. It's well known for years that MCU security just doesn't work that way.
<kaichiuchi>
right
<PaulFertser>
Some vendors don't even try to implement it in a robust way (remember the nrf51 exploit?).
<kaichiuchi>
nope
<kaichiuchi>
(frankly I'm a bit new to this type of embedded work)
<karlp>
convince your boss that you can never protect it from an attacker with physical access, and to spend valuable dev hours on features and functions that keep the customer coming to you...
<kaichiuchi>
our only saving grace is even if you manage to break the RDP the firmware is encrypted
<PaulFertser>
Since firmware runs it means it was decrypted by the device itself, so the CPU had access to the decryption key so that can be dumped too.
merethan_ has quit [Remote host closed the connection]
merethan_ has joined #openocd
<PaulFertser>
kaichiuchi: "How I hacked a hardware crypto wallet and recovered $2 mi..." https://www.youtube.com/watch?v=dT9y-KQbqi4 this video might be fun to watch for a non-engineer I guess.
Guest49 has joined #openocd
Guest49 has quit [Client Quit]
Haohmaru has quit []
nerozero has quit [Ping timeout: 272 seconds]
HelloShitty has quit [Ping timeout: 252 seconds]
wingsorc has quit [Quit: Leaving]
shibboleth has joined #openocd
HelloShitty has joined #openocd
jancoow has quit [Ping timeout: 260 seconds]
merethan_ has quit [Ping timeout: 246 seconds]
shibboleth has quit [Quit: shibboleth]
wingsorc has joined #openocd
renrelkha has quit [Quit: bye]
renrelkha has joined #openocd
<karlp>
I've done ./configure --prefix=/home/karlp/.local like "normal" and after install, I have all the scripts correctly installed at ~/.local/share/openocd/scripts,
<karlp>
does that ring any bells? it doesn't appear to be related to anythin in this branch'es code at least, but I'm going to go and rebuild another branch to be sure :|