<div dir="ltr"><br><br><div class="gmail_quote">On Sat, Jun 25, 2011 at 9:28 PM, Oleg Goldshmidt <span dir="ltr"><<a href="mailto:pub@goldshmidt.org">pub@goldshmidt.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">> The point of the additional file is to leave little room for anything else.<br>
> Regarding the FAT place: Assuming the CD ends up on an infected machine, or<br>
> falls into the wrong hands ( example: you want to make your client an offer<br>
> on a CD, but you do not wish to give the client info about other offers you<br>
> made, in this case the wrong hands are exactly the hands the CD goes to),<br>
> the infected internal machine and the infected external machine agree on the<br>
> interpretation of the extra space in the table sectors, and may communicate<br>
> information through it.<br>
<br>
</div>Let's be clear about one thing. What is the primary concern:<br>
preventing malware from spreading or preventing information from<br>
leaking?<br>
<br></blockquote><div><br>I assume malware spreads in various methods, and am not trying to disinfect machines/prevent propagation of malware etc. I leave this to antiviruses.<br><br>I am trying to prevent a specific action of various possible (imaginary?) malware, which attempt to export data as hitchhikers on data which is exported anyhow. I do not assume the malware is trying to add itself to the CD, in addition to the data.<br>
<br>The OCR idea is indeed nice. However, it is only good for small amounts of data, or where the accuracy is not so important (English texts). It is not so good for Hebrew or data (numbers), not to mention binary data.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Depending on the answer some of the responses you've got may be more<br>
relevant than others. E.g., I think that Shachar's comment about FAT<br>
tables is correct in the context of malware propagation. If catching<br>
steganographic messages is the point (as, e.g., I understood the<br>
problem) then custom filesystem metadata is as good a channel as any.<br>
<br>
I liked the idea of printing the stuff and OCRing it back, by the way.<br>
A low tech / dead tree step in the middle is a good way to sterilize<br>
bits. ;-)<br>
<div><div></div><div class="h5"><br>
--<br>
Oleg Goldshmidt | <a href="mailto:pub@goldshmidt.org">pub@goldshmidt.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Orna Agmon Ben-Yehuda.<br><a href="http://ladypine.org">http://ladypine.org</a><br>
</div>