Disassembler
in [Cobol]
|
From: CG on 26 Feb 2006 17:13 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? > Unfortunately, what you are missing is the real world! During our work with Y2K we found many, many sites that had production applications with no source code to go with the program. Because we looked at the executable code an not the source code as our first point of interest, our users could then match the executables with the source. When they did not have the match, then the panic set in and we referred them to Source Recovery. From the production JCL, they could identify the files used and therefore, likely had a record layout. Even if they did not have a current, formal COPY book, it was usually not too difficult to create one. BTW, this technology does not require the file layouts. My point was, IF you have the layout, the recovery technique would use your name. No COPY book, it just made up names as it did for the rest of the data items in the program. Another reason for needing this technology is when we discovered multiple executables with the same name, but different compile dates and/or different sizes, but only one source program. When you have different sizes it is highly unlikely that you will have a single source program. When we find this situation in our normal course of assessing an inventory, it is important to know which executable the source matches and then to determine the differences in the program logic for the other executable(s). Can it be done with pure executables? Yes. Can it be done with Assembler equivalents? Sure. Is it easier to match COBOL to COBOL? Absolutely! As I said... 'Reality' is what you missed. Carl
From: Pete Dashwood on 27 Feb 2006 06:23 "Alistair" <alistair(a)ld50macca.demon.co.uk> wrote in message news:1140964930.418112.96620(a)i40g2000cwc.googlegroups.com... > > 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'. > Well, of course, if he was a Project Manager, he was obviously testing to see if the DR procedures were in place and effective.... Quite right and proper. And if his name was Pete he was definitely beyond reproach. I have come across cases where the source was available, but the COPYs and INCLUDEs weren't. (they hadn't been perceived as part of the source library and were therefore stored separately, and later deleted.) I still can't see much point in going to all the trouble of disassembling code ifyou have the source. If you DON'T have the source, then disassembling it is really not going to help much... Maybe, if it is absolutely Mission Critical code and you really MUST amend it. Personally I wouldn't. I'd take the opportunitiy to rewrite it. But then, in my case it would be component based and I don't NEED the source anyway :-). Pete. >> >> Pete. >> >> >> It is quite an effective technology. I've never heard of >> > anyone else claiming to be able to do this. > >
From: Pete Dashwood on 27 Feb 2006 06:32 "Peter Lacey" <lacey(a)mts.net> wrote in message news:4401D1AE.578753D3(a)mts.net... > 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! > Ah, the joys of maintaining source... :-) There's more to disassembly than simply losing source. If you have no source and you disassemble what you have, you will still have major problems amending and mantaining it, especially on an ongoing basis. Disassembly is not a silver bullet (as anyone who's ever had to do it, knows). In fact, other than extreme and isolated circumstances, disassembly is not a solution at all. Programmers who have worked in high level languages all their careers and may have "some Assembler knowledge" are NOT Assembler programmers. Even people who ARE Assembler programmers would not embrace maintaining undocumented compiler output. (I know, because I was one...:-)) Please see response to Alastair above. Pete.
From: Pete Dashwood on 27 Feb 2006 06:35 "CG" <carl.gehr.RemoveThis(a)ThisToo.attglobal.net> wrote in message news:5323a$44022812$453db2dd$8469(a)FUSE.NET... > 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? >> > > Unfortunately, what you are missing is the real world! During our work > with Y2K we found many, many sites that had production applications with > no source code to go with the program. Because we looked at the > executable code an not the source code as our first point of interest, our > users could then match the executables with the source. When they did not > have the match, then the panic set in and we referred them to Source > Recovery. > > From the production JCL, they could identify the files used and therefore, > likely had a record layout. Even if they did not have a current, formal > COPY book, it was usually not too difficult to create one. > > BTW, this technology does not require the file layouts. My point was, IF > you have the layout, the recovery technique would use your name. No COPY > book, it just made up names as it did for the rest of the data items in > the program. > > Another reason for needing this technology is when we discovered multiple > executables with the same name, but different compile dates and/or > different sizes, but only one source program. When you have different > sizes it is highly unlikely that you will have a single source program. > When we find this situation in our normal course of assessing an > inventory, it is important to know which executable the source matches and > then to determine the differences in the program logic for the other > executable(s). Can it be done with pure executables? Yes. Can it be done > with Assembler equivalents? Sure. Is it easier to match COBOL to COBOL? > Absolutely! > > As I said... 'Reality' is what you missed. > No Carl, that's your reality. I live in a different universe. And I'm thankful for it. Pete.
From: ozzy.kopec on 27 Feb 2006 08:24
Pete Dashwood wrote: > > 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. > Had a bud who's boss had them print out the source for every COBOL program they had. They did incremental and full backups, but sure enough after a hard drive crash they were missing a few programs. The secretary hand entered the code from the printed listings so for once a boss had a good idea :0) |