Everything, Everything

Bit disappointed with the exclusive Xbox games. None of them feel like a "must have". I'll probably stick with the PS4 Pro.
11 days, 6 hours, 59 minutes ago
New Porsche 911 GT2 RS looks just like... a Porsche 911. Forza 7 looks pretty though. Might get it for Windows 10 over the Xbox One X.
11 days, 8 hours, 11 minutes ago
Running Solaris 10 x86
Saturday 27th May, 2017 08:27
Solaris 10 x86 isn't the easiest of operating systems to install, particularly the first few versions. The original GA release doesn't use grub, which seems to cause some issues running it under Hyper-V and possibly some other virtualisation (and real?) software. The original GA release also fails to install nicely under VirtualBox using graphical or text based installation; the workaround is to use the console and pipe the output to a pipe so you can install it that way. Thankfully the U1 release fixed the kdmconfig bug and moved to grub.

Great, so now U1 is installed, and it's time to reboot. Up comes Solaris's grub, then comes a reboot (or an error). This happens under Hyper-V and VMWare Workstation (I've not tried VirtualBox). Why's this happening? It appears that the "failsafe" option works fine as it's using the x86 kernel, but the main version that grub's trying to run is the x64 version. Probably because your CPU is x64. In theory that should be fine, but this is an old version of Solaris we're talking about. But as you're using grub, it's trivial to edit the grub menu at boot to force it to temporarily load the 32-bit x86 kernel by adding the string "kernel/unix" at the end. Once you're into your CDE desktop as root, you can manually edit menu.lst to make it a more permanent fix (as it may get wiped during an upgrade).

With your vulnerable version of Solaris up and running, you can now "telnet -l -fbin" into your host and copy across some of raptor's exploits to gain root. Tip: The raptor scripts expect gcc to be in your path, and will fail if this isn't the case. You can either edit your PATH or you can edit the scripts to point them directly at gcc on your system (which should be at /usr/sfw/bin).
© Robert Nicholls 2002-2017
The views and opinions expressed on this site do not represent the views of my employer.