𝒍𝒆𝒎𝒂𝒏𝒏

Hey 👋 I’m Lemann

I like tech, bicycles, and nature.

Dancing Parrot wearing sunglasses

  • 4 Posts
  • 480 Comments
Joined 1 year ago
cake
Cake day: June 6th, 2023

help-circle

  • Dang, that thing is the bees knees!

    Would make more sense to replace just the batteries rather than the whole unit IMO. Looks like it takes standard 12v 7Ah sealed lead acid batteries, so should be doable for under $120 (if you buy them individually and use the existing battery harness)

    I have three other UPSes, but none of them are as good as yours lol:

    • APC SUA1500RM2U - was a great online rackmount unit, stopped using this a few years back because of its tendency to overcharge batteries without a charge controller ADC calibration mod. It wrecked my last battery pack bad 😭 plan to convert it to LiFePo4 and put it back into service 🤞
    • Zigor Ebro - cheap and cheerful line-interactive UPS for the modem, network switch and CCTV cameras. Switchover time is pretty much instantaneous, worth every cent paid and has kept my network up through many outages
    • Cyberpower UT650 - A temporary offline UPS to hold the server gear specifically until I get the APC back in service. Honestly not worth the cheap price, the switchover delay is long enough to shut off anything that’s not a server PSU with massive bulk capacitors

    Edit: fix bullet list formatting




  • Flash drive hidden under the carpet and connected via a USB extension, holding the decryption keys - threat model is a robber making off with the hard drives and gear, where the data just needs to be useless or inaccessible to others.

    There’s a script in the initramfs which looks for the flash drive, and passes the decryption key on it to cryptsetup, which then kicks off the rest of the boot mounting the filesystems underneath the luks

    I could technically remove the flash drive after boot as the system is on a UPS, but I like the ability to reboot remotely without too much hassle.

    What I’d like to do in future would be to implement something more robust with a hardware device requiring 2FA. I’m not familiar with low level hardware security at all though, so the current setup will do fine for the time being!




  • If MIT AppInventor is still kicking around, you should be able to use it for this… although sadly you won’t have access to the source code since it’s a Scratch-like way to create apps.

    By default the Android voice assistant uses Google tech AFAIK, if you’re after a truly source-available solution then there’s ”Futo voice input" to handle STT, and “RHVoice” to handle TTS - though these would still need a HTTP API bridge to do what you want


  • I think so, assuming these malicious packages are all primitive enough to just look for the single file in a user’s home folder lol. The only downside here is needing to provide the keyfile location to ssh every time you want to connect… Although a system search would pretty much defeat that instantly as you mention

    SSH keyfiles can be encrypted, which requires a password entry each time you connect to a SSH server. Most linux distros that I’ve used automatically decrypt the SSH keyfile for you when you log in to a remote machine (using the user keyring db), or ask you for the keyfile password once and remember it for the next hour or so (using the ssh-agent program in the background).

    On Windows you can do something similar with Cygwin and ssh-agent, however it is a little bit of a hassle to set up. If you use WSL i’d expect the auto keyfile decryption to work comparably to Linux, without needing to configure anything









  • It’s not natively supported by the base RCS standard, in the section at the end of the paper in the section titled “Third Party RCS Clients” Google explains that they’ve built the e2ee their Messages app themselves, (on top of standard RCS).

    A developer has to use Google’s implementation specifically in order to send and recieve e2ee messages to Google’s Messages app (and Samsung Messages who also implemented this recently)

    Although the e2ee implementation is using the Signal protocol under the hood, it’s for message content only - this is what is transmitted in cleartext (taken from the paper)

    • Phone numbers of senders and recipients
    • Timestamps of the messages
    • IP addresses or other connection information
    • Sender and recipient’s mobile carriers
    • SIP, MSRP, or CPIM headers, such as User-Agent strings which may contain device manufacturers and models
    • Whether the message has an attachment
    • The URL on content server where the attachment is stored
    • Approximated size of messages, or exact size of attachments

    Without using this implementation of the Signal protocol on top of RCS, the message will deliver to the contact’s phone, but shows up as unencrypted garbled text

    That is a very useful resource though, never knew there was a paper available on the implementation. Saving 😁