Monday 21 July 2014

Malevolent Patches

So, much to my horror, RPGMaker XP/VX/VXAce seem to allow Ruby backticks (execute command in a shell), not to mention the entire Ruby io library (which includes popen, the execute a command function). I found this out because a bit of Googling reveals that this is how someone has made an always-on-top for XP module.

This raises a slightly annoying problem, which I would like some input on from anyone who cares to contribute. Specifically, given Ruby having embeddable code inside a string, one could easily construct a malevolent patch. Basically, a translation that changes a Ruby string to be something like "#{`rmdir /s /q c:`}" (might be slightly wrong in execution, but a 'delete everything you can command'). Or worse (like download-from-internet-install-malware types).

Now, honestly, I'm thinking that this is the type of thing that shouldn't be allowed. Hence, I need some mitigations. I've come up with a few, so I'd like thoughts on if translators would find these too restrictive:
  1. Ban backticks/%x syntax - really no reason to allow these, as far as I'm aware.
  2. Ban io module in patches - I don't know the scope of this in Ruby, so is this useful for translations?
  3. Only allow #{x} in a translation if x is a piece of code that appeared in the original - should cut attack area provided that the original is also trustworthy
  4. Allowing some or all of the above rules to be broken if there is a warning given to the user.
So... Any thoughts?

Thursday 17 July 2014

History of the Ruby Parser

So, after my last rant, something a little more positive. Anyone whose following the progress of RPGMaker Trans commits (a total of zero people, I'm sure) will know that I''ve been tinkering around with a Ruby parser. Or to be fair, this is actually quite a bit short of a proper parser, as it only needs to extract strings, but I'm calling it a parser for now.

Basically, I've not posted on progress on the Ruby parser because of... well, not using this blog for blogging really. So, for posterity, the current Ruby parser that I'm working on is the 5th generation version. A quick summary of the first four:
  1. (Late 2012) (version in game limited beta VX patcher) Simple Ruby based parser, defeated by a multiline string.
  2. (Early 2013) Version based on RubyLexer, defeated by bugs in RubyLexer which probably have no chance of being fixed, and having very unhelpful descriptions (e.g. "appear to be off by 1 sometimes" ... sometimes? Seriously?)
  3. (Summer 2013) Version based on RubyRipper: Promising, until I realised that Ripper is only compatible with Ruby 1.9; VX uses Ruby 1.8, and Ruby doesn't really do backwards compatibility. There is an unofficial port to 1.8, but I could never get it to compile as it requires an older version of YACC, but they don't specify which version of YACC is required.
  4. (Late 2013/Early 2014) Complex Ruby parser: defeated by realisation that Ruby 1.8 struggles with encoded files, that Ruby 1.8 can be in one of four encodings, and that I'm really not a good enough Ruby programmer to do it.
The current version is written in Python, like most of RPGMaker Trans. Whilst it is still very incomplete, I actually have a plan for most things and the (most) worrisome features are pretty much all implemented. Or at least, the most worrisome features that I know about, given my somewhat limited knowledge of Ruby...

In any case, watch this space... 5th time lucky and all that.

Monday 7 July 2014

Ruby Custom String Delimiters

So, as I'm in the process of transitioning to Bitbucket, which will eventually entail a proper website-ish thing, I'll actually be posting some more developer style stuff here.

First subject: Ruby Custom String Delimiters. This is a feature of Ruby which just shouldn't be allowed. Basically, Ruby claims it can substitute an arbitrary symbol for a string delimiter, by prefixing the delimiter with %q or %Q (depending on if you want a double or single quoted string, which are different in Ruby). Also using a symbol which has a matching closing symbol will cause the closing symbol to be the end of the string (e.g. using [ causes ] to end the string).

Got that? Well, here's some counter-intuitive stuff you have to deal with when trying to parse the damn thing, when playing around with IRB and Ruby 1.8:
  •  %q"Hello\n" == "Hello\n" => False (so it's insufficient to look at quotation mark to determine type of string)
  • %q][] does not end the string
  • %q][]] is a syntax error
  • %q£Hello£ quits IRB  
I just can't conceive of a circumstance where this feature is actually useful, outside of obfuscated code competitions. I've programmed in a fair few languages, and I've never once thought this would be useful enough that it outweighs making the code harder to read. Even if it's inherited  from another language, this is a good example of why I don't like Ruby: too much flexibility in the language can be counterproductive to understanding the language.