Hacking protected MCU firmware

[digidream]

Hello !

I don't know where to post this so, sorry if it is the wrong place.
I have a board in front of me with an ATXMEGA MCU and lock fuses enable so it is impossible to read the firmware.
But this board is delivered with a windows app and a firmware update feature.
When installing this software, I can found in hidden directory a firmware corresponding to the MCU on board but it is a .bin file and not a .hex one.
I tried to convert the .bin to .hex but I doesnt work. The file seems to not be in the right format.
Maybe the bin file is encrypted.

Do you think it is possible to listen the usb port during the transfert and copy the firmware or do other bad things ?

Thank you for your help

[pablo2048]

IMHO even this USB transfer is encrypted. IAP decrypt file on the fly...

[fpgaguy]

I'd suggest getting the spec for that particular part, to get a better understanding to what you are up against.

I have an ARM that I use that has e-fuse register on the part which can be set to an AES key, and when it's strapped to secure mode it will then use this AES key on the data contained in the secondary(external) boot SPI, in this mode JTAG is disabled also
The boot method for this part is then

internal ROM -> loads header from spi -> loads bin_hdr for DDR training/Serdes --> loads uboot --> loads linux kernel/ filesystem --> done booting

however _all_ those user pieces can be encrypted with the random 128 bit AES key you make

I suppose if you know the format of the boot code and can identify that the unencrypted code would have a certain pattern at a precise location somewhere in the code - perhaps reset vector, or something
and if you know the encryption method you could build some guessing tool with rainbow tables, but .... it may be quicker to just redesign


I've seen (s/w) USB sniffers  so that would be worth eliminating as a possibility

I see ATXMEGA is AES also .. so
there's quite a bit of discussion on the net for AES 128 cracking, but generally the consensus is it's not possible using a brute force attack
you will need to find a side channel and there is some vague sucesses reported on sim cards (Search Black Hat 2015, YuYu)

[CocaCola]

it may be quicker to just redesign

It's certainly more ethical to redesign...  With that said unless you have to tools and experience chances are you won't be cracking it in any realistic time frame or even ever...  I highly doubt logging or listening to the USB is going to get you anywhere as the 'decryption' is almost certainly fully contained in the chip, the only likely info being sent over the USB is the file you already found...

On the other hand, if you dig around there are some Asian electronics firms that specialize in dumping chips, and if you contact them with the chip number they generally will give you a yes/no and cost right away...  It's not cheap and you generally have to send them 2-3 pcs of the chip for them to work with just in case they destroy one by physically taking it apart to access the guts directly...  Going back about 7 years now, I had a quote for $1000 USD to dump a locked chip they claimed to be able to do, but since security measures have obviously improved over the years it might even be more costly now...

[hate]

Many years ago, I have converted a .bin file to a .hex file to program into a AVR. I don't remember what I used to convert at the time but a quick search suggests this:

Code:

avr-objcopy -I binary file.bin -O ihex file.hex

'avr-objcopy' comes with the Atmel AVR Tools.

There is also the 'srec_cat' way detailed here (I may have used this one):

Code:

srec_cat file.bin -binary -o file.hex -intel --line-length=44

'srec_cat' comes with WinAVR if not with Atmel AVR Tools.

But still the format of your .bin file may be a different format than the standard.

[pickit2]

also many years ago, I can't remember the programmer, but there was about 6 options to save an Hex file, in a bit of kit we used, we needed to save as option 4, but the number of times the wrong one was chosen. the techies said it was a bad chip.

This page I found trying to find the programmer we used.
http://www.keil.com/support/docs/1584/

[sadman]

hi

what i think you have right firmware file in the format of .bin normally we required INHX8M compatible hex file you can find more detail about hex file and there format on link given.

https://en.wikipedia.org/wiki/Intel_HEX

further if you found old 8051 compiler it come with two utils "bin2hex" and "hex2bin"  i have these two utility on my old hard drive i will find it and share it here, both util are from intel and they work like a charm you can search on google by "bin2hex"

so i found it on my hard

sadman

[nPn]

Strictly converting into HEX might be a bit of a red herring, because HEX is just a different (ASCII) representation of the data in the bin. There's nothing in a bin -> HEX conversion process that verifies if the data is valid AVR firmware or decrypts the bytes. Are you doing any additional steps that might fail? Please post your command line.

[CocaCola]

Just because the file extension is .bin does not mean it complies with any known format or is even a binary file at all...

IMO if the developers implemented even the most basic security and encryption trying to convert BIN to HEX isn't going to get you anywhere...  Sure if you knew the BIN files format and knew for sure it wasn't encrypted you could convert to HEX but I doubt this is the case in today's protection world...

[Gallymimu]

Just because the file extension is .bin does not mean it complies with any known format or is even a binary file at all...

IMO if the developers implemented even the most basic security and encryption trying to convert BIN to HEX isn't going to get you anywhere...  Sure if you knew the BIN files format and knew for sure it wasn't encrypted you could convert to HEX but I doubt this is the case in today's protection world...

I think you can pretty much guarantee if it's not ASCII it's BINARY

[CocaCola]

I think you can pretty much guarantee if it's not ASCII it's BINARY

