Quantcast
Channel: Antarctica Starts Here.
Viewing all 210 articles
Browse latest View live

Concert photos: Curse Mackey, the Bellwether Syndicate, and Clan of Xymox

0
0

There are few better ways to kick off the holiday season than with a good concert.  2018 was no exception in this regard - the DNA Lounge brought in a trio of goth heavy hitters spanning the last 40 years in.  The night was opened by Curse Mackey, who seems to have worked with just about everyone on just about everything from Thrill Kill Kult to Pigface.  Second up was a relatively new group called the Bellwether Syndicate (whose work I've grown quite fond of since that show), comprised of William Faith (best known for being one of the founders of Faith and the Muse) and long-time goth DJ Scary Lady Sarah.  They really capture the feel of classic goth and post-punk while still sounding fresh.  Last and certainly not least were gothic veterans Clan of Xymox, still going strong and sounding as powerful as they did when they were first founded in 1981.ev.

Anyway, here are the picture I took.  If you're curious, the Internet Archive has a copy of the concert's livestream to listen to.


Linux on the Dell XPS 15 Touch (9570)

0
0

UPDATED: 18 March 2019 - External display adapters that actually work with this model (and Arch Linux) added.

For various reasons, I found that I had a need to upgrade Windbringer's hardware very recently.  This might be the first time that a catastrophic failure of some kind was not involved, so it's kind of a weird feeling to have two laptops side by side, one in process and one to do research as snags cropped up.  This time around I bought a Dell XPS 15 Touch (9570) - I was expecting things to be substantially the same, but this did not seem to be the case.  Some things that I found myself ignoring because I had no use for them aren't in this newer model, and some things have changed as technology has advanced rather a lot in the last five years.

As before, first I'll post the hardware specs, and then follow up with everything I had to tinker with to get working as well as how I went about it.  As usual, I went with 64-bit Arch Linux (2019.02 installation build).

Kernel: 4.20.12-arch1-1-ARCH #1 SMP PREEMPT Sat Feb 23 15:11:34 UTC 2019 x86_64 GNU/Linux

Hardware:

  • Intel i9-8950HK CPU
    • 2MB cache
    • 4.8 GHz
    • 6 cores, 2 threads each
  • 32GB DDR4-2666MHz RAM (maxed out)
  • Video: Intel Corporation UHD Graphics 630 (Mobile) (i915, basically)
  • Video: NVIDIA® GeForce® GTX 1050Ti with 4GB GDDR5 vRAM (via Optimus)
  • Audio: Intel Corporation Cannon Lake PCH cAVS (this is basically the i915 audio chipset, nothing to write home about)
    • SATA controller: Intel Corporation Cannon Lake Mobile PCH SATA AHCI Controller
  • 2TB PCIe SSD
  • 15.6" HD display @ 3840 x 2160 touchscreen
  • Killer 1535 802.11ac 2x2 WiFi and Bluetooth 4.2
    • The output of `lspci` says this is a Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter.
  • 97WHr power cell
  • 130W PSU (the same one as my last XPS 15)
  • Built-in video camera: Microdia (the default `uvcvideo.ko` picks this up automatically)
  • SD card reader
  • USB 3.1 gen 1
  • Laptop security cable slot
  • HDMI 2.0
  • Thunderbolt 3
  • Fingerprint reader inside the power button.
    • I have no idea how to interact with this.

Before booting from a flash drive with the Arch Linux installer on it, I jumped into the system settings by tapping the F2 key a few times a second (don't just hold it down) after hitting the power button.  In the Dell system options I made a few minor changes to make life easier later on:

  • System Configuration -> SATA Operation -> AHCI
  • Secure Boot menu -> Secure Boot -> disabled (so that I don't have to muck around with signing kernels)
  • Power Management menu -> Primary Battery Charge Configuration -> AC plugged in most of the time (because I mostly use my laptop at home)
  • POST Behavior menu -> Extend BIOS POST time -> five seconds (so I have time to hit F2, F12, or whatever)
  • POST Behavior menu -> Full Screen Logo -> disabled
  • Virtualization Support menu -> Virtualization -> enabled (I use VirtualBox from time to time)
  • Virtualization Support menu -> VT for Direct I/O -> enabled

To make the system console font (not the X environment's typefaces) bigger, I installed the terminus-font package and ran the command setfont ter-132b to get bigger text.  To make this a permanent feature I created the file /etc/vconsole.conf with the following contents:

FONT=ter-132b FONT_MAP=8859-2

One thing that I discovered right up front is that the SSD doesn't appear as /dev/sda or /dev/sdb (like it did on the earlier model XPS 15).  Instead it shows up as /dev/nvme0, but that's not actually the disk device; I think that's just the PCIe interface.  The actual disk device that you interact with using fdisk is /dev/nvme0n1, so my partitions are actually called /dev/nvme0n1p1 and /dev/nvme0n1p2.

Before moving on, make a note of the GUID of your physical root partition for setting up the boot loader later.  Let's say it's 8468e49d-29b7-4353-8379-59b7e7996add.

The biggest jump I made here was to ignore BIOS backwards-compatibility entirely and go whole-hog on using UEFI (Unified Extensible Firmware Interface) to join the twenty-first century.  This wound up being a remarkably easy thing to get going.  When I partitioned the SSD, after blowing away all of the factory stuff I created a 512 megabyte /boot partition of type FE00 (EFI System) and formatted it as VFAT (one of the few filesystems the UEFI spec supports (they're all old-time DOS file systems)) and then a root partition that filled up the rest of the drive of type 82 (Linux filesystem).  The root partition was set up with the usual Arch dm-crypt procedure.  I installed a basic Arch Linux system and then used systemd's built-in UEFI boot loader (called systemd-boot) to make everything bootable.  Here's how I did it:

  • bootctl install
  • cd /boot/loader
  • vim loader.conf
timeout 5 console-mode 0 default arch
  • cd entries
  • vim arch.conf
title Arch Linux linux /vmlinuz-linux initrd /intel-ucode.img initrd /initramfs-linux.img options root=/dev/mapper/root cryptdevice=UUID=8468e49d-29b7-4353-8379-59b7e7996add:root:allow-discards rw mem_sleep_default=deep acpi_rev_override=1
  • vim fallback.conf
title Arch Linux Fallback linux /vmlinuz-linux initrd /intel-ucode.img initrd /initramfs-linux-fallback.img options root=/dev/mapper/root cryptdevice=UUID=8468e49d-29b7-4353-8379-59b7e7996add:root rw
  • An easy way of getting the GUID into those two config files is to use this command inside of vim so you don't have to retype them:
    • <hit esc>:r !blkid -s UUID -o value /dev/nvme0n1p2

After doing this, your system should boot normally; you don't need any other boot loader or software for the system to come up.  As far as the UEFI systemware is concerned, the Linux kernel is an EFI application so it runs it like any other.

I followed the nVidia Optimus instructions in the Arch wiki.  When installing Xorg on this model, do NOT install the xf86-video-intel package.  Those Xorg drivers will not work.  I installed bumblebee, bbswitch, and the official nVidia drivers, and then made the following configuration changes to /etc/bumblebee/bumblebee.conf:

  • TurnCardOffAtExit=true
  • Bridge=auto
  • PMMethod=none
    • Because TLP is handling this.

I also created a config file /etc/tmpfiles.d/nvidia_pm.conf with the following contents to fully enable power management for the nVidia chip:

w /sys/bus/pci/devices/0000:01:00.0/power/control - - - - auto

I got the value "0000:01:00.0" in the previous file by interrogating the integrated devices in the laptop, like this: lspci | grep -i nvidia | awk '{print $1}'

I'm using TLP for power management because I'm too old to screw around with all those config files.  I did have to do one thing, though, which is tell TLP to not manage power for the nVidia chip, because Bumblebee is going to do that.  I edited the file /etc/default/tlp and made the following change (where 01:00.0 is the PCI bus value above):

RUNTIME_PM_BLACKLIST="01:00.0"

In the /etc/systemd/logind.conf file, I uncommented the HandleLidSwitch line and set it to "ignore" because I want my desktop software to do that for me.

Due to the fact that my new laptop has only a solid-state drive for storage, I enabled periodic TRIMming of deleted data to keep the drive healthy.  If you look in the /boot/loader/entries/arch.conf file earlier in this post, you will see that the kernel is being passed the option :allow-discards.  This turns on TRIM support.  Actually enabling this functionality required two further commands:

  • systemctl enable fstrim.service
  • systemctl enable fstrim.timer

Last and certainly not least, migrating my home directory onto the new laptop.  The fastest and most reliable way to do this was to dig out an Ethernet switch and two USB-to-Ethernet adapters.  I plugged the two systems together into a little ad-hoc network on my workbench.  I don't do this very often, so in case I forget again (or if someone needs this in the future), here are the commands I ran on both the old and new laptops:

  • ifconfig | grep enp | awk '{print $1}'
  • ifconfig <interface name> 10.0.0.[2, 3] netmask 255.255.255.0 up
    • Give the network interface the IP address 10.0.0.2 or 10.0.0.3.
  • route add -net 10.0.0.0 netmask 255.255.255.0 dev <interface name>
    • Set a route for the network 10.0.0.0/255.255.255.0 that points to the USB-to-Ethernet interface.
  • ping -c5 10.0.0.[2, 3]
    • If you're on 10.0.0.2, try to ping 10.0.0.3 and vice-versa.

The command to copy everything from the old system onto the new one: rsync -avz --progress drwho/ drwho@10.0.0.3:/home/drwho/

Total time: About 26 hours (and you wonder why I do so much work with personal search engines!)

I fought for a week or two trying to get external displays to work with this particular unit.  As it turns out, adapters (and/or displays) you want to use have to be Active in construction, which is to say that they cannot merely be pin-to-pin converter cables, there has to be circuitry on-board doing signal processing.  After some consternation I remembered that I had an HDMI-to-VGA converter (Moread male HDMI to female VGA) in my field kit for presenting on the road.  I plugged it in - HDMI-to-VGA adapter to VGA cable to external display, and it came right up without needing to reconfigure X (modulo needing to turn up the brightness and contrast a bit).  I've also just tested an Itanda USB-C to mini-Displayport adapter purchased from Amazon, and much to my surprise and delight it works too, also with no reconfiguration.

Neologism: Rotten egg dependency

0
0

rotten egg dependency - noun phrase -  A service that a mission-critical application relies upon that nobody knows about but brings everything to a screaming halt when something happens to it.  In a sane world, said dependency should have nothing at all to do with the thing that just crashed.  Called this because it's as pleasant a surprise as a rotten easter egg at breakfast.  Best explicated by the following haiku:

It's not DNS
There's no way it's DNS
It was DNS

Neologism: Maintenance contention

0
0

maintenance contention - noun phrase - When there is only one bathroom but two people need it for the exact same urgent thing.

Neologism: Technical heresy

0
0

technical heresy - noun phrase - Openly demonstrating the imagination to come up with actual uses for a platform or application that it is currently popular to hate.

Neologism: Taxonomic debt

0
0

Taxonomic debt - noun phrase - The time you spend learning arbitrary jargon at a new job.

Source: Bradford Stephens
 

Neologism: Trapdoor goalposts

0
0

Trapdoor goalposts - noun phrase - When two or more requirements are set up so that meeting one automatically means failing another. This is a bad faith argument whereby it is impossible to meet the requirements someone sets, without admitting refusal to allow the outcome the other person desires.

Example:
"If you're making a decent income you can't possibly talk about poverty, you don't know what you're talking about."
"I'm actually below the poverty line."
"You just want a handout!"

Neologism: Proper channels excise tax

0
0

Proper channels excise tax - noun phrase - The markup paid on commonplace things when you go through proper channels at work to do something rather than going rogue, buying it yourself and filing an expense report.  For example, a flight from Chicago to Boston might cost $176us if you paid for it yourself, but by using your employer's internal processes and vendors the cost of the same flight is closer to $630us.


Neologism: @here grenade

0
0

@here grenade - noun phrase - The act of tagging a message @here (meaning, everyone) in a crowded Slack channel (users >= 100), causing everyone who's busy but monitoring to drop whatever they're doing and flame you for bothering them by messaging @here.  Normally done by a user trying to get a response to a maximum severity ticket that's been ignored for longer than the SLA.

Example: "PFY threw an @here grenade into the #tech-support channel because the border router was on fire and the admins on call were ignoring their pagers.  He got kicked but at least the outage is over."

War walking with a Raspberry Pi 0 W.

0
0

You've probably noticed from the datestamps of my last couple of weeks worth of posts that they were autoposted by an agent.  This is because work has taken a turn for the extremely busy and I haven't had the time or the energy to write anything in particular; certainly nothing really useful.  Rather than wasting everybody's time I decided to relax a bit by picking up an older project, namely a new war-walking rig, and making it work.  Since I wrote that original post a few more security updates have come out for my phone and broke not only the Wigle wardriving app but a couple of other things that I really like, but that's neither here nor there.  I'm still using the equipment outlined in the previous post and the latest Git commit of Kismet right out of the developers' repo.  I made a couple of design decisions that I'll discuss later which are specific to my use case, which you are free to ignore or discard as you deem necessary.

First off, I solved the problem of not having enough processing power to compile Kismet by popping the microSD card out of my RasPi0w and installing it into a spare RaspberryPi 3b+ I had on my shelf.  I ran through the quickstart procedure as documented without having to change anything.  The only real thing I had to do was wait because it took an hour or two for Kismet to compile.  I don't know if I could have sped it up any - maybe a faster microSD card, maybe using all four CPUs on the unit instead of just one (because I didn't want to risk overloading and crashing another RasPi, not having the patience to fight that particular battle at the time).  I had no particular deadline or schedule, so it didn't cause any real bother to go the long way around.  While Kismet was compiling, I went scrounging around in my parts bins for a few other things I knew I'd need, like a USB hub and a power bank that would run the entire rig for at least twelve hours at a stretch (my estimate later proved fairly accurate).  My component arrangement could probably use some work.  I could probably get a better cable layout with a USB squid of some kind and a handful of zipties, but I'll worry about that later.

One of the things I did was leave the built-in wireless NIC active, so that it would connect to my home wireless network when I got home.  This makes it easier to log into my wardriving rig and shut it down cleanly.  The external wifi NIC does all the work of scanning for access points.  I know that I could do something like rig up a button that tells the RasPi to shut down when somebody presses it but that would require a bit more electrical work than I have time for at this moment.  Maybe I'll figure out how to build a little USB device that does the same thing...

I also set up a systemd .service file that automatically starts Kismet on boot and shuts it down cleanly when the RasPi shuts down.  A sample .service file is provided in the Kismet source code, so this was a trivial operation.

Because the RasPiW does not have an internal clock (and there isn't room to install one in the housing) Raspbian queries the nearest known time servers at boot to set its system clock.  If it can't (and if I'm in the field, away from my home network (which is the only one configured) this is the case) the system clock won't be set properly, which means the timestamps on what Kismet records will be wrong, which means that short of database surgery (newer versions of Kismet use SQLite databases instead of flat files) the map results can't be uploaded, in which case there's no point.  To solve this particular problem I have my RasPiW set its system clock from the GPS receiver, which I posted a howto for late last year.  Initial tests seem promising.

Now, a couple of things I still need to figure out:

Kismet, if it's been running for a while (two or three hours) tends to suck up a lot of RAM.  When SSHing into my RasPiW at home, I found that it sometimes took a couple of tries to cleanly shut down the unit due to "out of memory" errors.  I was entirely unsuccessful when trying to cleanly kill Kismet (sudo systemctl stop kismet.service); the command would hang forever and I'd have to resort to a clean shutdown.  This means that to get at the Kismet databases I have to crack the case open, extract the microSD card, plug it into Windbringer, and manually copy the files over so I can convert them into the format that Wigle expects.  This also means that I have to have another copy of Kismet installed elsewhere, which works but isn't an elegant solution.  The best case scenario would be that I SSH into the wardriving unit, shut down Kismet, run the conversion on the RasPiW, and download the resulting files.

When uploading mapping data to Wigle, the site suggests also uploading the data to Open Streetmap to add to their cartographic database.  I've not yet figured out how to do this because the recommended utility doesn't seem to work with newer versions of Kismet.  Specifically, it seems to be expecting XML data dumps instead of SQLite databases.  I don't know if there are existing tools that will do this so I might have to write one myself.  We'll see.

While it's not really necessary, it might be nice to add a tiny display to my wardriving rig, if only so I can keep an eye on where it is in the shutdown process.  The RasPi zeroW has a miniature HDMI jack so I can use that but I don't yet know if suitably tiny displays (on the order of the dimensions of said RasPi) exist.  Maybe it would make more sense to use the built-in Bluetooth capability of the zero W to link it to my phone.  I'll have to play around a little and figure out how to do it.  Perhaps another project will come of it.

Getting the US Supreme Court to overturn Roe v. Wade is the entire point.

Notes from Thotcon 0x0a.

0
0

My notes from Thotcon 0x0a:

Hacking Con Badges for Fun and Profit

  • Given by an EE
  • Badge hacking started with DC23, HHV.
  • Turned his DC23 record-badge into an analog clock.
  • AND!XOR's DC24 independent badge.
  • Maple Mini STM32.
  • Live spectrum analysis of 20-20KHz as an add-on.
  • Mic, pre-amp, FFT running on the uc.
  • Wired into the badge, rock-and-roll.
  • Inspiration and OSINT - look at the badge when it's announced, think about it
  • Get ideas
  • PoC - if you don't have this, you're not going to have anything
  • dev & debug
  • DC25 - NRF52 - 503.party
  • Blow up any images you can and start thinking.
  • BMD-300 module
  • OxVox - synthesizer and firmware for the badge.
  • Thotcon 0x09 badge - Thotcoin miner
  • Arduino to toggle the pin to mine as many coins as possible
  • Spoiler alert: 0 coins
  • ESP8266, similar to the Sparkfun devkit.  Picaxe x4.
  • Rewrote the firmware in the EPROM that holds the coin count and changed the value.  :)
  • Added a speaker and amp, built a CW repeater for morse code.
  • It's not a badge, it's a development board.  Changes how you think about it.
  • Addons - badges for your badges.
  • DC26 shitty add-on connector, four-pin I2C interface, VCC is marked.  Male pins.  0.1" pin pitch.
  • Master badges have female headers.
  • SAO Genie, based on TPM Genie, PoC for I2C sniffing.
  • Badge -> SAO Genie -> Addon to monitor traffic, serial interface to hook to a computer.
  • Destination address, packet contents.  Passthrough, inject, modify, block packets.
  • DCZIA badge - 4x4 keyboard
  • Crappy audio processing unit to make a sequencer or a synth.
  • https://github.com/mediumrehr
  • @mediumrehr

From Dev to Security

  • LilBitEvil
  • Modern webdev is a holy-shit field, with a fucking broken ecosystem.
  • Security isn't really a priority for webdev.
  • Getting features out the door takes priority.
  • Infosec as the Department of NO.
  • Webapps are the new endpoint.
  • Infrastructure's getting harder, so the applications are the target now.
  • From the moment you have requirements, you have to think about security.
  • Dependencies dependencies dependencies...
  • I don't know which Defcon he went to, but that doesn't sound like Defcon.
  • Personal mission for getting into security.  Good luck, man.
  • Try to find a personal niche.
  • You have to have an understanding of how things work for the tools to make sense.
  • Hiding From the Internet
  • Open Source Intelligence Techniques
  • Coming into security from another field can lead to being typecast.
  • Figure out where you can go when you get into the field.  Just because you built webapps doesn't mean you want to do webapp security.  What if you like IR?
  • "Practice makes permanent."
  • Networking is crucial.  And it's hard because many of us are introverts.
  • If you carry yourself with respect, people will respond to you the same way.
  • They're all people.
  • Look for non-trad talent.
  • "Fortis fortuna adjvat."  "Fortune favors the bold/brave."
  • Every company has a gap.  Figure out what it is and how you can fill it.
  • It's easy to get mixed up in bad stuff.  Do the right thing.  People are depending on you.
  • At the very least, you value your bank account.  Advocate for the people who can't protect themselves.

Adversary Based Risk Analysis

  • CISOs and defense teams making ineffective decisions.
  • Vendors make bad products.
  • Apply more critical thinking.  Use the scientific method, rigorous analysis.
  • Appetite for new theories and perspectives.
  • Understand your org, because that's what you're defending.
  • How it looks to the attackers is what matters.  What do they think about when planning.
  • What kind of IP, what industry, how big a fish are you, public or private, countries you operate in, how valuable the information is (if the value can be known externally).
  • Which adversaries are most likely?
  • Threat intel
  • No data feeds, indicators of compromise, sigs... actionable information about tactics, methods, processes, mechanisms used.
  • Motivation, resources, strategies.
  • It's hard to find because threat intel vendors don't get this stuff.
  • Dossiers about adversaries.  Diamond model: Adversary, infastructure, victims, capabilities.
  • You want to look at the sociopolitical axis (who, why, located) and technical axis (infra, resources, tools, methods).
  • "All attackers are budget constrained."  -Dino Dai Zovi
  • "All attackers have a boss and a budget."  -Phil Venables
  • repeatability - capability to change the target and have the attack still work with the same success rate.
  • scalability - capability to launch similar attacks against multiple targets with minimal additional cost per target.
  • Attackers determine least costly and most valuable attacks based upon complexity of targets, number of targets, required success rate, speed of conversion.
  • Pro attackers work within organizations, with all that entails.  (Exploit their org to bog them down somehow?)
  • No adversary builds a custom playbook for your specific org.  They come up with general playbooks to deploy in the general case.  (Flexible enough for the specific case?)
  • Cyber count: 1
  • Grab the slides for the example dossiers.
  • 6D - detect/deny/disrupt/degrade/deceive/destroy
  • adversary economics - cost == minimum of (cost * success rate)
  • cost factors: expertise, time, money, politics
  • success factors: target commonality, probability, reliability, access
  • What can you do that will maximize the cost for the adversary?
  • "Kill whitehats"???
  • Use common and off-the-shelf stuff?  Their dev cost is too high.
  • Lowest cost for the defenders to implement?
  • Adversary evolution - attackers change tactics in response to what they find.
  • New techniques are developed as the success rate drops.
  • Predict new behavior.
  • "Based upon what they're going to find, this is what we think they'll do."
  • Mail gateways?  New phishing templates.
  • Endpoint protection appears?  Malware gets repacked, customized.
  • Probably won't see honeypots.
  • Rational adversaries will use the most cost-effective playbook to meet operational requirements.
  • (It's the irrational ones that you have to worry about.)
  • Do they change tactics by target to avoid attribution?  Prior knowledge of target?  Are they routinely bypassing COTS defenses?
  • Risk analysis.
  • Common threats vs. costly/unscalable/unrepeatable threats
  • Likelihood vs impact
  • CVSSv3 scores
  • Very few adversaries look for vulns in specific apps because they don't scale.
  • Scalable, repeatable attacks are more likely.
  • In most cases, issues should be scored on likelihood alone.  Treat everything as high impact.
  • Pro attackers often have political constraints.
  • Adversaries don't teach each other.
  • Analyze existing distille dintel.  Analyze research.  Collect raw intel.  Use expertise to build theories.

Hacking While Stressed

  • Dr. Celeste Lyn Paul
  • Human factors of infosec, mostly on the expert side and not the end-user side.
  • Mental health, stress, burnout.
  • What her employer does, required boilerplate, why I didn't present this year...
  • stress - physical and emotional reaction to adverse events
  • acute - temporary
  • episodic - repeated, little time to recover - start of adverse health events
  • chronic - enduring events, no sense of control
  • work-related stress - demanding job, little control, effort/reward imbalance
  • fatigue, frustration (anxiety), cognitive work (effort to use memory)
  • hacking is a set of complex problems that require creativity and planning.
  • unpredictable environments, things never go as planned.
  • high risk/high reward environments
  • Cyber count: 2
  • average tactical op length: 5 hours
  • Formal analysis and study overview...
  • Measure biometrics to gauge stress.
  • When you're under polygraph, you get more stress than you intend...
  • Fatigue and frustration, before and after.  Physical and mental demand.  Time pressure.
  • Operator fatigue increased 16%, frustration increased 12%.  (from baseline)
  • Is that a lot?  Depends on the cirucmstances.
  • Can't eliminate stress.
  • jinfowar.com
  • Self assessments of performance were independent of physical or mental stress.  They did as well as they did regardless of the effort required.
  • The only factor performance was linked to was frustration.
  • locus of control - the extent to which you feel you have control over outcomes
  • Frustration correlated with inverse of control over situation.
  • mistakes are taken as personal failures because they care about the mission
  • stress is self-induced due to buy-in
  • This makes it hard to manage.
  • Cyber is hard.
  • Maslow's hierarchy of needs.
  • if you can't survive, nothing else really matters
  • deficiency needs - if you don't have enough, you are focused on gaining them - everything but esteem (dignity, freedom, acknowledgement, status) and self-actualization (personal growth, peak experience, ambition).
  • Maslow's hierarchy of hacker needs:
    • self-actualization -> mission, personal achievement
    • esteem -> reputation, recognition, respect
    • love and belonging -> camraderie, teamwork, solidarity
    • safety -> authority, policy, support
    • physiological -> equiment, tools, access
  • Stress cannot be eliminated (short of eliminating stressors) but it can be managed.
  • mindfulness.  if you're running hot, have a spotter.  remember that it will be all right.
  • Creature comforts matter.  If you hurt, you can't think straight.  You don't want to be focused on physical problems.
  • Keep an eye on time.  You run down around five hours, give or take.  Take breaks.
  • As a manager, remember who you hired and why.

IMSI Catchers Demystified

  • cell site simulators/fake base stations
  • used by LEOs, military, PMCs
  • extreme secrecy - federal cases have been scuttled rather than divulging information
  • sometimes called Stingrays - this is one brand name made by Harris
  • IMSI - International Mobile Subscriber Identifier
  • unique IE for a SIM
  • IMEI - unique ID for cellphones
  • GSM to LTE based
  • lots of speculation
  • collect IMSIs of people in an area (at protests)
  • localize phones, figure out locations
  • content interception(?) (can certainly be done, Kraken is OSS)
  • remote exploitation of baseband bugs?
  • used in highly adversarial enironments
  • about a decade ago, DHS/FBI has been giving them to local LEOs for domestic use
  • foreign (counter)intel?
  • abuse and mass surveillance
  • criminal use
  • network interference
  • RCMP acknowledged that they use them, and confirmed that they interfere with e911 (five minutes at a time, two minute cooldown)
  • US senate wrote to the FCC about them, the FCC said they're used "in coordination" with the FBI, which doesn't have to comply with FCC regs, so fuck off and it's up to the FBI to do NDA stuff.
  • DHS was asked about foreign IMSI catchers in DC metroplex, and was it reported.  they confirmed "anomalous activity" but did not attribute it to IMSI catchers or entities.  DHS claimed that they have no technical ability to detect them, please give us more money to do it.
  • year-long pilot to look for IMSI catchers
  • anomalous activity was detected near "sensitive facilities" but can't attribute it and a few were actually real cell towers
  • legal framework is claimed to be the same as pen registers, trap-and-traces
  • pen registers don't count as 4th Amendment searches
  • no warrant required - third party doctrine
  • ECPA requires a court order - relevant to an ongoing criminal investigation
  • trap-and-trace records origins of incoming calls
  • usually lumped together with pen registers
  • wiretaps intercept content, not signalling traffic or metadata
  • is a search, does require a warrant
  • "Triggerfish"
  • capable of intercepting signalling and comms traffic, requires a warrant legally, so configure Triggerfish so it doesn't record comms content
  • some jurisdictions require warrants
  • even with a warrent, can you interfere with cellular?
  • Comms act of 1934 (47 USC)  - not really
  • section 2.807... US government is exempt
  • manufacturers got state governments to send form letters to the FCC that authorize sale to local governments.  FCC listened.
  • many of the documents you have to submit are public, so they wind up on the FCC website.  manufacturers got them to keep those docs secret, citing that they'd only be sold to LEOs and FBI coordination would be required.
  • FBI coordination letters may as well be more boilerplate.
  • NDA with FBI, FBI authorizes purchase, lots of interesting stipulations...
  • stipulations boil down to "STFU," including "Did you even use this at all?"
  • the FBI can ask you to drop the case rather than turn over evidence garnered from stingray use.  and this has happened multiple times.
  • Florida - ACLU sued Sarasota PD over public records requests - ACLU won - US Marshalls seized all of the records they were supposed to get - "federal property, not subject to public records laws, fuck your court order"
  • probably not collecting identifiers of all users in an area because they can subpoena tower dumps from cell providers (Carpenter vs. US)
  • probably not intercepting content, CALEA
  • easier, cheaper, more reliable
  • content interception requires a warrant, anyway
  • carriers can (ab)use e911 for localization
  • GSM - RRLP
  • UMTS - RRC
  • LTE - LPP and SUPL
  • can LEO demand active application rather that handing over records?  unknown.
  • Roximity, now something else, can query network providers for cellular locations.
  • LEOs use and abuse this (LOVEINT, stalking)
  • IMSI catchers cannot be used for precise location.  cellular coverage is cell-based (duh).
  • direction finding works for finding the right front door to kick in
  • all cell sites are connected to a central switch, calls are handed off when moving between areas.  phones have to tell cells when they transfer, but not every time.
  • GSM fundamentals..
  • fun fact: GSM has to account for the speed of light (Timing Advance).
  • mobile stations (phones) scann channels, lock on and synch to Base Transceiver Stations, adn receive System Information messages
  • Random Access Requests
  • Harris is the msot prominent vendor - the actual Stingray
  • Some data has been leaked, but not much.
  • Triggerfish is an analog device, probably does content interception.
  • Triggerfish had a jack for direction finding output.
  • Gossamer - portable, hand-held IMSI (and t-IMSI (temporary) catcher, can do a DoS against phones to block calls, can DF.
  • There is a TDMA Stingray, too.
  • Kingfish - man-portable, Bluetooth palmtop with a gargoyle rig.
  • Amberjack DF antenna ($38k?!?)
  • Harpoon - power amps
  • Hailstorm - Stingray + LTE
  • Wire the modules together, start sniffing.
  • Only one publically known photo of everything wired together.
  • Leaked price sheet states some of the capabilities
  • "collection"
  • Software manuals leaked and published by the Intercept in 2016
  • iDEN
  • "gemini mode" - DF and localization?
  • "GSM Interceptor"
  • survey mode - passive collection
  • logging - passive logging (paging, too?)
  • registration - IMSI, TMSI, IMEI collection
  • MSDF - Mobile Station DF - phone phone continually transmits
  • RayFish...
  • LTE requires redirection/downgrade to GSM or UMTS (and Hailstorm)
  • Gun Max - company that asked them for a price quote
  • gave price specs for what that they wanted the IMSI catcher to do... hfs.
  • Similar concepts apply to CMDA, UMTS, and LTE
  • Find the strongest cell, parse neighbor list, find weakest neighbor
  • You want your cell to be the strongest cell
  • Wireshark has dissectors for the protocols
  • Broken call setup.  Silent call.  Keep engaging on control channels.
  • Accidentally building IMSI catchers in the 900MHz band
  • Finding IMSI catchers is a matter of broadcast channel anomaly detection
  • Warsharing == Wardriving + Ridesharing
  • USCIS building in Seattle
  • SeaTac Airport
  • Asking phones to transmit at an unusual power level, unusual cell reselection history
  • SeaGlass app - ported OsmocomBB to Android, in the Play store, need a Motorola C139 phone
  • seaglass.cs.washington.edu

Hacking Non-Connected Cars

  • connected cars are hackable.  this is not news.
  • 4g, 5g, wifi, Bluetooth, GPS
  • critical car systems (like steering) are hooked to accessible networks.
  • but what about unconnected cars?
  • physical port into the CANbus network - OBD2 port
  • some cars, when you plug in even a passive sniffer, freak out.  dashboard locks up.
  • uh-oh.
  • have to disconnect the car battery to cycle power on the softlocked CPU.
  • 2006 to today
  • obd2 diagnostic port used by mechanics
  • inside the cabin, usually near the steering wheel
  • pinouts are googlable
  • other protocols than CANbus are used and found
  • internal network is based on bus topology
  • L1 protocol designed specifically for use in very EM noisy environments
  • CAN-H and CAN-L signals.  as long as the two signals are equal and opposite, it's a clean bit.  seems easy to filter noise out of, too.
  • CAN frame layout...
  • CANbus network protocol analyzer software... Wireshark probably has a dissector.
  • CANspy - platform for auditing CAN devices
  • there are several tools for doing this
  • just don't use ELM327 - it's a diagnostic tool not a sniffer, it's cheap, it sucks
  • while sniffing, do something in the car (turn on the headlights) and watch all the traffic that results.  very chatty - who knew it was so busy?
  • dashboards today are much closer to demos than actual displays anymore... sheesh.
  • CAN frames can be injected as well as passively monitored
  • invented a physical hardware implant for backdooring cars
  • PIC uc programmed for CAN, transceiver
  • GSM modem for remote control via SMS commands
  • "The Bicho" (Spanish - little insect)
  • https://github.com/UnaPibaGeek/thebicho
  • visual CAN frame builder and transmitter, C++
  • builds raw CAN frames - hex values get serialized
  • doesn't seem to support commands of the form "turn on the headlights"
  • can spoof SMS origin :)
  • "STOP" command can be remotely disabled :)
  • "Kill ECU" command does what it says on the tin - holy fuck
  • opencandb.net

Accelerating a RAID-5 array with a solid-state hard drive.

0
0

A couple of weeks ago, one of my co-workers mentioned in passing that he'd surprised himself by adding an SSD (solid state drive) to his file server at home.  To recap a bit, Leandra, my primary server at home has a sizable RAID-5 array storing all of my data.  However, one of the tradeoffs is that stuff recently written to the array is a little slow to be read back.  It's really not noticeable unless you're logged in and running commands, and even then the lag is something like one or two seconds.  Noticeable but not actually problematic.  At any rate, I'd been wanting to do some tinkering lately and had an Amazon order planned because I wanted to do some electronic work on my warwalking rig so I figured that, depending on the cost, I might add an SDD to my order.  Much to my surprise, a 120 gigabyte SSD is incredibly cheap, I paid a hair under $20us for a Kingston A400.  Emminently affordable.

Installing the SSD was surprisingly trivial.  Modulo a detour to count the number of SATA ports free on Leandra's mainboard (because I'd forgotten) and figuring out how long a SATA cable I'd need (for the record, a 1 meter SATA cable was more than enough to reach from port-to-SSD given the size of Leandra's chassis) mounting the SSD in Leandra's old floppy drive bay was a ten minute job, mostly because I took some extra time to make sure the cables stayed neat.

I'd done some research on the best way to go about adding a cache drive to an LVM, but ultimately I wound up using the instructions in the Arch Linux Wiki because my own research just didn't work.  Sometimes that happens.

A little bit of context, because it can be confusing (and there are one or two gotchas inherent in the procedure): First, the logical volume is built on top of the RAID-5 array, so forget about the fact that there's a RAID.  It doesn't matter, and you won't be messing with it.  Second, when you add a cache drive to a logical volume, you're not adding it to the volume group (the meta-pretend-big-ass virtual hard drive), you're adding the cache to a logical volume (a virtual, pretend partition of that meta-pretend-big-ass virtual hard drive).  So, I couldn't add it to the entire volume group, I had to add it to one logical volume, /home (or /dev/mapper/leandra-home).  All things being equal, the only thing I was really worried about speeding up was /home because that's where my home directory with all my stuff is.  In theory I could have "partitioned" the SSD so that there would be some cache space for each logical volume, but I wound up dropping that idea because what worked wasn't really feasible.

The SSD (henceforth referred to with the device file /dev/sdf) was a brand-new drive so I had to partition it first.  I created one big partition because I was going to add it to the volume group as a new device (and LVM doesn't care about the sizes of the devices (or physical volumes) that comprise it).

{19:14:36 @ Sun May 19} [drwho @ leandra:() ~]$ sudo fdisk /dev/sdf n p 1 <hit enter a few times to accept the default values> w

Create a physical volume on the SSD:

{19:20:01 @ Sun May 19} [drwho @ leandra:() ~]$ sudo pvcreate /dev/sdf1

Add the physical volume to existing volume group (named leandra):

{19:20:01 @ Sun May 19} [drwho @ leandra:() ~]$ sudo vgextend leandra /dev/sdf1

Now, here's the bit that took some trial and error: Create the cache and add it to the /home logical volume all in one go.  It seems scary but it really does work:

{19:20:01 @ Sun May 19} [drwho @ leandra:() ~]$ sudo lvcreate --type cache --cachemode writethrough -L 100G -n cachepool leandra/home /dev/sdf1

Note that the name of the logical volume is specified as "volume group/logical volume", here leandra/home.  Also note that I told the lvcreate utility which disk device to use as the cache (/dev/sdf1).  The output of the lvcreate command looked like this:

Using 128.00 KiB chunk size instead of default 64.00 KiB, so cache pool has less than 1000000 chunks. Logical volume leandra/home is now cached.

Last and certainly not least, let's ask the lvs utility what it sees.  As you can see in the output, the "cachepool" entry reflects what the solid-state cache was called when it was built (-n cachepool), the value of "Data%" is how much of the cache is used, and the value of "Meta%" is how much of the cache metadata (data that describes the cached data):

{19:32:02 @ Sun May 19} [drwho @ leandra:() ~]$ sudo lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert home leandra Cwi-aoC--- 11.05t [cachepool] [home_corig] 12.11 24.10 0.00 opt leandra -wi-ao---- 1.00t srv leandra -wi-ao---- 1.00t var leandra -wi-ao---- 1.50t

If you look at the value of "Attr" in the above output it's different from the other three logical volumes (-'d entries omitted because they're null):

  • C - Cached volume
  • w - Volume is mounted read/write
  • i - Data allocation policy is inherited from elsewhere (i.e., the default)
  • a - Active
  • o - Open
  • C - Target type: Cache

End result: My home directory on Leandra is now running faster than greased teflon.  Not bad for maybe $30us worth of parts off of Amazon.

Neologism: Disasterbation

0
0

disasterbation - noun - Idly fantasizing about possible catastrophes (World War III, EMP strikes, nexus collapse, civil war, simulation hypothesis system shutdown, full-blown hyper-blight) without considering their likelihood or their possible solutions and preventions.  Very common in the prepper and futurist communities.

Source: M. Alan Kazlev (updated a bit and cross-referenced by me)

Another .plan file update.

0
0

Yup, I've updated my .plan file yet again.  The usual warnings about NSFW content apply.


Have you tried turning it off and back on again?

0
0

Disclaimer: The content of this post does not reflect my current employer, or any of my clients at present.  I've pulled details from my work history dating back about 20 years and stitched them into a more-or-less coherent narrative without being specific about any one company or client because, as unfashionable as it may be, I take my NDAs seriously.  If you want to get into an IT genitalia measuring contest please close this tab, I don't care and have no interest.

Time was, back in the days of the home 8-bit computers, we were very limited in what we could do in more than one way.  Without even a proper reset button or development tools other than the built-in BASIC interpreter if something went wrong there was really no way that you could debug it.  If you happened to be hacking code in any serious way on the Commodore chances are you'd shelled out good money for a debugger or disassembler and had at least a couple of reference books nearby.  If you were doing everything in BASIC then either you were growing your program a few lines at a time or using some code you got out of a magazine to do low level programming from inside of BASIC (an exercise fraught with frustration, let me tell you).  Even then, if something went sideways it was difficult to figure out where you went wrong and fix it.  The tools just weren't common at the time.  All you could really do was turn off the machine, wait a few seconds, turn it back on, and give it another shot in the hope that the machine wouldn't lock up on you again.

Now let's jump ahead a couple of decades to the twenty-first century.  We're writing just about everything server side in Java and deploying .jar files that are anywhere from a couple of tens of gigabytes to a couple of hundred gigabytes in size, counting the dozens of dependencies that have to be installed and/or are packaged with your application to make the bloody thing work.  Dozens upon dozens of libraries that do something so your devs don't have to tear their hair out re-inventing innumerable wheels yet again.  We have cloud hosting providers offering everything and the kitchen sink that you might decide to use for building whatever your enterprisey at-scale thingy is.  And because we can't leave well enough alone, we have to take perfectly good servers and dice them up into virtual machines, and then run clusters of containers inside of those virtual machines with virtual networks tying them all together.  And once you start getting really creative you have to figure out how to get everything communicating appropriately, which means managing configuration information and secrets.  And then throw in load balancers and collecting metrics to monitor it all.  It's a virtual Cambrian explosion of software components.

Eventually you've taken what seemed at first like a fairly straightforward system and sent its complexity spaceward.  And sometimes that's what you have to do - if you want tens of thousands of people using the same thing at the exact same second day in and day out you have to have enough resources for them to hammer on.  Gone are the days where you could stand up one database server, one web server, and one application server on the same subnet and have a product.

The thing about all of these dependencies - all of these databases, application servers, web servers, streaming pipelines, message queues, microservices, and whatever else may come - is that at some point you can't know for sure at any given moment what's going on anymore.  As these systems become more complex emergent behaviors appear.  Some work in your favor, some are just there and you have to learn how to live with them because they're strange but not hurting anything, and some can being the whole shebang crashing down around your ears faster than you can throw your work phone against the wall.  Sometimes it happens that there are very tight tolerances on timing or communication delays in between components and a few extra microseconds (even mere milliseconds are too long!) in between an event being sent and being received can cause multiple components to stop functioning correctly.  Or a third party application decides that it's going to stop responding, peg the CPUs, and cause the rest of the system to slam to a dead stop and you probably don't have any easy way of getting at its insides to see what's happening.  Or there's a bug in an undocumented API that one of your dependencies uses that your code tickled in just the right way to freeze it solid.

The hell of it is, there are no tools for debugging these sorts of emergent properties in a complex system.  It isn't any one component of the system that's acting up to cause trouble, it's the cumulative and sometimes chaotic interactions of every component with every other component resulting in a stunning demonstration of the principle of definitional equivalence.  Who knew that a job scheduler that didn't have anything to fire off for just two seconds would cause a database connector to crash and drop all of its active connections?  How is it that a service bus with a number of customer services that's an even power of 3 will start randomly throwing away messages before any of the customer services can grab them for processing?  Why does running an application inside a container cause it to crash when it gets too busy, but running it on its own virtual machine with an overabundance of system resources that it never makes use of is just fine, but it refuses to even start on the next virtual machine size down?  Who could have predicted that deep inside a third-party service is a leftover check to see if it's running as root (which you should never, ever do without a good reason) which caused it to crash without warning?

Nobody has any idea.  This stuff comes out of nowhere like a meteor on final approach.  You can spend days and weeks and months throwing every utility and trick in the book at it and you'll be no closer to understanding the reasons than you were when you started.  Audit the code all you like because eventually you'll stop noticing the bugs that'll come back to bite you the next time you're on call.  All you can do is log in, terminate the box with extreme prejudice, and let your provider automatically fire up a replacement.  Answers?  Zero if you're lucky.  But no outage, and no angry customers flaming you on Twitter about your SLA.

We've basically come full circle, as the industry tends to do.  We started off as "pull the power, it's locked up again" to having tools available to diagnose and fix bugs.  And it was good for a while.  But then we somehow went all the way back around to "just reboot it, because we can't fix it."  And that's really all we can do because that complexity defines the baseline of everyday life.  At the very least, stuff comes back up most of the time.

Hacking around memory limitations in shared hosting.

0
0

Longtime readers are aware that I've been a customer of Dreamhost for quite a few years now, and by and large they've done all right by me.  They haven't complained (much) about all the stuff I have running there, and I try to keep my hosted databases in good condition.  However, the server they have my stuff on is starting to act wonky.  Periodic outages mostly, but when my Wallabag installation started throwing all sorts of errors and generally not working right, that got under my skin in a fairly big hurry.  I reinstalled.  I upgraded to the latest stable release.  I installed the latest commit from the source code repository401 and 500 errors as far as the eye could see whenever I tried to do anything regardless of what I did.

In a misguided attempt to figure out what was going on, I bit the bullet and installed PHP on one of my servers, along with all of the usual dependencies and tried to replicate my setup at Dreamhost.  What that was a bit tricky and took some debugging I eventually got it to work.  It was getting my data out of the sorta-kinda-broken setup that proved troublesome.

Wallabag has a built-in data export feature which will allow you to take copies of your stored articles with you in a variety of formats.  Every time I tried to use it, however, I kept getting an HTTP 500 error - something was broken either on the server or in my install.  Poking around in the server logs showed that Wallabag kept using up all of the memory available to it.  In hindsight, perhaps I pushed things a little too far.  This isn't uncommon on shared hosting, by the way - if you're going to turn people loose on your server you have to have some restrictions in place to keep everyone from accidentally killing the box with all of their stuff.  It just so happened that the php-fpm daemons they'd allocated me were just a little short of memory to get my data dumped.  I wasn't able to get anything using the console commands, either.  Now what?

Statement of the problem:

  • Get my data out of the messed up Wallabag install.
  • Figure out how to parse said data.
  • Pump said data into my new Wallabag install.

When it comes to extracting data from recalcitrant applications, this isn't my first rodeo.  Off to the API documentation.  Step one: Get an API token to authenticate me to Wallabag:

[drwho @ leandra:(3) ~]$ curl -s "https://wallabag.virtadpt.net/oauth /v2/token?grant_type=password&client_id=AAAAA&client_secret=BBBBB &username=CCCCC&password=DDDDD" {"access_token":"EEEEE","expires_in":3600,"token_type":"bearer","scope":null, "refresh_token":"FFFFF"}

(Secrets redacted, of course.)

Step two: Get (or, GET) Wallabag entries out of the database into a format I can use (namely, JSON for reimportation) using the /api/entries.json API call.  Due to the sheer volume of articles I have stashed away, I had to do it in batches of 500 or so at a time and store each batch into a separate file:

{14:22:13 @ Thu May 30} [drwho @ leandra:(3) ~]$ curl -X GET "https://wallabag.virtadpt.net /api/entries.json?access_token=EEEEE&perPage=500&page=1" > wallabag-1.json {14:22:13 @ Thu May 30} [drwho @ leandra:(3) ~]$ curl -X GET "https://wallabag.virtadpt.net /api/entries.json?access_token=EEEEE&perPage=500&page=2" > wallabag-2.json {14:22:13 @ Thu May 30} [drwho @ leandra:(3) ~]$ curl -X GET "https://wallabag.virtadpt.net /api/entries.json?access_token=EEEEE&perPage=500&page=3" > wallabag-3.json ...

You get the picture.  Repeat until done.

Now the fun part: Re-importing those batches of articles into the new Wallabag install.  As it turned out, I couldn't just import them with Wallabag's built-in file reader, they're not in the right format.  So, after taking a look at one of the files in a text editor I decided to hack together a quick bit of Python that would read in a batch of JSON, take each article, pick out the information needed to populate a new entry, and fire it over to the server using the /api/entries.json API call using POST instead of GET this time.  It's short, it's sweet, it got the job done, and it could probably be turned into a utility with a little bit of spit and polish.

parameters = {} parameters["grant_type"] = "password" parameters["client_id"] = "GGGGG" parameters["client_secret"] = "HHHHH" parameters["username"] = "IIIII" parameters["password"] = "JJJJJ" request = requests.post("https://new.wallabag.virtadpt.net/oauth/v2/token", data=parameters) headers = {} headers["Authorization"] = "Bearer " + request.json()["access_token"] file = open("wallabag-X.json") articles = json.load(file) file.close() for article in articles["_embedded"]["items"]: parameters = {} parameters["url"] = article["url"] parameters["title"] = article["title"] parameters["content"] = article["content"] if article["tags"]: parameters["tags"] = article["tags"] parameters["published_at"] = article["updated_at"] parameters["origin_url"] = article["url"] request = requests.post("https://new.wallabag.virtadpt.net/api/entries.json", data=parameters, headers=headers) print("Uploaded article: " + parameters["url"]) print()

I had to watch the server logs in realtime from another window because Wallabag's access tokens are only good for an hour, and when they expire you get 401 errors again.  And, of course, no new articles imported.  So, I basically ran that blob of code over and over again until all of my data was in the new Wallabag server.  It's not my finest work but it got the job done.  The new Wallabag server seems to be working pretty well across two different web browsers and two Android devices.  Much more reliably, too - when you're not contending with an unknown number of other users, thing seem to work smoothly.  Who knew.

It's been a while. Summer vacation, if you like.

0
0

I haven't actually been on vacation lately, not really.  I decided that I needed to go off and do some different stuff for a while.  I've been in a rut lately and decided that I needed to shuffle some stuff around.  I swapped out the "writing rambling computer nerd blog posts" module for teaching myself a couple of new things and spending some of my downtime offline, curled up with cinnamon tea and a stack of books.  Getting away from a screen for a while seems to have done me some good, and I'm almost back up to my old reading pace of five or six books a week.  I'd all but forgotten how much dead tree books weigh after the fixed mass of a tablet for so long.  The wireless router at home that I set up to replace the astoundingly shitty DSL modem-cum-wireless access point that Annoying, Trying, and Twisted insists we use is starting to act flaky, which suggests that it's reached the end of its functional life, not unexpectedly since this model tends to have overheating problems.  A few weeks back I picked up a new router, a Linksys WRT 1200 AC and promptly made a few hardware modifications to it, which is to say I cracked open the case, unbolted the heat sinks, scraped the crappy thermal tape off of the chips and applied decent heatsink grease, and put the router back together.  I'm considering wiring a small cooling fan onto the motherboard, maybe on one of the development ports.  Lately I've flashed OpenWRT onto the unit and set up quality of service and monitoring so I can keep an eye on things.  I'm still working out how to patch it into my exocortex for realtime status monitoring.  From a practical standpoint I can install Python on the new router, but doing so leaves next to no room for anything else.  I have to think about it some more.  I do NOT want to use SNMP if I can help it.

If you thought you were going to escape computer nerd-related rambling, you were sorely mistaken.

In all the time I've been working on Systembot, I somehow forgot to add support for questions like "Systembot, what time is it where you are?"

At my dayjob these days, I seem to do a lot of work with Docker, which is one of a slew of new-school applications for deploying applications on servers and managing them.  To explain it simply, I should probably explain some computing history first.  Trust me, it'll make the explanation much easier.

Once upon a time, we had mainframes, big honking machines that filled entire data centers and carried out vast (for the time) tasks.  To make mainframes easier to use time-sharing operating systems were developed, which allowed multiple users (often a couple of hundred at a time) to do stuff at the same time.  Then, for various reasons mainframes OSes implemented virtual machines which, as far as users and applications were concerned gave them an whole mainframe all to themselves.  Several decades later virtual machine technology reached street level (so to speak) with the release of VMware Workstation, Virtualbox, and then everybody's (least) favorite service provider, Amazon Web Services.  Computer geeks and devops engineers are nodding along sagely; I'm writing this for everyone who isn't, so be nice.  Times being what they are, it got too tricky to wring every last erg of power out of even fleets of virtual machines running on stupidly powerful hardware.  Managing applications got more difficult, and on top of that just getting them to run the way they were supposed to got harder because everything even vaguely enterprisey has its own slew of dependencies, usually of different conflicting versions.  Enter containerization.

In a nutshell, containerization is when the OS is able to carve off little parts of itself - memory, disk space, space in the process table, and so forth - stick them together, and give them a name called a namespace.  As far as the OS (and any users) are concerned, every namespace is a single process running on the system, like any other.  They can't interact with each other without explicitly setting them up to do so.  Give the namespaced container a file system and a really, really stripped down environment and you have, for all intents and purposes a really tiny server.  As far as anything you install into a container is concerned, it thinks it's running in an isolated server all by its lonesome.  All the junk that an application needs can be installed into a container can be without having to worry about stepping on each other's dependencies.  Containerization has really come far since Solaris.

In addition to getting some practice time in for my next maintenance run at work (it's hard to mess around when there are paying customers), of course I was tinkering with Huginn again.  A stumbling block for many years for me has been the limited selection of agents, in theory easy enough to fix by writing more of them.  Just one thing: Ruby, as a language, drives me up a fucking wall.  I've been trying to learn it for a couple of years now and I'm no closer to getting anywhere with it than I was five years ago.  For my money, Ruby code reads like somebody decided to drop three hits of acid, read the language spec for Pascal, and decided to write an interpreter for it.  Someone in a Huginn chat I monitor mentioned using OpenFaaS with Huginn and, smelling an opportunity I decided to play around with it.  Long story short, I've been enjoying writing my own pseudo-agents (yes, I need to write documentation!) using OpenFaas and converting a few command line tools into functions along the way.  I've been loading them to my Docker Hub account in case anyone might find them useful.  Basically, if you can make it listen on port 8080/tcp and print stuff out, you can use it as an OpenFaaS function.

Yes, I've been shamelessly geeking out for the last month or so.  And I've needed to, because I needed to recharge.  I had to do something different from what I've been doing lately.  Still working out what to do next, truth be told.  I'm writing this during a long weekend (as inferable from the timestamp) so I'm deliberately just... not doing much of anything.  This is probably showing in my writing, as I've covered pretty much everything I wanted to cover, and now I'm trying to figure out a good way to end this post.  I might write some stuff up later, might throw up my backlog of event photos over the new few weeks.

Fuck it, I may as well get this in the open just like everyone else.  I live in a country that is running concentration camps. (local mirror, 20190708)  Actual, no shit, "Didn't you assholes learn anything from history?!" concentration camps and the few people who have any kind of political clout are witnessing it firsthand and basically being told point blank "Go fuck yourselves."  I'm frightened out of my mind and I'm sick in my hearts that this is going on.

Got some new hardware installed.

0
0

For a couple of years now, I've had my eye on the community of people who've had RFID or NFC chips implanted somewhere in their bodies, usually in the back of the hand.  If you've ever used a badge to unlock a door at work or tapped your phone on a point-of-sale terminal to buy something, you've used one of these two technologies in your everyday life to do something useful.  What I've wanted to do for a while was use an implanted chip as a second authentication factor to my servers for better security.  As for why I couldn't just use something like a key fob or a card or something.. there were a bunch of reasons, most of them having to do with only being able to find what I needed in bulk or the cost being too high because the equipment was aimed at corporate IT departments, where they have a need to crank out a couple of dozen ID badges an hour.  There is also the fact that, while I've been curious about various forms of body modification over the years I never really got into into them for a couple of reasons that probably aren't terribly interesting so why not do something useful?

Due to the fact that not everybody is going to be okay with me talking about an elective medical procedure, I'm going to put the rest of this article after the fold.

What proved to be a more significant problem was actually getting the procedure done.  After making the decision and realizing that there was little to no chance that I could install it myself I had to find someone who could implant the chip for me in a reasonably safe manner.  This took a couple of years, including a few failed attempts to get to the biohacking village at Defcon.  Early last week through a backchannel, I found out that Amal Graafstra of Dangerous Things and pretty much a vanguard in the field of elective implantation would be speaking at a nearby meetup and he'd have a batch of injectable chips with him.  Of course, opportunity was knocking and I hit the button as fast as I could before rearranging my schedule a bit to accomodate.

Cutting to the chase, the installation procedure was fairly straightforward albeit a little hairy in places.  The kit that I had purchased was the NExT RFID/NFC hybrid implant, meaning that it has the capabilities of both wireless tags in one tiny glass capsule 14mm long by 2mm in diameter, about the size of one or two large grains of rice.  The chip is small enough to fit inside a 14 gauge needle attached to a one-shot injector.  It was a little bit bigger than an IV cannula (though I might be overestimating slightly).  Also included in the kit was a chlorhexidine surgical prep, the same kind of tear-off bandage used to hold IV lines in, a couple of sterile gauze pads, a pair of nitrile gloves, and a disposable surgical field that unfolds onto a flat surface.  The injection itself was complicated by a couple of connections in the back of my hand that had to be routed around, so rather than "jab, inject, withdraw," the procedure wound up being "jab, root around a little bit, inject, carefully withdraw so nothing gets nicked."  This is more an artifact of my body than anything someone else would have to worry about.  For this reason it hurt a bit; I've never gotten a piercing before, so the only thing I can compare it to is getting an IV put in the last time I was in the hospital.  Total installation time was eleven seconds (after watching the video).

It's two days later as I write this and the only sign that anything happened is a 1/8" scab between the thumb and forefinger of my right hand.  There's a little bit of creeping bruising, probably due to my reaching in to a reasonably narrow jar repeatedly to scoop out coffee.  The chip is small enough that I can't actually feel it unless I'm right on top of it, and even then it's only the tenderness around the unit that registers.  It's between the hypodermis and fascia, maybe a quarter of an inch down if that.  Weirdly, the first day after I was getting some phantom pain on the opposite side of my body.  That went away by Friday and now I just have a slight ache in my hand if I type a little too hard.  The chip isn't embedded in the musculature, nor is it coated with a surgical bonding agent so if I ever need to get it removed, I can go to a general practitioner and have it done in maybe ten minutes time (with a local), or a bit less without one with a scalpel and a little pressure.  The soft tissue surrounding the chip (and along the injection channel) should be fully healed up in about two weeks, I'm told.

Following the obligatory "Why in the hell would you do such a thing?!" conversation when I got home (which is entirely fair), I thought it might be useful to someone out there to write up a few of the things that came up.  The implanted chip is passively powered, meaning that a signal from the reader (RFID or NFC, they're not the same) is what powers it.  It's not active all the time.  The range of the chip is very short; you quite literally have to have the sensor sitting right on top of it due to the fact that it doesn't technically have an antenna, it has a miniature inductance coil.  The signal is also undoubtedly attenuated by the fact that it's inside my body.  All in all, you'd have to be within a quarter inch of the glass capsule to read the chip, and that's a generous estimate.  In addition to that, I discovered that the position of the reader relative to the orientation of the chip is important and makes it somewhat difficult to access.  A certain amount of turning one way and another is necessary, as is moving the sensor around a bit so it picks up.  So, this chip really isn't useful as a tracking beacon.  You'd have to be sitting on top of me to pick up the signal, and by definition then you wouldn't need to track the signal.  The implanted chip doesn't have any sensors on board, nor is it capable of carrying out any calculations on its own (though there are a few implants capable of this, but of course they also need to be externally powered by a reader).

In theory I could store whatever I wanted inside the chip; I don't have an interactive RFID reader yet, but pinging the NFC part with an app on my phone reveals (among other things) a serial number which looks a bit like a MAC address, the amount of storage space (820 bytes), and a URL (dngr.us/NExT).  My phone says that I could add a few more records to the chip, erase it, or even set an admin password to keep people from messing with it (which I'm going to do).  On the RFID side of the house, it's fairly easy to get a reader which plugs into a USB port and pretends to be a keyboard, meaning that whatever is on the chip gets typed into whatever terminal or window is open, including a secondary password or a certificate.  RFID is less secure than NFC, though, so I might reserve it for shenanagains the next time I go to a con.  I think that's going to be my next project.

Neologism: Checkers and chess

0
0

checkers and chess - noun phrase - A situation where two or more actors in a situation are using entirely different strategies, working toward two entirely different goals, or are following entirely unrelated ideologies.  With sufficient cluelessness the actors in question may never actually come into conflict, even though they may be convinced they are fighting tooth and nail with one another.  The end result is a complete and total waste of time, money, and energy.

Viewing all 210 articles
Browse latest View live




Latest Images