Re: ICQ charsets.

On Jun 4, 2005, at 7:11 PM, Elektron wrote:
> snort gives the following dumps when I'm sent "abc", "def", and=20
> "abc<opt-v>" by an Adium user (with my brother's ICQ number blanked=20
> appropriately):
>
> ***AP*** Seq: 0x678EFA8C  Ack: 0xDEAB692F  Win: 0x4000  TcpLen: 20
> 2A 02 CC 63 00 58 00 04 00 07 00 00 91 E3 C1 80  *..c.X..........
> 9B 4D 39 F6 F7 E8 A1 05 00 01 08                 .M9........xxxxx
> 39 38 39 00 00 00 04 00 01 00 02 00 50 00 06 00  989.........P...
> 04 20 03 00 00 00 0F 00 04 00 00 00 9B 00 03 00  . ..............
> 04 42 A2 55 65 00 02 00 11 05 01 00 02 01 06 01  .B.Ue...........
> 01 00 07 00 00 00 00 61 62 63 00 0B 00 00        .......abc....
>
> ***AP*** Seq: 0x678EFAEA  Ack: 0xDEAB692F  Win: 0x4000  TcpLen: 20
> 2A 02 CC 64 00 58 00 04 00 07 00 00 91 E3 C7 E2  *..d.X..........
> D3 FE ED A5 D5 F3 D9 E4 00 01 08                 ...........xxxxx
> 39 38 39 00 00 00 04 00 01 00 02 00 50 00 06 00  989.........P...
> 04 20 03 00 00 00 0F 00 04 00 00 00 9D 00 03 00  . ..............
> 04 42 A2 55 65 00 02 00 11 05 01 00 02 01 06 01  .B.Ue...........
> 01 00 07 00 00 00 00 64 65 66 00 0B 00 00        .......def....
>
> ***AP*** Seq: 0x678EFB6B  Ack: 0xDEAB6975  Win: 0x4000  TcpLen: 20
> 2A 02 CC 66 00 5D 00 04 00 07 00 00 91 E3 E4 0D  *..f.]..........
> 5B FA 6C C3 51 E2 20 AE 00 01 08                 [.l.Q. ....xxxxx
> 39 38 39 00 00 00 04 00 01 00 02 00 50 00 06 00  989.........P...
> 04 20 03 00 00 00 0F 00 04 00 00 00 A4 00 03 00  . ..............
> 04 42 A2 55 65 00 02 00 16 05 01 00 02 01 06 01  .B.Ue...........
> 01 00 0C 00 02 00 00 00 61 00 62 00 63 22 1A 00  ........a.b.c"..
> 0B 00 00                                         ...
>
> It looks like there's a length-prefixed string (two bytes big-endian,=20=

> confirmed with strings longer than 256 chars), and then a four-byte=20
> prefix to the message, which is probably two bytes for the text=20
> encoding and two bytes reserved, followed by the message.
>
> Fire incorrectly interprets the string as a blank line. I assume=20
> something truncates it at the null char. I don't know what the=20
> 'correct' behaviour is, but when the text encoding is set to UTF-16, I=20=

> still get a blank line. It also translates normal text into mostly=20
> chinese characters. It doesn't look at the character set embedded into=20=

> the message.
>
> Now, when I *send* something (anything!) as UTF-8,
>
> ***AP*** Seq: 0xDEAB6AF0  Ack: 0x678F0612  Win: 0xFFFF  TcpLen: 20
> 2A 02 2E 40 00 34 00 04 00 06 00 00 00 00 00 00  *[email protected]..........
> 00 00 00 00 00 00 00 00 00 01 08                 ...........xxxxx
> 39 38 39 00 02 00 0F 05 01 00 01 01 01 01 00 06  989.............
> 00 00 00 00 FE FF 00 06 00 00                    ..........
>
> Obviously, it's truncating everything at the byte prefix. It also=20
> doesn't send the 00020000 prefix to signify big endian UTF8. It's=20
> interpreted as ISO-latin-1 (I suppose, anyway), which gives "latin=20
> small letter thorn", y-umlaut. It's even stranger when I tell him to=20=

> send it back to me:
>
> ***AP*** Seq: 0x678F19F0  Ack: 0xDEAB7009  Win: 0x4000  TcpLen: 20
> 2A 02 CC B8 00 57 00 04 00 07 00 00 91 F3 BF 44  *....W.........D
> 93 B3 73 7E 1B 27 D9 C4 00 01 08                 ..s~.'.....xxxxx
> 39 38 39 00 00 00 04 00 01 00 02 00 50 00 06 00  989.........P...
> 04 20 03 00 00 00 0F 00 04 00 00 04 EA 00 03 00  . ..............
> 04 42 A2 55 65 00 02 00 10 05 01 00 02 01 06 01  .B.Ue...........
> 01 00 06 00 03 00 00 FE FF 00 0B 00 00           .............
>
> I don't know what encoding 00030000 is, but I assume it's iso-latin-1=20=

> or similar, and 00000000 is for plain ASCII only, though it falls back=20=

> to iso-latin-1. This is, of course, Adium's behaviour, but it's bound=20=

> to be closer to the standard than truncating at the first null char.
>
> Something needs to be fixed here. I'm sick of telling him that he's=20
> sending me blank lines.
>
> The exact same message on AIM is similar (except AIM annoyingly forces=20=

> me to send HTML AAAAAARGH):
>
> ***AP*** Seq: 0xAA62E40A  Ack: 0x5F62FE24  Win: 0x4000  TcpLen: 20
> 2A 02 26 DE 00 5D 00 04 00 07 00 00 91 DA 50 0D  *.&..]........P.
> 1F 3C 6D 19 9D 38 DE 10 00 01 08                 .<m..8.....xxxxx
> 39 38 39 00 00 00 04 00 01 00 02 00 50 00 06 00  989.........P...
> 04 20 03 00 00 00 0F 00 04 00 00 07 9F 00 03 00  . ..............
> 04 42 A2 55 65 00 02 00 16 05 01 00 02 01 06 01  .B.Ue...........
> 01 00 0C 00 02 00 00 00 61 00 62 00 63 22 1A 00  ........a.b.c"..
> 0B 00 00                                         ...
>
> This time, however, it correctly shows up as abc=C3. Whether that =
shows=20
> up in your mail client is another story. Maybe using the AIM library=20=

> for ICQ would fix some things.
>
> But then, AIM leaves much to be desired (like all the HTML tags it=20
> sends x.x).
>
> - Purr

In the current TOT CVS code you have the choice of using either=20
libicq2000 or libfaim for ICQ. Which library/Fire version are you=20
using? I'm hoping this problem is specific to libicq2000.

-Jason



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20