We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Kiosk provider seeking an 8051 assembly language developer to patch firmware to: * Add two i2c commands: 1-turn on 2-turn off Notes: 1. Device has pre-existing soft power control. 2. Device has pre-existing operational I2C interface. 3. Current firmware is available only as ROM image. 4. We -possibly- have some C source code for the 8051-based controller, but it is not configured for the product, nor includes past manufacturer provided customizations. It is probably mostly useful as a reference tool. Deliverable Requirements 1. ROM image: a. With new I2C on/off command functionality. b. Upon boot, the device must start in the existing on state. c. All existing functionality must still be operational. d. Provided in the same ROM-able Intel hex format the original firmware image was supplied in. 2. New functionality in deliverable #1 must pass 100 I2C command off/on test cycles. 3. Assembly language listing for deliverable #1, with descriptive comments documenting changes. 4. Deliverables must be provided within 6 business days from when both parties agree to commencement of work. Available Resources We can provide for the duration of the work: * One controller board for development/testing. -and- * One end-product module which uses the controller board. Work Quotation Please e-mail: * Your all-in fixed price for the work. * Relevant qualifications. * The option of partial payment mid-way through project requires two strong references. Otherwise, payment is upon receipt of the required deliverables.
Anybody know how to make a web site? Duhh. (Sic)
Now to get my consultancy business fully operational. (jokes apart) No hard feelings. All the Best. :)
Note that you can find 8051 chips with at least 1MB of code flash. So way, way larger would, in my language, mean that you have disassembled at least 10MB+ binaries.
But one thing to note is that huge binaries are normally generated from a high-level language. While 8051 binaries can contain very tricky code written all in assembler to get the most out of the chip. Tricky code includes situations where the same byte can be both data and code. That isn't something a compiler would produce. Tricky code may require that you need to know the allowed value range stored in specific registers to be able to deduce the behaviour - and that isn't so easy even for a multi-pass disassembler.
In this case, we know that there may be some C source code in existence. But that doesn't prove that this in original the code was 100% C. A significant part could be in assembler, and written by a wicked developer willing to use any trick in the book to squeeze an extra clock cycle or byte.
No sane human with the proper skills to understand the issues would enters a fixed-price contract with a fixed deadline based on so much unknowns. Only a fool or a troll (which is just another type of fool) would jump at it.
"And yes, I got the LED flashing. No thanks to the respondents here for that one."
Only a fool or a troll would make such a comment, when the linked post shows that there wasn't even a brand or model specified for the processor.
May be he has never seen the assembler code for function pointers!!
Imagine a situation where, there is a keyboard, display (16*2lcd, for a start) and some other peripherals. The code dynamically changes the execution flow depending on user inputs from keyboard. I cant imagine a binary file of such a code given to me and asked to generate the code from binary file.
Certainly in excess of a few MB. Haven't you?
Per, please stop being such a pompous git.
Richard Marshall BEng(Hons)
"But that doesn't prove that this in original the code was 100% C"
My reading of the original post is that the 'C' is definitely not the source of the available image.
"written by a wicked developer"
Well, the lack of source code is certainly a Big Red Light!
At the very least, it shows a hopless lack of development process.
What other important design information is also going to be missing...?
Something is seriously wrong if there is a need to make a total reverse engineering of a multi-MB project.
Unless the goal is to steal someone elses code, most situations where reverse engineering is needed would relate to quite small blocks within a larger binary. Such as the interfacing of the binary with a specific hardware device, to allow totally new code to be written for existing, but badly documented hardware.
Small fixes for a binary with missing source code is normally produced by patching in new code at the end of the binary and just patch the existing binary to access this new code.
Large fixes for a binary with missing source code? Normally solved by rewriting everything. Or suggest that the hardware is old enough that it is better to make a completely new product with new electronics and get a product where the customer both owns documented source code, and have a cheaper hardware platform to produce and sell for possibly quite a number of years.
In the end, reverse-engineering of larger projects is normally a huge fail. Wrong route to solve a problem after having already huge fail of losing the source code.
Sometimes, a debate isn't nonsense, even if the debate is started by a troll.
Issues when reverse-engineering binaries are still issues. So it is still just as relevant to make sure that the correct version of the source code and the requirements specifications are never, ever, lost, as long as there are any economic interest in a product, or any need to be able to supply bug fixes.
Just because a processor can read op-codes like a native, it is so easy for people to think that it is easy to take a binary and recreate source code in a way that is meaningful to maintain. Just that the optimization steps used by compilers (and sometimes, like for 8051, linkers) can wreak havoc on any structure of the original source code. And the op-code sequences can represent lots of ambiguities that can't be easily resolved without specific knowledge about the product - knowledge that probably was lost at the same time as the original source code. And that costs lots of money for a developer to regain when trying to learn everything about the workings of the product.
Chuck Norris can turn a hamburger back into a cow.
That's so cool ;)
* The ROM image is 128 KB.
* This does require reverse engineering using IDA or similar.
* We have been unable to obtain the datasheet for the microcontroller so presence of a debug interface is unknown.
If interested, please e-mail the information requested in the Work Quotation section to firmware-enhancement-8051 at hcn-inc dot com.
... often signifies modifications to or illegal use of someone else's proprietary code.
that said, I once were - long ago - asked to recreate a project from the object (reading out a chip), the factory burned and the fools did not have off-site data storage. After digesting the disassembly for two weeks (see the time requirement stated by the OP) I gave up and created the project from scratch.
In my opinion/experience it is faster to recreate than to reverse engineer.
Erik
As mentioned in original posting:
Device has pre-existing operational i2c interface.
"We have been unable to obtain the datasheet for the microcontroller"
Oh dear!
I'm too busy. I'll have to get my junior onto it.
Zeusti. Hey, Zeusti. Where are you? I've got a job for you mate.