[ale] tool to repair a binary file given a diff between hex dumps of the original and the altered

[Jerry Yu]

I meant "The presence of CR or NL in the encrypted file" instead of "The
presence of CR or NL in the plain-text", near the end of the 2nd paragraph.

On Thu, Apr 24, 2008 at 1:14 PM, Jerry Yu <jjj863 at gmail.com> wrote:

> Greg,
>
> that was my initial assumption too, with two twists.
>
>    - The \r\n is not an EOL, but part of a file encrypted in binary
>    format.
>    - the \r\n is on our Linux (RHEL5/ppc) server, while the \n only
>    version is on the Windows server to be decrypted. I expected the other
>    direction.
>
> I tried to spare the list the gory details of the whole thing when I
> initially posted the question.  The file actually jumped a few more hops
> (outside my control, mainframe and all that) to get decrypted. Only one or
> two out of twenty files will get screwed like this.  My theory is these one
> or two encrypted files happen to use \r, \n, or both in the middle of the
> file, just as it uses 'a' or 'b'. The presence of CR or NL in the
> plain-text,  causing decryption to fail, if any \r \n or both get dropped or
> inserted *en route*.
>
> Long-term, I proposed to switch to armor text to avoid non-ascii in the
> encrypted files. GPG can survive a unix2dos transformation.
> For troubleshooting, I wants the final destination to verify decryption
> with the exact file on our Linux server (by repairing the 'bad' one) and
> make sure it is absolutely not an encryption/decryption problem, but a
> transmission problem.  No good & secure channel exists to ensure the final
> recipient receive an exact replica.
>
>
> On Thu, Apr 24, 2008 at 12:33 PM, Greg Freemyer <greg.freemyer at gmail.com>
> wrote:
>
>> Jerry,
>>
>> I just looked at your diff again and realized it really is a binary
>> file, not a text file so a simple editor like I described won't work
>> most likely.
>>
>> I bet you FTP'ed it in text mode and thus the corruption.  If you have
>> to resend it, be sure to use binary mode in FTP.
>>
>> Greg
>>
>> On Thu, Apr 24, 2008 at 12:29 PM, Greg Freemyer <greg.freemyer at gmail.com>
>> wrote:
>> > Jerry,
>> >
>> >  If you look closely at the diff, you have a \n in the first and \r\n
>> >  in the second.
>> >
>> >  \n is the Unix / Linux way
>> >  \r\\n is the Windows way (iirc).
>> >
>> >  Assuming \r\n is never valid in this doc, then there are several
>> >  little converters available to do that.  I think just bringing it into
>> >  vi and saving back out will do it.
>> >
>> >  Greg
>> >
>> >
>> >
>> >  2008/4/24 Jerry Yu <jjj863 at gmail.com>:
>> >
>> >
>> > > what tool can I suggest a remote Windows admin to use to 'repair' his
>> binary
>> >  > file given the hex diff below.
>> >  > Of course, if this 'repair' is too hairy, I'd go down the
>> retransmission
>> >  > route (expensive).
>> >  >
>> >  > diff meta.od-x tpp.od-x
>> >  >  24,25c24,26
>> >  >  < 0000560 6b92 d311 01fb f7be 402c c959 a125 0ac4
>> >  >  < 0000600
>> >  >  ---
>> >  >  > 0000560 6b92 d311 01fb f7be 402c c959 a125 0d0a
>> >  >  > 0000600 c400
>> >  >  > 0000601
>> >
>> > > _______________________________________________
>> >  >  Ale mailing list
>> >  >  Ale at ale.org
>> >  >  http://mail.ale.org/mailman/listinfo/ale
>> >  >
>> >  >
>> >
>> >
>> >
>> >  --
>> >  Greg Freemyer
>> >  Litigation Triage Solutions Specialist
>> >  http://www.linkedin.com/in/gregfreemyer
>> >  First 99 Days Litigation White Paper -
>> >
>> http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf
>> >
>> >  The Norcross Group
>> >  The Intersection of Evidence & Technology
>> >  http://www.norcrossgroup.com
>> >
>>
>>
>>
>> --
>> Greg Freemyer
>> Litigation Triage Solutions Specialist
>> http://www.linkedin.com/in/gregfreemyer
>> First 99 Days Litigation White Paper -
>> http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf
>>
>> The Norcross Group
>> The Intersection of Evidence & Technology
>> http://www.norcrossgroup.com
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20080424/a324b4a3/attachment-0001.html