Author: Frans-Willem Hardijzer

UIB Update

Thanks to a little hint of someone at MS, we now know that the current UIB version is 0.5, which means that we now know the meaning of all used fields 🙂 The only command we don’t know yet is one that saves a value somewhere that, according to our research, isn’t ever used again. Luckily, none of the UIB files in messenger seem to be using that command, so we don’t really care 😉

On a related note, my current UIB parser can currently handle almost all resids in messenger, with the exception of two files using rcbmp (I still have to implement that), and a bunch of resids that are corrupt (but those are not used in messenger anyway, so who cares ;)?). After this I’m going to write some kind of library that allows patchers to load the UIB as an in-memory representation of the user-interface, apply patches to it, and then write back to UIB. Hopefully that will get both A-patch and MessPatch up to speed with the new messenger. After that I plan to write a bunch of other UIB tools, and at some point Steve and I still intend to document the UIB format fully and release it to the public.

But for now: Let’s just celebrate that we know all the fields 😉

Clarifications on the new WLM9 “protection”

With Windows Live Messenger 9 Wave 3, Microsoft abandoned the XML-like UIFile format to describe their user-interface layout.  Instead, a new proprietary binary format was introduced named UIB (named after the first three bytes in the files), which TheSteve and I are now reverse engineering.
What bothers me is that somehow people have misinterpreted this move, and are labelling it “protection”, insinuating that Microsoft did this intentionally to block skins and patches.

So allow me to clear that up. First of all, the new format is not actually a protection. The format is, once you figure out how it works, rather simple and elegant, in no way designed to mislead anyone trying to understand it. I personally think that the developers at Microsoft made the switch to a proprietary format because parsing XML for each and every window is just slow and quite a resource hog. Switching to their own optimized-for-this-purpose format allows them to make it faster and more memory efficient, and also smaller.

Secondly, in the first beta to feature UIB, the XML files were still included and (using a registry switch) messenger could be forced to load those instead of the UIB. In the new release candidate this switch as well as the XML files have disappeared. Contrary to what the following information alone would suggest, I don’t think that this was done to “piss us off” either. Beta builds are regularly built as “Debug” versions, which include extra information to facilitate troubleshooting: e.g. logging extra information to a file, dumping more verbose messages to the debug output, and possibly allow for developers to quickly change minor things (like the user-interface) without having to do a full-blown recompile (which can take quite a bit of time on big projects). Releases and release candidates are often compiled in “Release” mode: everything that might slow the program down or make it unnecessary big will be stripped, and only what is needed to actually run the program is included. If you then look at the name of the registry entry to allow UIFiles (“DUIDebug”), you will see that it was only there as a debug feature, to allow the developers to quickly change the UIFile/XML files to test certain cases, without having to convert them to UIB all the time.

One last misconception I heard a lot is that the format “changed” from the beta to the release-candidate. While this is technically true, it’s only minor. Think of it as a change from Word 97 .doc files to Word 2000 .doc files: They’re still the same format, yet the 2000 one has a few extra features that the 97 one doesn’t have. But in the end, the file format is largely the same, and that’s also the case for the new UIB files: the beta used UIB 4.0 (or 0.4, we’re not sure yet), the release candidate UIB 5.0 (or 0.5).

So to conlude:

  • The new format was most likely not introduced as a security measure, but rather to speed up our favourite messenger client.
  • There is no encryption, protection, or whatsoever that would prevent us from trying to understand the format or reproduce it.
  • There were no major changes in the format from beta to RC.
  • The trick allowing messenger to load UIFiles in the beta was most likely just a debug feature.
Some other quick things:
  • Converting from UIB to UIFile is possible, but not foolproof (e.g. named constants are not preserved, layoutpos=none will be turned into layoutpos=-3, although those have already disappeared in the UIFiles from the first beta)
  • Converting to UIFile to UIB is possible, but writing such a program would be a rather tedious job, and would likely be error-prone. It’s more likely that Steve and I will come up with an inbetween format that would be readable and editable by normal human beings, but would still be close enough to UIB to be less error-prone.
  • The UIFile/XML parser that we know of is no longer available in the release-candidate: tricking it into loading XML will likely be rather difficult.
That’s all for now. Please put any comments or questions you have in the comments section.

Making the switch

I love the GNU and Linux philosophy. I love the command-line. Yet, I’m still running Windows Vista.

I’ve tried, honestly. A few days before last year’s Biton LAN Party, I decided to switch to Ubuntu. I liked it at first, but then things started to piss me off: I couldn’t find a proper replacement for Visual Studio, Wine failed to produce any sound, and as soon as I wanted something slightly different, something in Ubuntu would fail. After a day at the LAN without any gaming done, I gave up an just booted to Vista. After all, what’s a LAN party without games ?

At least 6 months have passed since then, and I still long for a Linux desktop. My recent adventures with setting up a MythBuntu server at home and playing around with an ArchLinux Gaming LiveDVD have only made that longing stronger. So I’ve decided that once I’m back in the Netherlands, I’m going to give it another try. And this time slightly more prepared.

So I’ve taken the time to make a little list stating things I should investigate before making the plunge, and I’ll try to tackle them one at a time later on. So here goes:

  • Which distribution? Ubuntu sounds simple, but once you start messing in the configuration it breaks horribly. And there are so many around nowadays, why not look a bit further?
  • KDE or Gnome? or even XFCE?
  • What apps do I rely on, and what are their Linux counterparts?
  • If counterparts are not available for a specific app, will it work under Wine or a VM ?
  • My hardware should all work (especially my networked HP Laserjet 4000 printer, which was failing last time in Ubuntu)
For now, that’s all I can think of. I’ll try to maintain that todo list, and occasionally post about some of the things I found out.

Introduction

Hi,

If you’re reading this, chances are that you probably already know me. However, for the occasional passer-by that came in through google, here’s a quick introduction.

As of writing this, I am a 21 year old computer programmer. Still busy with my Computer Science study at Utrecht University, although currently I am having a small (5 months) break from my studies and am working for a Parisian company called “Iminent“.

As my study has probably already suggested, I have a passion for programming, and am especially challenged by algorithmic contests like the NWERC (and all related contests like the UKP, BAPC). I also have a deep passion for finding out “how things work”, and as thoroughly enjoy the act of reverse engineering.

Of all the progamming languages I know, I enjoy working in C++ and x86 Assembly the most.

Currently my best known work is an add-on for Windows Live Messenger named StuffPlug, that targets it’s (what I experience as) shortcomings and glitches, and apparently even today it’s downloaded several thousand times per day. Apart from that, I also enjoy working on numerous smaller projects, but they’re too many to all list here.

This blog will be a place for me to share technical stories, challenges, examples, or anything else technical I feel should be public. Oh, and the occasional rambling, probably.

If there is anything I failed to mention in this introductory post, please let me know through a comment. At this time I have comments restricted to registered users to prevent comment-spam, but it shouldn’t be too difficult to register at all. In the future I might opt for guest-posting with a filter to comment-spam…