A 6502, In The Shell

Shell scripting is an often forgotten programming environment, relegated to simple automation tasks and little else. In fact, it’s possible to achieve much more complex tasks in the shell. As an example, here’s [calebccf] with an emulated 6502 system in a busybox ash shell script.

What’s in the emulator? A simple 6502 system with RAM, ROM, and an emulated serial port on STDIO. It comes with the wozmon Apple 1 monitor and BASIC, making for a very mid-1970s experience. There’s even a built-in monitor and debugger, which from our memories of debugging hand-assembled 8-bit code back in the day, should be extremely useful.

Although the default machine has a generous 32k of RAM and 16k ROM, you can easily adjust these limits by editing machine.sh. In addition, you can get a log of execution via a socket if you like. Don’t expect it to run too fast, and we did have to adjust the #! line to get it to run on our system (we pointed it to bash, but your results may vary).

What you use this for is up to you, but we’re sure you’ll all agree it’s an impressive feat in the shell. It’s not the first time we’ve seen some impressive feats there, though. Our Linux Fu column does a lot with the shell if you want further inspiration.

Linux Fu: Use The Source (Command), Luke

You can argue if bash is a good programming language or not, but you can’t argue that it is a programming language. However, there are a few oddities about it that make it different from most other languages you probably know. For one thing, variables are dynamically scoped. Second, you can easily change variables in an upper scope. This leads to a problem when you want to do something like reset your path:

#!/bin/bash
#: This does NOT work
PATH=/usr/bin:/bin

Well, actually, it does work; it just doesn’t work the way you imagine it might. The key is to realize that when you execute our script (say, resetpath), a new copy of bash runs. It inherits all the variables from your shell. Now the script sets PATH for the new copy of bash. Anything else you run in that script will see your change. But when the script exits, the new copy of bash is gone and the old copy sees the same old PATH it always did.

Continue reading “Linux Fu: Use The Source (Command), Luke”

Bits of GRUB syntax on pink background

Wake, Boot, Repeat: Remote OS Selection With GRUB And ESP

What do you do when you need to choose an OS at boot but aren’t physically near your machine? [Dakhnod]’s inventive solution is a mix of GRUB, Wake-on-LAN (WOL), and a lightweight ESP8266 running a simple HTTP server. In the past, [dakhnod] already enlightened us with another smart ESP hack. This one’s a clever combination of network booting and remote control that opens up possibilities beyond the usual dual-boot selector.

At its core, the hack modifies GRUB to fetch its boot configuration over HTTP. The ESP8266 (or any low-power device) serves up a config file defining which OS should launch. The trick lies in adding a custom script that tells GRUB to source an external config:

#!/usr/bin/env cat 
net_dhcp 
source (http,destination_ip_or_host:destination_port)/grub/config

Since GRUB itself makes the HTTP request, the system needs a running web server. That could be a Raspberry Pi, another machine, or the ESP itself. From there, a WOL-enabled ESP button can wake the PC and set the boot parameters remotely.

Is it secure? Well, that depends on your network. An open, unauthenticated web server dishing out GRUB configs is risky, but within a controlled LAN or a VLAN-segmented environment, it’s an intriguing option. Automation possibilities are everywhere — imagine remotely booting test rigs, toggling between OS environments for debugging, or even setting up kiosk machines that reconfigure themselves based on external triggers.

For those looking to take it further, using configfile instead of source allows for more dynamic menu entries, although it won’t persist environment variables. You could even combine it with this RasPi hack to control the uptime of the HTTP server. The balance between convenience and security is yours to strike.

If you’ve got your own wild GRUB customisation, let’s hear it!

A CaptionCall Phone Succumbs To Doom, Again

Pour one out for yet another device conquered. This one’s a desk phone for conferences and whatnot, a colour display, a numpad, and a bog standard handset with a speaker and mic. Naturally, also running Linux. You know what to expect – [Parker Reed] has brought Doom to it, and you’d be surprised how playable it looks!

