2003scape
Feature Request: support ISAAC + RSA for 235 server compatibility
https://github.com/2003scape/rsc-client/blob/2146ae22ddc903361c4bc69cf2d1d961d25d0ee8/src/packet-stream.js#L35-L39
Not sure what else is needed here to enable ISAAC.
Also in https://github.com/2003scape/rsc-client/blob/2146ae22ddc903361c4bc69cf2d1d961d25d0ee8/src/game-connection.js#L58-L150, the login packet isn't encapsulated in RSA, so it won't work for a 235 server. Might be correct for a 204 server, haven't looked into that.
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 deprecated the security of the traditional Jagex protocol (rsa+isaac) in favor of traditional TLS mechanisms
// which are inherently more secure and also we gain the support for it through built-in standardized libraries automatically
// Even though we no longer need to, I still encrypt the login block for the reason that one may wish to provide non-TLS
// client support and this will protect the user login credentials in this case.
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 I dont see rust version, chance i never committed it. Be at PC soon and will commit latest probably
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
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.
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.