I can confirm that the firmware sysupgrade flashing works on this latest luma-board2 branch!
For reference, to do your own build:
git clone https://github.com/tmn505/openwrt.git
cd openwrt
git checkout luma-board2
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig # and select at least all the "additional packages" mentioned above
#target system: qualcomm ipq40xx
#target profile: luma home
make -j6
Got one luma flashed! I added i2cset -y 2 0x48 3 1 0 0 i using the web interface to
System->Startup->Local Startup to turn off the led upon boot.
Thanks a ton.
Any guidance on how to setup OpenWRT to have 1 as the router and the other 5 as access points (connected with wire)?
@tmn505 given how rarely Luma updated their firmware, I don't think it's a far fetched idea that an exploit that could give us shell access to these routers, which would allow going around the official update process and flashing OpenWrt via, say, a script. Sadly, Luma's support is terrible, and after selling these, by the way quite expensive, units to people, they've been pushing the sale of their extra "security" services for ages, while giving zero attention to commonly used feature requests. Now that they're practically defunct, I doubt they will be kind hearted enough to provide a way into their routers for customization. But if (and this is a big if!) an exploitable security issue was present, we could maybe simplify the installation process.
Did you get a chance to dump the original firmwares of your units? We could dig around to see if anything pops up.
If You own this device instructions how to get root access to OEM firmware are in this topic. In case You want an offline investigation, I uploaded two versions of rootfs copied from the device, use binwalk or p7zip to extract the .bin files.:
1.1-16r
https://mega.nz/file/8c4H2BwB#dxI6eUwQ7jq_YJ3mpn2ocgmG8YmigWciIn1SgWejYa4
1.1-18
https://mega.nz/file/QAoVwJ6K#4dyVzW0pjIzLVdX8XOstZ2MzqulMvgvaSorIK_IkIak
You can look for example how they enable ssh access by searching/grepping for string disable_ssh. But then You'll also need to decode at least one of the users password (preferably root). You can also go for decoding app communication with servers. These are only pointers, I don't have time to pursue this further but if You do, I will gladly test any exploit.
@rayclark
The easiest one: https://openwrt.org/docs/guide-user/network/wifi/dumbap
@drandyhaas
Did the installation instructions work for both devices with different flash layouts?
I suspect the easiest way to get in would be using bluetooth. Looking
Yes, seems fine for various devices.
Good.
Improved version of the patches has been sent for review:
http://lists.infradead.org/pipermail/openwrt-devel/2020-August/031136.html
http://lists.infradead.org/pipermail/openwrt-devel/2020-August/031135.html
I do have a 3 unit kit, however it's not under my hands (it is being used as WiFi for my parents), so opening it up is not an option right now. Thanks for the rootfs, I'll look into it, see if we can exploit something - since it's OpenWrt based, and in my experience, Luma's engineers were not exactly the best, I have somewhat high hopes for a Xiaomi-style debug/development endpoint left in that could be used for RCE in a minimal fashion.
I also made some progress on the keys - there's two of them in the firmware, one used for the USB firmware upgrade, the other being an engineering key. I've got some free cloud computing power, so right now I'm trying to run a handful of RSA attack vectors and brute force tasks on it. In case I do manage to get the keys, I will send them to you through appropriate channels - leaking such private keys would be a disaster for current Luma users, and would most likely force the new owner to release a quickfix update, changing the keys.
It would not be considerate the leak those keys however, the ability of the new owner releasing updated software is very unlikely since the lumaops site hosted by AWS is defunct.
IF I manage to bruteforce the private key, I will make sure that it is only in the possession of @tmn505 and possibly the OpenWrt admins. I have no intention of leaking the keys to make these devices vulnerable, the exact opposite - I want these devices to be usable with OpenWrt without opening it up, making them even more secure.
Wow, this is great progress. I've been away from the forums for a while. Good to see other people are interested in having usable Luma units.
I'll have to dig my Luma out and load OpenWrt, run some tests.
Thanks for the pointer to the dumbap. This does not seem to be working correctly as a meshed network. I am looking at https://openwrt.org/docs/guide-user/network/wifi/mesh/80211s but just not sure.
Can this be added to the snapshot branch??
Can anyone with a login create a WIKI page for this unit ans add it to the hardware support database?
Is it already supported?
If yes, with which commit has the support been added?
More like initial support, still probably some work to do. I've have had no time trying to load the image that TMN505 posted the link to. Maybe this weekend.
I cant seem to be able to get good communication, all garbled. Switched the RX/TX and then nothing.
How would I get this connected correctly? From what im reading, only the RX and TX need to be connected (the two pins in the middle).
I have a 6 pin FTDI USB to TTL Serial Adapter - 3.3V and 5V just like this one
https://www.hobbypcb.com/index.php/products/accessories/ftdi232
using windows 7, putty, set to 115200, Data Bits:8, Stop Bits: 1, parity: none, Flow Control: none
What am i doing wrong? Should i try a different adapter? This one worked fine with a UBNt ER-X router I got flashed to OpenWRT.
You need RX, TX, and GND connected.
Tried that as well. No go. Ill have to double-check my soldering. When I tried about 6 months ago it was working, so am not sure what happened since.
Have 3 more units one the way. I'll test with those. Not going to solder anything on these ones, just going to clip the RX/TX and GND pins. Also ordered CP2102 mentioned above @drandyhaas
Make sure the voltage selection jumper is set to 3.3V.
You mentioned you connected only TX and RX, GND must be connected too.
You also said you used the pins in the middle. According to the link you included, it's actually pins 4 and 5 counting from GND (pin 1)
If that's done, try reversing RX and TX, aka connect the RX from your serial adapter to the TX of your Luma and similarly, TX from adapter to RX of Luma.
It's often confusing, as TX at one end must go to RX at the other.
See the pic in the message for reference.
Hope this helps.
