My very first task working in Product Engineering at Analog Devices (1980 and fresh out of college) was to compare an ADC module (yes module at that time) with one from the arch competitor, Analogic. I had samples of both and copies of the ADI schematic so I traced them both. They were identical so I asked the department manager "Who copied who?"
His response: "We copied Bernie."
We never mentioned Analogic by company name, just "Bernie."
I have no experience in that regard, but I find natural RE to be an area of real potential. These kinds of techniques can reap a true reward, and do not run the risk--unlike other forms of RE--of being deemed illegal or unethical, at least I hope not.
Sounds like "sometimes" RE occurs beneficially far more often than many may beieve. Not a bad thing.
Aside from doing it with your own products when there's missing info, technologists must invest in staying highly aware of what competitors are doing...obeying Sun Tsu's rule: "Know your enemy." DIY RE now is likely far beyond many internal engieering teams' abilities or time capacity. So a few highly focused businesses offer very specialized expertise and services.
@HankWalker: Reverse engineering must also be used when you are making modifications, improvements, additions to an existing hardware or software product with poor or no documentation (or designers) available.
Good point. Early in my carear I spent a lot of time writing functuional test programs for PCBs. I was given a PCB that was claimed to be "known-good" (but after wasn't) and a schematuc that was said to be at the same revision level as the board (but often wasn't) and ... that was it.
It was up to me to try to determine what the board was supposed to do and how it did it, and then write a test program that fully exercised the board. Of course this wa sback in the very early 1980s when boards were much simpler than they are today, but it still gave me a lot of mental exercise.
As a by-product, this was quite possibly the best training I ever received LOL
I remember when I had to make an RTOS (which we had licensed) interoperate with our code. The RTOS documentation for the particular instruction architecture was incomplete. You were supposed to use a "board support package", but if your board wasn't on the list -- e.g., if it was your product rather than a standard development board -- the documentation was simply not there. (This particular RTOS at one time had excellent, complete documentation for a different architecture, but they had been acquired by a Large Company who obviously felt that complete documentation was unprofitable.)
So I had to disassemble the task switch machine language so that I could see how it was using and saving registers. Once that was clear, the rest was pretty easy.
Absolutely! Reverse engineering is often an essential skill when you are tasked with modifying your own company's existing product or re-using IP. Designers come & go, and documentation often lacks important details that another designer needs to know in order to successfully modify a product or IP block.
Black box reuse (don't change anything) is a luxury you don't always have on a new product. As soon as you hear the words "reuse with a few changes," it's time to bring out those reverse engineering skills!
Reverse engineering must also be used when you are making modifications, improvements, additions to an existing hardware or software product with poor or no documentation (or designers) available. One time I needed to know something, and one designer was on pregnancy leave and the other one was on a honeymoon in Tahiti! At least I knew who the designers were, but I still had to reverse engineer the system to get the answer I needed.
In some sense, reverse engineering is about keeping the system model in sync with the implementation. Or creating a system model if you can't find one.
Reverse engineering is a fun, whatever be the legality or illegality behind it.
Way back in 1988, as a free lance assignment, i really enjoyed the reverse engineering of the MS-DOS "debug "program . I used the "debug" program itself to understand its working, its data structures and successfully ported it onto a locally made 8086 development kit.
In my opinion, reverse engineering is a very good learning tool for engineers!
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.