Not sure where you are going with that as there are other recognized and even proprietary character encoding schemes beyond ASCII, so your statement is essentially false, beyond the point that in the end all files are binary at the foundation...

[Gallymimu]

Not sure where you are going with that as there are other recognized and even proprietary character encoding schemes beyond ASCII, so your statement is essentially false, beyond the point that in the end all files are binary at the foundation...

Please elaborate with some examples so I can learn.  I simply didn't think the comment "... or is even a binary file at all" seemed nonsensical to me.  I simply didn't consider, at least at a high level, besides ASCII or BINARY encoding of data irrespective of some goofy character format where you might be using a bunch of other ascii symbols in the format.

BUT, I'm still interested if you have some particular examples in mind that don't really fall into the general category of ASCII encoding or binary encoding.  (No I'm not trying to nitpick and say everything is ones and zeroes at the end of the day).  

so I'm probably not FALSE and you probably don't actually sound silly.  We just need a meeting of the minds and then we can hug it out!

I'm here to learn, not to be right... though... I'm pretty much always right... 

[poorchava]

I'd ask in China about the price for dumping the firmware. The quotes can be as low as $600 for simple stuff like PIC12 or PIC12. I doubt AVR is much more complex than those.

More complex chops,  like for example larger CM4 and CM7 MCU can be much more expensive due to complexity of the chip and typically lower process geometries.

[zac]

I'd ask in China about the price for dumping the firmware. The quotes can be as low as $600 for simple stuff like PIC12 or PIC12. I doubt AVR is much more complex than those.

More complex chops,  like for example larger CM4 and CM7 MCU can be much more expensive due to complexity of the chip and typically lower process geometries.

How do they extract the code?  Do they actually microprobe the memory array on the chip? 

[CocaCola]

How do they extract the code?  Do they actually microprobe the memory array on the chip?  

It all depends on the chip, and they are not going to disclose their methods publicly...

Many times you can voltage 'glitch' a chip at start up that creates a soft/corrupt boot where the security is not in place and the chip can be dumped...  You can also clock 'glitch' chips similarly...  Other chips can be buffer overflowed causing the security to fail... And so on...

This company makes devices to aid in the 'cracking' but I'm linking it not because of that but because they give a very decent overview of many different attacks to get chips to cough up their memory...

https://newae.com/sidechannel/cwdocs/

And yes for some (if you have the money) they will request 2-3 samples and they will literally dissolve the epoxy to expose the die and micro-probe it with the help of microscopes and/or even electron microscopes to disable security and get it to cough up it's insides...

[mario2000]

   This company located in china are dedicated to clone all kinds of boards, included chips and their firmware
  http://www.pcb-copy.com/pcb-copys/IC-Chip-Schematic-Extraction.html
 
     

     

[gabriel]

http://www.break-ic.com/

[Sideshow Bob]

https://www.youtube.com/results?search_query=Chris+Tarnovsky
The video "How to Reverse-Engineer a Satellite TV Smart Card" is quite interesting. Even if it is 8 years old and probably kind of outdated.

[fpgaguy]

one thing to note about the video (I was just looking for that to post up here since I saw that a few weeks go but didn't keep link!)

is that they read out a hard coded ROM which, which is set by factory and has easily identifiable bits - the item in question though is a flashed ROM, with keys likely in EEPROM or flash structure - so a different methodology may be needed

[CocaCola]

Regardless of the methodology I love seeing Tarnovsky's name as it brings back many memories and what would become a story right out of Hollywood...  I was quite connected to the Sat TV hacking community at the time and a member and/or staff at several of the forums that Tarnovsky was also a member, so I literally was a side note in that history, a history that would eventually turn out to be a second story of secret corporate espionage and beyond...

[norkimo]

http://www.break-ic.com/

I do not recommend this company.  I've used them before to crack a very simple chip, a PIC18F6621.

They didn't follow their own published procedure, and ultimately sent us code with errors.  We told them that the code they sent is corrupted but they would not acknowledge their mistake even after we sent them additional test hardware and multiple chips.  They ended up blaming it on the fact that the chip was from a "high security" RFID reader even though it had nothing to do with it.

Thankfully we had already extracted part of the firmware on our own using in-house techniques, and the error in break-ic's code by sheer luck was in the section that we had already extracted successfully.  By combining our work with their work, we finally got working firmware.

They ended up not even sending our hardware back or providing a refund, so we filed a PayPal chargeback and won.

The PIC18F6621 is a very straight-forward chip to break using decapping techniques.  If a business who is dedicated to this service can't handle it or even admit when they made a mistake, I don't trust them.  Find someone else.

[HackAndCrack]

This is regarding post 1 of this thread. If you can provide the Circuit and .bin file I will see if I can get the firmware from it.

[dvbguy]

Regardless of the methodology I love seeing Tarnovsky's name as it brings back many memories and what would become a story right out of Hollywood...  I was quite connected to the Sat TV hacking community at the time and a member and/or staff at several of the forums that Tarnovsky was also a member, so I literally was a side note in that history, a history that would eventually turn out to be a second story of secret corporate espionage and beyond...

we probably bumped modems.... maybe even shared a channel inside AXABOT