icq update protocol version

[GoogleCodeExporter]

pyicq-t was received message from contact 1:

=============================
         System Message
=============================
The version you are using is not supported by ICQ.  Download a free
authorized ICQ version from ICQ's official website.

Pyicq-t 0.8.1.1 

Original issue reported on code.google.com by IS.U...@gmail.com on 21 Jan 2009 at 10:34

[GoogleCodeExporter]

Same error on version 0.8b.

Original comment by vitaliy....@gmail.com on 21 Jan 2009 at 11:07

[GoogleCodeExporter]

Same here :-( What a irony, 5 days ago pyicq-t was updated.

Tried four different login servers:
64.12.200.89 205.188.179.233 205.188.153.121 205.188.153.121

all of them reject pyicq-t.

Gosh, wish I would be able to drop ICQ altogether.

Original comment by zapparello on 21 Jan 2009 at 11:23

[GoogleCodeExporter]

Same error in 0.8.1.1

Original comment by balance...@gmail.com on 21 Jan 2009 at 12:35

[GoogleCodeExporter]

Confirm on 0.8.1 and 0.8.1.1 too.
ICQ update your protocol.
Kopete, Pidgin, QIP, Miranda and some other clients have this issue too. At 
official
sites of non-official ICQ messengers I see the messages that this issue will be
solved in newer versions that will be releases as short as possible.

Original comment by Mur...@gmail.com on 21 Jan 2009 at 1:11

[GoogleCodeExporter]

Some people tell that helps setting "Client ID" as "ICQ5" on the non-official 
ICQ client.

Original comment by Mur...@gmail.com on 21 Jan 2009 at 2:00

[GoogleCodeExporter]

"Some people tell that helps setting "Client ID" as "ICQ5" on the non-official 
ICQ
client."

how to make it in PyICQ config ???

Original comment by nordheim...@mail.ru on 21 Jan 2009 at 2:10

[GoogleCodeExporter]

the same problem with 0.8b-0.8.1.1, but there is a strange: Pidgin is working 
(Debian
Lenny)

Original comment by springhe...@gmail.com on 21 Jan 2009 at 2:17

[GoogleCodeExporter]

i think problem in that lines  (marked >):
  self.sendFLAP('\000\000\000\001'+
                TLV(TLV_USERNAME,self.username)+
                TLV(TLV_ROASTPASSARRAY,encpass)+
                TLV(TLV_CLIENTNAME,'ICQBasic')+
>                TLV(TLV_CLIENTID,"\x01\x0a")+
>                TLV(TLV_CLIENTMAJOR,"\x00\x14")+
>                TLV(TLV_CLIENTMINOR,"\x00\x22")+
                TLV(TLV_CLIENTLESSER,"\x00\x01")+
                TLV(TLV_CLIENTSUB,"\x06\x66")+
                TLV(TLV_CLIENTDISTNUM,"\x00\x00\x06\x66")+
                TLV(TLV_LANG,"en")+
                TLV(TLV_COUNTRY,"us"),0x01)
But i dont know right values

Original comment by demm...@gmail.com on 21 Jan 2009 at 2:30

[GoogleCodeExporter]

I think you can use sniffer (tcpdump, wireshark) to get right values.

Original comment by vitaliy....@gmail.com on 21 Jan 2009 at 2:32

[GoogleCodeExporter]

pidgin downloaded right from the official site is not working.
only that who not reconnected today are still online :)

Original comment by roman.sh...@gmail.com on 21 Jan 2009 at 2:38

[GoogleCodeExporter]

My friend have this problems with ICQ on Pidgin 2.5.2-0ubuntu1 on Linux, but 
have
succesfully connected to ICQ at now with Pidgin 2.5.3 on Windows.
I think that we can sniff the Pidgin 2.5.3 on Windows traffic to solve the 
problem. 

Original comment by Mur...@gmail.com on 21 Jan 2009 at 3:59

[GoogleCodeExporter]

details how to connect here:
http://www.forum.mista.ru/topic.php?id=384750#93

