[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Stegotorus Challenge - Inheriting from FileStegMod
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@xxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxx>
>> Date :2014/04/05 19:11 (GMT-05:00)
>> Ã : vmon@xxxxxxxxxx
>> 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@xxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxx) 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@xxxxxxxxx> 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?
>>>>
>>
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev