-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: support ISAAC + RSA for 235 server compatibility #4
Comments
Yeah I explicitly disabled those to make it easier to test my server. JS has native BigInt support now so the RSA can be identical the the regular 204, and the ISAAC class just needs to be ported over or I can just use an ISAAC module instead. To support 235, some of the chat encoding, friends list, and login packet structures would need to be modified slightly, as well as some of the opcodes. I think a branch of this repository with 235 support would make sense. |
My fork contains an RSA implementation in both JS and one in Rust. The JS one maybe got removed in master; might have to look to commit history to locate it. I have ISAAC code in my local copy, however I have stalled dev work lately as 2020 really smacked me in the face recently. Maybe I can put some patches together for you in a little while. EDIT: A note on my Rust implementation, some form of memory bug might occur where the block of Wasm memory shared with JS apparently contains bad data. I am not sure if it is fixed in that revision or not. In any event, it usually worked fine even when it had this issue. |
Found this note in your fork & didn't look too much further; seems like you went for an updated approach with "room in the future for maybe non-TLS client support".
I've been updating Open RSC & now am able to log into it with RSC+. So in the future, there will actually be a running fully-featured server that supports the RSC235 protocol. Could possibly support 204 client protocol too, I understand it's not that different (haven't looked very closely at 204 client dev personally), but it would be neat if that was not necessary to support 204 & there were a javascript client that supported RSC235. |
No, the TLS crypto is all automagically taken care of transparently, in the websocket code. The RSA being used in my client is plain jane identical to Jagex. I even made a program in Go to generate exponents and mods. 204 vs 235 is a thing i know a thing or two about. They are incredibly similar, can basically count differences on 2 hands. Biggest hurdle is going to be chat charset encoding. Can discuss further on discord if you like. Edit: js code here https://github.com/spkaeros/rsc-client/blob/master/src/gamelib/rsa.js |
JS supports BigInt natively now, so the big-int module isn't required: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#BigInt_type |
Indeed. Explored that option brother, found its API sincerely lacking. The from/toArray calls were my hickup to be specific, had wrote a workaround using a conversion function I hand wrote but ran into some form of issue and reverted to the library. |
Hey @Hubcapp hope you don't mind me getting involved here I am the author of this https://www.npmjs.com/package/isaac-crypto It's tested, written in TypeScript (if that's your thing) and is used by a few RS2 projects. I'd love to help get it set up here if you think it would be useful! Let me know if you have any questions about it |
Well, I think you @'d the wrong person. I have a lot of projects I'm already working on without getting directly involved in javascript client dev. I'm hoping @spkaeros or @misterhat will get around to it. Thanks for your input though, it does look like a useful library. P.S. RSC235 support is now part of the Open RSC code base, and the feature goes live tomorrow. |
Yeah @Jameskmonger the ISAAC library looks useful, great work. Makes sense to implement it in rsc-server and rsc-client at some point. |
Implementation underway here, will keep you posted, hopefully just a few days just looking for time to write the code. |
Sorry forgot all about this I have redone the networking code in what I view as an improvement, with 235 compliance. Will post soon as am at pc |
Definitely something we're still interested in...! |
So making a cogent PR here will be a task of its own as our code bases have changed too dramatically just to diff&push. That said I'm working on getting it to you. |
Am I to assume your preference is to use your network API with my crypto code Frankensteined onto it? Cos i been perfecting my networking API and truly suhgest its use. Ill do a push to my webclient master shortly as an update for yall |
Alsi pretty sure frankensteIm patchery is how ORSC gets born. no disrespect intended but seriously isnt it |
Any way you can do it without modifying too much of the OpenRSC source is fine. Ideally it would be RSC235 over websocket instead of TCP. |
Obviously over ws; unless looking to make a connection after forcing a browser plugin installation on our end users. If you'd seen my private rsc-client any time last few months, focus has been on standardizng many things, and modernizing things I deemed to outdated. The reason I bring that up, I have implemented a src/packets.js which has a func for each client opcode packets builder. Keep this would mean I can give you my patch like now, but I gutted src/packet.js and src/network-stream.js they are NOTHING like Jagex's and packet is even unused, the Packet class when needed is found embedded in the desired stream I/O class as I felt there were far too great number of files total. Also I use webpack 5 now, custom bigint rsa where I took modpow from the big-num? package, src/lib/isaac.js is just basically an encapsulated isaac module and we now import xtea out of npm. So some reasons I bring this things up, a direct port is going to be a bitch. It'd be far easier to just follow my login procedures along and copy-paste their functionality, so this is my path forward but my recomendation for structuring is to do similar in the near future to my changeset. My input handling is also totally redone, incl. src/net/lib/{socket,file-download-stream} and both mouse/kb. I changed if I had to estimate 75-90% of the codebase. Lemme know thoughts yes??? Intriguingly, back to using my Android phone for a main driver here for dev work, will be ordering highest end pine device to replace soon enough alrdy got thte NVME SSD for it. |
Hey 👋 I don't know if this is also useful to you @spkaeros, but I also wrote an almost feature-complete implementation of the buffer logic here https://github.com/Jameskmonger/rs-buffer It's in TypeScript, and unit tested - not sure how similar this is between 317 and rsc but if it's useful I'm also happy to help get this set up 👍 If there's anything you think is missing which would make it easier to use please let me know |
It handles the different endianness as well as the different transformations 😄 |
As long as it is to RSC235 spec & client behaviour isn't apparently different to users, I don't mind any drastic rewrites you mention. Those are the only goals that matter to me though. |
rsc-client/src/packet-stream.js
Lines 35 to 39 in 2146ae2
Not sure what else is needed here to enable ISAAC.
Also in
rsc-client/src/game-connection.js
Lines 58 to 150 in 2146ae2
The text was updated successfully, but these errors were encountered: