This is a quote from my old post. It does contain some major errors, it does work but it leaks like a ol' pipe so it should only be used as reference.
Quote:
As usual this has no interest in private server section so here it goes, it's not finished yet. If you see errors / places where it could be better, post here. It's not tested but it should work unless there's a major fuck-up somewhere.
Are you expecting to read plain text? Because that won't happen. The protocol is a binary one, and has very little text in it. For starters, fix this:
Get the result from recv(), which is the actual number of bytes receive (rather than the size of the buffer). Then output_hex (cout, buf, recv_len); You should get something a bit more readable.
Are you expecting to read plain text? Because that won't happen. The protocol is a binary one, and has very little text in it. For starters, fix this:
Get the result from recv(), which is the actual number of bytes receive (rather than the size of the buffer). Then output_hex (cout, buf, recv_len); You should get something a bit more readable.
so lets make every thing clear i send to the client:
Code:
const int Seed=74185296;
send(sListen,(char *)Seed,8,0);
i recv() what ever i will recv. then i take the buf into the Blowfish then it should decrypt every thing but the password right1?
You don't simple send the Seed value like that. You must structure it into the packet you posted in the other thread.
Code:
typedef struct packetSeed
{
unsigned short Length; // 0x8
unsigned short Type; // 0x423
unsigned int Seed; // random
} * PPACKETSEED;
packetSeed * packet = new packetSeed();
packet->length = 8;
packet->type = 0x423;
packet->Seed = 74185296;
send(s, (uint8_t*)packet, sizeof(packetSeed), 0);
delete packet;
Oh, and I noticed you're sending/recieving on your listen socket. You shouldn't do that. You should be send/receiving on the connected socket that was returned in the call to accept(); I'd suggest go reading Beej's guide to network programming for further details.
You don't simple send the Seed value like that. You must structure it into the packet you posted in the other thread.
Code:
typedef struct packetSeed
{
unsigned short Length; // 0x8
unsigned short Type; // 0x423
unsigned int Seed; // random
} * PPACKETSEED;
packetSeed * packet = new packetSeed();
packet->length = 8;
packet->type = 0x423;
packet->Seed = 74185296;
send(s, (uint8_t*)packet, sizeof(packetSeed), 0);
delete packet;
Oh, and I noticed you're sending/recieving on your listen socket. You shouldn't do that. You should be send/receiving on the connected socket that was returned in the call to accept(); I'd suggest go reading Beej's guide to network programming for further details.
a question if i may why should i send it by this way?
Edit: reading the Beej's guide also when i used sConnect to send and recv the cllient crashs!?
Because that's what the client expects to receive. The particular pieces of data are required in order to the client to be able to interpret the data you are sending.
For starters, the length field of the packet is required in TCP (stream based) communication, because the client must be able to recognise where a particular piece of information starts and ends. If you call send 5 times on a server, that doesn't necessarily mean that the client will need to call recv 5 times to recv those 5 pieces of data. It may only need to call it once, or it may need to call it 10 times. It depends on the load on the network, it cannot be decided beforehand where each send was sent in the stream. So we add a length to each "send" so that the receiver can interpret the data and decide where each piece of sent information begins and ends.
As for the type - This is a primitive that decides what the receiver should do with the data. There's lots of different pieces of data you can send that do different functions (for example, one might contain login information, another might contain some chat information). The type primitive just identifies each piece of information so that it can be mapped to a function that is to be performed on the payload. (In this case, is the seed).
So if you send data as described. The client will first read the length, to determine when to stop receiving for this particular piece of data. It will then read the type, and see it is the Seed packet type, and it can then call a function which sets the seed for the cryptography using the final piece of data in the stream.
Because that's what the client expects to receive. The particular pieces of data are required in order to the client to be able to interpret the data you are sending.
For starters, the length field of the packet is required in TCP (stream based) communication, because the client must be able to recognise where a particular piece of information starts and ends. If you call send 5 times on a server, that doesn't necessarily mean that the client will need to call recv 5 times to recv those 5 pieces of data. It may only need to call it once, or it may need to call it 10 times. It depends on the load on the network, it cannot be decided beforehand where each send was sent in the stream. So we add a length to each "send" so that the receiver can interpret the data and decide where each piece of sent information begins and ends.
As for the type - This is a primitive that decides what the receiver should do with the data. There's lots of different pieces of data you can send that do different functions (for example, one might contain login information, another might contain some chat information). The type primitive just identifies each piece of information so that it can be mapped to a function that is to be performed on the payload. (In this case, is the seed).
So if you send data as described. The client will first read the length, to determine when to stop receiving for this particular piece of data. It will then read the type, and see it is the Seed packet type, and it can then call a function which sets the seed for the cryptography using the final piece of data in the stream.
man thanks u made my day xD , really thnx , onther question :P why is the client crashs when i use sConnect?
Most likely because you are sending incorrectly formed data which the client doesn't expect, and it is unable to recover from the error, so it just shuts down.
Most likely because you are sending incorrectly formed data which the client doesn't expect, and it is unable to recover from the error, so it just shuts down.
Getting blowfish key and using the algorithm 03/17/2011 - SRO Coding Corner - 10 Replies Good evening:)
I am still busy with the packets of silkroad and I'm now trying to understand on how to decrypt the packets but I'm having some problems with it.
I read drew benton's artikel about the silkroad security but I still don't know on which blowfish key is used to decrypt the packets.
let's say these four packets are the first 4
S -> C
00000 25 00 00 50 00 00 0e d2 a9 27 80 2d c3 23 6c f6 %..P.....'.-.#l.
00016 00 00 00 62 00 00 00 8d ac fe 38 3d d0 9c ef 67 ...
[help]blowfish 10/15/2009 - Lineage 2 - 0 Replies hello i haven't idea how to find blowfish in server
any idea?