𞋴𝛂𝛋𝛆

  • 0 Posts
  • 5 Comments
Joined 3 years ago
cake
Cake day: June 9th, 2023

help-circle
  • Complex social hierarchy is a super important aspect to account for too. In the proprietary software realm, you infer confidence in the accumulated wealth hierarchy. In FOSS the hierarchy is not wealth, but reputation like in academia or the film industry. If some company in Oman makes some really great proprietary app, are you going to build your European startup over top of it? Likewise, if in FOSS someone with no reputation makes some killer app, the first question to ask is whether this is going to anchor or support a stellar reputation. Maybe they are just showing off skills to land a job. If that is the case, they are just like startups that are only looking to get bought up quickly by some bigger fish. We are all conditioned to think in terms of horded wealth as the only form of hierarchy, but that is primitive. If all the wealth was gone, humans are still fundamentally complex social animals, and will always establish a complex hierarchy. This is one of the spaces where it is different.


  • The main problem is when following instructions for command line tools. They might figure out how to use dnf instead of apt, but the extra layers required for ostree are not very friendly. There are a ton of potential frustrations in this area, especially with GPU stuff or hobbyist hardware like Arduino where kernel stuff is needed in userland. At least as of nearly 3 years ago, the documentation in this area sucks. I was on Silverblue for a few years and managed to get through the frustrations due to intermediate experience level. I found toolbox useless compared to distrobox. But using this with something like Arduino was annoying at best. The needed dependencies expected by whatever stuff I wanted to install was usually a big mystery with near useless error failure messages and names of packages and libraries totally unrelated to the package naming in DNF. When updating the base OS, stuff built in these containers is totally useless because I could not update the containers to the new OS image. Playing around with Flash Forth on a microcontroller was even worse. I ended up layering a bunch of stuff on the host because the containers were just not working. When I got an Nvidia machine, I went to Fedora Workstation and have had far fewer issues and frustrations. SB wasn’t bad, but it is a pain to use these if you need kernel level access. Just my $0.02. I was actually on SB for ~2-3 years.


  • Depends on the system. Typically, the older systems do not work like this. The GPS satellites only transmit a signal that contains their location information and the time. The device must collect several of these signals and then use trigonometry to calculate your real location in time and position. Yes there are relativistic effects due to the distance to the satellites and gravity.

    For instance, in home lab electrical engineering, if a person wants a really good reference clock but cannot afford a cesium atomic reference, they can use a relatively cheap GPS system to build a referenced oscillator that is disciplined by the reference clock on these satellites. I think they are cesium too, but it has been awhile since Dave Jones made YT uploads on the eevblog about it. A Garmin bicycle computer is another example. It is triangulating the signals and plotting periodic waypoints with some basic averaging.

    That said, WiFi routers and cellular towers are possible to use for similar triangulation. Maybe check out Hak5 if they are still around. It has been awhile since I looked them up, but they used to make pen testing red team stuff that will infer much about vulnerabilities.



  • The easiest way I know of to check any machine is to put another router or machine in front of it with a white list firewall or way of logging DNS traffic. You just need to spot the address in the list.

    DNS filtering usually only filters on incoming packets, but for bot stuff that should catch issues.

    In general, most routers run everything from a serial flash chip on the board. These are usually 8, 16, or 32 megabytes. They have a simple bootloader like U-Boot. This is what loads the operating system. These devices have a UART serial port on the PCB. You can use a USB to serial UART adaptor to see what is happening in the device. With a proprietary OS, you are still likely to see the pre-init boot sequence that the bootloader prints to terminal. Most operating systems also print information to this interface, at least of the couple dozen junk devices I have been given and messed around with. I make a little mount for a USB to serial adaptor and add it to all of my routers when new, so I only need to plug in USB to get to the internal bootloader and tty terminal interface of OpenWRT. You will need to know the default baud rate of the device, although it is probably listed somewhere online or can be guessed as one of the common high values at or above 9600.

    Getting into this further gets complicated. It is probably better to look for any CVE that is relevant to the device or software and work backwards. Look for any software updates that have obfuscated the risk for each CVE. If the issue was not fixed, that is where to look to see if someone has exploited the device. Ultimately, they need clock cycles from the CPU scheduler. So it must be a process or some way of executing code from unregistered memory.

    This is getting to the edge of what I have messed around with and understand. There may be a way to get a memory map that includes unused pages, and compare that with a hex dump of the flash memory. This is outside of your scope of a proprietary OS, but hopefully frames the abstract scope of what is possible on this class of device when you have an open source stack. The main advantage of this kind of device and issue is that you can physically remove the flash chip and then see and manipulate every page and memory location. The device likely doesn’t have microcode loaded into the CPU(s) that make it challenging to determine what is going on.

    There is probably an easier way, but a hex dump of the current system can be hashed against the factory updated version to see if any differences are present. It is likely that any exploit will include a string with the address to connect to somewhere in flash memory. It could be obfuscated through encryption or a cypher, but a simple check for strings in the hex dump and a grep for “http” is a simple way to looks for issues.

    The OpenWRT forum is a good general source. The people behind the bootloaders for these devices are also Linux kernel developers and on the OpenWRT forum.