create a global handler e.g.
on encryptSend me, recipient, data , otherargs
Then globally find/replace all sendNetMessage( instances with encryptSend(
Instead of calling the sendNetMessage directly, all scripts will be calling
the encryptSend handler. You can then perform all modifications necessary
and use the sendNetMessage from within that handler.
From what I can recall though, using #all as a prefix in the encrytpion
string, instructs the xtra to encrypt all messages, and not just the
handshake. So perhaps you don't really need to use your custom encryption
code.


"justinjkdr" <webforumsuser@macromedia.com> wrote in message
news:fgtl7e$5om$1@forums.macromedia.com...
> Alright well I have a game here that has already been made and I wanted to
> add
> an encryption to all the outgoing subject and contents, the function to
> encrypt
> the strings is already made and working called encryptStr()
>
> Now my question, is there a way i can intercept the outgoing messages
> without
> having to go to EVERY single sendNetMessage instance adding the encryptStr
> function there...? Because that seems to be a pain in the butt and a
> complete
> waste of time, there are over 400 sendNetMessage instances and I don't
> want to
> do a 'Find Text' for all of them =P =P
>
> Thank you for your help!
>

Besides the message structure weakness, have you been able to decrypt an
encrypted message (e.g. the logon packet), knowing the encryption key?
Or, to put it another way, since according to some doc I think I read once,
mu is using a 'variation' of the blowfish algorithm, have you checked if
standard blowfish decoding works?
I tried it once quite some time ago without much success, and will have to
give it a second go in the near future.

"justinjkdr" <webforumsuser@macromedia.com> wrote in message
news:fh9568$dml$1@forums.macromedia.com...
> Aw damn so simple and I didn't even think to do that, that replace string
> should work nicely =)...
>
> I don't use the #all blowfish encryption because I actually made my own
> server
> that the director client connects to and I haven't added that encryption
> into
> it yet... Plus that encryption isn't really too strong for what I'm trying
> to
> protect against. If you actually look at an encrypted packet using the
> built in
> encryption the packet structure stays the same... For example the packets
> are
> the same length and people can just mix and match messages and put them
> together because it encrypts each part of the packet seperately (header,
> timestamp, errorcode, sbject, etc..) whereas my encryption changes with
> each
> packet it sends because it uses the timestamp as a key ;) So each piece of
> data, even though its the same string, will be different when encrypted,
> and if
> people know the timestamp is the key and freeze it, then we're down to the
> same
> level as the built in one... So I might as well use mine, no average gamer
> is
> really going to figure out a homemade encryption especially people playing
> this
> game, it's actually pretty good.
>
> Thank you for your help though, I appreciate it =)
>

> and I check it against the encrypted key that the client sends on
> connection.
Huh? I hope this is a typo.. You said you are sending the encryption
key?!?!?

"justinjkdr" <webforumsuser@macromedia.com> wrote in message
news:fhacrl$5fn$1@forums.macromedia.com...
> Nah I haven't been able to decypher it, since I made my own server I have
> total
> flexibility so I have a VAR stored with the encrypted text in the server
> and I
> check it against the encrypted key that the client sends on connection.
>

> No it wasn't, I'm talking about from the VERY beginning of the connection,
> you know...
Yes, I do - I've made an mus/mux compatible Xtra a couple of years ago.
Though some of the things you are mentioning are not 100% accurate, I do
know that mus has security issues, but I'd never discuss them over a public
forum.

> As for my actual encryption... ...i made the encryption myself what are
> they gunna do with it?
Didn't you say you are concerned about security? Handing out the key makes
it an easy task to break even the strongest cipher, for someone who knows
what he 's doing. Just sniffing a couple of short messages and examining the
patterns should do it.
Changing the key makes it even easier, long as the key is known.
There is a good reason why noone transmits encryption keys. I'd highly
suggest to consider changing your approach. If anything, use a fixed key,
that you won't be including in the message.

Regards,
Harris.

P.S.
Kudos for building your own server, btw.


"justinjkdr" <webforumsuser@macromedia.com> wrote in message
news:fhd4gt$rsd$1@forums.macromedia.com...
> No it wasn't, I'm talking about from the VERY beginning of the connection,
> you
> know that connection key you use? #all or #23894782934hasdfj and it has to
> be
> the same in the server config.... it gets encrypted and put at the end of
> the
> logon packet... when you first log in you send a message with the subject
> "logon" (You don't see this in the MUS server because it handles it and
> logs
> you in accordingly and adds you to a group, but like I said I made my own
> server so I had to code the part to check the key...) And what I was
> saying is,
> I don't know how to decrypt the key that is put at the end of the logon
> packet,
> so what I did was just stored the encrypted text in the server and checked
> it
> against the one people use when logging in, it's actually not even a big
> deal,
> I should just accept all connections whether the key is right or not,
> because
> if they aren't using my client they aren't going tobe able to send
> messages to
> me anyways because of my custom encryption and if they don't send a
> LoadChar
> message within 5 seconds of logon it boots them.
>
> That stupid logon key doesn't really do anything actually, I could log
> into
> any server with any key and start sending and receiving messages...
>
> As for my actual encryption I encrypt the recipient, subject and content
> strings before sending the message and I use the timestamp that is sent
> with
> the message as a key so that EVERY message is different and NEVER the same
> (It's pretty tricky) and i dont gotta worry about people realizing that
> the
> timestamp is the key because like I said, i made the encryption myself
> what are
> they gunna do with it? =P
>