Firmware crippled devices - Page 1
Forum section: electronics / general

author: gnif
author_rank: Unknown
timestamp: February 24, 2013, 05:26:52 am
content: I would love to see a video on how hardware can be firmware crippled, and how to go about reverse engineering it to re-enable the features. A good example would be my recent success upgrading my Agilent meter, and how others are now finding that they can perform the same upgrade across the Agilent range of devices.The other example would be the Rigol DSO that uses software to configure a bandwidth limiter, so it is both a hardware & software implementation.I have also found devices such as car stereo's that had signal diodes to select/enable additional features in them, by adding/moving them around I have been able to enable Bluetooth capability, higher bit rate MP3 encoding when recording radio, and line level inputs on the rear of the unit.

author: SeanB
author_rank: Super Contributor
timestamp: February 24, 2013, 06:21:46 am
content: Pretty common to have the same MCU in a range of products but only to have certain features enabled. If you buy a Samsung media player in the USA it does not have a radio in it, but the same unit in Australia does. Simple enough to reflash it and the radio appears.

author: EEVblog
author_rank: Unknown
timestamp: February 24, 2013, 07:35:44 am
content: It's much easier if you have access to both units, and don't mind if you brick them!Dave.

author: Bored@Work
author_rank: Super Contributor
timestamp: February 24, 2013, 07:56:22 am
content: Quote from: gnif on February 24, 2013, 05:26:52 amBut isn't that obvious? You either don't povide necessary code for some function in the firmware at all, or you only execute necessary code depending on some condition.What condition? Whatever the firmware programmer can come up with, including checking ports or decrypting some license key.I really don't see why anyone needs a video to understand these concepts.QuoteExperience, knowledge, skills, equipment/tools, creativity, perseverance, public and insider information, luck and maybe a few more things, in the right combination at the right time and place.Good luck backing that into a universal reverse engineering recipe, and then presenting that in a video.

author: gnif
author_rank: Unknown
timestamp: February 24, 2013, 08:34:25 am
content: I do not mean a universal guide to hacking them, but a general primer to show that large manufacturers do this, and how some of them are implemented. This would give newbies a leg up in reversing devices to enable the additional features, or additional protections they should include in their designs to prevent this. And no, I am not taking about just updating/flashing firmware, I am talking about pre-existing features that have been disabled/limited.Tearing things apart to see how they work is one thing.. tearing things apart and checking data stored in proms, or simple tests such as, short the data lines and see what happens as was the case with the DIMM, is where it gets interesting. Dave does heaps of tear-downs, and part of them could even include that simple 2 second check, which would encourage people like myself to purchase one and see about making the change permanent.

author: EEVblog
author_rank: Unknown
timestamp: February 24, 2013, 09:11:26 am
content: Quote from: gnif on February 24, 2013, 08:34:25 amI think you got lucky with the Agilent and the I2C bus shorting, when it was able to continue to work (and default to higher order functionality) without being able to read the EEPROM.Most systems would simply throw up an error code and/or refuse to work in some way.Dave.

author: Bored@Work
author_rank: Super Contributor
timestamp: February 24, 2013, 09:52:01 am
content: Quote from: gnif on February 24, 2013, 08:34:25 amThat is the typical relativism of such a broad request. You are looking for a general recipe where there is non. You want to generalize from a few examples and getting a recipe spoon feed. It doesn't work this way. You'll have to put your own time and money into it.

author: gnif
author_rank: Unknown
timestamp: February 24, 2013, 10:01:14 am
content: Quote from: Bored@Work on February 24, 2013, 09:52:01 amI know this, I am not asking to be spoon fed anything, I am suggesting this as a topic that may interest others as not everyone realises that it is possible to do this. I have reverse engineered many things in the past in order to enable additional features, some simple others quite complex, and I do know more then most that there is no single way to do this and know that a lot of it comes from experience.And as this forum states, it is for suggestions, which is exactly what this is, I don't need a tutorial/video for myself to perform this work. If it is not wanted, or not viable, then fair enough, no skin off my nose.Quote from: EEVblogAgreed, it is rarely this easy.

author: kolonelkadat
author_rank: Regular Contributor
timestamp: February 26, 2013, 02:30:40 pm
content: Quote from: Bored@Work on February 24, 2013, 07:56:22 amI dont think its all that complicated once you have the code. once you have the code, the changes are generally eitherNo Operation (OP->NOP) :: change the code fromdo somethingtodo nothingorconditionless branch (JZ/JG/JE...->JMP) :: changeIf A is less than B,Go {here}to simplyGo {here}so Id say the universal recipe would be::1)retrieve code from hardware2)test for checksum protectionmodify a string in the string table, string should maintain length eg change "ENTER PASSWORD:" to "BUMPY PASSWORD:"run new codeDoes it work?proceed to step 3:give up or proceed to step 1;question?yes:no3)make the code do what you want it to do.4)put code back on hardware6)PROFITI will readily admit that I have no idea how to do step one, but I suspect its pretty trivial to a guy who knows how to use things like i2c and spi.

author: Neilm
author_rank: Super Contributor
timestamp: February 26, 2013, 07:00:35 pm
content: Quote from: kolonelkadat on February 26, 2013, 02:30:40 pmSome devices will not let you do stage 1 - protection in the device means that you have to erase the device before you can access the program space.Neil

author: PA0PBZ
author_rank: Super Contributor
timestamp: February 26, 2013, 07:28:45 pm
content: Quote from: Neilm on February 26, 2013, 07:00:35 pmI found that getting hold of an update is an easy way around that in a lot of cases

author: mariush
author_rank: Super Contributor
timestamp: February 26, 2013, 07:53:45 pm
content: One of the most interesting and fun projects I was involved with recently is the CHDK - Canon Hack Development Kit.It's a custom firmware that can be loaded straight from the SD camera in various Canon cameras (mostly Powershot models) without overwriting the original firmware enabling or improving various functions.So you can enable saving pictures as RAW data, before the camera itself generates the JPG picture, or you can tweak the JPG compression quality that normally is fixed, on some cameras it's possible to increase the video framerate (changing bitrate for video is a given, same for removing length limits), or make the camera a sound recorder, make it do motion detections (snap pictures when motion is detected) and even play games like snake or tetris.To be fair, a lot of these were restrictions made by Canon to sell various models, the chipset inside the cameras is pretty much the same (but several versions, like pentium 1, pentium 2 , pentium 3 etc), but some options were also limited on some models to save battery power or to prevent a lower quality sensor from overheating (in the case of recording movies)If I remember correctly, they figured this stuff out when Canon posted on some Japanese site of theirs a firmware update for a camera, which had a part unecrypted or something like that.So they figured out the camera will search for a particular file on SD camera and run it.They figured the architecture and wrote a simple program that just set various ram locations to 1 and found that doing that made the leds on the camera to light up... so then they basically made a program to read the memory and blink the led for every bit.From that point it's easier... dump the rom with the OS from the camera, dissable it, find the routine that does beeps to the speaker, now you have high speed memory dump of the memory ..Figure out what each function does, replace some functions in memory with your own, and it's smooth sailing from there.