miranda with some deep "magic" connected as ICQ for MAC.

Original comment by roman.sh...@gmail.com on 21 Jan 2009 at 4:05

[GoogleCodeExporter]

I have made pyicq to work through the server: login.alwayson.im:443
And I am very nice chat with bot here :-)

Original comment by bars...@gmail.com on 21 Jan 2009 at 5:27

[GoogleCodeExporter]

Do you change TVL_CLIENTNAME to "Mac ICQ" ?

Original comment by andr.smi...@gmail.com on 21 Jan 2009 at 5:39

[GoogleCodeExporter]

just changed only pyicq's server and port to login.alwayson.im:443
 and everything working, not touched client name.

Original comment by roman.sh...@gmail.com on 21 Jan 2009 at 5:41

[GoogleCodeExporter]

thanks, it's working now, without any modification... but i have suspicions 
about bot )) 

Original comment by springhe...@gmail.com on 21 Jan 2009 at 5:44

[GoogleCodeExporter]

Waiting for patch that allow to use standard login servers... Bot is annoying %)

Original comment by andr.smi...@gmail.com on 21 Jan 2009 at 6:12

[GoogleCodeExporter]

Some investigation about this problem...
I'm VERY sory, but it's on russian...
Maybe anyone can translate it for english-speaking people...

http://forumlocal.ru/showthreaded.php?Cat=&Board=soft&Number=8273715&fullview=&s
rc=&o=&vc=1

Original comment by andr.smi...@gmail.com on 21 Jan 2009 at 6:17

[GoogleCodeExporter]

As far as I know leading developer can read in Russian. Is translation still 
needed?

Main theses are:
1) only Russian users are affected — you're not affected if you use 
non-Russian proxy
2) full list of client capabilities is checked, it should match with `original` 
client.
3) there MAY be some secret key somewhere that is either hardcoded in original 
client
or is calculated with some secret algorithm inside of original client
4) there is assumption, that initial `sequence id` is the `secret key` as most 
of
alternative clients generate random number for it and `original` client MAY have
another algorithm for seqid generation.

Original comment by mathemonkey on 21 Jan 2009 at 6:25

[GoogleCodeExporter]

yes only russian... the issue board in this thread is so empty for global 
problem

Original comment by springhe...@gmail.com on 21 Jan 2009 at 6:28

[GoogleCodeExporter]

http://habrahabr.ru/blogs/im/49778/
some new things...

Original comment by andr.smi...@gmail.com on 21 Jan 2009 at 8:41

[GoogleCodeExporter]

Solution for this problem for miranda icq+ plugin was just published.

SVN is at http://sss.chaoslab.ru:81/svn/icqjplus/

Hopefully somebody can port this to pyicqt ?

Original comment by yo...@cs.msu.su on 21 Jan 2009 at 11:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

No, they did not commit it yet. However binaries already available.

Original comment by yo...@cs.msu.su on 21 Jan 2009 at 11:50

[GoogleCodeExporter]

http://habrahabr.ru/blogs/im/49778/ (on Russian)

solution for Miranda:
set clientname to icq6
set proto version = 12
add capability "41 49 4D 00 00 00 00 00 00 00 00 00 00 00 00 00"

does anyone know how to apply it to pyicq-t?

Original comment by Equidamoid on 22 Jan 2009 at 5:24

[GoogleCodeExporter]

Please, don't panic

Original comment by r000ns...@gmail.com on 22 Jan 2009 at 7:07

[GoogleCodeExporter]

Don't forget to make some notes if you find a solution for this problem.

Original comment by V.Titare...@gmail.com on 22 Jan 2009 at 7:41

[GoogleCodeExporter]

UPD3: Сейчас нашли корреляцию между временем 
входа и используемым номером
последовательности, так что есть зацепка, 
что для генерации все же используется какое
то случайное число, но эту версию надо 
проверять. Так же как оказалось коннектятся
все старые клиенты, даже icq2003b, и TestBuddy 2002 
года. Плюс есть несколько
сообщений о том что у некоторых 
провайдеров в Омске все работает 
нормально. В общем
сейчас конечный вывод — «асечники» нашли 
коренное различие между официальным 
клиентом
и всеми клонами и активно его используют.

