<wpwrak>
no register-level documentation for the radio transceiver. the competition (nordic) can do better
<DocScrutinizer05>
quite possible. I was amazend by the "sub-GHz feature" aka 130 to 950MHz, with RX sensitivity up to -120dB and TX +19dB
<DocScrutinizer05>
comes with 2.4GHz custom TRX too aiui
<DocScrutinizer05>
RFSENSE
<wpwrak>
yeah, they have a lot of combinations. but all the RF hidden behind their binary-only firmware
<DocScrutinizer05>
err well, aiui you can at least define your own firmware on top
<DocScrutinizer05>
for arbitrary protocols at almost arbitrary frequencies
<DocScrutinizer05>
so maybe they just have a higher abstarction level on their API
<DocScrutinizer05>
only had a cursory look
<wpwrak>
well yes, you can run your own application. but you can't replace their proprietary radio firmware. (unless you decompile it, etc.)
<DocScrutinizer05>
yeah well, do you need to?
<wpwrak>
it'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
<DocScrutinizer05>
do 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
<DocScrutinizer05>
no 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
<wpwrak>
yeah, open source is just a waste of time ;-)
<DocScrutinizer05>
not really, but you don't have open source in any eMMC or uSD or any other such subsystem either
<DocScrutinizer05>
nor for example for the controller in an accelerometer chip
<DocScrutinizer05>
sure 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...
<whitequark>
actually I demand the source to my eMMC too
<DocScrutinizer05>
for me the question is if it lets me do what I want
<whitequark>
you can put rather nice backdoors into them
<DocScrutinizer05>
backdoor doing what?
<DocScrutinizer05>
chnage random bits in your data?
<DocScrutinizer05>
on a HDD I still could see it tainting the bootloader which is usually found on the HDD
pcercuei has quit [Quit: bbl]
<DocScrutinizer05>
I have a relatively hard time figuring an exploit from uSD FTL
<DocScrutinizer05>
for that Blue Gecko I see a scenario where it activates 933MHz to leak your BT data unencryted to an attacker
<whitequark>
people boot from uSDs too...
<whitequark>
in fact if you stick a uSD in your PC chances are it might to try to boot from it
<whitequark>
and don't forget UEFI exploits and stuff
<DocScrutinizer05>
yes, but the target platform is way too diversified
<DocScrutinizer05>
ok, on PC it's a valid concern
<DocScrutinizer05>
anyway 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
<DocScrutinizer05>
it'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
<DocScrutinizer05>
PSU*
<DocScrutinizer05>
maybe 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
<DocScrutinizer05>
or maybe they actually offer I/Q access to the radio
<DocScrutinizer05>
I don't really need the drivers for the ADC and DAC to be FOSS
<DocScrutinizer05>
as long as there's a nice API to access/provide the I/Q data
<DocScrutinizer05>
gonestly who cares e.g for the details how to program the PLL to generate the upmix frequency, or how they tune their RF filters
<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).<<
<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:<<
<wpwrak>
DocScrutinizer05: 1) you can't fix bugs, including security issues, in the proprietary library, 2) worse, you can't audit the library
tavish has joined #qi-hardware
<DocScrutinizer05>
security issues?
<wpwrak>
buffer overruns or whatever
<DocScrutinizer05>
isn't security a task of the protocol layer YOU the user have to implement?
_whitelogger has quit [K-Lined]
_whitelogger has joined #qi-hardware
<DocScrutinizer05>
sure there's theoretically a possibility for a buffer overflow in CRC algo
<DocScrutinizer05>
or in bit shuffler, or whatever
<DocScrutinizer05>
and yes, obviously they keep their BT radio stack sekrit, so you couldn't fix security issues in _that_ protocol
<DocScrutinizer05>
well, I don't actually know of any buffer in CRC
<DocScrutinizer05>
MEH wifi firmware. This is a SDR
<DocScrutinizer05>
it runs YOUR wifi firmware
<whitequark>
can your SDR act as a bus master?
<whitequark>
then you're screwed
<DocScrutinizer05>
hardly
<DocScrutinizer05>
depends on the firmware you implement in it, no?
<whitequark>
well exactly
<whitequark>
I can make sure my stuff is fine, but not the vendor blob crap
<whitequark>
and vendor blob crap is virtually universally *not* fine emphatically
<DocScrutinizer05>
freakin shit!!!
<whitequark>
full of trivial things like stack overflows
<DocScrutinizer05>
FUD
<DocScrutinizer05>
there is no firmware, period
<whitequark>
prove it
<whitequark>
what?
<DocScrutinizer05>
now we start from there
<DocScrutinizer05>
now up to you to prove mne wrong
<whitequark>
sigh
<DocScrutinizer05>
exactly!
<whitequark>
okay nevermind
<DocScrutinizer05>
there's a hw SDR radio and an attached M4 core
<whitequark>
not in the mood to split hairs today
<DocScrutinizer05>
maybe in the mood to have a look in the datasheet then?
<DocScrutinizer05>
I'm still trying to find out how to program that thing. But very obviously there *is* a way to program it
<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
<DocScrutinizer05>
consumption. 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?
<whitequark>
the vendor blob that you have to link to your own M4 firmware to control the thing
<DocScrutinizer05>
ok, now we're talking. yes that's a bad implementation then
<whitequark>
like if you strictly isolate the vendor blob behind a communication interface and do all important work on another core
<whitequark>
then it's fine inasmuch as possibly receiving junk or doctored data is fine
<DocScrutinizer05>
:nod:
<DocScrutinizer05>
there's only one core
<whitequark>
I mean you can add another CPU to the system always
<whitequark>
but it's cost and latency and complexity
<DocScrutinizer05>
where is that blob available, and what's the documentation it comes withß
<DocScrutinizer05>
I mean, if it's only a 2k, or maybe even partially documented content, it might be bearable
<whitequark>
you could reverse-engineer it, sure
<whitequark>
or you could even run some static analysis, if it never even uses any buffers of memory it's likely safe
<whitequark>
no writes through calculated pointers
<DocScrutinizer05>
yep
<DocScrutinizer05>
ARM code is a bitch to disassemble but still feasible