2018-10-25
Small TFT displays for Kali on the Raspberry Pi
I've had the PiTFT working under Raspbian for years, but Kali isn't Raspbian, and I remember that getting it working the way I wanted, even with the Adafruit helper tool, was somewhat of an ordeal.
Although a number of folks (e.g. re4son) have published unofficial Kali images for the Pi, some of which claim to work with various add-on displays, I tried and a few and failed to get them to work properly, if at all, even without the display. I started with a fresh official Kali Linux 2018.3 RaspberryPi 2 and 3 image.
The fbcp-ili9341 driver doesn't work out-of-the-box on Kali, either, but getting it up and running wasn't too hard. It doesn't support touch input yet, but for me, Kali requires at least a keyboard, and my trusty Logitech K400r (affiliate link) is always nearby. One thing I like about framebuffer copy (fbcp) is that you can have the Pi plugged into HDMI (or not...) and the video is mirrored to the TFT, but needless to say, you'll have to start with the Pi plugged into an external monitor until you get the TFT working.
To get the driver to compile on Kali, I had to download libbcm_host.so, libvchiq_arm.so and libvcos.so from the opt/vc/lib directory of the RaspberryPi Git repository (or you could copy them from a running raspbian host or SD card).
I put the library files in /opt/vc/lib (I had to create this directory) and then added it to the libary path by creating a file called /etc/ld.so.conf.d/vc.conf :
#vc libs
/opt/vc/lib
run ldconfig to reload the library cache.
I'll be going through the steps specific to the Adafruit PiTFT 3.5, however it looks like a lot of various, generic displays have been tested to work, as long as you pass the right options to cmake when you build it. The Readme in the repository has a lot of helpful tips on cmake options, but the basic "get it compiled" instructions are pretty simple:
For the Adafruit PiTFT 3.5 display, this was the magic sauce for the cmake command, though you may wish to mess with the Clock Divisor timing:
cmake -DADAFRUIT_HX8357D_PITFT=ON -DSPI_BUS_CLOCK_DIVISOR=30 ..
Before I ran "make -j" per the above, I edited config.h to make some tweaks, uncommenting two options to get the orientation of the display the way I wanted it (so the Raspberry Pi power plug sticks out of the top when looking at the screen upright) and to fill more of the display:
#define DISPLAY_ROTATE_180_DEGREES
#define DISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING
Once I got it running nicely, I copied the binary to /usr/local/bin/fbcp (because I can't remember "fbcp-ili9341")
Next, I edited /boot/config.txt and experimented with the various video modes to give me a display that was both legible on a tiny screen, and filled as much of the display as possible. I ended up with a 480p 16:9 mode that, combined with the BREAK_ASPECT_RATIO fbcp build config, looks about as good as I can get it on the display. You'll have to tinker with these options to find what works best on yours. I added this to the end of /boot/config.txt:
hdmi_group=1
hdmi_mode=3
If you're cool with running full brightness, you can skip this next part. If you want variable brightness on the backlight, we have to configure GPIO. This display uses GPIO Pin 18 for the backlight LEDs. Other TFTs might not support PWM brightness control, or may use a different pin than 18 for it. By default, the display is on 100% full brightness, but if you tweak the GPIO configuration in the bootloader, you can use PWM to modulate the brightness. I added the following line to /boot/config.txt:
dtoverlay=pwm,pin=18,func=2
This change will kill the power to the backlight at boot (as the PWM mode will default to no power output) so you'll need to initialize and power-up the GPIO at boot if you want the display to be usable. To do this, I created a "rc.local" file in /etc (which systemd will run at boot) to launch the fbcp driver, initialize the GPIO, and set the display to 50% brightness. I'm running a really high frequency on the GPIO because a lower frequencies created a very audible high-pitch whine, and very low values (e.g. periods of 255 to 10000) were not giving any kind of granularity to the backlight brightness. /etc/rc.local:
#!/bin/bash
/usr/local/bin/fbcp&
echo 0 > /sys/class/pwm/pwmchip0/export
echo 10000000 > /sys/class/pwm/pwm0/period
echo 5000000 > /sys/class/pwm/pwm0/duty_cycle
echo 1 > /sys/class/pwm/pwm0/enable
Make sure it's executable:
chmod 755 /etc/rc.local
I opted to enable automatic login (as root) on this since it's basically a plug-in-and-go appliance. I followed this quick guide.
Reboot to test it out. You should see a white screen (or whatever was on the screen before rebooting) for a few seconds, then the backlight should go out until rc.local is executed right before it goes into GUI mode.
Finally, I created a "backlight.sh" script that handles setting the brightness. You'll need to make this executable, too. Syntax is basically "./brightness.sh (percentage)" where 0 is off, 1 is very dim, and 100 is full brightness.
#!/bin/bash
if [ -n $1 ]
then
echo ${1}00000 > /sys/class/pwm/pwm0/duty_cycle
fi
Labels: hardware, kali, linux, raspberrypi
2018-10-24
OpenBSD 6.4 released, Web server guide updated
OpenBSD 6.4 was released last week. It comes chock full of new goodies, including a built-in Wireless network manager ('join' syntax for ifconfig), derived snapshots for vmm virtual machine disk images (based on qcow2 support), improvements to pledge including the addition of unveil, and RETGUARD, a new stack protector for thwarting ROP attacks just to name a few new features.
I've been busy with the new job and getting settled into the new digs here in the Austin suburbs, but I carved out some time to update the OpenBSD/HTTPD/MySQL/PHP guide. There are a few changes to how PHP-FPM is configured, so you may want to pay close attention if you've followed the guide before.
The nginx and apache pages haven't gotten that many views lately, so I am not updating them this go-around. The httpd in OpenBSD's base install is a pretty well-proven web server at this point, and I've been using it in production, reliably, for years now. If you're thinking of running nginx or apache on OpenBSD, I'd urge you to take a look at httpd.
2018-09-25
Running pkgsrc on OpenBSD
After a discussion somewhere on teh webs, I decided to dig into the state of PHP 7.1 and PHP 7.2 on OpenBSD. The short version is "we're working on it" (in OpenBSD ports) but no ETA. However, being keen to NetBSD's pkgsrc distribution, I knew that they had been cooking up newer versions in their software tree. So I decided to kick the tires.
Pkgsrc is roughly NetBSD's equivalent to the OpenBSD/FreeBSD "Ports" repository, however, they've put significant effort into making it quite portable. It works in one way or another on other BSDs, Linux, OS X and even more esoteric platforms like Haiku and Illumos.
Initially, bootstrapping pkgsrc on OpenBSD 6.3-STABLE didn't work. Buried deep in my inbox from the pkgsrc mailing list in April, I found a hint from Sevan Janiyan about some patches that are needed to make it work. Partially, this is because OpenBSD uses both clang and gcc compilers in the base distribution on modern hardware.
Anyhow, on with the show.
First, check out the pkgsrc repository. You can do it with cvs:
env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
It's going to churn for a few minutes while it downloads all the files.
When it's done downloading, you can move it to /usr (/usr/pkgsrc) if you want, but I usually just leave the pkgsrc tree in my home directory. Change into the pkgsrc directory:
cd pkgsrc
make a file called pkgsrc.patch with the following contents:
--- archivers/libarchive/files/libarchive/archive_openssl_hmac_private.h
1 Aug 2017 22:21:17 -0000 1.1.1.2
+++ archivers/libarchive/files/libarchive/archive_openssl_hmac_private.h
5 Apr 2018 20:50:09 -0000
@@ -28,7 +28,8 @@
#include
#include
-#if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)
+#if OPENSSL_VERSION_NUMBER < 0x10100000L || \
+ (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x2070000fL)
#include/* malloc, free */
#include/* memset */
static inline HMAC_CTX *HMAC_CTX_new(void)
Apply the patch:
patch -p0 < pkgsrc.patch
cd bootstrap
A "privileged" install requires root (via doas or su) but will store all of the binaries into /usr/pkg:
doas ./bootstrap --compiler clang
-- OR --
If you wish to build "unprivileged" without root, the binary packages will be installed in the "pkg" directory under your home dir.
./bootstrap --unprivileged --compiler clang
Then go have a coffee or something. It takes a while.
If it finishes up with out a screen full of errors, you're almost all the way there:
You'll need to edit your .profile (or .bashrc if you roll that way) to add the pkg/bin directory to your path. In a privileged install, add /usr/pkg/bin and /usr/pkg/sbin to your path. In an unprivileged install, add ~/pkg/bin and ~/pkg/sbin instead.
Adding these paths to the end of the PATH line in the default .profile should work for a privileged pkgsrc install:
PATH=$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:/usr/pkg/bin:/usr/pkg/sbin
You need that in your path, because pkgsrc portable requires you to use NetBSD's "bmake" in the pkgsrc tree, and bmake is compiled as part of the bootstrap. You can log out and log back in, or just run this command to get bmake into your working path.
PATH=$PATH:/usr/pkg/bin:/usr/pkg/sbin
Let's try building something. It works a lot like ports. It will recursively build any dependencies or libraries that are needed, and install them into the pkg directory before building the application you're trying to compile. I'll start with the latest version of PHP in pkgsrc, PHP 7.2, since that's how this whole journey started. I'm using doas since I did a privileged install.
cd pkgsrc/lang/php72
doas bmake
It compiled.
I'm going to run doas bmake install without running bmake test because pkgsrc isn't the boss of me.
And it all works.
2018-07-12
Wi-Fi on OpenBSD just got a lot easier
... if you're running the latest OpenBSD-CURRENT snapshot, at any rate...
Last night, Reyk Floeter posted this teaser, hinting that phessler@'s work on this feature was inching toward completion.
And it's already in snapshots dated July 12, 2018 and newer. Some mirrors haven't gotten this snapshot yet, as of the time of publication. What this means is that you can load up all of your frequently-used wireless networks into your wifi adapter's /etc/hostname.if file, and it will attempt to auto-join them in the order they're listed. It'll be interesting to see if the installer for OpenBSD 6.4 uses this syntax if you set up a wireless network during the install process.Watch #OpenBSD CVS: @phessler just committed his „join“ feature to configure a list of possible access points. pic.twitter.com/3EtPb2oQ1E— Reyk Flöter (@reykfloeter) July 11, 2018
I like the simplicity of this, versus the complexity of configuring wpa_supplicant, NetworkManager, NetCtl and similar tools. I suspect if you've got only wpa-enabled networks in the list, it should be resistant to most evil twin attacks such as Karma, but I haven't tried that yet.
Documentation of this feature doesn't seem to be covered in the hostname.if or individual wireless driver man pages yet, but the above photo was obvious enough for me to create a working example configuration file for my daily-driver laptop running -CURRENT (on which I'm writing this article).
It looks like a lot of other good things are coming out of the g2k18 hackaton, including advances on unveil, a simple way to control filesystem-level access on a per-process basis, which Bob Beck presented at BSDCan 2018.
2018-04-23
PHP/MySQL Articles updated for OpenBSD 6.3
No surprises, the existing instructions from OpenBSD 6.1 worked flawlessly for both the httpd and nginx web servers. I just made sure everything still works and updated some version numbers. Once again, I did all of the testing using OpenBSD's built-in vmm hypervisor on my personal laptop, and it did remind me of a few recent changes in vmm's network configuration that I had forgotten about.
2018-04-02
OpenBSD 6.3 Early Release!
OpenBSD 6.3 was slated for release on April 15th, but it's already showing up on mirrors this morning. It looks like the full package tree is available only for the most popular platforms at the moment, but the install sets for all supported architectures are live on the two mirrors I use most frequently (sonic and ftp5). I haven't checked the rest of the mirrors. Elsewhere on the Internet, I saw a number of core developers confirm the release is underway almost two weeks ahead of schedule.
I'm looking forward to using the improved install script ("Please Listen Carefully as Our Menu Options Have Recently Changed") and taking advantage of some iterative improvements to the VMM hypervisor, such as snapshots and the ability to attach ISO images to VMs.
Labels: openbsd
2018-02-07
Bad idea? Let's put a Windows 2000 server on the Internet.
Today, I decided to install Windows 2000 Advanced Server onto my Dell Latitude D610. The laptop itself is a workhorse, if a bit dated. Mostly, I was just curious what would happen if I left it out on the Internet without any service packs or firewall rules* and I live-tweeted it as I did my research.
Here's my twitter thread with just a few additional notes added. pcap and IDS alerts are at the end:
What happens when I put this on the Internet? pic.twitter.com/d19rvRnitG— ax0n (@ax0n) February 6, 2018
Okay, so... nmap is like DisGunBeGud.gif https://t.co/ZC0Kek8CTQ— ax0n (@ax0n) February 6, 2018
Span port fired up. @Snort on a @Raspberry_Pi 3 is watching intently.
About to drop this sucker into my DMZ.
Cannon fodder mode: Activate pic.twitter.com/3ftrVcOOeA— ax0n (@ax0n) February 6, 2018
So far, the Mirai telnet noise is the most prevalent junk, but I just took my Cowrie honeypot offline for this experiment. Snort with @EmergingThreats ETOpen rules is seeing RDP DoS and SipVicious, and nothing else since the cut-over. Bots are dumb. 30 minutes without being pwnd. pic.twitter.com/tmCyDMWY3Z— ax0n (@ax0n) February 6, 2018
There's basically nothing going on in the logs except for mass hysteria when I corrected the system clock. pic.twitter.com/lfVmdSU2VQ— ax0n (@ax0n) February 7, 2018
RDP login attempts (and counts) so far:— ax0n (@ax0n) February 7, 2018
181.214.87.7 (5)
51.15.184.118 (7)
74.63.221.148 (8)
5.101.40.60 (12)
Alright, so my ISP is giving me some firewall rules of their own, probably to stop the spread of EternalBlue exploit bots and WannaCry ransomware. Honestly, I appreciate it, but it's not helping me get pwned.77.72.82.x is smurfing its recon or something. Low and slow. pic.twitter.com/2fFZUfCIwG— ax0n (@ax0n) February 7, 2018
Here's a big part of the... problem? Apparently ATT UVerse is filtering in-bound connections on SMB/CIFS. https://t.co/QZGJLKfikJ (note: this is a good thing, unless you're *trying* to get pwned) There's still plenty of attack surface.— ax0n (@ax0n) February 7, 2018
[BRUTEFORCE INTENSIFIES] pic.twitter.com/xTOCNNMZiH— ax0n (@ax0n) February 7, 2018
Now let's see who guesses my six-character (4 lowercase alpha, 2 digit) Administrator password.— ax0n (@ax0n) February 7, 2018
The VNC scanners have come out to play. I'm not running VNC server though. pic.twitter.com/aPQSdHQGiF— ax0n (@ax0n) February 7, 2018
Alright kids, we're about 5 hours in without getting pwned (as far as I can tell). Here's the final count of source-IP/destination port tuples for inbound TCP connection attempts where count > 3. pic.twitter.com/eVF4BxCGGN— ax0n (@ax0n) February 7, 2018
With that, here are the links to those:I'm gonna wrap this thread up, link to these tweets in a blog post on @H_i_R tonight or tomorrow, and link to sanitized pcap and snort alert log files. Thanks for watching!— ax0n (@ax0n) February 7, 2018
Sanitized pcap (gzip): http://stuff.h-i-r.net/win2k.pcap.gz
Sanitized IDS log: http://stuff.h-i-r.net/win2k-ids-alerts.txt


