IRC log for #qi-hardware on 20170405

00:22.41*** join/#qi-hardware infobot (ibot@rikers.org)
00:22.41*** topic/#qi-hardware is Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben/atusb 802.15.4 wireless, anelok and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware
00:22.41*** mode/#qi-hardware [+v infobot] by ChanServ
01:23.33*** join/#qi-hardware sb0 (~lekernel@210006059234.ctinets.com)
01:27.46*** join/#qi-hardware eightdot (~eightdot@customer-212-084-140-031.solcon.nl)
01:30.24*** join/#qi-hardware eightdot (~eightdot@customer-212-084-140-031.solcon.nl)
04:55.10*** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg)
05:26.59*** join/#qi-hardware sb0 (~lekernel@59.152.213.90)
07:38.53*** join/#qi-hardware wej (j@gateway/vpn/mullvad/x-ibzrtjjwxfexdbuz)
09:25.14*** join/#qi-hardware pcercuei (~paul@137.71.226.54)
11:53.09*** join/#qi-hardware sb0 (~lekernel@210006059234.ctinets.com)
12:20.17*** join/#qi-hardware erichvk (~esh@ppp14-2-88-63.lns21.adl6.internode.on.net)
15:52.31DocScrutinizer05https://www.silabs.com/documents/login/data-sheets/efr32bg1-datasheet.pdf  interesting BT/130-950MHz transmitter
15:53.09DocScrutinizer05http://www.digikey.com/product-detail/en/EFR32BG1P233F256GM48-C0/336-3710-ND/6057206
16:02.46wpwrakno register-level documentation for the radio transceiver. the competition (nordic) can do better
16:06.15DocScrutinizer05quite possible. I was amazend by the "sub-GHz feature" aka 130 to 950MHz, with RX sensitivity up to -120dB and TX +19dB
16:07.19DocScrutinizer05comes with 2.4GHz custom TRX too aiui
16:08.32DocScrutinizer05RFSENSE
16:09.14wpwrakyeah, they have a lot of combinations. but all the RF hidden behind their binary-only firmware
16:09.44DocScrutinizer05err well, aiui you can at least define your own firmware on top
16:10.08DocScrutinizer05for arbitrary protocols at almost arbitrary frequencies
16:10.44DocScrutinizer05so maybe they just have a higher abstarction level on their API
16:11.30DocScrutinizer05only had a cursory look
16:11.59wpwrakwell yes, you can run your own application. but you can't replace their proprietary radio firmware. (unless you decompile it, etc.)
16:12.30DocScrutinizer05yeah well, do you need to?
16:13.39wpwrakit'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 it
16:14.12DocScrutinizer05do 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*: 0x352000
16:16.05DocScrutinizer05no 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 want
16:16.48wpwrakyeah, open source is just a waste of time ;-)
16:18.07DocScrutinizer05not really, but you don't have open source in any eMMC or uSD or any other such subsystem either
16:19.21DocScrutinizer05nor for example for the controller in an accelerometer chip
16:20.45DocScrutinizer05sure 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:21.20whitequarkactually I demand the source to my eMMC too
16:21.26DocScrutinizer05for me the question is if it lets me do what I want
16:21.29whitequarkyou can put rather nice backdoors into them
16:22.20DocScrutinizer05backdoor doing what?
16:23.05DocScrutinizer05chnage random bits in your data?
16:24.24DocScrutinizer05on a HDD I still could see it tainting the bootloader which is usually found on the HDD
16:25.20DocScrutinizer05I have a relatively hard time figuring an exploit from uSD FTL
16:27.26DocScrutinizer05for that Blue Gecko I see a scenario where it activates 933MHz to leak your BT data unencryted to an attacker
16:27.27whitequarkpeople boot from uSDs too...
16:27.38whitequarkin fact if you stick a uSD in your PC chances are it might to try to boot from it
16:27.45whitequarkand don't forget UEFI exploits and stuff
16:27.52DocScrutinizer05yes, but the target platform is way too diversified
16:28.27DocScrutinizer05ok, on PC it's a valid concern
16:34.59DocScrutinizer05anyway 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 HAL
16:37.31DocScrutinizer05it'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 liniter
16:37.41DocScrutinizer05PSU*
16:40.40DocScrutinizer05maybe 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 rate
16:41.14DocScrutinizer05or maybe they actually offer I/Q access to the radio
16:42.57DocScrutinizer05I don't really need the drivers for the ADC and DAC to be FOSS
16:43.30DocScrutinizer05as long as there's a nice API to access/provide the I/Q data
16:49.05DocScrutinizer05gonestly who cares e.g for the details how to program the PLL to generate the upmix frequency, or how they tune their RF filters
16:56.43DocScrutinizer05>> 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:59.59DocScrutinizer05>> 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:<<
17:01.10wpwrakDocScrutinizer05: 1) you can't fix bugs, including security issues, in the proprietary library, 2) worse, you can't audit the library
17:01.18*** join/#qi-hardware tavish (~tavish@unaffiliated/tavish)
17:01.35DocScrutinizer05security issues?
17:02.06wpwrakbuffer overruns or whatever
17:02.11DocScrutinizer05isn't security a task of the protocol layer YOU the user have to implement?
17:04.38DocScrutinizer05http://susepaste.org/9793627
17:05.20*** join/#qi-hardware _whitelogger (~whitelogg@uruz.whitequark.org)
17:05.20*** mode/#qi-hardware [+v _whitelogger] by ChanServ
17:05.29DocScrutinizer05sure there's theoretically a possibility for a buffer overflow in CRC algo
17:05.58DocScrutinizer05or in bit shuffler, or whatever
17:07.59DocScrutinizer05and yes, obviously they keep their BT radio stack sekrit, so you couldn't fix security issues in _that_ protocol
17:20.49*** join/#qi-hardware whitequark (~whitequar@uruz.whitequark.org)
17:21.13whitequarkDocScrutinizer05: theoretically?
17:21.47whitequarkDocScrutinizer05: 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.html
17:21.54DocScrutinizer05well, I don't actually know of any buffer in CRC
17:22.24DocScrutinizer05MEH wifi firmware. This is a SDR
17:22.39DocScrutinizer05it runs YOUR wifi firmware
17:22.42whitequarkcan your SDR act as a bus master?
17:22.47whitequarkthen you're screwed
17:22.55DocScrutinizer05hardly
17:23.09DocScrutinizer05depends on the firmware you implement in it, no?
17:23.14whitequarkwell exactly
17:23.27whitequarkI can make sure my stuff is fine, but not the vendor blob crap
17:23.38whitequarkand vendor blob crap is virtually universally *not* fine emphatically
17:23.41DocScrutinizer05freakin shit!!!
17:23.43whitequarkfull of trivial things like stack overflows
17:23.49DocScrutinizer05FUD
17:24.04DocScrutinizer05there is no firmware, period
17:24.05whitequarkprove it
17:24.07whitequarkwhat?
17:24.23DocScrutinizer05now we start from there
17:24.39DocScrutinizer05now up to you to prove mne wrong
17:24.45whitequarksigh
17:24.55DocScrutinizer05exactly!
17:25.03whitequarkokay nevermind
17:25.12DocScrutinizer05there's a hw SDR radio and an attached M4 core
17:25.13whitequarknot in the mood to split hairs today
17:25.52DocScrutinizer05maybe in the mood to have a look in the datasheet then?
17:26.48DocScrutinizer05I'm still trying to find out how to program that thing. But very obviously there *is* a way to program it
17:28.19DocScrutinizer05>> 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.21DocScrutinizer05consumption. 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.59whitequarkthe vendor blob that you have to link to your own M4 firmware to control the thing
17:29.42DocScrutinizer05ok, now we're talking. yes that's a bad implementation then
17:30.22whitequarklike if you strictly isolate the vendor blob behind a communication interface and do all important work on another core
17:30.33whitequarkthen it's fine inasmuch as possibly receiving junk or doctored data is fine
17:30.46DocScrutinizer05:nod:
17:30.55DocScrutinizer05there's only one core
17:31.05whitequarkI mean you can add another CPU to the system always
17:31.16whitequarkbut it's cost and latency and complexity
17:31.58DocScrutinizer05where is that blob available, and what's the documentation it comes withß
17:32.44DocScrutinizer05I mean, if it's only a 2k, or maybe even partially documented content, it might be bearable
17:33.05whitequarkyou could reverse-engineer it, sure
17:33.22whitequarkor you could even run some static analysis, if it never even uses any buffers of memory it's likely safe
17:33.38whitequarkno writes through calculated pointers
17:33.43DocScrutinizer05yep
17:34.06DocScrutinizer05ARM code is a bitch to disassemble but still feasible
17:34.32whitequarkhttps://siliconlabs.github.io/Gecko_SDK_Doc/efr32bg1/html/index.html
17:34.33whitequarkdocs
17:34.40DocScrutinizer05ta! :-)
17:35.48DocScrutinizer05LOL WTF?! https://siliconlabs.github.io/Gecko_SDK_Doc/efr32bg1/html/group__Parts.html inactive links for "register declaration"
17:35.57whitequarkhm
17:36.07whitequarkso I'm actually reading through their source
17:36.08whitequarkhttps://siliconlabs.github.io/Gecko_SDK_Doc/efr32bg1/html/ezradio__api__lib_8c_source.html#l00132
17:36.23whitequarkthis looks to me like they actually have another M? core in there
17:36.26whitequarkthat runs the radio firmware
17:36.49whitequarkhttps://siliconlabs.github.io/Gecko_SDK_Doc/efr32bg1/html/ezradio__comm_8c_source.html
17:36.54whitequarkit's connected via SPI
17:37.00whitequarkso no shared memory (I hope)
17:37.49whitequarkthat actually seems like a quite sane design
17:37.53whitequarksurpirsingly
17:38.09whitequarkI presume they have the same problem as smartphone vendors in the end...
17:40.49DocScrutinizer05:-)
17:41.52whitequarkohhhh
17:41.55whitequarkI think I understand now
17:42.21whitequarkoh, hm, no, not sure
17:42.27whitequarkit's not quite clear how the parts fit together
17:44.29whitequarkI'm being confused by some of the #defines
17:44.39whitequarkfor example, they mention 3-wire or 4-wire SPI
17:44.53whitequarkit seems absurd to use 3-wire SPI for on-chip communication
17:46.01whitequarkoh I see
17:46.16whitequarkyou can *also* get the *standalone* version of the RF front-end
17:46.34whitequarkso for that you might want to use 3-wire or 4-wire SPI, whereas on the fully integrated BG1 it just does on-chip communication
17:46.42whitequarkpresumably via 4-wire SPI in the SoC
17:47.01whitequarkI think?
18:01.28DocScrutinizer05sounds sane
19:34.32DocScrutinizer05https://en.wikipedia.org/wiki/EFM32
19:35.01DocScrutinizer05(nothing at all about tadio in there)
19:35.07DocScrutinizer05radio*

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.