> Santa is stranded on the Christmas Islands and is desperately trying
> to reach his trusty companion via cellphone. We've bugged the device
> with a primitive keylogger and have been able to decode some of the
> SMS, but couldn't make much sense of the last one. Can you give us a
> hand?

We're given a tarball containing a bunch of CSV files, text files and
a header file.  The CSV files contain two columns each, one with a big
number, another with a small one.  More interesting stuff can be found
in the header file, an enum of keypad keys, IME methods and characters
corresponding to each key.  There is definitely a correlation between
the CSV files and header file as every second column in a CSV file can
be represented with a keypad key number.  The first column is an
increasing number, most likely a timestamp.  Let's try to make sense
of the first CSV file by manually decoding the first few characters
and check whether they resemble any of the text files.

    100 # N7110_KEYPAD_MENU_LEFT
    100 # N7110_KEYPAD_MENU_LEFT
    100 # N7110_KEYPAD_MENU_LEFT
    100 # N7110_KEYPAD_MENU_LEFT
    11 # N7110_KEYPAD_HASH -> N7110_IME_METHODS
    11 # N7110_KEYPAD_HASH -> N7110_IME_METHODS
    7 # N7110_KEYPAD_SEVEN -> N7110_KEYPAD_SEVEN_ABC_CHARS "pqrs7"
    7 # N7110_KEYPAD_SEVEN -> N7110_KEYPAD_SEVEN_ABC_CHARS "pqrs7"
    7 # N7110_KEYPAD_SEVEN -> N7110_KEYPAD_SEVEN_ABC_CHARS "pqrs7"
    8 # N7110_KEYPAD_EIGHT -> N7110_KEYPAD_EIGHT_ABC_CHARS "tuv8"
    8 # N7110_KEYPAD_EIGHT -> N7110_KEYPAD_EIGHT_ABC_CHARS "tuv8"
    3 # N7110_KEYPAD_THREE -> N7110_KEYPAD_THREE_ABC_CHARS "def3"
    6 # N7110_KEYPAD_SIX -> N7110_KEYPAD_SIX_ABC_CHARS "mno6"
    6 # N7110_KEYPAD_SIX -> N7110_KEYPAD_SIX_ABC_CHARS "mno6"
    6 # N7110_KEYPAD_SIX -> N7110_KEYPAD_SIX_ABC_CHARS "mno6"
    5 # N7110_KEYPAD_FIVE -> N7110_KEYPAD_FIVE_ABC_CHARS "jkl5"
    5 # N7110_KEYPAD_FIVE -> N7110_KEYPAD_FIVE_ABC_CHARS "jkl5"
    5 # N7110_KEYPAD_FIVE -> N7110_KEYPAD_FIVE_ABC_CHARS "jkl5"
    3 # N7110_KEYPAD_THREE -> N7110_KEYPAD_THREE_ABC_CHARS "def3"
    3 # N7110_KEYPAD_THREE -> N7110_KEYPAD_THREE_ABC_CHARS "def3"
    3 # N7110_KEYPAD_THREE -> N7110_KEYPAD_THREE_ABC_CHARS "def3"

The first word of the message is "rudolf" and each of its characters
can be found in the associated charset.  The IME button has been
pressed twice, toggling it from the first to the third method
`N7110_IME_ABC`.  Likewise, pressing each number button starts with
the first char of the associated charset, then toggles to the next
char.  There's a few more gotchas though with the ABC IME:

- It's possible to press the number key more often than there are
  chars in the charset.  In that case the current character wraps
  around to the first one.
- The toggling doesn't happen unconditionally, after a timeout the
  behavior switches from toggling to entering a new char, starting
  again with the first one from the charset.  To figure out the
  timeout, the first column of the CSV needs to be turned into a
  timestamp, then compared against the last one and taken into account
  when decoding a key.
- It's possible to erase characters by pressing a specific key.  It's
  not a dedicated erase key, but one of the generic non-numpad ones.
- It's possible to navigate backward and forward through the text,
  then insert new characters at a different position than the end of
  the text.  It's unclear which of the direction keys does that
  though.

For these reasons it's strongly suggested to write a solve script that
does basic decoding, then improve it to account for these gotchas.
After messing around for an hour or so I've figured out that the
timeout value is 1000ms, the right menu key erases the character
preceding the current position and the up/down cursor keys move
backward/forward through the text.  Running it on `sms4.csv` yields
the following message:

> alright pal heres ye flag good luck entering it with those hooves
> lol its aotw{l3ts_dr1nk_s0m3_eggn0g_y0u_cr4zy_d33r}