By now you’re probably well-acquainted with the “discovery” of so-called “god modes” or “superuser” features in Windows 7.  In actuality, these are nothing more than undocumented developer shortcuts to common control panel dialogs, apps and utils.  In fact, the wild-eyed brouhaha that’s erupted from this has caused some mirth down Redmond way, with Windows Division President, Steven Sinofsky even providing a C|NET reporter with a list of the shortcuts.

Here’s how you can quickly create your own “god mode” shortcut links to experiment with:

Step 1:  Copy the following code into your fave editor and save as a batch file – I called mine “godmodes.bat” (removing the line numbers).  Save this file in a folder on your desktop or other preferred location.

    1 mkdir "GodModeA.{05d7b0f4-2121-4eff-bf6b-ed3f69b894d9}"

    2 mkdir "GodModeB.{1206F5F1-0569-412C-8FEC-3204630DFB70}"

    3 mkdir "GodModeC.{15eae92e-f17a-4431-9f28-805e482dafd4}"

    4 mkdir "GodModeD.{17cd9488-1228-4b2f-88ce-4298e93e0966}"

    5 rem mkdir "GodMode.{1D2680C9-0E2A-469d-B787-065558BC7D43}"

    6 mkdir "GodModeE.{1FA9085F-25A2-489B-85D4-86326EEDCD87}"

    7 mkdir "GodModeF.{208D2C60-3AEA-1069-A2D7-08002B30309D}"

    8 mkdir "GodModeG.{20D04FE0-3AEA-1069-A2D8-08002B30309D}"

    9 mkdir "GodModeH.{2227A280-3AEA-1069-A2DE-08002B30309D}"

   10 mkdir "GodModeI.{241D7C96-F8BF-4F85-B01F-E2B043341A4B}"

   11 mkdir "GodModeJ.{4026492F-2F69-46B8-B9BF-5654FC07E423}"

   12 rem mkdir "GodMode.{62D8ED13-C9D0-4CE8-A914-47DD628FB1B0}"

   13 mkdir "GodModeK.{78F3955E-3B90-4184-BD14-5397C15F1EFC}"

   14 mkdir "GodModeL.{ED7BA470-8E54-465E-825C-99712043E01C}"

Note:  The rem’ed entries were included in Sinofsky’s list, but didn’t work when I created them – I’ve included them here for completeness.

Step 2:  Open a command console using Run As Administrator from your Start Menu and execute the batch file created in Step 1 above.

Step 3:  Behold the “God Mode” links that have been created – double-click and explore away!  The most useful one by far is the last one, the “original” God Mode discovery that provides a consolidated list of shortcuts to just about every imaginable Windows 7 control panel feature, property manager or utility.

One more note:  The folder names don’t have to be prefixed with “GodMode” – in fact, any prefix will do.  As the batch file reveals, the trick is in naming the folder with a “.[GUID]” suffix.  I’ve added an alphabetical identifier to each of my entries to keep them in order.

Earlier today, I was working on a custom survey list event receiver that ports results into a SQL database table when I noticed some peculiar behaviour:  Every time I added an entry to the survey, two duplicate rows were added to the SQL table.

Poking around the web, I see that this is indeed a common issue – David Birin captured the problem (and a solution) quite succintly on his blog in his January 2009 entry.  As he notes, the root of the problem is that if you have your event receiver deployed as a Feature (I did) and then create a template of a targeted list (you bet I did that) then the event receiver registrations are “baked in” to the template definition.

Now, when you create a list based on this template in a site that has the same event receiver Features enabled, you now are running each event handler twice.  As you repeat this process, you register more event receivers and things get out of hand geometrically.

NOT GOOD.

A Hack for a Solution

David’s solution is to add in some custom code that loops through the event receivers and deletes them individually.  While this is robust for future-proofing, I wanted an easier way so that I could get back to coding.  Here’s what I did:

1. First, I went to the List Template Gallery for my Site Collection and saved the offending list template to my C:\ drive and renamed the extension from “.stp” to “.cab”
2. Next, I opened up the .cab file and extracted the manifest.xml file within and tossed it into Visual Studio where I cleaned it up with an Edit -> Advanced -> Format Document
3. I located the <Receivers> element and removed each <Receiver> child element.
4. I changed the <TemplateTitle> to reflect the new version, eg. “My Survey V4”
5. I made similar changes to the <Form> and <WebPart> element URL attributes, eg. “Lists/My Survey V4/DispForm.aspx”
6. Next, I saved this file and then used MAKECAB.EXE to package it up (comes with the Windows SDK) and renamed the extension from “.cab” to “.stp”
7. I opened up a browser on my test server, navigated to the List Template Gallery and uploaded my revised template and created a list from it.
8. Presto!  The ItemAdded event was only firing once as it should.

