Disassembler
in [Cobol]
|
From: Alistair on 25 Feb 2006 10:03 Reading in comp.lang.asm370 I came across the following item which may be of some interest: <QUOTE> On Fri, 10 Feb 2006 13:54:57 -0500, Gilbert Saint-Flour wrote: <usenet5...(a)yahoo.com> wrote: > I found this page by accident a moment ago: > http://patents.nimblewisdom.com/patent/5946484-Method-of-recovering-source-code-from-object-code > It's a patent issued in 1999 by the USPTO for a disassembler, which > wasn't a > new concept back then (I've written my first disassembler in 1982). > The problem is that the language of patents is so arcane that it's > difficult > to spot the original elements of this patent, or if there's any > originality > in it at all. Hopefully, one of you will dig something up. It appears to be more than just a dissassembler, based on the generated assembly code it looks for known patterns charateristic of the IBM Cobol compiler and attempts to symthesize the Cobol source, as nearly as I can tell in 5 minutes. But this has been done for many years, I am not sure what is novel here. </QUOTE> Perhaps there will soon be an answer to the perennial "Where can I find a cobol disassembler?"
From: CG on 26 Feb 2006 00:05 Alistair wrote: > Reading in comp.lang.asm370 I came across the following item which may > be of some interest: > > <QUOTE> > > On Fri, 10 Feb 2006 13:54:57 -0500, Gilbert Saint-Flour wrote: > <usenet5...(a)yahoo.com> wrote: >> I found this page by accident a moment ago: >> http://patents.nimblewisdom.com/patent/5946484-Method-of-recovering-source-code-from-object-code > >> It's a patent issued in 1999 by the USPTO for a disassembler, which >> wasn't a >> new concept back then (I've written my first disassembler in 1982). > > >> The problem is that the language of patents is so arcane that it's >> difficult >> to spot the original elements of this patent, or if there's any >> originality >> in it at all. Hopefully, one of you will dig something up. > > > > It appears to be more than just a dissassembler, based on the generated > > assembly code it looks for known patterns charateristic of the IBM > Cobol > compiler and attempts to symthesize the Cobol source, as nearly as I > can > tell in 5 minutes. But this has been done for many years, I am not > sure > what is novel here. > > </QUOTE> > > Perhaps there will soon be an answer to the perennial "Where can I find > a cobol disassembler?" > This is not your typical disassembler. ["DisASSEMBLER" is probably a misleading term.] If you look carefully, you will see that the patent owner is Source Recovery Company. They turn executable code into _COBOL_source_. That's a simplified description. They also will use your variable names in the generated source if you provide record definitions. It is quite an effective technology. I've never heard of anyone else claiming to be able to do this.
From: Pete Dashwood on 26 Feb 2006 05:23 "CG" <carl.gehr.RemoveThis(a)ThisToo.attglobal.net> wrote in message news:4ba4a$44013727$453db2dd$15883(a)FUSE.NET... > Alistair wrote: >> Reading in comp.lang.asm370 I came across the following item which may >> be of some interest: >> >> <QUOTE> >> >> On Fri, 10 Feb 2006 13:54:57 -0500, Gilbert Saint-Flour wrote: >> <usenet5...(a)yahoo.com> wrote: >>> I found this page by accident a moment ago: >>> http://patents.nimblewisdom.com/patent/5946484-Method-of-recovering-source-code-from-object-code >> >>> It's a patent issued in 1999 by the USPTO for a disassembler, which >>> wasn't a >>> new concept back then (I've written my first disassembler in 1982). >> >> >>> The problem is that the language of patents is so arcane that it's >>> difficult >>> to spot the original elements of this patent, or if there's any >>> originality >>> in it at all. Hopefully, one of you will dig something up. >> >> >> >> It appears to be more than just a dissassembler, based on the generated >> >> assembly code it looks for known patterns charateristic of the IBM >> Cobol >> compiler and attempts to symthesize the Cobol source, as nearly as I >> can >> tell in 5 minutes. But this has been done for many years, I am not >> sure >> what is novel here. >> >> </QUOTE> >> >> Perhaps there will soon be an answer to the perennial "Where can I find >> a cobol disassembler?" >> > This is not your typical disassembler. ["DisASSEMBLER" is probably a > misleading term.] If you look carefully, you will see that the patent > owner is Source Recovery Company. They turn executable code into > _COBOL_source_. That's a simplified description. They also will use your > variable names in the generated source if you provide record definitions. Why would you need to disassemble something you have the source to? If you have the source fo the record definitions it is reasonable to suppose you have the source of the programs...? Am I missing something here? Pete. It is quite an effective technology. I've never heard of > anyone else claiming to be able to do this.
From: Alistair on 26 Feb 2006 09:42 Pete Dashwood wrote: > "CG" <carl.gehr.RemoveThis(a)ThisToo.attglobal.net> wrote in message > news:4ba4a$44013727$453db2dd$15883(a)FUSE.NET... > > Alistair wrote: > >> Reading in comp.lang.asm370 I came across the following item which may > >> be of some interest: > >> > >> <QUOTE> > >> > >> On Fri, 10 Feb 2006 13:54:57 -0500, Gilbert Saint-Flour wrote: > >> <usenet5...(a)yahoo.com> wrote: > >>> I found this page by accident a moment ago: > >>> http://patents.nimblewisdom.com/patent/5946484-Method-of-recovering-source-code-from-object-code > >> > >>> It's a patent issued in 1999 by the USPTO for a disassembler, which > >>> wasn't a > >>> new concept back then (I've written my first disassembler in 1982). > >> > >> > >>> The problem is that the language of patents is so arcane that it's > >>> difficult > >>> to spot the original elements of this patent, or if there's any > >>> originality > >>> in it at all. Hopefully, one of you will dig something up. > >> > >> > >> > >> It appears to be more than just a dissassembler, based on the generated > >> > >> assembly code it looks for known patterns charateristic of the IBM > >> Cobol > >> compiler and attempts to symthesize the Cobol source, as nearly as I > >> can > >> tell in 5 minutes. But this has been done for many years, I am not > >> sure > >> what is novel here. > >> > >> </QUOTE> > >> > >> Perhaps there will soon be an answer to the perennial "Where can I find > >> a cobol disassembler?" > >> > > This is not your typical disassembler. ["DisASSEMBLER" is probably a > > misleading term.] If you look carefully, you will see that the patent > > owner is Source Recovery Company. They turn executable code into > > _COBOL_source_. That's a simplified description. They also will use your > > variable names in the generated source if you provide record definitions. > > Why would you need to disassemble something you have the source to? If you > have the source fo the record definitions it is reasonable to suppose you > have the source of the programs...? Am I missing something here? Yeah, the idea is that the source does not exist although the FD may. This is a situation that I have come across in the real world where project leaders have been known to delete libraries of source. His nickname thereafter was 'Pete the Delete'. > > Pete. > > > It is quite an effective technology. I've never heard of > > anyone else claiming to be able to do this.
From: Peter Lacey on 26 Feb 2006 11:05
Pete Dashwood wrote: > >> > > This is not your typical disassembler. ["DisASSEMBLER" is probably a > > misleading term.] If you look carefully, you will see that the patent > > owner is Source Recovery Company. They turn executable code into > > _COBOL_source_. That's a simplified description. They also will use your > > variable names in the generated source if you provide record definitions. > > Why would you need to disassemble something you have the source to? If you > have the source fo the record definitions it is reasonable to suppose you > have the source of the programs...? Am I missing something here? > > Pete. > I find it very easy to imagine that the source for a program is lost whereas the copy books for the files still exist, either in the copy libs or as listings. As copy books usually apply to more than one program it's more likely that they'll be looked after more carefully. I haven't done it myself but I have had dealings with several sites who were running productions programs for which they'd lost the source. Heads rolled, naturally, and there was frantic reverse-engineering. One place I know of had it happen more than once! Usually, as I recall, it had happened because someone left a backup or a save or some scheduled task until tomorrow but then had forgotten about it by tomorrow. And in one case backups hade been scrupulously done but the JCL stream was in error and the tapes didn't actually get written on! PL |