Hey Noah,

size_t tmp_len = cover_len * 32; //assert here to prevent overflow

This is probably prevented somewhere else, but it is always good to harden the code.

/*if (inf_len < 0 || out_sz < inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN) { fprintf(stderr, "inf_len = %d\n", inf_len); free(tmp_buf); return -1; }*/

Why did you get rid of this part?

//how to check max SWF size? c_HTTP_MSG_BUF_SIZE?

Sure, there is a confusion between HTTP_MSG_BUF_SIZE and c_HTTP_MSG_BUF_SIZE but we should unite them and use one (the latter is better).

tmp_len= inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN; //reassigned to existing variable return (ssize_t)tmp_len; //added for new return type

sure, you can do

return (ssize_t)(inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN);

But it isn't a big deal.

Also please take a look at:

doc/writing_new_file_steg_mod_for_http_steg.txt

Best of luck, vmon

Noah Rahman selimthegrim@gmail.com writes:

Have finished everything I think I need, trying now to compile a patch for SWF. Will start on JS once that is socked away. A few questions though... (on tmp_len line, and commented out free block)

ssize_t SWFSteg::decode(const uint8_t *cover_payload, size_t cover_len, uint8_t* data) { int inf_len; size_t tmp_len = cover_len * 32; //assert here to prevent overflow for large covers? char* tmp_buf = (char *)xmalloc(tmp_len);

for (;;) { inf_len = decompress(cover_payload + 8, cover_len - 8, (uint8_t *)tmp_buf, tmp_len); if (inf_len != -2) break; tmp_len *= 2; tmp_buf = (char *)xrealloc(tmp_buf, tmp_len); }

/*if (inf_len < 0 || out_sz < inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN) { fprintf(stderr, "inf_len = %d\n", inf_len); free(tmp_buf); return -1; }*/ //how to check max SWF size? c_HTTP_MSG_BUF_SIZE?

memcpy(data, tmp_buf + SWF_SAVE_HEADER_LEN, inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN); tmp_len= inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN; //reassigned to existing variable return (ssize_t)tmp_len; //added for new return type }

On 4/5/14, vmon vmon@riseup.net wrote:

...

Just make a patch of you changes and email me the patch:

http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/ Envoyé depuis un mobile Samsung

-------- Message d'origine -------- De : Noah Rahman selimthegrim@gmail.com Date :2014/04/05 19:11 (GMT-05:00) À : vmon@riseup.net Objet : Re: Stegotorus Challenge - Inheriting from FileStegMod

Ok. I'll shoot for SWF and Js by turn and add that to a revised proposal for the challenge period. I have not heard back from Zack yet. I am in UTC+5 now so that leaves me all of my Sunday at least?

On Apr 5, 2014 11:02 PM, vmon@riseup.net wrote: Hey Noah,

Just keep in mind that I need to make a recommendation on your application by the end of the weekend.

I also like very much if you can add "merging SRI branch of Stegotorus" to our Stegotorus as well, to the list of the deliverables of the proposal.

Thanks, vmon

Noah Rahman selimthegrim@gmail.com writes:

...

Yes, the capacities were a bit of a head scratcher. I'll try swf first and then js. My github ID is baronwolfenstein.

Hey Noah,

For committing: I think Zack needs to give you write access. Please send your github id to Zack (zackw@cmu.edu) and cc me. Once that is done, please branch out of tor-improve and commit. If it takes Zack long to give you permission, you can just fork Zackw/stegotorus of course. Just please only commit compilable code (no syntax error etc), this way it is easier to review the commits.

SWF would be easier than JS but if you like the JS it is cool with me. For the swf, basically swf_wrap should go to encode, swf_unwrap to decode and you need basically discard the http_server_SWF_transmit and http_handle_client_SWF_receive functions (these are redundant). Just be careful that what is supposed to be send to each function, is it the payload without header? with header? etc. So just tweak the swf_unwrap/swf_wrap to be compatible with what encode/decode.

Capacity functions: Then PayloadServer::capacitySWF should be implemented as swfSteg::capacity. However, You'll find 4 capacity functions and it is probably quite confusing.

capacity headless_capacity static_capacity static_headless_capacity

static vs virtual: When all the modules are moved to the new model, we'll get rid of static_capacity, static_headless_capacity but till then, we need them to keep this old/new hybrid stegs model. Hence:

capacity just calls static_capacity headless_capacity just calls static_headless_capacity

headless vs headfull: headless_capcity: computes the capacity when the payload is given without http header (pure file).

capacity: compute the capacity when the payload is given as an HTTP response (So it starts with

HTTP/1.1 200 OK Server: Apache Accept-Ranges: bytes Content-Type: text/html; charset=utf-8 Content-Length: 920 Connection: keep-alive

and then the file starts, so you just need basically to skip the header and call headless_capacity (we probably should implement the capacity in the parent and only make headless_capacity pure virtual).

If you take look at:

jpgSteg::capacity jpgSteg::headless_capacity jpgSteg::static_capacity jpgSteg::static_headless_capacity

all I what say will sound less gibberish to you.

Good luck et bon courage, vmon

Noah Rahman selimthegrim@gmail.com writes:

...

Laying over in Tokyo enroute to bkk, had a look at all the modules

and

...

will start on the JS one on the plane. I have 24 hours in bkk so should be able to convert the Js and at least one of the other ones

if

...

not both to inherit from the FileStegMod by the time I leave there. Should I submit the pr to your Tor-improve branch or zackw's?