I once met a person that never drank water, only soft drinks. It’s not the unhealthiness of this that disturbed me, but the fact they did it without the requisite paperwork.

Unlike those disorganised people I have a formal waiver. I primarily drink steam and crushed glaciers.

  • 1 Post
  • 36 Comments
Joined 3 years ago
cake
Cake day: June 14th, 2023

help-circle


  • WaterWaiver@aussie.zonetoSelfhosted@lemmy.worldOpenWRT router
    link
    fedilink
    English
    arrow-up
    28
    ·
    edit-2
    2 months ago

    Thing is, its EOL, per Asus. Does this mean that it won’t be supported on OpenWRT for much longer?

    OpenWRT tends to support devices longer and better than the OEM, but it depends on the popularity of the chipset inside the router.

    Many different routers by different companies are almost identical internally, because they use the same chipset. Eg the RT-AC3100 seems to be a bcm53xx variant, of which OpenWRT supports a few dozen products. Support will probably only be dropped when every single one of those devices goes EOL and several years pass (ie no people left contributing/maintaining it and the builds break somehow).

    Router chipsets can be very long lived. Many new devices use decade old chipset designs. Some chipset families have almost identical chips released every few years with slightly different peripherals, clocks & pinouts; but are supported by the same kernel drivers.

    (This is all much better than the world of mobile phone hardware support. Maybe it’s because of different market pressures? Not to mention you don’t have a monopoly that benefits from keeping the hardware fractured. Imagine if people could make a competitor to Android that works across most devices out there)


  • WaterWaiver@aussie.zonetoSelfhosted@lemmy.worldWireguard over IPv6
    link
    fedilink
    English
    arrow-up
    37
    ·
    edit-2
    3 months ago

    As far as I understand, wireguard is designed so that it can’t be portscanned. Replies are never sent to packets unless they pass full auth.

    This is both a blessing and a curse. It unfortunately means that if you misconfigure a key then your packets get silently ignored by the other party, no error messages or the likes, it’s as if the other party doesn’t exist.

    EDIT: Yep, as per https://www.wireguard.com/protocol/

    In fact, the server does not even respond at all to an unauthorized client; it is silent and invisible.




  • Bleepingcomputer’s title and article are very misleading, the presentation did NOT reveal a backdoor into an ESP32. It looks like Bleepingcomputer completely misunderstood what was presented (EDIT: and tarlogic isn’t helping with the first sentence on their site).

    Instead the presentation was about using an ESP32 as a tool to attack other devices. Additionally they discovered some undocumented commands that you can send from the ESP32 processor to the ESP32 radio peripheral that let you take control of it and potentially send some extra forms of traffic that could be useful. They did NOT present anything about the ESP32 bluetooth radio being externally attackable.

    Another perspective that might help: imagine you have a cheap bluetooth chipset that is open source and well documented. That would give you more than what the presentation just found. Would Bleepingcomputer then be reporting it’s a backdoor threatening millions of devices?



  • All of the the surface normals are backwards. This means your shoe is inside-out; instead of being a solid shoe in a vacuum it’s a shoe-shaped-hole inside a solid universe.

    By default blender renders all polys as double-sided so you mostly don’t notice (other than some lighting oddities near corners). Turn on backface culling if you want to check if your normals are the right way around or not.

    I often end up with some of my polys backwards because of the way I extrude and join parts of my models. I distinctly remember a bug in Gmax (old free version of 3DSmax) where the mirror tool would create polygons with some special, broken property where their normals would be correct in the editor, but completely wrong when exported :( much time and hassle was lost to that.








  • SFF = Small Form Factor. It’s smaller than traditional ATX computers but can still take the same RAM, processors and disks. Motherboards and power supplies tend to be nonstandard however. Idle power consumptions are usually very good.

    USFF = Ultra Small Form Factor. Typically a laptop chipset + CPU in a small box with an external power supply. Somewhat comparable with SBCs like Raspberry Pis. Very good idle power consumption, but less powerful than SFF (and/or louder due to smaller cooler) and often don’t have space for standard disks.

    SBC = Single Board Computer.


  • I wouldn’t attack via USB, that path has already been too well thought out. I’d go for an interface with some sort of way to get DMA, such as:

    • PCIE slots including M.2 and external thunderbolt. Some systems might support hotplug and there will surely be some autoloading device drivers that can be abused for DMA (such as a PCIE firewire card?)
    • Laptop docking connectors (I can’t find a public pinout for the one on my Thinkpad, but I assume it’ll have something vulnerable/trusted like PCIE)
    • Firewire (if you’re lucky, way too old to be found now)
    • If you have enough funding: possibly even ones no-one has thought about like displayport + GPU + driver stack. I believe there have been some ethernet interface vulnerabilities previously (or were those just crash/DOS bugs?)

  • I recommend using a different set of flags so you can avoid the buffering problem @thenumbersmason@yiffit.net mentions.

    This next example prevents all of your ram getting uselessly filled up during the wipe (which causes other programs to run slower whenever they need more mem, I notice my web browser lags as a result), allows the progress to actually be accurate (disk write speed instead of RAM write speed) and prevents the horrible hang at the end.

    dd if=/dev/urandom of=/dev/somedisk status=progress oflag=sync bs=128M

    “oflag” means output flag (to do with of=/dev/somedisk). “sync” means sync after every block. I’ve chosen 128M blocks as an arbitrary number, below a certain amount it gets slower (and potentially causes more write cycles on the individual flash cells) but 128MB should be massively more than that and perfectly safe. Bigger numbers will hog more ram to no advantage (and may return the problems we’re trying to avoid).

    If it’s an SSD then I issue TRIM commands after this (“blkdiscard” command), this makes the drive look like zeroes without actually having to write the whole drive again with another dd command.