WIP: ICQ legacy protocol support (V2-V5) based on iserverd#171
WIP: ICQ legacy protocol support (V2-V5) based on iserverd#171
Conversation
|
Hello, I am very excited about this PR. Unfortunately, this is problematic: If I knowingly merge code that is based on decompilation, that puts my project at risk of a copyright takedown. I can only accept changes that are made based on clean reverse engineering techniques (pcap analysis, etc). |
|
Please don't merge, this is WIP and will change as I will test it more. It's just to show conceptually that this is possible. Feel free to review and suggest improvements. Disassembly didn't produce any substantial assistance, v4 is based on documentation from internet archive, v2 is from iserverd and trial and error, both don't actually are in usable state, and more for reference and future development, if somebody will come up with dumps or ideas, as protocol flow is still unclear. |
|
Cleaned up work notes and documentation. |
|
Thanks for letting me know. I’ll review the code and provide some early feedback. |
|
It turned out that old versions of open-source clients are good protocol Protocol v2 should also work, but it is unclear which ICQ version The implementation is now ready for proper review, although many |
|
Excellent, I’ll review over the next couple days |
|
I found ICQ version with protocol 1 and 2. These are ICQ 1.02 beta from 1996 and ICQ 1.111 Beta from 1997 respectively, but they are strictly checking for windows 95 or nt 4.0 (don't want to install in windows 98 even). 1997 ICQ for windows 3.11 1.111 beta seems also to be a variant of protocol 2. Either way, I can't figure out their FirstLogin flow (first login after installation), it's the same problem I solved with protocol V4. Open source clients only do normal login (that is different state machine). Either way, these clients are very niche, and how much I would like to support them (especially windows 3.11 one), so far I was not able to figure it out. |
|
How are you configuring the server hostname in the client? I tried overriding the hostname in |
|
Nevermind, figured it out. Set the hostname by clicking "For admin use" on sign-on. |
|
I'm able to connect and chat between ICQ99 and ICQ2000b—pretty cool! I will focus on reviewing the code architecture next. |
One small message for a client, one giant leap for interoperability. :) |
|
Just checking in on this PR. Is this something you’d like to move forward with? No rush. Happy to keep iterating on it if needed, or close it out if it’s not a direction you want to take. Thanks. |
|
Hey @VasylSamoilov I still would like to move forward with this PR. 👍 My main architectural concern with this PR is that there is net new logic added to the It appears that open-oscar-server/foodgroup/icq.go Line 390 in 1c3fe17 I think much of the legacy ICQ server can be implemented by passing messages to and from the existing I invite you to you look at the Here are some guidelines:
Let me know if this makes sense or not :) |
|
Hey @mk6i, I went ahead and followed your guideline for the rearchitecture.
Good news that it still works! Please have a look. |
|
@mk6i You are correct. Cleaned up a little bit.
|
mk6i
left a comment
mk6i
left a comment
There was a problem hiding this comment.
Thanks for those changes. Now that the ICQ legacy logic is isolated to 1 package, I’ll focus my review on the internals of the package itself.
Will likely continue the review tonight (my time).
|
Default supported versions are now V3, V4, V5. These are production-ready, covers nearly all known icq clients including groupware. V1 is logging only (not implemented). V2 is disabled by default but the login sequence is nearly complete. With some help on the remaining handshake steps we could enable it going forward - and get icq for windows 3.11 up and running. I can provide dosbox image with windows 3.11, icq and aim clients pre-installed in someone is willing to help, would appreciate it. SetHomepageCategory removed from foodgroup ICQUserUpdater - only used by icq_legacy. DeleteUser stays on foodgroup UserManager because the management HTTP API (mgmt_api.go) uses it for account deletion. Other requested and not requested :) changes:
|
mk6i
left a comment
mk6i
left a comment
There was a problem hiding this comment.
Please squash your commits and I'll be ready to merge!
In a follow-up PR, would you please write user documentation that explains how to set up clients for each protocol?
|
I did it. V2 login works! Now a little bit of testing is required. 
|
|
And I broke legacy-oscar bridge during refactoring. Now I'm scratching my head how to fix it properly and don't break the architecture. Stay tuned :) |
|
@mk6i I'm really pushing the envelope of my capabilities here. Attempted a minimal-impact bridge, but this area is more complex than expected. |
How do I reproduce? Login with incorrect credentials? |
No. When a user adds someone to their contact list, that entry should be placed in a “waiting authorization” state. The other party cannot add them to their own contact list unless approval is granted on the remote side. This is handled via a dedicated authorization request/response message flow. This mechanism already functions correctly on the ICQ-ICQ pair and ICQ side of ICQ-OSCAR pair (OSCAR contact requires explicit authorization for visibility). However, for OSCAR, ICQ users are currently added as visible/authorized by default. |
|
Which OSCAR client are you using to test? |
ICQ 2003b build # 3916 |
|
Does authorization work if you set AuthRequired=true on the users sql table? We set this to false by default recently, I don’t think it was intentional. |
|
I'll check tomorrow and report. That may be the root cause. |
|
Please pull main, I restored requiring authorization by default |
It was not only that. But it helped. Ready for review. |
|
Excellent. Can you squash your commits? |
| export ICQ_LEGACY_UDP_LISTENER=0.0.0.0:4000 | ||
|
|
||
| # Comma-separated list of supported ICQ protocol versions. Valid values: 1, 2, | ||
| # 3, 4, 5. V1 is logging only (not implemented). V2 is partial (login sequence |
|
|
||
| if err := s.feedbagManager.FeedbagUpsert(ctx, instance.IdentScreenName(), items); err != nil { | ||
| return nil, err | ||
| // Check which buddy items require authorization. Items that need auth |
| return nil | ||
| } | ||
|
|
||
| // RequestAuthorizeToHost forwards an authorization request from the user who |
There was a problem hiding this comment.
Out of curiosity, which ICQ versions send this?
UDP-based ICQ legacy protocol handlers for pre-OSCAR clients. Implements login, messaging, contacts, search, user info, status notifications, registration, and offline messages. Based on iserverd and old versions of licq source code. Cross-protocol bridge between legacy ICQ and OSCAR: - Bidirectional presence notifications (status, online/offline) - Message routing (text, URL, contacts, auth messages) - Authorization enforcement (feedbag 0x000E, request/grant/deny flow) - Profile save persistence for all protocol versions - Status mapping between legacy ICQ and OSCAR status values - V2: Based on licq source, untested - V3: Tested with ICQ Groupware - V4: Based on licq, tested with ICQ 98a - V5: Tested with ICQ99
Squashed. |
UDP-based ICQ legacy protocol handlers for pre-OSCAR clients. Implements login, messaging, contacts, search, user info, status notifications, registration, and offline messages. Based on iserverd and old versions of licq source code. Cross-protocol bridge between legacy ICQ and OSCAR: - Bidirectional presence notifications (status, online/offline) - Message routing (text, URL, contacts, auth messages) - Authorization enforcement (feedbag 0x000E, request/grant/deny flow) - Profile save persistence for all protocol versions - Status mapping between legacy ICQ and OSCAR status values - V2: Based on licq source, tested with ICQ for windows 3.11 - V3: Tested with ICQ Groupware - V4: Based on licq, tested with ICQ 98a - V5: Tested with ICQ99
Ok, I have completed V2 protocol support and force-pushed squashed result. Please review. |
|
So far it's the only ICQ server implementation that supports v2 and v4 protocol. |
|
👏 |
|
@VasylSamoilov can you plz fix the go vet errors (see build failure) |
|
yes, this and small test fix. #180 |
2 participants
This PR introduces initial support for legacy, UDP-based ICQ protocols used by pre-OSCAR clients. The implementation focuses on protocol compatibility across multiple historical versions and is still a work in progress. Feedback and criticism are very welcome.
Supported protocol versions
V2: Partial login support
Tested with Windows 3.11 16-bit client
V3: Functional login and messaging
Tested with ICQ Groupware
V4: Initial login succeeds
ICQ 98a specific version only
V5: Fully working
Tested with ICQ99
Known limitations
Later ICQ 98a releases use V5 with TCP_VER=4 (V4 encapsulated in V5 framing).
This mode is not yet supported.
Implementation notes
Based on the iserverd reference implementation.
Includes protocol documentation and research notes on client internals to aid future development and maintenance.