Disassembly of C binary

[Caveman]

Hello,

My company recently purchased source code from a company we have been
doing business with for several years. In the past, they have done all
of the development for this product. Their business had dwindled to
the point where we were the last company to use their software so we
purchased the source and brought development in house.

We have now found that our source is out of date for one of the
components. The component was last updated in February of 2002;
version 1.2.2. Our source (for this component) is for January of 2002
version 1.1.2.

This company has not been able to yet locate the source. They had
several temporary contractors work on the code over the years, and
version control apparently was not properly enforced.

We have the binary, and perhaps fortunately, it is a debug build (built
in VC++ 6.0).

Over the years I've always believed that shipping product with debug
symbols embedded would allow a person enough information to actually
reverse engineer the binary and steal source, but when I have done
preliminary disassembly of this particular component, I see nothing
extraordinarily useful.

This particular component has only 4 source files, no libraries linked
in, and is relatively small.

Is there a tool that can utilize this debug info and rebuild this
source? Is there a different approach that anyone can think of? I
have played with a decent one (REC;
http://www.backerstreet.com/rec/rec.htm), but have not yet fully
explored its possibilities.

This may be our only alternative if the company can't produce the
source. The bugs between versions were small, but typically critical.

Any input is appreciated.

Thank you!

 

[mlimber]

Hello,

My company recently purchased source code from a company we have been
doing business with for several years. In the past, they have done all
of the development for this product. Their business had dwindled to
the point where we were the last company to use their software so we
purchased the source and brought development in house.

We have now found that our source is out of date for one of the
components. The component was last updated in February of 2002;
version 1.2.2. Our source (for this component) is for January of 2002
version 1.1.2.

This company has not been able to yet locate the source. They had
several temporary contractors work on the code over the years, and
version control apparently was not properly enforced.

We have the binary, and perhaps fortunately, it is a debug build (built
in VC++ 6.0).

Over the years I've always believed that shipping product with debug
symbols embedded would allow a person enough information to actually
reverse engineer the binary and steal source, but when I have done
preliminary disassembly of this particular component, I see nothing
extraordinarily useful.

This particular component has only 4 source files, no libraries linked
in, and is relatively small.

Is there a tool that can utilize this debug info and rebuild this
source? Is there a different approach that anyone can think of? I
have played with a decent one (REC;
http://www.backerstreet.com/rec/rec.htm), but have not yet fully
explored its possibilities.

This may be our only alternative if the company can't produce the
source. The bugs between versions were small, but typically critical.

Any input is appreciated.

Thank you!

I'd suggest posting on a Microsoft-specific newsgroup, where you're
likely to get more specific help. See this FAQ for a list of other
groups:

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.9

Cheers! --M

 

[marcas]

Hello,

My company recently purchased source code from a company we have been
doing business with for several years. In the past, they have done all
of the development for this product. Their business had dwindled to
the point where we were the last company to use their software so we
purchased the source and brought development in house.

We have now found that our source is out of date for one of the
components. The component was last updated in February of 2002;
version 1.2.2. Our source (for this component) is for January of 2002
version 1.1.2.

This company has not been able to yet locate the source. They had
several temporary contractors work on the code over the years, and
version control apparently was not properly enforced.

We have the binary, and perhaps fortunately, it is a debug build (built
in VC++ 6.0).

Over the years I've always believed that shipping product with debug
symbols embedded would allow a person enough information to actually
reverse engineer the binary and steal source, but when I have done
preliminary disassembly of this particular component, I see nothing
extraordinarily useful.

This particular component has only 4 source files, no libraries linked
in, and is relatively small.

Is there a tool that can utilize this debug info and rebuild this
source? Is there a different approach that anyone can think of? I
have played with a decent one (REC;
http://www.backerstreet.com/rec/rec.htm), but have not yet fully
explored its possibilities.

This may be our only alternative if the company can't produce the
source. The bugs between versions were small, but typically critical.

Any input is appreciated.

Thank you!

 

[Christopher Benson-Manica]

I'd suggest posting on a Microsoft-specific newsgroup, where you're
likely to get more specific help. See this FAQ for a list of other
groups:

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.9

As long as FAQs are being posted, the comp.lang.c FAQ will also be
helpful to OP:

http://www.ungerhu.com/jxh/clc.welcome.txt
http://c-faq.com
http://benpfaff.org/writings/clc/off-topic.html

 

[Walter Bright]

We have now found that our source is out of date for one of the
components. The component was last updated in February of 2002;
version 1.2.2. Our source (for this component) is for January of 2002
version 1.1.2.

This company has not been able to yet locate the source. They had
several temporary contractors work on the code over the years, and
version control apparently was not properly enforced.

We have the binary, and perhaps fortunately, it is a debug build (built
in VC++ 6.0).

What I'd do is compile the 1.1.2 version that you do have, and disassemble
it. Then compare the disassembly with the 1.2.2 binary. This should
drastically reduce the effort needed to reconstruct the 1.2.2 source.

Walter Bright
www.digitalmars.com C, C++, D programming language compilers

 

[Mark McIntyre]

On 10 Jan 2006 07:01:32 -0800, in comp.lang.c , "Caveman"

(of reverse engineering some binaries).

This is known as the hamburger-back-into-cows problem. Its just as
tricky - can make a cow-shaped object, but it won't moo.

There exist professional companies and software to do this. Its not
cheap. There's a sourceforge project too, but how effective it is,
depends very heavily on the original code. With anything complex,
forget it.

Either way, expect to do a LOT of hand-crafting, and expect it to be
easier to understand what the code does, and rewrite it from scratch.
Mark McIntyre

 

[Chuck F.]

My company recently purchased source code from a company we have
been doing business with for several years. In the past, they
have done all of the development for this product. Their
business had dwindled to the point where we were the last
company to use their software so we purchased the source and
brought development in house.

We have now found that our source is out of date for one of the
components. The component was last updated in February of 2002;
version 1.2.2. Our source (for this component) is for January
of 2002 version 1.1.2.

This company has not been able to yet locate the source. They
had several temporary contractors work on the code over the
years, and version control apparently was not properly enforced.


We have the binary, and perhaps fortunately, it is a debug build
(built in VC++ 6.0).

Over the years I've always believed that shipping product with
debug symbols embedded would allow a person enough information
to actually reverse engineer the binary and steal source, but
when I have done preliminary disassembly of this particular
component, I see nothing extraordinarily useful.

This particular component has only 4 source files, no libraries
linked in, and is relatively small.

Is there a tool that can utilize this debug info and rebuild
this source? Is there a different approach that anyone can
think of? I have played with a decent one (REC;
http://www.backerstreet.com/rec/rec.htm), but have not yet fully
explored its possibilities.

This may be our only alternative if the company can't produce
the source. The bugs between versions were small, but typically
critical.

Any input is appreciated.

Provided you have the identical compiler/linker/libraries, you can
experiment with source modifications to produce the same binary as
you now have. This is highly system specific, and not topical for
this group. You have a fair chance since this is C and not C++

If you want expensive help to achieve this, contact me directly via
the reply-to address in this header.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>