>>UPD3: Where have been found some correlation between time of login and used
sequences number, so looks its using some random  number for generating it. But 
it
has to be tested first. We find out that old clients, even icq2003a & TestBuddy 
2002
is now working. ...

Original comment by nordheim...@mail.ru on 22 Jan 2009 at 8:01

[GoogleCodeExporter]

temporary solution use 'tor', example for FreeBSD:

1) cd /usr/ports/security/tor && make install clean
2) echo 'tor_enable="YES"' >> /etc/rc.conf
3) /usr/local/etc/rc.d/tor.sh start
4) vim /usr/local/etc/jabber-pyicq.xml  (add use socksProxyServer 127.0.0.1 
socksProxyPort 9050)
5) /usr/local/etc/rc.d/jabber-pyicq-transport.sh restart

Original comment by m.surkiz on 22 Jan 2009 at 8:27

[GoogleCodeExporter]

I want to mention that it is insecure solution as many of tor exit-nodes have
sniffers installed and ICQ does not encrypt it's traffic.

Original comment by mathemonkey on 22 Jan 2009 at 8:29

[GoogleCodeExporter]

>I want to mention that it is insecure solution as many of tor exit-nodes have
sniffers installed and ICQ does not encrypt it's traffic.

Do you think AOL doesn't monitor ICQ traffic? ICQ is insecure by definition, 
unless
you use end-to-end encryption.

Original comment by vi...@wagner.pp.ru on 22 Jan 2009 at 8:40

[GoogleCodeExporter]

There is option <usemd5auth> in config.xml It should prevent passwords leaking.

Original comment by maxim.br...@gmail.com on 22 Jan 2009 at 8:41

[GoogleCodeExporter]

Vitus, AOL may monitor traffic, but some of exit-nodes DO monitor, so it should 
be
considered while using TOR network. This is important as there is market for 
6-digits
and 7-digits ICQ uins. Also spammers use to steal ICQ accounts to send spam to 
user's
contact-list.

Right, Maxim, that's exactly what I meant. One should not use TOR unless 
md5auth is
enabled.

Original comment by mathemonkey on 22 Jan 2009 at 9:02

[GoogleCodeExporter]

> This is important as there is market for 6-digits
and 7-digits ICQ uins.

Оh, you are about passwords. And I've meant data. I just forgot that there 
might be
people who are smart enough to run own jabber-icq transports, and don't use 
secure
authentication.

Original comment by vi...@wagner.pp.ru on 22 Jan 2009 at 9:18

[GoogleCodeExporter]

m.surkiz: Thanks!!!! It's working!

Original comment by andr.smi...@gmail.com on 22 Jan 2009 at 9:36

[GoogleCodeExporter]