Hope this helps anyone encountering the same issue – it’s a quick-fix which helps avoid the ground-zero for the issue which is building a template of a list while the event receiver feature that targets that list is enabled.

As promised, I’ve set up a wiki to help aggregate the information gathered so far in my efforts to black-box reverse engineer the Tassimo T-DISCs!  You can find the main wiki page at http://blog.chapmanconsulting.ca/wiki and the top page for Tassimo Hacking at http://blog.chapmanconsulting.ca/wiki/Tassimo%20Hacking.ashx

The pages are definitely works-in-progress, and best of all:  You can create an account to help out!  In fact, I’m really hoping that there will be some collaborative input to build the pages out into a hacking Tassimopedia.

I’ll be updating the pages on and off for the next while as I have a whack of other articles to finish and, of course, X-Mas errands to run!

Today's entry is an update in the progress made so far, which is "close, but not quite there yet".  I've received a lot of fantastic suggestions, and I have to give credit where it's due:

@SomeOne:  For providing the lead to the patent, which led to the now-famous Table 3 with the operational parameters binary codes;

@Mike Clay:  For suggesting converting the codes into binary or hex and looking for patterns;

@Tim Nowaczyk:  For having the 'nads to ask Braun's customer service if he could get the lookup codes directly.  Hey, the worst they could do was say "no" and that's exactly what they did!

@Hargobind Khalsa:  For three key observations:  That the leftmost 5 digits of the codes don't appear to exceed 65536, or 2^16;  That given this, the codes break down in 13 bits + 3 bits checksum;  That the last digit of the code seems to conform as a standard barcode/UPC check digit.

@Brandon Siegel:  For observing that the volume code "1101" for 250ml appears consistently for the Columbian, Crema and Cleaner programs when the bits are read in little-endian (right to left).

@Andreas Happel:  For providing 1) codes for Twinings Tea and Cafe Crema Vollmudig that can be "mocked" to get more measurement data;  2) his own empirical data on them;  3) observations that European T-DISCs have a slightly different encoding with a leading zero which may affect decoding the internal algorithms or lookups.

The Story So Far...

For those following along at home, here's a quick overview of the mini-breakthroughs that the above contributors, especially Brandon Siegel, have made possible:

• Of the six digits decoded from the barcodes, the first five are significant, while the last is a standard UPC/barcode check digit;
• Converting the five significant digits to binary provides 16 bits, which suggests 13 bits for data (per Table 3) and 3 bits as an internal checksum;
• A "landmark" value for a beverage volume of 250ml (dec 13 or 1101 base-2), which should be seen in the Columbian, Crema and Cleaner programs, appears in a consistent location starting with the 7th bit when the binary is read in little-endian format;

So, if we take the codes for the Three Amigos (Columbian, Crema, Cleaner):

64226
44738
07879

... and convert them to little-endian binary:

0100011101011111
0100001101110101
1110001101111000

the code for dispensing 250ml is readily apparent.  This is a fairly significant coincidence which suggests that bits 7,8,9,10 are responsible for controlling the water pump.  However, this gets dashed to pieces when we look at the binary for the Latte and Cappucino discs which should dispense 148ml and 118ml respectively - which don't align to any values in Table 3 without some rounding and coercion.

In this range, Table 3 only accounts for 110ml, 130ml, and 150ml  (0110, 0111 and 1000) - looking at the binary for the Latte and Cappucino discs at bits 7-10 we see:

1110111000011111 - 150ml
1110111111101111 - 300ml

