k0ngo

I guess I shouldn’t be surprised, but still fun to see that they’re apparently using an ESP32 as management processor (without antenna, probably just RMII directly to the switch ASIC)

Edit: there’s a RTL8201 10/100 PHY to the left of the switch asic, that connects the ESP to one of the switch ports.

Yeah, looks like it :(

I read out the patch data from two LPC55S69 I have at hand, and...

MCU Date Code: 2019-07-20: 11/16 slots used 2019-11-05: 14/16 slots used

Why can't NXP use the ROM patch mechanism (which was the cause of the previous vulnerability) to fix this? Was that all in vain?

This is very similar to the OtterCast, which is an open source and open hardware Chromecast replacement.

Overview: https://cast.otter.jetzt/ Sources: https://github.com/Ottercast

There's also a version with a built-in class D amplifier and color display. On the software side it's neatly packaged with a web UI for configuration, as well as support for snapcast (multiroom), airplay and pulseaudio besides spotify.

I'm not affiliated with them, just very tempted to build one.

I'm a big fan of Fabrice Bellard, but there are other eNB and UE implementations that are fully open source, like OpenAirInterface[1] and srsLTE[2]

[1] http://www.openairinterface.org

[2] https://github.com/srsLTE/srsLTE

The article doesn't mention it, but I think Fabrice Bellards PoC [1], in which he generated a valid DVB-T and PAL/SECAM carriers using a graphics card (2005), is very elegant and highly related prior art.

[1] https://bellard.org/dvbt/

I'd expect scp to detect (using argv[0]) that it is called through a symlink and behave as rcp, not scp. This is how busybox is implemented, with many programs in one binary.

I like the idea, but unfortunately PCIe isn't easy or cheap to implement on silicon. The problem is that you'd need the PHY, which is the high speed, analog interface, and that needs to be designed and tuned for the fab and process node you're targeting. In practice the only sane way to get PCIe on your chip is to buy a PCIe IP block from Faraday or Synopsys. The same goes for SATA. Ethernet and USB on the other hand is available in discrete PHY chips, so writing some open-source controller RTL for RGMII and ULPI is much more reasonable for an open-source chip. (Obviously, if someone would cough up the money for taping out a RISC-V SoC with PCIe PHYs onboard and make it in a large enough volume that the price gets down to reasonable levels, I'd be buying a bunch of'em.)

Just as a software compilation flow is devided into preprocessing, compilation, assembly, and linking, a HDL flow is divided into synthesis, mapping, place and route, timing analysis and bitstream generation. RTL is the output of the synthesis stage and is readily available to the designer, typically both as code and as a graphical schematic.

> On a different note, why is that (as far as non-expert me knows) that nice mics often have eq settings? Is this not a blatant layer violation?

The low-frequency/subsonic content that this switch will remove often consists of wind noise, pops from talking too close, vibrations from the floor/mic stand, etc. Even if these low frequency noises may be more or less inaudible, they'll contribute to a large signal swing that will decrease the headroom in the following amplifiers. In other words, you won't be able to turn up the gain in the microphone amplifier/mixer as much as you'd want, because the low-frequency but high-amplitude content will make the amplifier clip and distort the sound. Filtering the signal after the mic preamp won't solve the problem, because the preamp (which can provide in the order of 60 dB gain) will be the component that clips. By including a low-cut filter in the head amplifier circuit inside the microphone (the amplifier serves only as a buffer, and usually with unity gain), the disturbing low-frequency noises can be removed before entering the high-gain microphone preamp. You can find the low-cut switch next to the capsule in the U87 schematic [0]. It seems to me that they increase the capsule bias voltage, thus changing the low frequency response by electrostatically tensioning the membrane.

[0] http://recordinghacks.com/images/mic_extras/neumann/U87-sche...

edit: tweaked some things. meta: i'm not very good at commit messages.

This. It is also important to note that you may interrupt the service of other people's handsets even if your BTS doesn't allow them to connect, just by operating your SDR with an insufficient clock reference [1]. The handset will re-calibrate it's VCXO to match your SDR, and then won't be able to see the legitimate cell networks.

[1] http://openbts.org/w/index.php?title=Clocks

Yes, Point will perform all processing in the device and only send events with time stamps, as well as plain sensor readings for temperature/humidity/etc. It should be easy to verify by looking at the outbound bandwidth. Limiting outbound connections w.r.t hosts, ports and bandwidth (even filtering out OTA firmware updates) should be possible (as we're not trying to hide what we do, only protect your data), but it might affect the performance and battery life of the device, and is not something we can endorse.

If the power goes out or the router gets funky, most internet connected solutions would go offline anyway. But, being battery powered, Point would at least still be active and keep track of things. The fact that the device has lost it's connection to the cloud will trigger a notification to the owner as well. The wireless configuration is done using an app and should be straight forward for most users. As long as the router is securely configured and the user is capable to connect a phone or laptop, installing Point should be piece of cake. As for being self-contained, we mean that it is plug-and-forget, without any cables or base stations. There might be methods of expanding the set of sensors, although at the moment, you see what you get. Adding a cellular modem to the device would make it deviate too much from our current concept in terms of cost (both manufacturing and recurring costs for the cell network usage) and power consumption, but it is something we might include in a future, special version for places without a permanent internet connection, like a cabin or boat.

I wouldn't call it hubris when we're saying that we know of these aspects, consider them our most important design constraints and do our very best to address them. Not being a native English speaker, it perhaps didn't come through humble enough :)

That would require breaking the firmware encryption and signing schemes of multiple physically isolated processors, and even then it would be limited by the power budget, meaning transmitting audio data would drain the batteries very quickly. So, it is not completely impossible (what is, these days?) but extremely implausible and at the same time rather easy to detect; I'd say your (smart)phone is a much better attack vector ;)

Yep, the sound analysis is done on the device. We're working with IFTTT and others on integration, and there'll be an open API as well.

We're using plain batteries and wifi to avoid using cables, thus making it much easier and elegant to install. That also means the device is completely self-contained, so you don't need any base stations or gateways to connect it to the internet. It's just plug-and-forget. I wouldn't call 802.11bgn "shoddy"; it's basic infrastructure already available in most people's homes these days.

The device is configured wirelessly using the smartphone app. It'll queue the events and measurements if your wifi is down, but I see that it will be hard for you to use if you always turn your wifi off when you are away.

Form engineer here. We're not planning on shipping our firmware signing keys along with our product like Belkin did. Jokes aside, security, integrity and trust are our very top priorities. The hardware is designed in a way that should be extremely hard to misuse, and even if someone would be able to break the encrypted protocols, the encrypted and signed firmware images and manage to run custom firmwares on the MCU:s, they would still be limited by the extremely low power budget and the very limited amount of memory, so I would say that it is nearly impossible to store and/or transmit any meaningful amount of audio.

Is it just me, or isn't "BareMetal OS" an oxymoron? I guess it sounds cool, but taking an established term and use it as a name for the exactly opposite seems confusing to me. Please be responsible when choosing names for your projects :)

The good news are that CERN has adopted KiCAD for it's open hardware platform and are actively developing it, adding some cool features which may make it more on par with commercial tools: http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages