On Tue, Jul 31, 2012 at 9:35 AM, vmon <vmonmoonshine@gmail.com> wrote:

I'm working on changing how client sends info to the server for ApachePayloadServer, according to our discussion. This is how it's going to be for now. The server sends a list of file in some order to the client at the begining of the conversation. The client will send its coded request by chosing a url a from the list and a parameter that it sends to that file such as:

/groups/watch.cgi?param=QTwFt25

Sounds good.

For this I need to send the list of files somewhere to the client. I looked at the paper and paper says that on a new link the server will send a reply to the handshake of the client with ECDH data. I thought there would be a good place to send these data as well. Unfortunately I couldn't spot that in the code. Could you please tell me where that is happening?

That ... still hasn't been implemented. *embarrassed* But that's not where this should go, anyway.

Another option is to assign an opcode to this operation, and when the client receive that opcode then, it will process the packet differntly rather than just write its content in upstream event buffer.

This is what you should do. Remember how opcodes 128 through 255 are "reserved for steg modules"? This is exactly what I had in mind. The way it ideally ought to work is going to involve changes to the chopper as well as your code; I'm not going to have time to do the chopper end for at least three weeks; if you want to tackle that, please be my guest, but if you'd rather kludge something in your code instead, that's fine too. Here's how it ought to work: On the receive side, you just need to add a steg method to process a reserved-for-steg-modules block, taking F and the data payload (in an evbuffer). Call it from process_queue when appropriate. On the transmit side, we would like to send your special block in the same *cover protocol* message as the server's handshake reply, so we need a little more complexity than just a "please send this evbuffer now with this opcode" steg-to-chop callback. I'm not sure this is the right API, but what comes to mind is to extend transmit_room so that it returns a second number, which means "if you send on this connection next, I want to send Y bytes of additional data". Then there's a new steg method called something like augment_message, which gets called in a loop right after we prepare and encrypt the actual block to transmit. Each time it fills up an evbuffer with data and returns a steg-specific opcode; the chopper packs the evbuffer and opcode into another block and appends it to the block that's about to be transmitted. Finally steg_transmit gets the entire message to be steganographed, which may now consist of several blocks.

For now I suppose that the client has the list and write the code from that point till you give me more info.

It would also be fine if you want to get things working on this assumption first. zw