<32> I can't find any option <usemd5auth> in pyicq-t config.xml
(http://pyicqt.googlecode.com/svn/trunk/config_example.xml).

Where can I find this option? This is undocumented feature?

Original comment by V.Titare...@gmail.com on 22 Jan 2009 at 10:22

[GoogleCodeExporter]

Look at http://code.google.com/p/pyicqt/wiki/Git
pyicq-t in git repo.

Original comment by maxim.br...@gmail.com on 22 Jan 2009 at 10:33

[GoogleCodeExporter]

m.surkiz: Thanks, it's working for me too!

Original comment by Mur...@gmail.com on 22 Jan 2009 at 10:39

[GoogleCodeExporter]

Tor is good idea, but my pyICQ-t 0.8b works again without any 
patches/modifications.
It's working perfectly now. 
Kind of joke from AOL?

maxim.britov thanks.

Original comment by V.Titare...@gmail.com on 22 Jan 2009 at 10:47

[GoogleCodeExporter]

New solution (I have not tested it):

--- pyicqt-0.8.1.1.orig/src/tlib/oscar.py       2009-01-06 23:31:38.000000000 
+0600
+++ pyicqt-0.8.1.1/src/tlib/oscar.py    2009-01-22 16:40:20.000000000 +0600
@@ -3990,7 +3990,7 @@
            self.sendFLAP('\000\000\000\001'+
                TLV(TLV_USERNAME,self.username)+
                TLV(TLV_ROASTPASSARRAY,encpass)+
-               TLV(TLV_CLIENTNAME,'ICQBasic')+
+               TLV(TLV_CLIENTNAME,'ICQ 4 Lite')+
                TLV(TLV_CLIENTID,"\x01\x0a")+
                TLV(TLV_CLIENTMAJOR,"\x00\x14")+
                TLV(TLV_CLIENTMINOR,"\x00\x22")+
@@ -4013,7 +4013,7 @@
                TLV(TLV_USERNAME,self.username)+
                TLV(TLV_PASSWORD,encpass)+
                TLV(0x004C)+
-               TLV(TLV_CLIENTNAME,'ICQBasic')+
+               TLV(TLV_CLIENTNAME,'ICQ 4 Lite')+
                TLV(TLV_CLIENTID,"\x01\x0a")+
                TLV(TLV_CLIENTMAJOR,"\x00\x14")+
                TLV(TLV_CLIENTMINOR,"\x00\x22")+

Original comment by m.surkiz on 22 Jan 2009 at 11:26

[GoogleCodeExporter]

It works with login.alwayson.im:443 for me

Original comment by roman.ja...@gmail.com on 22 Jan 2009 at 11:28

[GoogleCodeExporter]

Sorry, people say that the patch does not work...

Original comment by m.surkiz on 22 Jan 2009 at 11:30

[GoogleCodeExporter]

My pyICQ-t 0.8b works with troubles: some people with UIN starts with 4* can't 
send
any messages. They get a message about wrong ICQ version.

But I can send and receive messages (between 1* and 3*). All UINs is 9-digits.
It would be load-balanced servers divided by UIN there.

login.alwayson.im:443 don't work for me.

Original comment by V.Titare...@gmail.com on 22 Jan 2009 at 12:20

[GoogleCodeExporter]

We may change host to slogin.alwayson.im or login.alwayson.im.

And it works. And it adds a kind if clever bot (assistant@ao.im), that behaves 
like a
quest :). And it does not get banned.

But are their enough reliable to let them login for us? Who knows what does AOL 
say
about alwayson.im?

Google "site:aol.com alwayson.im" and "site:icq.com alwayson.im" says nothing...

Original comment by dlu...@gmail.com on 22 Jan 2009 at 12:23

[GoogleCodeExporter]

Working over socks-ssh-tunnel to NON russian server.

Original comment by vole...@gmail.com on 22 Jan 2009 at 12:41

[GoogleCodeExporter]

http://habrahabr.ru/blogs/im/49877/ — patch for some clients is ready and 
will be
published soon.

Original comment by mathemonkey on 22 Jan 2009 at 12:49

[GoogleCodeExporter]

http://www.asechka.ru/

Original comment by kuvi...@gmail.com on 22 Jan 2009 at 2:31

[GoogleCodeExporter]

BTW, pyicq-t already starts FALP seq. numbers from 0 for quite a long time, so,
seems, it is not enough.
I assume, that capabilities set is wrong, but I know no details :-)

Original comment by mathemonkey on 22 Jan 2009 at 2:56

[GoogleCodeExporter]

That work for me:

--- oscar.py.orig       2009-01-06 20:31:38.000000000 +0300
+++ oscar.py    2009-01-22 19:03:51.000000000 +0300
@@ -598,7 +598,7 @@
 class OscarConnection(protocol.Protocol):
     def connectionMade(self):
         self.state=""
-        self.seqnum=0
+        self.seqnum=10000
         self.buf=''
         self.outRate=6000
         self.outTime=time.time()

Original comment by Master.N...@gmail.com on 22 Jan 2009 at 4:06

[GoogleCodeExporter]

comment #49 worked for me too :)

Original comment by roman.sh...@gmail.com on 22 Jan 2009 at 4:16