[Help] How to modify received Packet?

Page 2 of 2

05/30/2015 22:02 anonentity#16

Quote:

Originally Posted by ohaiithar

Wouldn't it be len +3 for strings and bins?

Could you please elaborate on that?
Thanks.

05/30/2015 23:07 ~Goodnight~#17

Wait a minute. You're 0ing out the T_BIN of packet 00000000?

I don't think you can do that anon. Reason why being because the the BIN contains senitive data that the client needs to create the item. If the BIN was 0 (or equal from a different 00000000 packet), then the client cannot recreate that same item.

You would have to decode that binary by two ways :

1) Find out where that binary is being located to in the client (should be easy by hooking mint function of readbinarry) and reverse engineer it.

2) Find out how the aura team remade the binary packet

Or 3), just ingore T_BIN

05/31/2015 04:17 anonentity#18

Quote:

Originally Posted by ~Goodnight~

Wait a minute. You're 0ing out the T_BIN of packet 00000000?

I don't think you can do that anon. Reason why being because the the BIN contains senitive data that the client needs to create the item. If the BIN was 0 (or equal from a different 00000000 packet), then the client cannot recreate that same item.

You would have to decode that binary by two ways :

1) Find out where that binary is being located to in the client (should be easy by hooking mint function of readbinarry) and reverse engineer it.

2) Find out how the aura team remade the binary packet

Or 3), just ingore T_BIN

I'm was only trying to receive a duplicate of the packet myself and get rid of the original packet the client was supposed to receive. This, however, crashes the client.

So do you think it is normal for the client to crash when it receives the exact duplicate of the 00000000 packet it is about to receive? And by the way, could you please tell me how to 'ignore the T_BIN'?

Currently I'm assuming the following two reasons for the crash:
1. The duplication was not done correctly, meaning the manually received packet is invalid.
2. The duplication was done successfully. But the client is able to identify that the packet was not generated by server (somehow using the correlation between T_BIN values and the packet) and therefore crashes.

05/31/2015 12:47 Caesarw#19

Quote:

Originally Posted by anonentity

I'm was only trying to receive a duplicate of the packet myself and get rid of the original packet the client was supposed to receive. This, however, crashes the client.

So do you think it is normal for the client to crash when it receives the exact duplicate of the 00000000 packet it is about to receive? And by the way, could you please tell me how to 'ignore the T_BIN'?

Currently I'm assuming the following two reasons for the crash:
1. The duplication was not done correctly, meaning the manually received packet is invalid.
2. The duplication was done successfully. But the client is able to identify that the packet was not generated by server (somehow using the correlation between T_BIN values and the packet) and therefore crashes.

well, this one might help, put only these lines in your RecvHook func:

Code:

int opcode = recvPacket.GetOP();
if (opcode == 0x0000 || opcode == 0x520C) {
    BYTE *pn;
    int len = recvPacket.BuildPacket(&pn);
    if (Recv)
        Recv(pn, len);
    return 0;
}

05/31/2015 20:29 ohaiithar#20

Quote:

Originally Posted by anonentity

Could you please elaborate on that?
Thanks.

I guessing you wrote your own functionality, so, here's the original build packet, from the old pake archives:

[Only registered and activated users can see links. Click Here To Register...]

Case 6 (string) and 7 (binary), would be gibberish to the client, without those extra bytes, telling it the relevant info about those parts of the packet, compared to the set lengths/formats of the previous ones.

I'm just guessing, because I can't see how you handled your other variable types, nor how you read the data, but since you're crashing only on these two formats, it seems a moderately safe bet.

06/01/2015 01:06 anonentity#21

Quote:
Originally Posted by Caesarw
well, this one might help, put only these lines in your RecvHook func:
Code:
int opcode = recvPacket.GetOP();
if (opcode == 0x0000 || opcode == 0x520C) {
    BYTE *pn;
    int len = recvPacket.BuildPacket(&pn);
    if (Recv)
        Recv(pn, len);
    return 0;
}

Thanks. But it crashed the client just like my attempt :(

06/07/2015 08:52 swagola#22

Hint: opcode 0 isn't a real packet.

06/11/2015 21:32 Anyrei#23

So RecvHook still works? What about the rest.

06/12/2015 02:12 Caesarw#24

Quote:

Originally Posted by Anyrei

So RecvHook still works? What about the rest.

everything works.

Page 2 of 2