Wait, you are open sourcing code that you did not write but reverse engineered? It that legal?
Google vs Oracle seems to say that offering up a compatible api with different internals is legal. Exploiting the signs seems risky though.
Taking over a Dead IoT Company
101–110 of 213 posts
Re: Taking over a Dead IoT Company
#102"As we discussed earlier, even at $300 the product is too cheap. The sign should have likely been selling at $600 from the very beginning." Even at $600 - there's a screenshot saying the company had three engineers and a marketer. If your 4 employees earn $25k per annum, with the $150 parts cost you'd have to sell 222 signs at $600. And if the employees were on $100k, that's 888 signs a year. That's a heck of a lot o…
This makes me wonder how Tidbyt's business is doing. They seem to have a fair amount of employees.
I actually built something very similar and all in my spare time. I've been wondering how realistic making a side-business out of it is, but if you are a single engineer that has to code the firmware, server, build the displays and market it all... it's pretty tough (especially in your spare time).
Re: Taking over a Dead IoT Company
#103Hello, author here. Happy to answer any questions! My apologies for the downtime, I wasn't expecting much traffic today since I submitted the post to HN yesterday but I've started scaling my server now!
Awesome work!
Re: Taking over a Dead IoT Company
#104Earlier quoted context omitted.
If your product needs to output HDMI, I can easily see an argument for using a Pi. If your product needs a couple GPIOs to drive an LED matrix? Using an RPi is pretty difficult to justify. You're likely going to spend more on the SD card for the Pi than you would on more suitable microcontroller (which can still be easily programmed and, in my experience, has a better [or at least no worse] story for GPIOs than the P…
It's difficult to drive these LED matrix devices from a typical MCU, especially with chained panels, lots of LEDS, etc. Either due to the ~10Mhz+ output needed, or the memory to hold all the pixel data. Consider, for example, that each of the two panels in this sign has 32x64X3 (6144) leds. You have to send on/off for all of those, and then control brightness for each color by using PWM...meaning half-red brightness…
ESP32 is perfect for this application. RPI is far too beefy, unless you really want to do everything locally (without relying on an external server to package up the train data for you)
Re: Taking over a Dead IoT Company
#105I didn’t quite understand the need for an injection attack. Once you had bought the domain and could respond to the devices‘ API calls, weren’t you in the driving seat already?
I actually had written more about the exploit & vulnerability in my original drafts but I cut it out because it was a bit boring to read.
You are correct that with domain control I am able to serve content to any sign but the content will only be loaded once at boot time. Any future updates would have needed to come from their defunct AWS IoT connection (ignoring full restarts).
Using the exploit I remove the connection to AWS IoT and update some of the code to better connect it to the recreated API so users can update their signs in mostly real time.
Re: Taking over a Dead IoT Company
#106Earlier quoted context omitted.
This is all too common in my experience, "oh we could just use an arduino/pi and a hat and a peripheral" rather than "Design a system that does ". As an EE who spent their primary career programming (horrors I know) and in systems analysis, I see it as the logical extreme of "why use a 555 when I can program an ATTiny to be a timer and do other stuff too!" The allure of having one be able to add features "with just a…
Oof. My electronics stopped before GCSEs, and even I know about 555s. I can believe someone might prefer software for prototyping, but manufacturing? Well, I've seen prototypes enter production, so yes, but still, ugh .
A attiny might not make sense, but you can get something like the PMS150C for around ~5ct, where it makes more sense to use a single MCU than a 555 with all the extra needed BOM Items.
Re: Taking over a Dead IoT Company
#107Earlier quoted context omitted.
The entire project looks like the result of a high school student's first Instructables. It's hilariously under-engineered and it's clear that these folks had absolutely no idea of how to build a product, IoT or otherwise. Hint: if your product plans involve a raspberry pi, you probably fucked up.
How would you get a quick MVP of PCB + needed interfaces? I'd love to know if there is a PCB design as a service + manufacturer that allows small size of order (as a 3rd party integration). I think they definitely exist .. I just have to figure out who to talk to first.
There are existing PCBs out there for driving HUB75 displays (like the one used in this project).
Re: Taking over a Dead IoT Company
#108I didn’t quite understand the need for an injection attack. Once you had bought the domain and could respond to the devices‘ API calls, weren’t you in the driving seat already?
A guess, but... "At boot time, the Config Server will pull the latest configuration from an HTTP server. In addition, the Config Server will connect to an AWS IoT Core endpoint to receive real time config updates from an MQTT server." So, perhaps to bootstrap information they didn't have, like the current configuration? It sounds like they sold different types of signs with different resolutions, and also whatever tr…
Yes the exploit removes the AWS IoT connection so that updates can come from the recreated API.
There was only one type of sign but it did come in various different cases.
Re: Taking over a Dead IoT Company
#109Woof. Adafruit + Raspberry Pi in a shipped product screams to me that they did not have a real electronics guy on their team. https://ukdepartureboards.co.uk/ is the British equivalent of this, and it seems to do everything right (don’t own one, but have seen on Twitter)- optional subscription, and nice looking hardware (seems like they contracted out for that). Though at the minute I suppose there are barely any tra…
The Code Quality section in the article also listed software red flags that point to the product being Amateur Hour. From the archive.org About Us link OP provided[1], there seemed to be plenty of "coders" but maybe not much embedded SW experience? They couldn't even agree on what language to use, whether to use tabs or spaces, and couldn't manage to produce a pristine Micro SD image without bash_history and a git repository littered onto it.
Kind of reminds me of a small company I used to work for where I noticed shortly after joining that they 1. had no source control or reproducible builds, and 2. ship Debug builds with symbols and no optimizations to customers, because they couldn't get the Release configuration to run without crashing.
1: https://web.archive.org/web/20180107132644/https://www.devsh...
Re: Taking over a Dead IoT Company
#110Earlier quoted context omitted.
It's difficult to drive these LED matrix devices from a typical MCU, especially with chained panels, lots of LEDS, etc. Either due to the ~10Mhz+ output needed, or the memory to hold all the pixel data. Consider, for example, that each of the two panels in this sign has 32x64X3 (6144) leds. You have to send on/off for all of those, and then control brightness for each color by using PWM...meaning half-red brightness…
ESP32 is perfect for this application. RPI is far too beefy, unless you really want to do everything locally (without relying on an external server to package up the train data for you)
Sure, though 240Mhz, 32bit, optional gobs of PSRAM, etc, aren't usually what comes to mind when you hear MCU.
Edit: Yes, you could even use an ESP8266, though 32x128x3 plus X bits of PWM brightness would mean being limited to drawing from storage rather than in-memory manipulation. I'd jump right to the WROOM type devices with PSRAM.