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.
More likely not... May be Tom Cruise(MI:Infinite) or Daniel Craig(James Bond - RE: Reverse Engineering) can do it.
~ LOOP HOLES ~ We dont even know which specific chip has been used? Whether it has on-chip I2C? What code is already written?
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.
No assurity of existing Code.
Does any body have any idea of who some one is going to generate the assembler code, (or even C for that matter - if you are Einstein, i dont have any problem) from the ROM image in 6 days (forget writing the patch code)?
"We dont even know which specific chip has been used? Whether it has on-chip I2C? What code is already written?"
Neither do we know the size of this "ROM image".
A couple of hundred bytes shouldn't be hard to disassemble (assuming no deliberate obfuscation)...
c. All existing functionality must still be operational. After reading this, i can only hope and have my fingers crossed that code is less than few hundreds of bytes.
I am a bit worried about how will the contractor differentiate between the const strings/arrays from the actual code? (given only the hex)
I'm interested.
How can I PM the guy?
Richard Marshall BEng(Hons)
You basically need to do a 100% code coverage simulation based on the received hex file, to catch exactly what is code and what is data.
A raw disassembly will normally pick up false code unless it supports multipass analysis to try to catch jumps. But code that has computed jumps aren't easy to analyze - how many jump destinations are possible?
Have you ever heard of ida pro? there are quite a number of tools that can reasonably accurately detect code and data when creating a disassembly.
And yes, I got the LED flashing. No thanks to the respondents here for that one.
Dear Richard, You have any idea why people are not taking you seriously??
experts over here are even not attempting and you are readily saying "YES" to it? (astonished)
Dear "you just dont get it DUDE!!!"
Well, it's their loss.
Why do you pretend to be someone else? It is obvious from what you have posted before under your real name to know who you are.
Maybe it is you who "doesn't get 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.
As mentioned in original posting:
Device has pre-existing operational i2c interface.
and so what. With no source is available it will take a complete idiot to quote a firm price, let alone delivery.
Erik
The ROM image and available information are available for inspection before quoting a price. Charging an hourly fee to scope the work involved is reasonable.
It is challenging work, so we expect it to be priced according. Generally one charges accordingly with expecting a worst case for the available information.
Ultimately, what we are looking for, is someone who; * Can get the job done, * Will get the job done as fast as possible, and, * Has enough experience with patching 8051 binary images to provide a solid quote.
Has enough experience with patching 8051 binary images to provide a solid quote.
in the olden days when a compile took measurable time, I did quite a bit of "patching 8051 binary image" when debugging BUT, and here's the crux, I could see from source and link map how and where.
"patching 8051 binary image" with nothing but a "8051 binary image" as a reference is one of those "I will know how long it takes when I'm done"
PS not interested, too busy with other work, otherwise it would be fun, but no way I would do it with up front pricing.
PPS what processor, maybe it is just plain impossible
But patching a binary wouldn't be done by disassembling all of the binary and document.
It would just be locating the parts of the binary that was related to the patch, and then either patch in-place if the patch was smaller than the original code, or jump to free space and there place the patch before returning back to the old code again.