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

[Jerry Yu]

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/639ff774/attachment.html