The Latte program could be considered correct if we round-up the 5oz I originally observed (it's 147.8ml), but the Cappucino program is completely wrong - it's more than the original beverage!

Conclusions

So far, the code is proving resilient to applying a consistent, rational pattern as suggested in the patent.  In turn, this suggests a couple of theories:

• The table is completely wrong or needs adjusting
• The values in the code have some interplay that may look up against another table, or perhaps adjust values, that can impose some consistency - perhaps the three "checksum" bits are involved?

As always, I'm ever-grateful for the input - I'm now investigating setting up a wiki to track this project so that I can aggregate the findings without having a string of blog posts!  I need to get back to my original articles in short order...!

In a post last week I wrote on my exploits into “black-box” reverse-engineering my Tassimo Hot Beverage Dispensing System.  In the article, I detailed how I began probing the Tassimo’s inner-workings by analyzing the barcodes that are printed on the surface of the beverage T-DISC pods with a barcode scanner and a little ingenuity.  While I did discover that each disc is encoded with a six-digit number, I ran into a bit of a wall as I couldn’t discern any patterns that would correlate the codes to the machine’s functions of temperature, water and brew cycle.

Stumped, I decided that I should see what help I could get from the most definitive reverse-engineering community I could think of:  Makezine.com.  The folks in charge of the blog there shared my curiosity, and as a result I not only had a whack of hits on the old blog, but also got some really interesting and tantalizing leads to crack the Tassimo code!

Patents, 13 Bits and Operational Parameters

Of the feedback I received, one in particular has contributed significantly to advancing my understanding of how the barcodes on the T-DISCs relate to the operation of the Tassimo machine.  An anonymous benefactor (!!) provided me with this link to the original patent for the Tassimo via Google Patent Search.

Ok, first:  D’oh!  Second:  Google has a Patent Search?  Excellent!

Turning to page 36 I gleaned a major break in the case:

The cartridge 1 comprises a code provided on or in the cartridge 1 representing the operational parameters required for the optimal dispensation of the beverage in that cartridge 1.  The code is in binary format and comprises a plurality of data bits corresponding to the variables stored in the control processor memory.  Table 3 illustrates how 13 bits of data can be used to represent the necessary variables for the operational parameters described above.

Bingo!

Looking at the table, I discovered that contrary to my first assumption, there are five, not three operational parameters that the Tassimo uses to brew a beverage which are in turn programmed via segments of bits in a code:

1. Water temperature (Bits 0,1)
2. Cartridge charge (Bits 2,3)
3. Beverage volume (Bits 4,5,6,7)
4. Flow rate (Bits 8,9,10)
5. Purge (Bits 11,12)

As the patent describes, each parameter is “programmed” via a series of 13 bits, with an additional 3 bits for error checking:

The code on or in cartridge 1 will normall comprise one or more extra data bits for error checking.  In one example, a 16 bit code is provided.  For example, using the variables listed in Table 3, a cartridge 1 bearing the code “1000100011110” would have the following operational parameters:

10 – Water temperature of 83* C
00 – Fast charge with soak
1000 – Dispensed drink volume of 150 ml
111 – Flow rate equals 100%
10 – Fast air flow purge / short period

Cool.  So, what does that code look like in regular base-10?  Easy-peasy:  Paste the binary into your calculator thus:

Convert to decimal and we get:

Presto!  Now we have another piece of the puzzle – only four of the six digits in the barcodes are relevant to controlling the Tassimo’s five operating parameters.  We’re thus left to assume that the remaining two digits must be dedicated to some form of error checking.  I’ll revisit this later as there are a number of methods for applying checksums that need to be considered.

Applying the 13–Bit Coding Scheme to the Sample T-DISCS

Given what we know about the encoding scheme, it’s a relatively simple process to use a calculator to break down the deciphered barcodes into binary and begin mapping them to the operational parameter table from the patent application.  Of course, we need to know which four digits are relevant to the encoding.  I took an educated guess and went with the leftmost or most significant four digits.  Here’s my results:

These findings are close approximations to the observations I recorded earlier – but they are inconsistent, if not totally wrong.  Here’s what I’ve noticed:

• The Temperature parameter is perhaps the most consistent with what I recorded given I was using an analog meat thermometer!
• The Charge parameter is only correct – I think – for the Columbian and Cafe Crema programs;  it is entirely wrong for the Espresso program which definitely has a soak stage, and for the Latte and Cappucino programs which have no soak program whatsoever.
• The Volume parameter is wildly inconsistent with the actual results for each program.  For example, both the Columbian and Crema programs produce drinks with 250ml of water – not 150ml and 210ml respectively.  Similarly, the Espresso program uses 60ml of water, not 170ml, and the Latte and Cappucino discs use 148ml and 118ml of water.
• Given that I can’t reliably project at this point that bits 3–5 control flow (ie. can’t experiment) I’m running with the Flow percentages being fairly accurate from what I’ve observed, with the exception of the Cappucino program, which I think has a similar flow to the Latte disc.
• The Purge cycle seems consistent with the observations I’ve made about how long the machine seems to run “dry” after expunging all liquid.  I do need to verify and quantify this better.

Conclusions

Given that we’re seeing such inconsistency, three possiblities exist from our efforts so far: 

• First, the operational parameter table in the patent application is a little different from what made it into the programming of the retailed Tassimo machines.  This could mean that the order of the bits is wrong, or that the number of options within a parameter, eg. water volume, is actually less than suggested. 
• Second, the rightmost four digits of the code should be decoded.
• Third, some additional encoding is performed by the Tassimo’s control unit.

Tackling the first possibility will take a bit of methodical guesswork;  the second possibility I tried out with the Columbian program and found the results even more out-of-step with my recorded findings, so I discarded them.  The third possibility is difficult to assess – I think it plausible, but not likely, as it makes programming the discs even more challenging than it needs to be.

So, back to the drawing board!  I think we’re close – really close – to solving the riddle!