This is the second time a CaptionCall device has graced our pages running Doom — CaptionCall patched out the previous route, but with some firmware dumping and hashcat, root has been acquired once again. [Parker] has upgraded this impromptu gaming setup, too – now, all the buttons are mapped into Doom-compatible keyboard events coming from a single input device, thanks to a C program and an Xorg config snippet. Feel free to yoink for your own Doom adventures or just general CaptionCall hacking!

If you’re interested in the hacking journey, get into the exploitee.rs Discord server and follow the hack timeline from password recovery, start to finish, to Doom, to the state of affairs shown in the video. Now, as the CPU speeds have risen, should the hackerdom switch away from Doom as the go-to? Our community remains divided.

Continue reading “A CaptionCall Phone Succumbs To Doom, Again”

Linux Fu: USB Everywhere

It is a common problem: I have a USB device on a computer out in the shop, and I want to use it from the comfort of my office. What to do? Well, you could remote desktop into the distant machine. But, honestly, I always find any remote desktop more than ssh clunky and somewhat undesirable. Fortunately, Linux can do virtually anything if you only know how to do it. So, this time, I’ll show you how to transport a USB device over your network. Of course, I have a network that reaches out to the shop. It should be a simple matter to tell my desktop machine that one of its USB devices lives across the network. Well, it wasn’t that simple, but it is doable.

The Tools

The whole thing involves a program called usbip. That should be the end of it, but of course, it isn’t. In order for this to work, both machines on the network will need some kernel modules and a daemon on the server: the machine with the USB devices to share.

You may be able to install usbip from your package manager. On Ubuntu, it is in the linux-tools-common package, so a simple apt-get might give you everything you need. I wasn’t so lucky. Continue reading “Linux Fu: USB Everywhere”

Give Your Animal Crossing Villagers The Gift Of Linux

If you’ve played any of the versions of Nintendo’s Animal Crossing over the years, you’ll know that eventually you get to the point where you’ve maxed out your virtual house and filled it with all the furniture you could possibly want — which is arguably as close to “winning” the game as you can get.

But now thanks to the work of [decrazyo] there’s a piece of furniture that you can add to your Animal Crossing house that will never get old: an x86 emulator that boots Linux. As explained in the video below, this trick leverages the fact that Nintendo had already built a highly accurate Nintendo Entertainment System (NES) emulator into Animal Crossing on the GameCube, which could be used to run a handful of classic games from within the player’s virtual living room. But it turns out that you can get that emulator to load a user-provided ROM from the GameCube’s memory card, which opens the doors to all sorts of mischief.

Continue reading “Give Your Animal Crossing Villagers The Gift Of Linux”

Make A Secret File Stash In The Slack Space

Disk space is allocated in clusters of a certain size. When a file is written to disk and the file size is smaller than the cluster(s) allocated for it, there is an unused portion of varying size between the end of the file’s data and the end of the allocated clusters. This unused space is the slack space, it’s perfectly normal, and [Zachary Parish] had an idea to write a tool to hide data in it.

The demo uses a usb drive, using the slack space from decoy files to read and write data.

[Zachary]’s tool is in Python and can map available slack space and perform read and write operations on it, treating the disparate locations as a single unified whole in which to store arbitrary files. A little tar and gzip even helps makes things more efficient in the process.

There’s a whole demo implemented on Linux using a usb drive with some decoy files to maximize the slack space, and you can watch it in action in the video embedded below. It’s certainly more practical than hiding data in a podcast!

Note that this is just a demo of the concept. The approach does have potential for handling secret data, but [Zachary] points out that there are — from a serious data forensics point of view– a number of shortcomings in its current form. For example, the way the tool currently structures and handles data makes it quite obvious that something is going on in the slack space.

[Zachary] created this a few years ago and has some ideas about how to address those shortcomings and evolve the tool, so if you have ideas of your own or just want to try it out, the slack_hider GitHub repository is where you want to go.

Continue reading “Make A Secret File Stash In The Slack Space”