#qi-hardware IRC log for Wednesday, 2017-04-05

--- Wed Apr 5 201700:00
DocScrutinizer05https://www.silabs.com/documents/login/data-sheets/efr32bg1-datasheet.pdf  interesting BT/130-950MHz transmitter15:52
DocScrutinizer05http://www.digikey.com/product-detail/en/EFR32BG1P233F256GM48-C0/336-3710-ND/605720615:53
wpwrakno register-level documentation for the radio transceiver. the competition (nordic) can do better16:02
DocScrutinizer05quite possible. I was amazend by the "sub-GHz feature" aka 130 to 950MHz, with RX sensitivity up to -120dB and TX +19dB16:06
DocScrutinizer05comes with 2.4GHz custom TRX too aiui16:07
DocScrutinizer05RFSENSE16:08
wpwrakyeah, they have a lot of combinations. but all the RF hidden behind their binary-only firmware16:09
DocScrutinizer05err well, aiui you can at least define your own firmware on top16:09
DocScrutinizer05for arbitrary protocols at almost arbitrary frequencies16:10
DocScrutinizer05so maybe they just have a higher abstarction level on their API16:10
DocScrutinizer05only had a cursory look16:11
wpwrakwell yes, you can run your own application. but you can't replace their proprietary radio firmware. (unless you decompile it, etc.)16:11
DocScrutinizer05yeah well, do you need to?16:12
wpwrakit's nice if you can. nordic give you their blobs and register information. so you can get started quickly using their blobs, but have the choice to replace it, if you feel the need for it16:13
DocScrutinizer05do you want to deal with I/Q values and tuning registers when you can tell the thing "frequency: 433.258MHz, level:+10dB, moculation:256QAM, signal*: 0x35200016:14
DocScrutinizer05no idea what they really offer, but I guess when they offer custom 130-950 5band plus 2400MHz, they must have a way to talk to the radio so it sends exactly what you want16:16
wpwrakyeah, open source is just a waste of time ;-)16:16
DocScrutinizer05not really, but you don't have open source in any eMMC or uSD or any other such subsystem either16:18
DocScrutinizer05nor for example for the controller in an accelerometer chip16:19
DocScrutinizer05sure it would be nice to have the firmware that reads out the A/D converter registers and comparators in there and talks to the IRQ lines and I2C, but...16:20
whitequarkactually I demand the source to my eMMC too16:21
DocScrutinizer05for me the question is if it lets me do what I want16:21
whitequarkyou can put rather nice backdoors into them16:21
DocScrutinizer05backdoor doing what?16:22
DocScrutinizer05chnage random bits in your data?16:23
DocScrutinizer05on a HDD I still could see it tainting the bootloader which is usually found on the HDD16:24
DocScrutinizer05I have a relatively hard time figuring an exploit from uSD FTL16:25
DocScrutinizer05for that Blue Gecko I see a scenario where it activates 933MHz to leak your BT data unencryted to an attacker16:27
whitequarkpeople boot from uSDs too...16:27
whitequarkin fact if you stick a uSD in your PC chances are it might to try to boot from it16:27
whitequarkand don't forget UEFI exploits and stuff16:27
DocScrutinizer05yes, but the target platform is way too diversified16:27
DocScrutinizer05ok, on PC it's a valid concern 16:28
DocScrutinizer05anyway when that Gecko allows me implementing whatever protocol and modulation (out of the wide range of offered ones?) I want to implement on an arbitrary frequency between 130 and 950MHz or on 2400MHz, while I have control over TX level and even RFSENSE, then I'm not too worried when the actiual low level hardware control registers are hidden behind a blob firmware HAL16:34
DocScrutinizer05it's really sort of like blaming my lab PSZ for closed BLOB that doesn't allow me to directly access the DACs and ADCs or PWMs or whatever they use, and only provides USB access to control the voltage regulator and current liniter16:37
DocScrutinizer05PSU*16:37
DocScrutinizer05maybe direct I/Q access for the TRX would be even nicer, but then the question is if the ARM M4 could even cope with the needed sampling rate16:40
DocScrutinizer05or maybe they actually offer I/Q access to the radio16:41
DocScrutinizer05I don't really need the drivers for the ADC and DAC to be FOSS16:42
DocScrutinizer05as long as there's a nice API to access/provide the I/Q data16:43
DocScrutinizer05gonestly who cares e.g for the details how to program the PLL to generate the upmix frequency, or how they tune their RF filters16:49
DocScrutinizer05>> The EFR32BG1 uses a low-IF receiver architecture, consisting of a Low-Noise Amplifier (LNA) followed by an I/Q down-conversion mix- er, employing a crystal reference. The I/Q signals are further filtered and amplified before being sampled by the IF analog-to-digital converter (IFADC).<<16:56
DocScrutinizer05>> EFR32BG1 has an extensive and flexible frame handling support for easy implementation of even complex communication protocols. The Frame Controller (FRC) supports all low level and timing critical tasks together with the Radio Controller and Modulator/Demodula- tor:<<16:59
wpwrakDocScrutinizer05: 1) you can't fix bugs, including security issues, in the proprietary library, 2) worse, you can't audit the library17:01
DocScrutinizer05security issues?17:01
wpwrakbuffer overruns or whatever17:02
DocScrutinizer05isn't security a task of the protocol layer YOU the user have to implement?17:02
DocScrutinizer05http://susepaste.org/979362717:04
DocScrutinizer05sure there's theoretically a possibility for a buffer overflow in CRC algo17:05
DocScrutinizer05or in bit shuffler, or whatever17:05
DocScrutinizer05and yes, obviously they keep their BT radio stack sekrit, so you couldn't fix security issues in _that_ protocol17:07
whitequarkDocScrutinizer05: theoretically?17:21
whitequarkDocScrutinizer05: how about a functional over-the-air exploit of broadcom wifi firmware https://googleprojectzero.blogspot.ru/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html17:21
DocScrutinizer05well, I don't actually know of any buffer in CRC17:21
DocScrutinizer05MEH wifi firmware. This is a SDR17:22
DocScrutinizer05it runs YOUR wifi firmware17:22
whitequarkcan your SDR act as a bus master?17:22
whitequarkthen you're screwed17:22
DocScrutinizer05hardly17:22
DocScrutinizer05depends on the firmware you implement in it, no?17:23
whitequarkwell exactly17:23
whitequarkI can make sure my stuff is fine, but not the vendor blob crap17:23
whitequarkand vendor blob crap is virtually universally *not* fine emphatically17:23
DocScrutinizer05freakin shit!!!17:23
whitequarkfull of trivial things like stack overflows17:23
DocScrutinizer05FUD17:23
DocScrutinizer05there is no firmware, period17:24
whitequarkprove it17:24
whitequarkwhat?17:24
DocScrutinizer05now we start from there17:24
DocScrutinizer05now up to you to prove mne wrong17:24
whitequarksigh17:24
DocScrutinizer05exactly!17:24
whitequarkokay nevermind17:25
DocScrutinizer05there's a hw SDR radio and an attached M4 core17:25
whitequarknot in the mood to split hairs today17:25
DocScrutinizer05maybe in the mood to have a look in the datasheet then?17:25
DocScrutinizer05I'm still trying to find out how to program that thing. But very obviously there *is* a way to program it17:26
DocScrutinizer05>> The EFR32BG1 contains a high performance, low phase noise, fully integrated fractional-N frequency synthesizer. The synthesizer is used in receive mode to generate the LO frequency used by the down-conversion mixer. It is also used in transmit mode to directly generate the modulated RF carrier. The fractional-N architecture provides excellent phase noise performance combined with frequency resolution better than 100low energy 17:28
DocScrutinizer05consumption. The synthesizer has fast frequency settling which allows very short receiver and transmitter wake upoptimize system energy consumption. Hz, with times to optimize system energy consumption.<<  Where's the backdoor and the firmware here?17:28
whitequarkthe vendor blob that you have to link to your own M4 firmware to control the thing17:28
DocScrutinizer05ok, now we're talking. yes that's a bad implementation then17:29
whitequarklike if you strictly isolate the vendor blob behind a communication interface and do all important work on another core17:30
whitequarkthen it's fine inasmuch as possibly receiving junk or doctored data is fine17:30
DocScrutinizer05:nod:17:30
DocScrutinizer05there's only one core17:30
whitequarkI mean you can add another CPU to the system always17:31
whitequarkbut it's cost and latency and complexity17:31
DocScrutinizer05where is that blob available, and what's the documentation it comes withß17:31
DocScrutinizer05I mean, if it's only a 2k, or maybe even partially documented content, it might be bearable17:32
whitequarkyou could reverse-engineer it, sure17:33
whitequarkor you could even run some static analysis, if it never even uses any buffers of memory it's likely safe17:33
whitequarkno writes through calculated pointers17:33
DocScrutinizer05yep17:33
DocScrutinizer05ARM code is a bitch to disassemble but still feasible17:34
whitequarkhttps://siliconlabs.github.io/Gecko_SDK_Doc/efr32bg1/html/index.html17:34
whitequarkdocs17:34
DocScrutinizer05ta! :-)17:34
DocScrutinizer05LOL WTF?! https://siliconlabs.github.io/Gecko_SDK_Doc/efr32bg1/html/group__Parts.html inactive links for "register declaration"17:35
whitequarkhm17:35
whitequarkso I'm actually reading through their source17:36
whitequarkhttps://siliconlabs.github.io/Gecko_SDK_Doc/efr32bg1/html/ezradio__api__lib_8c_source.html#l0013217:36
whitequarkthis looks to me like they actually have another M? core in there17:36
whitequarkthat runs the radio firmware17:36
whitequarkhttps://siliconlabs.github.io/Gecko_SDK_Doc/efr32bg1/html/ezradio__comm_8c_source.html17:36
whitequarkit's connected via SPI17:36
whitequarkso no shared memory (I hope)17:37
whitequarkthat actually seems like a quite sane design17:37
whitequarksurpirsingly17:37
whitequarkI presume they have the same problem as smartphone vendors in the end...17:38
DocScrutinizer05:-)17:40
whitequarkohhhh17:41
whitequarkI think I understand now17:41
whitequarkoh, hm, no, not sure17:42
whitequarkit's not quite clear how the parts fit together17:42
whitequarkI'm being confused by some of the #defines17:44
whitequarkfor example, they mention 3-wire or 4-wire SPI17:44
whitequarkit seems absurd to use 3-wire SPI for on-chip communication17:44
whitequarkoh I see17:46
whitequarkyou can *also* get the *standalone* version of the RF front-end17:46
whitequarkso for that you might want to use 3-wire or 4-wire SPI, whereas on the fully integrated BG1 it just does on-chip communication17:46
whitequarkpresumably via 4-wire SPI in the SoC17:46
whitequarkI think?17:47
DocScrutinizer05sounds sane18:01
DocScrutinizer05https://en.wikipedia.org/wiki/EFM32 19:34
DocScrutinizer05(nothing at all about tadio in there)19:35
DocScrutinizer05radio*19:35
--- Thu Apr 6 201700:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!