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

[Jerry Yu]

The remote Windows admin was not as timid as thought. Given the hex diff, he
repaired the file himself (w/o me giving him pointers to tools gathered from
this thread)
He reported successful decryption.

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

> 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/623b1069/attachment.html