I am not an affiliate of any of the links provided in this entry. No product referenced in this blog is an endorsement. I’m just a guy posting a thing.
Because I’ve been working extensively with Bitmain’s ASIC line for quite a while, I’ve naturally had to create tools and scripts for this line of hardware. The basis for these systems is a Nix variant running on a custom built Beagle Bone control board driving the ASIC boards. Generally the user interacts via a web service running the ASIC via another computer, which acts as a control terminal for all of the hardware at the controller’s site. These units also run SSH, allowing full access to the system.
I’d written scripts to mass configure the units some time ago and with the help of one of my crew, Mat Vaughn, I was able to determine the nature of how the IP REPORT button mounted on the front of the Bitmain hardware works. Those familiar with the Bitmain IP report tool will tell you that the client software from Bitmain runs on windows systems and, by running this software on your client and pressing the button on the ASIC unit, you can get the IP address of that particular unit. A lot of people out there are familiar with this simple software and they use it to locate the logical addressing of their physical units.
This may be acceptable for casual users, but I didn’t find this adequate for my uses. For one, I prefer to operate from Linux systems, and Bitmain’s tool offered no Nix variant. Second, I needed to be able to progressively and rapidly record multiple devices IPs and MACS and logically map them based on the rack,shelf,stall position nomenclature, rather than manually inputting locations. Finally, I needed to standardize this so that I could use it on ANY computing hardware, not just Bitmain’s ASICS, but custom built GPU rigs, servers, or any other computers on the network.
What we learned in playing with the IP Report button and using wireshark/tcpdump was that the ASIC host sends a UDP packet containing the IP and MAC to the broadcast address on port 14235. Mat whipped up a netcat
nc -lu 0.0.0.0 -p 14235
and confirmed the output in raw format. By the end of the evening, I’d written up a test script in python that perpetually runs a listener UDP server. Listener.py was my first test for this, and I still find myself using it for diagnostic testing with these units.
Because MACS are ‘burned in addresses’ that we can use to associate the logical addressing of an IP with a physical device. It’s not perfect, but from the network perspective, we can hunt down devices much faster. Because we use logical addressing to interface with the devices over network, if we can pair a physical location to a physical device that we can always logically locate that device and know we are interacting with that particular physical inventory unit.
Within a few days of writing the listener test I wrote Mo’BetaIPR, a complementary setup to the configuration script, CIRCS , which allows a user to pair the workernames designated with configuration to a physical location via use of the IP report button, and nested ‘for’ loops that set up the logic for a grid format akin to a rack, shelf, stall position matrix.
Still not done yet, I lacked the means by which to have GPU equipment perform the same headless ‘mapping’ and identification feature. I whipped up a quick replacement script in python for the function performed as observed by the IP Report button, called IPRanywhere . I revisited an old script I’d worked on in the past, called massscp that, you guessed it, performed an iterative scp of a single file to a hostlist of IP addresses. The new, cleaner, single purpose mass scp for IPRanywhere assumes we’re using EthOS and pushes the IPRanywhere.py script to the home directory. Because an OS like EthOS boots to a terminal window, all keyboard input is directly input into a terminal, but like most rigs, we can’t expect to have a keyboard and monitor connected, nor do we wish to invoke the script manually, nor will access the rig logically give us a physical association with a tool like Mo’Beta. Enter a favorite hacking tool of mine that I have used more for System’s Admin work than I have pentesting: the Hak5 RubberDucky. You could also give the DigiSpark a similar treatment. After writing up a quick ducky script, compiling it and moving it to the Ducky, it lets us program up a keystroke injection binary, which invokes the file we just pushed to all of the devices once we plug in the USB key. The USB key, then acts as our physical location verifier, replacing the function of pushing the IP REPORT button on a Bitmain ASIC. From there we can chose to use Bitmain’s Windows IP report tool for rig tracking with GPUS or we can chose to use something like MO’Beta’s configuration-less alternative to map the locations for later.
With these few tools, I’ve standardized an IP/MAC physical location mechanism for mapping and troubleshooting both ASIC and GPU nix based systems supporting Python and Windows Systems with Bitmain’s IP report tool and Nix systems running CLI Python and a few common libraries. Run with it 😉
Keep it logical, and have fun out there.
Hack the Planet.