The first assignment of the SLAE64 exam states: Create a Shell_Bind_TCP shellcode: Binds to a port Needs a “passcode” If passcode is correct then execute a shell Remove 0x00 from the Bind TCP shellcode discussed in the course Shell Bind TCP shellcode The first assignment is to create a shell bind TCP shellcode which requires a passcode to spawn a shell. What happens when a wrong password is entered isn’t defined so I’ll just exit with a non-zero return code.

Recently I decided to study for the SLAE64 course from Pentester Academy to work on my assembly knowledge, specifically on x86_64. Through the course does focus on Linux I want to apply the knowledge to OpenBSD/amd64 too and thus I installed NASM and looked at what I needed to adjust on my Linux samples to get it working on OpenBSD. Turns out, not that much actually! Both operating systems use same calling convention, namely the System V AMD64 ABI.

The following documents the steps needed to setup NetBox on OpenBSD. I am running NetBox on a PC Engines APU which holds up fairly well and I have since migrated my own setup from RackTables to NetBox, primarily because of the API functionality NetBox offers which allows for integration with SaltStack. But more on that some other time. I have ported a few dependencies but gave up after realising all of the Django applications/modules needed to be ported including their dependencies.

When managing configuration for various services, you’ll (hopefully) end up having to install TLS certificates at some point. Instead of having to come up with the same logic in various modules, roles or formulas I’ve had an Ansible role for a while that bundled all the logic into a single role that used the vault to obtain all certificates, keys and bundles that needed to be managed on a given node.

Whilst setting up consul on SmartOS I noticed the packages distributed through pkgsrc were lagging behind a bit and the upstream “distribution” contains only the consul binary. Running consul -dev in a tmux window will get boring pretty quickly, so I came up with the following SMF manifest using manifold which supports start, stop and refresh (triggers a configuration reload): <?xml version="1.0"?> <!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1"> <!– Created by Manifold –> <service_bundle type="manifest" name="consul"> <service name="site/consul" type="service" version="1"> <create_default_instance enabled="true"/> <single_instance/> <dependency name="network" grouping="require_all" restart_on="error" type="service"> <service_fmri value="svc:/milestone/network:default"/> </dependency> <dependency name="filesystem" grouping="require_all" restart_on="error" type="service"> <service_fmri value="svc:/system/filesystem/local"/> </dependency> <method_context> <method_credential user="consul" group="consul"/> </method_context> <exec_method type="method" name="start" exec="/usr/local/bin/consul agent -config-dir %{config_dir}" timeout_seconds="60"/> <exec_method type="method" name="stop" exec=":kill" timeout_seconds="60"/> <exec_method type="method" name="refresh" exec=":kill -HUP" timeout_seconds="10"/> <property_group name="startd" type="framework"> <propval name="duration" type="astring" value="child"/> <propval name="ignore_error" type="astring" value="core,signal"/> </property_group> <property_group name="application" type="application"> <propval name="config_dir" type="astring" value="/etc/consul.