after spending 30 minutes fucking around with the grabber hooks (never use these. seriously. just solder a wire or something. you'll only short out your DUT with the hooks) i discovered that one of the connectors on the board actually just has SWD on it

? SWCLK GND SWDIO ?

also it seems to be a 1.8 V IO bank

nope i'm wrong, it just doesn't work properly on anything under 24 V (i'm not sure why i thought it would. bad assumptions)

and it's just a normal 3.3 V design

ok, new problem

it responds over SWD... sometimes

i _think_ the board is attempting to boot and in the process of that browning out and resetting itself. maybe the u-blox has some dead capacitors, maybe something else; this is difficult to diagnose. all i know the power LED seems to go out briefly every second and the SWD interface doesn't work consistently

conveniently they put NRST on the same debug connector

so it's

RESET SWDIO GND SWCLK ?

okay, it doesn't seem to brown out any more, and probe-rs no longer crashes with an SWD error

however, because enough ROM tables are in reset, i can't get `probe-rs info` to work

the problem with this is that this is an uhhhhhh very special device

jebani dostawcy

oops i was reading ITCM instead of Flash which is at 0x08000000

now _this_ looks like code (the very start of the firmware doesn't have anything interesting in it)

(holding "identifying firmware" book)

yep. that's firmware

based on strings in the firmware, it looks like it's using this exact STM32 bootloader

the bootloader repo is over 300 MB in size because they checked in a build of an Android app that you can use to reflash the thing

https://github.com/Embetronicx/STM32-Bootloader

perfect match

(the \n was probably chomped off by clang as it turned printf into puts. yes, this is a valid optimization it does)

besides one or two functions in the bootloader, there are no strings in the firmware

the application section is a 128K blob full of vector floating point instructions. this is going to be extremely challenging to reverse engineer

okay i think i know why it was unstable

remember that broken down capacitor that i removed? it was on the VIN pin of a TPS5430 buck converter. and TPS5430 really, _really_ wanted its VIN pin to be bypassed

looking at this firmware: it has no strings (except in the bootloader), very little structure i can recognize, and is basically a 128K sized blob of numeric code

i don't think it's one of the popular open-source firmwares. definitely not as-is, and probably not even a modified one; i would expect vtables, command parsers, stuff like that; none of it is there

when reverse-engineering embedded devices, i like to make these overlays

to make one yourself, open the datasheet screenshot in gimp, use "select by color" on the _black_ (this is important), grow the border by 1-3 px, copy the selection, paste onto a photo, and use universal transform until it matches

here's another one

i had to expand the u-blox symbol a bit since they didn't quite get the spacing right

for some reason people expect military firmware to do things like "code protection", "encryption", or "obfuscation"

they forget this firmware is usually made in a rush, by the lowest bidder, and (quite likely) by someone who doesn't really care about the craft

i have never seen any RE countermeasures

i played myself, the firmware doesn't actually use the SDMMC1 peripheral except to enable its power :/

and i'm fairly sure it's not being used with the SPI peripheral either, given PC8 is connected to DAT0/MISO

i've never seen resistor markings like this

are these jumpers?

i'm going to make a bet that nobody has tried to reverse-engineer Thumb code with VFP instructions in Binary Ninja before

i opened one trivial function and immediately found three bugs, one of which is a show-stopper

https://github.com/Vector35/binaryninja-api/issues/6945
https://github.com/Vector35/binaryninja-api/issues/6946
https://github.com/Vector35/binaryninja-api/issues/6947

implemented a glasgow applet for sniffing conversations over UART with accurate sequencing; this will be used for finding out how the MCU talks to the GPS module

https://github.com/GlasgowEmbedded/glasgow/pull/899

just realized that i can't exactly expect this device to work as intended right now, because it doesn't have its IMU

and it needs an IMU, alongside GPS, to know where it is

of _course_ this device pair is being annoying and switching UART speed at runtime

i didn't implement autobaud in uart-analyzer applet because i thought it 'would not be that important'. agh

adding proper autobaud is fairly tricky for the analyzer, but i did at least add per-channel baud (i.e. you can have different baud rates for RX and TX)

an online ublox protocol decoder (implemented e.g. as a script) could promptly switch baud rates when it observes a command to do so

i've reverse-engineered the entire state machine in the firmware. it only parses three messages! these are:

UBX-NAV-PVT
UBX-NAV-SOL
UBX-NAV-SAT

once again, the firmware is... simple. every part i can understand does exactly one thing, in the most uncomplicated way possible

@whitequark

UBX-NAV-PVT length = 92 bytes
UBX-NAV-SOL length = 52 bytes
UBX-NAV-SAT length = how many satellites can you see right now?

@chrisgj198 @jpm it overflows the buffer

i don't know how long it is exactly because it appears to never check the buffer but it's like half the module channel count

@chrisgj198 @jpm i could also just feed it the ublox binary messages; same result for less effort (with the caveat that i don't know if the ublox module will actually emit such long messages in any practical environment)

i _really_ don't want to mess with GNSS signals too much, since if they leak i'll get a not-so-friendly visit from Ofcom and it'll be 100% deserved