internalblue VS flipperzero-firmware

I wonder how they deal with the channel hopping? I remember BT "Classic" derives the hoping sequence from the encryption key. Not sure if that changed significantly for BLE? So either they establish normal connections between relays and victims (meaning two keys, one between each relay and each victim), and then forward data coming out of the Link Layer between the attacker devices - or they need to sniff the whole spectrum in case there is just one key between car and fob.

Last time I checked, sniffing the full spectrum of BT required three SDRs, meaning six in total; making this attack rather expensive to pull off (no problem for professional thieves though, I guess). OTOH if they can use any BT stack (or manipulate it with e.g. InternalBlue[1]), potential carjackers just need two Android Phones and good WiFi :(

[1] InternalBlue: https://github.com/seemoo-lab/internalblue

Man I got really excited thinking this was about the Flipper Zero device https://flipperzero.one/

We use littlefs in Flipper Zero's firmware[1] for storage in leftover flash space after the main firmware image. Flipper implements a virtual FS, where both external SD card and internal storage have own mount points. SD card is used for storing apps and user-created data, and internal littlefs contains persistent data like BLE pairing, system services configs and such.

We never had any issues with littlefs - however, it cannot be easily repartitioned when amount of available leftover space changes with firmware updates. So on installing an update, it gets fully backed up to SD card, reformatted and later restored.

1- https://github.com/flipperdevices/flipperzero-firmware/blob/...

Issue opened.

It is used in FlipperZero with FreeRTOS to handle the data structure.