Mir3 Encryption

[shorty606]

I bet you they have changed.

But for some commands, like NPC click. The header decodes fine. Very strange indeed. Can you think of any explanation for this?

 

[NickAKAVexus]

But for some commands, like NPC click. The header decodes fine. Very strange indeed. Can you think of any explanation for this?

We are just confusing each other. The packet you posted before is differen't to npc click isn't it? Maybe some of the idents changed? Maybe the other packet has a buffer in replace of its header and is identified another way? Who knows.

 

[shorty606]

I know this may be tedious but how, from your experience, are header files structured and how are they decrypted? Just a brief overview if its a complex subject

 

[NickAKAVexus]

The header is just a record encoded:

  TDefaultMessage=packed record   //12×Ö½Ú
      Recog             :integer;
      Ident             :Word;
      Param             :Word;
      Tag               :Word;
      Series            :Word;
  end;

Thats why its always the same length.

encodemessage() decodemessage().

 

[shorty606]

How could it have changed, I can decode the body and the header uses the same method to decrypt. I'll look into it now anyway and tell you if I made any progress.

 

[NickAKAVexus]

How could it have changed, I can decode the body and the header uses the same method to decrypt. I'll look into it now anyway and tell you if I made any progress.

I'm saying the ident number is probably different.. then SM_TURN which is (14?)

You are probably just trying to decode the wrong packets.. :P

 

[shorty606]

Lol probably, I'll look into it all now :P

 

[shorty606]

Right, When I walk I get a packet which is this #e\Ak<XHGpmt@<FH=! and when I decrypt it all as a header I get:
msg.ident = 3011
msg.recog = 24052134
msg.param = 7891
msg.tag = 4
msg.series = 49

Now in delphi CM_WALK = 3011 so the walk command is recognised. Problem is that I think the recog, param, tag and series are garbage as I can't make any sense from them like coords or that because they don't match any onscreen coords. Also the recog changes from each walking packet. Does this packet look similar to anything anyone has worked with?

 

[NickAKAVexus]

Right, When I walk I get a packet which is this #e\Ak<XHGpmt@<FH=! and when I decrypt it all as a header I get:
msg.ident = 3011
msg.recog = 24052134
msg.param = 7891
msg.tag = 4
msg.series = 49

Now in delphi CM_WALK = 3011 so the walk command is recognised. Problem is that I think the recog, param, tag and series are garbage as I can't make any sense from them like coords or that because they don't match any onscreen coords. Also the recog changes from each walking packet. Does this packet look similar to anything anyone has worked with?

Ident and recog seem correct rest = crap. lol maybe they changed the varible for the header record to say word to integer.. just an example or the records bigger now?. I have no idea really.. thats odd.

 

[shorty606]

I've done some more looking into the headers - they are a COMPLETE challenge. Some idents decode fine, some give wild numbers like 32424 and I know that the packets I'm reading are correct for what they do.
I have a basic Mir3 client working, just annoying I can't hammer down some of the more useful commands like trade simply because the header structure is funny.
Has anyone decrypted Mir3 private server (1.4 protocol) header structure?
Thanks in advance
Sarah

 

[NickAKAVexus]

I've done some more looking into the headers - they are a COMPLETE challenge. Some idents decode fine, some give wild numbers like 32424 and I know that the packets I'm reading are correct for what they do.
I have a basic Mir3 client working, just annoying I can't hammer down some of the more useful commands like trade simply because the header structure is funny.
Has anyone decrypted Mir3 private server (1.4 protocol) header structure?
Thanks in advance
Sarah

lol your female?
Not that it matters but what a shocker.

female programmers. amg.

I also recall some one saying that was infact the problem.. the headers sizes change.. maybe theres 2 header records who knows? :P

 

[shorty606]

Yar, I'm a female and an amateur model - more of a shocker? :P
Damn headers! lol, I'll have to try and figure it out. 3 years later :P.

 

[Damian]

The original headers are 16 Bytes in length. What are the new headers?
I'm sure they will be very similar - and the server will be sure to decide
on which header to use based on this size difference.

On a side note: nice to have some talent on these forums :P

 

[NickAKAVexus]

Yar, I'm a female and an amateur model - more of a shocker? :P
Damn headers! lol, I'll have to try and figure it out. 3 years later :P.

Yes it is a shocker. I'm a model too I pose for all the ladies out there like damian.:tongue1:

 

[shorty606]

The headers are all 16 bit in length, the same as mir2. The odd thing is that some ident of the headers are correct, e.g walk = 3011 and clicking and npc = VKP^A{D?<<<<<<<< , the ident being 1010. Those work, so in theory, I have the right decoding method for the headers.
The shock is when it comes to other headers. I tried decoing the header recieved when a group has been cancelled, and here is what I got. I recorded each header every time a group was broken, so I could compare them all.
Ll<<<Kj^<<<<<<<<
ml<<<<U<<<<<<<<<
cL<<<HQ@<<<<<<<<
If you decode the idents, they are all different yet they are sent in response to the same thing - a group being cancelled.
It truly baffels me.
Included is the modified EDcode.pas that I use for Mir3 1.4 Protocol.

 

[Damian]

Yes it is a shocker. I'm a model too I pose for all the ladies out there like damian.:tongue1:

Ha! Ha! Ha! :dunce:

:mooned:

 

[NickAKAVexus]

The headers are all 16 bit in length, the same as mir2. The odd thing is that some ident of the headers are correct, e.g walk = 3011 and clicking and npc = VKP^A{D?<<<<<<<< , the ident being 1010. Those work, so in theory, I have the right decoding method for the headers.
The shock is when it comes to other headers. I tried decoing the header recieved when a group has been cancelled, and here is what I got. I recorded each header every time a group was broken, so I could compare them all.
Ll<<<Kj^<<<<<<<<
ml<<<<U<<<<<<<<<
cL<<<HQ@<<<<<<<<
If you decode the idents, they are all different yet they are sent in response to the same thing - a group being cancelled.
It truly baffels me.
Included is the modified EDcode.pas that I use for Mir3 1.4 Protocol.

I need more information, Are these after clicking the on/off button for group? Which would be group mode? 1019.
Reason i'm saying this is because.. if it is the packets should be exact untill the middle part where 1 byte would be different due to 0/1.

 

[shorty606]

It happens when you are the group holder and you remove everyone in the group by clicking remove and typing your name.

 

[NickAKAVexus]

It happens when you are the group holder and you remove everyone in the group by clicking remove and typing your name.

So basicly:
CM_DELGROUPMEMBER = 1022;

you are 100% sure these are correct packets? It just seems odd. :x

 

[shorty606]

I'll giveyou two I deffinately know work then, as although I'm sure that what is above is true, I don't use it in my program lol.
There are two complete packets:
#XL<<<>=[<<<<<<<<MrQhXbagGrqeXsI^TREuGl!GrqeXsI^TREuGl!
#KL<<<=za<<<<<<<<MrQhXbagGpmeWBmuMbQaGl
They contain the list of group members sent to everyone in a group when players are added/removed.
Should be SM_GROUPMEMBERS = 667; from my guess
/20chrs????