flashing problem about chameleonmini-rebooted

[slurdge]

I hope this is the correct issue to comment on.
Firstly, I (almost) completely reversed BOOT_LOADER_EXE and CreateBin.exe. The encryption (?) is quite strange but I managed to fully reverse engineer CreateBin.exe into a python application.
First, the key is designed by dxls (16 bytes). Secondly, the following script will produce identical files:

from Crypto.Cipher import AES
import sys

datain = open(sys.argv[1], "rb").read()
if len(datain) % 16 != 0:
	datain += b'\0'*(16-len(datain)%16)
datain += b'\xcd'*(16-len(datain)%16) #strange fill in value on heap
with open(sys.argv[2], "wb") as fout:
	for i in range(0,len(datain),16):
		aes = AES.new(b'designed by dxls', AES.MODE_CBC, '\0'*16)
		block = datain[i:i+16]
		scrambled = [(block[j] ^ ((0x2d + i + j)&0xff)) for j in range(16)]
		out = aes.decrypt(bytes(scrambled))
		fout.write(out)

Notice the decrypt operation. I kid you not, it took me a long time to find it was the decryption of AES that was called.

Now, when going to bootloader:
The execute_flash command of dfu-programmer has been changed with the additional following lines:

  decrypt_res = decrypt((char *)filename, &dec_buffer);
  v11 = decrypt_res;

But one important point I found, is that the 0x2d xor seems to be never reversed. So it is possible that it's done by the bootloader. Hence, the impossibility to flash "regular" images.

I also found hardcoded commands inside the bootloader for dfu-programmer:

aMy           ; "my"
aAtxmega32a4u ; "atxmega32a4u"
aReset        ; "reset"
aMy           ; "my"
aAtxmega32a4u ; "atxmega32a4u"
aFlash        ; "flash"
aMyfileBin    ; "myfile.bin"
aMy           ; "my"
aAtxmega32a4u ; "atxmega32a4u"
aErase        ; "erase"
aForce        ; "--force"
aMy           ; "my"
aAtxmega32a4u ; "atxmega32a4u"
aFlash        ; "flash"
aEeprom       ; "--eeprom"
aMyfileeBin   ; "myfilee.bin"

I think the order is erase, eeprom, flash, reset.
I hope this will help! I'm not that good at flashing but I hope we can get a better version of the tools with this.

[slurdge]

Success! I patched the official firmware by descrambling and rescrambling, and I changed the version number from 1.0 to 1.4. I then programmed normally with dfu-programmer.

101:OK WITH TEXT
Chameleon-new-1.4

So I am rather confident that this method would work for all firmwares (if the original bootloader is kept, as per current instructions) and also on linux.

@iceman1001 , @bogiton , what would be the best way for me to create such instructions ?
I'm planning a pull request with all the python utilities needed. Also, I think that we may be able to close #12 with this. I'll try my hand with a linux laying around next.

[iceman1001]

Aha, you too!?!? I just spend hours with this.. not to mention cursing at it.

[iceman1001]

I just did flash this repo ;) However, since I don't know the functions before, that was maybe a pre-hasten idea. Never mind, why look back? Now that it can get some bug fixes from the offical revE and RevG

[slurdge]

I have a proof of concept ihex patcher. It does work on the produced Chameleon-Mini.hex but upon flashing, I have trouble connecting to it. The serial port appears, I can connect but enumeration triggers a bug/problem inside the firmware and the device resets. Maybe it's related to eeprom as it needs to be in sync - not sure about this TBH.

scramblehex.txt

However I could reflash the original. Right now, I use only dfu-programmer and never the original exe tool. I have some work to do beginning of next week but I'll try to create a PR with all the tooling & info.

[iceman1001]

What more files do you have in the same folder as BOOT_LOADER_EXE ?!? ITS_A_CARD.hex doesn't seem to be enough

For the normal Rev.G you need to have the files Chameleon-Mini.hex and the Chameleon-Mini.eep in the same directory where the flash.bat is located.

[bogiton]

I think that the BOOT_LOADER_EXE file has the dfu-programmer as well as the required "original" hex files embed into it. So, it works standalone. The only thing required is for the Chameleon to be in bootloader mode with the libusb drivers loaded for it.

[bogiton]

Actually, my bad, it needs the following two files:

• myfile.bin (Probably the flash binary)
• myfilee.bin (Probably the EEPROM binary)

bootloader-files.zip

[iceman1001]

I don't know. I put the libusb0.dll and some of the warnings went away.

old_driver_bootloader dfu-old-driver: no device present.

[iceman1001]

you can create the first myfile.bin if you put the ITS_A_CARD.hex in the same folder
https://github.com/iceman1001/ChameleonMini-rebooted/tree/master/Software/FlashTools

and run the bat file.
The eeprom generation I havn't figured out yet.

[iceman1001]

oops.. I removed the libusb.file and my BOOT_LOADER_EXE.exe worked..
and i have the myfile.bin / myfilee.bin in same folder...

It feels we figured out something important here. When compiling the project, we can now get the myfile..

[bogiton]

Now that you mentioned it, when I had the libusb0.dll in the same folder, the flashing (with the BOOT_LOADER_EXE) wasn't working. I had to remove that dll in order to work.

[bogiton]

Ha, you found out fast enough! :)
As for the EEP, maybe we can generate the myfilee.bin with the flash tools from the compiled Chameleon-Mini.eep file?

[iceman1001]

Could be. lets test.

[bogiton]

Yep! That worked! :)
I created the myfilee.bin from the compiled Chameleon-Mini.eep (ihex format) and the myfile.bin from the ITS_A_CARD.hex. I copied those two files in the same folder as the BOOT_LOADER_EXE and run it. Flashing successful!
And btw, the ITS_A_CARD.hex seems to be missing the DETECTIONMY command.

[iceman1001]

yes, It worked for me too!

I took some time looking at the generated bin files. It adds two bytes to the end of the file and scramble/encrypt/xor the whole file.

So we can update the flash.bat, to copy and rename. Give instructions to copy hex,eep file from compilation, and run flash, then copy to BOOT_LOADER_EXE folder, and run...

[iceman1001]

Bravo! We have now unlocked achivement, flash your own firmware onto device.

[iceman1001]

Someone wants to compile the official revE firmware and test? ;)

[bogiton]

Hehe, I was thinking of doing either that or try to compile the initial commit of your repo. Before the migration, just to see if it gives the same functionality as the "stock" flash files.

[iceman1001]

Added some draft wiki page for flashing on windows. I have no clue how the linux/osx based users will be able to flash given the need for BOOT_LOADER_EXE.exe. We would need source code for that file, or decompile it ourselfs.

[bogiton]

It seems weird to me that even if that BOOT_LOADER_EXE seems to be using dfu-programmer, the needed files for it are in binary format. As far as I have seen, dfu-programmer only accepts ihex files for flashing. Could this exe be (re-)extracting the ihex data from the supplied binaries, using also somehow those two bytes you noticed that the Createbin.exe utility is adding to them? Maybe we should first figure out what this Createbin.exe file does. By the way, decompilation is almost impossible for those two binaries (probably written in C++). We need someone with disassembling skills.
Good thing is, though, that the avrdude utility, that Linux/OSX users can use, accepts both ihex and bin files for flashing. Haven't tested what happens if I try to flash those myfiles using another tool like avrdude.

[iceman1001]

Don't know. SInce it uses two files to compile, and the orignal hex is only one file. Try and see what happens on a linux?

Someone with IDA pro skills can do their magic :) when it comes to decompilation. That even I manage but understanding whats going on from the deadlisting is not my cup of tea.

[iceman1001]

ok, I chatted with manufacturer, the createbin does apperantly a AES encryption. The software was developed (gui, code) by a external developer. Sad part of story, the developer seems to have forgotten which key was used.

Still, if its encryption, it needs to be decrypted somewhere. If there is a decryption, the key must be there too.
If its just a MAC, then the private key doesn't need to be there in order to verfify key.
This suggest that the aes key would exist inside createbin (fix array) and that testing all possible contingency 16bytes with AES to encrypt a normal bin to see if one candidate key would generate the same myfile.bin file. Its not a huge program createbin (64kb)..

[gurubook]

I passed an all zero file to CreateBin.exe and the resulting myfile.bin has 256 byte block of repeating apparently random data.
I think about super duper xor encryption, but does not seem the case, and than you say AES was used. It make sense as xmega has AES 128 hardware implementation, and the repeating patter tell us that ECB mode was used, apparently with constant IV.
I'll too will try to put an eye on it as soon as i have some free time next week.

[iceman1001]

AES with padding also fits the two extra bytes. In order to fit a aes blocksize of 16bytes.
Using PEiD on createbin.exe also confirms AES.

Since the myfile.bin is completely encrypted and padded with 2bytes, the key is not added to the file.

PEiD also shows that BOOT_LOADER_EXE.exe uses AES.

So createbin encrypts -> boot_loader_exe decrypts and flashes.
Would explain why the dfu-programmer doesn't work at all.

[iceman1001]

Createfile.exe is called with two params.

myfile.bin
bin

The second param allows bin or txt where text generates a file with hex strings of the file instead .

[bogiton]

Running Createbin.exe txt on an empty file (0 bytes) returns this:
0x0D,0xD5,0x33,0x0B,0x67,0xB5,0xE1,0xA9,0xC4,0x46,0xEC,0xA1,0xE5,0xFE,0x1D,0x3A,

Since we are stuck for the time being with these utilities, I updated the flash.bat script to work with those two (+avr-objcopy.exe), having the eep and hex files as input.

flash.zip

[iceman1001]

nice. I pushed it, why don't you make a pull request (PR) and use github for what its built for?

[bogiton]

Indeed, I will next time. Maybe we should also copy the BOOT_LOADER_EXE.exe into the /Software/FlashTools/ directory? To have there everything needed for flashing.

[iceman1001]

Its under a differnt folder, Win32, We would need a better structure of files. Many binaries which we don't have source code for. Maybe a wget/curl script which downloads all needed binaries.

[WolfgangMau]

ok, I probably bricked my chameleon :-D
I was playing with dfu-programmer:

dfu-programmer atxmega32a4u erase
Checking memory from 0x0 to 0x7FFF... Not blank at 0x7FF1.
Erasing flash... Success
Checking memory from 0x0 to 0x7FFF... Not blank at 0x7FF1.

then I tried to flash the ChameleonMiniRDV2.0_ATxmega32A4U.hex

dfu-programmer atxmega32a4u flash ChameleonMiniRDV2.0_ATxmega32A4U.hex
Bootloader and code overlap.
Use --suppress-bootloader-mem to ignore

dfu-programmer atxmega32a4u flash ChameleonMiniRDV2.0_ATxmega32A4U.hex --suppress-bootloader-mem
Hex file error, use debug for more info.

with more debug:

dfu-programmer atxmega32a4u flash ChameleonMiniRDV2.0_ATxmega32A4U.hex --suppress-bootloader-mem --debug 300
target: atxmega32a4u
chip_id: 0x2fe4
vendor_id: 0x03eb
command: flash
quiet: false
debug: 300
device_type: XMEGA
------ command specific below ------
validate: true
hex file: ChameleonMiniRDV2.0_ATxmega32A4U.hex

dfu.c:414: dfu_device_init( 1003, 12260, 0x7fff59f5e6e0, true, false )
dfu.c:431: found device at USB:11,0
dfu.c:663: Found DFU Inteface: 0
dfu.c:293: dfu_abort( 0x7fff59f5e6e0 )
dfu.c:844: -EPIPE: a) Babble detect or b) Endpoint stalled 0xffffffe0 (-32)
dfu.c:204: dfu_get_status( 0x7fff59f5e6e0, 0x7fff59f5e5f8 )
dfu.c:230: ==============================
dfu.c:232: status->bStatus: errSTALLEDPKT (0x0f)
dfu.c:233: status->bwPollTimeout: 0x0000 ms
dfu.c:235: status->bState: dfuERROR (0x0a)
dfu.c:236: status->iString: 0x00
dfu.c:237: ------------------------------
dfu.c:688: State: dfuERROR (10)
dfu.c:252: dfu_clear_status( 0x7fff59f5e6e0 )
dfu.c:204: dfu_get_status( 0x7fff59f5e6e0, 0x7fff59f5e5f8 )
dfu.c:230: ==============================
dfu.c:232: status->bStatus: OK (0x00)
dfu.c:233: status->bwPollTimeout: 0x0000 ms
dfu.c:235: status->bState: dfuIDLE (0x02)
dfu.c:236: status->iString: 0x00
dfu.c:237: ------------------------------
dfu.c:688: State: dfuIDLE (2)
intel_hex.c:337: Address offset set to 0x0.
atmel.c:1295: atmel_flash( 0x7fff59f5e6e0, 0x7fff59f5e5a8, false, false )
atmel.c:1158: atmel_flash_prep_buffer( 0x7fff59f5e5a8 )
atmel.c:1335: Flash available from 0x0 to 0x7FFF (64kB p. 0 to 0), 0x8000 bytes.
atmel.c:1339: Data start @ 0xFFFFFFFF: 64kB p 65535; 256B p 0xFFFFFF + 0xFF offset.
atmel.c:1343: Data end @ 0x8FEB: 64kB p 0; 256B p 0x8F + 0xEB offset.
atmel.c:1348: Totals: 0x8FED bytes, 4278190225 256B pages, 4294901762 64kB byte pages.
atmel.c:1353: ERROR: Data exists outside of the valid target flash region.
Hex file error, use debug for more info.
commands.c:360: Error writing memory data. (err -1)

ps ... I'm working on Mac OSX

update:
downloaded me a windows7 virtualbox-image from microsoft
installed dfu-driver
(re)flashed the chameleon successfully
but it seems not to work like before anymore can not set anything within the Chameleon-Gui even if it 'says' it is connected
this was possible before

OK ... not the way it should be, but seems to work:
I have renamed the ChameleonMiniRDV2.0_ATxmega32A4U.hex to Chameleon-Mini.eep
and the ITS_A_CARD.hex to Chameleon-Mini.hex
executed flash.bat ... and was able to enable all slots within the GUI again.
this is probably total mess ...
but the pm3 can now at least detect mf again (1k & 4K)
set mfu is not possible anymore (GUI-error)
random uid for mf is also not possible anymore

I suppose the eep is for the settings, but the ChameleonMiniRDV2.0_ATxmega32A4U.hex
seems not to have the ultralight- and random-uid-feature ;-)
but I'm glad that my chameleon is working again - with limited features ;-)

[iceman1001]

Aha, the rename of the hex file to eep, is just wrong. eep == eeprom
So you didn't do the right process.

Either:
ChameleonMiniRDV2.0_ATxmega32A4U.hex -> Chameleon-Mini.hex
or
ITS_A_CARD.hex to Chameleon-Mini.hex

These hex files is ok to flash with the avrp-mkII.
if not, you need the BOOT_LOADER_EXE way to do it.

Those scripts generates two BIN files. myfile.bin (old hex) and myfilee.bin (old eep)
and flashes to the device. Follow instructions on Wiki.

---

Now, the dfu-programmer software, have you had any success with that???
I didn't.

[WolfgangMau]

hehe ... dfu-programmer bricked my device ... but now I know how to 'reload' it ;-)
since the BOOT_LOADER_EXE (or the bootloader himself) seems to do some magic while uploading
even if I convert the working binaries back to hex (since dfu-programmer can only handle hex-files at flashing-mode) it will not work out.

I know such behavior from a former project on a 328p... the russian guy was using a homebrewed bootloader which did some magic while flashing, so only his bootloader could handle the hex in a correct way (to prevent chinese cloners) ... so, there was no (simple) way around ... if the bootloader was missing or not his one, his public downloadable firmware was not working.

so, the magic might be totally different here, but something unknown seems to happen inside the BOOT_LOADER_EXE - as already mentioned by you or some other guy in this issue

[iceman1001]

Yeah, basically, the createbin and BOOT_LOADER_EXE does that. We think it encrypts with AES+padding into the myfile.bin* files and boot_loader decrypts it.
We know that the device can be flashed with AVRP-mkII with hex-files and get working device, so encryption on device is out of question.

It took us some time to get some different files. Once we have the bin-file which was distributed from manufacture to retailer, it is easy to get a square one device again.

but once we started fixing the firmware, the bricks started to happen. We don't seem to get a correct eeprom file. When I compile I get a 44bytes file, but the original one is 40bytes. And this is also a complain when trying to flash, and if I force it, I brick it.

[WolfgangMau]

hmm ... if you flash it with a ISP-device ... the bootloader should not be present anymore?!
that was at least the behavior on a m328p
but of course th xmega may behave totally different

I guess this could be a nice playground for half the price:
atxmega32a4u breakoutboard
should be enough for testing firmware and gui

or even this one (has a cp210x on it - so probably no DFU functionality)

[jackkleeman]

@iceman1001 what eep should I use to flash ChameleonMiniRDV2.0_ATxmega32A4U.hex ??

[iceman1001]

Not sure, I just used the avpr-mkII together with the atmel studio 7.0, which generated a eep file for me when I pointed to that hex-file.

[jackkleeman]

I am using the same device with the same software. Where is the option to generate an eep from a hex??

[iceman1001]

I don't have that tool installed now, but somewhere under device programming form... From production hex file??

[jackkleeman]

It only allows from production elf files...

[jackkleeman]

Can you please share the MF Classic patch code with me? If I had that then I wouldn't need to try to flash any of the compiled hex files

[prensel]

I have tested on both Linux and Windows systems and at this point i'm thinking that the standard Atmel bootloader is replaced with a modified version and not working with the standard dfu-programmer of avr-dude tools. Hence the 'special' boot_loader_exe is needed.

[bogiton]

Indeed. Actually, the boot_loader_exe file seems to be using the dfu-programmer internally, possibly also modified to handle the modified bootloader. On the other hand, since iceman already managed to flash it using the AVRISP-mkII device in Atmel Studio, I believe that the same can be achieved with the avrdude under linux, instead of the flip2 "device".

[prensel]

When using a device like an in-circuit-serial avrisp programmer your not using the usb bootloader so that should always work. Since avrdude and dfu-bootloader need to have a working usb bootloader we're stuck at that point unless there's a way to upload the standard atmel usb bootloader using a device like the avrisp.

[bogiton]

Admittedly that is a very good idea. As far as I can see, there are lots of USB DFU bootloader implementations for XMEGA and even for the atxmega32a4u specifically. Also, right after your suggestion, I noticed this batch script https://github.com/iceman1001/ChameleonMini-rebooted/blob/master/Firmware/Atmel%20DFU%20Bootloader/GenerateBootloader.bat which was apparently used to generate the bootloader of the rebooted version.

[iceman1001]

Is this the final piece of the puzzle? We had it all the whole time? haha, there was so much to focus on, so I never looked and thought about this batch file.
So we should be able to generate correct hex->bin->for flash files :)

[bogiton]

I believe we are getting close! :)
But we still need the "Atmel-DFU-Bootloader\atxmega32a4u_104_PA6.hex" file that this script requires. Have you seen this anywhere?

[iceman1001]

Found some binaries bootloader. Not PA6, but it may work anyway

AVR1916_1.zip

[iceman1001]

And a reference to srec_cat which is also used
http://srecord.sourceforge.net/

[prensel]

i have found some other documents about this regarding dfu-programmer. will look into it today. maybe by generating a modified dfu-programmer that will 'talk' to the mini that takes the plain .hex and .eep files might make it a lot easier to upload new firmware without having an external icsp.

[iceman1001]

Having a way of flashing in Linux / Windows would be great, without the need of extra hardware would be even greater!

[iceman1001]

Im stupid... if we only looked at official chameleon mini repo we would have found
https://github.com/emsec/ChameleonMini/blob/master/Firmware/Atmel%20DFU%20Bootloader/bootloader-atxmega128a4u-104-PA6-SPM.hex

[jackkleeman]

That's for the 128a4u

[iceman1001]

Aha, got the file from manufacturer, after asking for it.

RevE-atxmega32a4u_104_modified.zip

[iceman1001]

And he told me it was in the offical repo aswell.
https://github.com/emsec/ChameleonMini/blob/master/RevE/Firmware/Atmel%20DFU%20Bootloader/RevE-atxmega32a4u_104_modified.hex

Just under the >RevE< firmware. sigh

[prensel]

I've also found that file in the RevG repo under RevE :-)
But did the mfg told you what is specific about this bootloader part compared with the original one ?
It probably has to be something with timing causing the standard dfu tools to timeout during communication. Maybe I can reverse both hex files and see what their differences are.

[prensel]

Does anyone know if the RevE bootloader is using flip1, flip2, or any other protocol like avr109 ?

[icsom]

it uses avr109 - as far as I remember - it was only one which worked for me, even if it didn‘t ran on the device

…

Am 22.02.2018 um 13:36 schrieb prensel ***@***.***>: Does anyone know if the RevE bootloader is using flip1, flip2, or any other protocol like avr109 ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[iceman1001]

Just write down what you guys want me to ask the manufactur and I convey it.

[prensel]

I assume you used avr109 with an external icsp because avrdude doesnt understand what -P usb is when using avr109 as protocol ?

[icsom]

nope i- was using -p ATxmega32A4 or something similar Vom Handy gesendet Am 22.02.18 um 15:41 schrieb prensel

…

I assume you used avr109 with an external icsp because avrdude doesnt understand what -P usb is when using avr109 as protocol ? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #11 (comment)

[icsom]

pretty sure there was a X and a U and a atmega32 but don’t remember exactly - but definitely without isp Vom Handy gesendet Am 22.02.18 um 15:41 schrieb prensel

…

I assume you used avr109 with an external icsp because avrdude doesnt understand what -P usb is when using avr109 as protocol ? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #11 (comment)

[WolfgangMau]

I have to doublecheck on my other labtop ...- but my local history says I was using flip2 instead of avr109:
avrdude -c flip2 -p ATxmega32A4U -B 60 -P usb -U application:w:Chameleon-Mini.hex:i -U eeprom:w:Chameleon-Mini.eep:i
I will doublecheck in the evening ...

ok, I guess my memories are fooling me ;-)
can't replicate any success with avrdude
only thing that partially works is dfu-programmer

dfu-programmer --version
dfu-programmer 0.7.2

dfu-programmer atxmega32a4u erase
Checking memory from 0x0 to 0x7FFF...  Not blank at 0x7FF1.
Erasing flash...  Success```

dfu-programmer atxmega32a4u flash-eeprom Chameleon-Mini.eep
Checking memory from 0x0 to 0x3F...  Empty.
0%                            100%  Programming 0x40 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x400 bytes...
[ X  ERROR
Memory read error, use debug for more info.
FAIL
Memory did not validate. Did you erase?

dfu-programmer atxmega32a4u flash Chameleon-Mini.hex
Checking memory from 0x0 to 0x58FF...  Empty.
0%                            100%  Programming 0x5900 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x8000 bytes...
[ X  ERROR
Memory read error, use debug for more info.
FAIL
Memory did not validate. Did you erase?

[prensel]

I'm still on this one trying every possible combination of avrdude, dfu-programmer and even flip on windows.
Currently looking into the Lufa bootloader source files to see if anything can be found there.
If this boot_loader_exe.exe is actually based on the avrdude or dfu-bootloader there has to be some settings included in the exe as well. Maybe reversing this might shed a light on this. Next step is hooking up my ics programmer and readout the bootloader part of the flash and reverse and compare that to the standard lufa bootloader to see whats different.

[WolfgangMau]

got my ATxmega32A4U breakout board yesterday ...

so I wanted to try to get firmware running on this device.
but all I tried did not work out ...

only thing that at least seems to work:
flashing the bootloader 'RevE-atxmega32a4u_104_modified.hex' into the flash section ...
that at least makes the device get recognized by the OS (Azmel Composite Device) ...
trying tro flash this to the bootloader-section didn't work ... uploading 'ITS_A_CARD.hex', "myfile.bin', 'Chameleon-Mini.hex' or 'eep' makes it disappear from the OS again.

serval other x32a4u-bootloader, found in the internet, also work ... very strange ... but since my equipment (PDI programmer) was DIY & breadboarded ... there might be room for improvements ...

I wonder if the firmware expects any signal on a certain gpio to startup correctly, or if it should start but simply don't work correct ... because the breakout board has no peripheral devices, but I can surly fake/moc something with some arduino, pi or so, just need to know whats expected ;-)

some pictures of the mess around ;-)
https://www.dropbox.com/s/8pq4e2ah11urii2/x32a4u-breakout.jpg?dl=0
https://www.dropbox.com/s/fgnufbivjvcp8ah/RevE-Hookup.jpg?dl=0
https://www.dropbox.com/s/wwmg2o182jypruh/diy_pdi.jpg?dl=0

[iceman1001]

Wow! Great work, this will enable some linux ppl to compile/flash :)

[slurdge]

Well, I still don't completely understand how the bootloader loads the code with the "scrambling" on. Did anyone replace the default bootloader ? Or maybe I should try to decompile the AVR code (but i'm really bad at AVR assembly).

[slurdge]

Ok I did some more tests. I "decrypted" (read: use AES encryption, lol) myfile.bin and then applied the XOR on the resulting file. Results are very promising, inside the file there is this:

.d100:OK..........................e101:OK WITH TEXT................n110:WAITING FOR XMODEM..........È200:UNKNOWN COMMAND.............É201:INVALID COMMAND USAGE.......Ê202:INVALID PARAMETER...........VERSIONMY.............CONFIGMY........².¨...UIDMY.............á.¸.READONLYMY........6.'.UPLOADMY........L.....DOWNLOADMY......Q.....RESETMY.........V.....UPGRADEMY.......`.....MEMSIZEMY...........j.UIDSIZEMY.............BUTTONMY..........¢...SETTIN

So we are defintely on the good track. Only remaining question left is, who does this rolling xor ? I would bend toward the modified bootloader, but it may be somewhere in the BOOT_LOADER_EXE file that I missed. I'll try to do some more experiments!

I attached the decrypted file for everyone to look at.

myfile.decrypted.bin.zip

[slurdge]

Some more tests (also please tell me if I spam too much)!
I "crafted" a file by decrypting the official myfile.bin but keeping the rolling xor. I converted to hex format by doing:

avr-objcopy.exe -I binary -O ihex myfile.bin.dec myfile.dec.hex

The I flashed the resulting hex file with dfu-programmer.

>dfu-programmer.exe atxmega32a4u erase
Checking memory from 0x0 to 0x7FFF...  Not blank at 0x1.   
Erasing flash...  Success                                  
Checking memory from 0x0 to 0x7FFF...  Not blank at 0x7FF1.
>dfu-programmer.exe atxmega32a4u flash --force myfile.dec.hex
0%                            100%  Programming 0x5800 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x8000 bytes...
[ X  ERROR
Memory read error, use debug for more info.
FAIL
Memory did not validate. Did you erase?
>dfu-programmer.exe atxmega32a4u reset

And my Chameleon keeps working! My next step is to try to change the version string inside the binary to be sure that the flash indeed succeeded. If that's the case, then I guess all we need to flash regular images with regular tools is to create a script that does the rolling xor (very easy). It would then be compatible with the modified bootloader.

[iceman1001]

I would say that I would like to have it both in the GUI for windows ppl and python scripts for Linux ppl..

Like a create firmware script, which can be called by the flash script.

[bogiton]

That's amazing! Very good job! We should also include the steps in the Wiki! :)
So, flashing in Linux would be possible using your python scripts? Essentially creating the correct hex files given the ones produced by the compilation process of the firmware? Is it possible to integrate the encryption/decryption directly to the output hex files of the compiled source? Have you noticed if the same happens with the eep file?

[slurdge]

So, flashing in Linux would be possible using your python scripts?

I do believe so. It even doesn't need to be a python script. I did it in python because it was easy but the same effect could be achieved by regular shell code. Remember that encryption is only used for CreateBin.exe <-> BOOT_LOADER_EXE.exe "hiding", and that for the actual bootloader code, it's a light xor rolled over the whole file. So we can even put it in a makefile with enough script-fu.

Essentially creating the correct hex files given the ones produced by the compilation process of the firmware?

Yes. I did not try to flash this repository compilation result, though.

Is it possible to integrate the encryption/decryption directly to the output hex files of the compiled source?

I'm looking into it. It shouldn't be too hard as iHex files are quite easy to parse/patch.
Moreover an important detail I noticed while looking into ihex files is that the bootloader seems to be at 0x8000 address and regular code at 0x0000. This could be why you had to combine boths files. However! Notice how dfu-programmer erases only from 0x0000 to 0x7FFF. So, a little bit of a mystery for me right now.

Have you noticed if the same happens with the eep file?

Yes they to the same process indifferent from flash/eeprom file. The only difference for eeprom is they add --eeprom as a flag to the command line. I do not know the use of the eep file as of now. I never flashed mine and the board did not complain (I kept the original one). I don't know if we have to be in sync between eep and flash.

[bogiton]

@slurdge Amazing work! Looking forward to the PR. I really want to try this out later.

[Iskuri]

Just wanted to add to this as I am having similar issues, when I try to flash I get this output. Any ideas?

Creating the EEPROM binary...
Write done!

Creating the Flash binary...
Write done!

Flashing the files onto the "Chameleon-Mini Rev-E Rebooted"...
old_driver_bootloader
Erasing flash...  Success
Checking memory from 0x0 to 0x6FFF...  Not blank at 0x1.

If there are no errors above, flashing the firmware to your "Chameleon-Mini Rev-E Rebooted" should be finished now. Enjoy!

[bogiton]

@Iskuri This is not necessarily an error. Just the checking of memory fails. Is the Chameleon working after that output? Are you using the "original" BOOT_LOADER_EXE.exe and the myfiles?

[Iskuri]

Yep using all of the original stuff, and have had this procedure work before, it's possible that mine has died or is no longer writeable. It still runs but the EEPROM is all wrong and the current setting value isn't right so it can't switch between settings.

[Rickventura]

I did flash the firmware innumerable times.
I just did it to show you it's flowless. Below is a screenshot.
sudo avrdude -c flip2 -p ATXMega128A4U -B 60 -P usb -U application:w:Ch
ameleon-Mini.hex:i -U eeprom:w:Chameleon-Mini.eep:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9746 (probably x128a4u)
avrdude: NOTE: "application" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "Chameleon-Mini.hex"
avrdude: writing application (131072 bytes):

Writing | ################################################## | 100% 2.16s

avrdude: 131072 bytes of application written
avrdude: verifying application memory against Chameleon-Mini.hex:
avrdude: load data application data from input file Chameleon-Mini.hex:
avrdude: input file Chameleon-Mini.hex contains 131072 bytes
avrdude: reading on-chip application data:

Reading | ################################################## | 100% 0.61s

avrdude: verifying ...
avrdude: 131072 bytes of application verified
avrdude: reading input file "Chameleon-Mini.eep"
avrdude: writing eeprom (100 bytes):

Writing | ################################################## | 100% 0.03s

avrdude: 100 bytes of eeprom written
avrdude: verifying eeprom memory against Chameleon-Mini.eep:
avrdude: load data eeprom data from input file Chameleon-Mini.eep:
avrdude: input file Chameleon-Mini.eep contains 100 bytes
avrdude: reading on-chip eeprom data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 100 bytes of eeprom verified

avrdude done. Thank you.

[bogiton]

@Rickventura This works on the hex files using @slurdge's patcher or on the generated hex files after recompiling?

[Rickventura]

1. Use make to compile the new modified firmware. The hex file Chameleon-Mini.hex and Chameleon-Mini.eep are generated in the process.
2. after that just trigger the chameleon mini boot loader. There are two ways for that as described in
   Getting started guide https://rawgit.com/emsec/ChameleonMini/master/Doc/Doxygen/html/_page__getting_started.html.
3. with ubuntu run the command
   sudo avrdude -c flip2 -p ATXMega128A4U -B 60 -P usb -U application:w:Chameleon-Mini.hex:i -U eeprom:w:Chameleon-Mini.eep:i.
   Everything is described in the above link.
   Note: If your are using a linux release different from Ubuntu make sure you are logged in your linux system as root and run the command.
   avrdude -c flip2 -p ATXMega128A4U -B 60 -P usb -U application:w:Chameleon-Mini.hex:i -U eeprom:w:Chameleon-Mini.eep:i.

[Rickventura]

I forgot to tell that before running make you must cd to the /Firmware/Chameleon-Mini directory.
From that go through the above 3 steps.

[bogiton]

You are probably referring to the Chameleon Mini RevG, hence the ATXMega128A4U. This repo is for RevE Rebooted (ATXMega32A4U).

[Rickventura]

You are right. Sorry for the misunderstanding. I'll be more carefull next time. Il gio 11 ott 2018, 20:28 bogiton <[email protected]> ha scritto:

…

You are probably referring to the Chameleon Mini RevG, hence the ATXMega128A4U. This repo is for RevE Rebooted (ATXMega32A4U). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ApzuRwiAh2YMsZAK5ZnJ4DKpGQ8h_glhks5uj423gaJpZM4RHenq> .

[slurdge]

Re: doing work with the firmware. I found the original atxmega32a4u_104.hex file, if I flash it along the new Chamelon-Mini.hex (hence replacing bootloader), the original dfu-programmer works out of the box.

Checking memory from 0x0 to 0x60FF...  Empty.
0%                            100%  Programming 0x6100 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x8000 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
Validating...  Success
0x6100 bytes written into 0x8000 bytes memory (75.78%).

[bogiton]

@slurdge Does this mean that if we mergehex the atxmega32a4u_104.hex and the Chameleon-Mini.hex and then flash that merged hex, we will get a working RevE rebooted??

[slurdge]

Yes I believe so. At least that's what I have right now. My device still has the "can't go to bootloader by button" problem, but I believe it's unrelated. I go to bootloader through UPGRADEMY, then I can use dfu-programmer, and reset and I have an upgraded device 😄 Right now I'm looking at the differences between the two. FIY the original file was found here: https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591085

[bogiton]

That's wonderful news! I will test it on my device later today and let you know. Great find, man! :)

[iceman1001]

Excellent news!
It would be great if we could add better flashing user experience from the GUI.
If we could make a firmware / bootloader which makes it become a normal device again, where we don't have the encrypt problems. Maybe a gui button "liberate device" :)

[slurdge]

That was my initial thought! I would be so cool to have a special operation that reverts back to original bootloader.
Still, I compared the two bootloaders and there is really only a few bytes changed. So I really wonder how the strange xor operation I found previously comes from. I'm not good at AVR assembly :-(

[slurdge]

After more tries, it seems that the modified version is only related to the button functionality. Only a few address are changed and it may be related to the button correct address. I can flash with dfu-programmer both with the modified and original version. Sorry to add noise, seems we didn't advance after all. I combine the files with
srec_cat RevE-atxmega32a4u_104_modified.hex -intel Chameleon-Mini.hex -intel -o Full.hex -intel
or
srec_cat atxmega32a4u_104.hex -intel Chameleon-Mini.hex -intel -o Full.hex -intel
And flash with Atmel tools.

[bogiton]

@slurdge About the button, can't we just change the trigger code of the bootloader when the PA6 pin is pulled low?
Hmm, I just noticed this batch script: https://github.com/iceman1001/ChameleonMini-rebooted/blob/master/Firmware/Atmel%20DFU%20Bootloader/GenerateBootloader.bat
It does exactly what you tried, by using a bootloader file named atxmega32a4u_104_PA6.hex. Have we got this file anywhere? Apparently it uses the correct button pin for the bootloader triggering.

[slurdge]

Yes we have this file, it is the RevE-atxmega32a4u_104_modified.hex file. I diffed the two hex files (and started disassembly). Per the docs, the default port/pin for bootloader mode is PC3. PC3 is on port C which is 0x640. The modified hardware has the button on PA6 (seems so) and PA6 is port A which is 0x600. The diff between the two files have one important difference, where a 0x60 becomes a 0x64 and a 3 becomes a 6.
And it's consistent with my experience: the default bootloader doesn't work with the button/pin, the modified one works. So the RevE-atxmega32a4u_104_modified.hex, combined with a new user program such a Chameleon-Mini.hex, restores both the button and the dfu-programmer functionality.
Now, I stupidly erased my whole flash a long time ago, so I don't have the initial (flashed in factory) bootloader anymore. Does anyone have a dump (binary format is fine) of the original bootloader so I can compare and try to find this damn xor operation ? This would prove 3 bootloaders: original one, modified pin, modified pin+special ops for compatibility with the BOOT_LOADER_EXE.exe file.

[bogiton]

Isn't it this one here: https://github.com/iceman1001/ChameleonMini-rebooted/blob/master/Firmware/Compiled/ChameleonMiniRDV2.0_ATxmega32A4U.hex ?

[slurdge]

@bogiton I believe you are right!

[slurdge]

This 3rd file is indeed doing a xor operation related to the constants I see in CreateBin.exe (that the two others files aren't doing). I guess the "best" file to stick around is the RevE-atxmega32a4u_104_modified.hex one.

[exander77]

@slurdge Hello, where is the RevE-atxmega32a4u_104_modified.hex available?

How to flash it to replace the original bootloader?

I am trying to flash on Linux, but no luck so far.

[exander77]

@slurdge I built bootloader from sources.

Changes needed for ports & pins for rebooted are in this commit: exander77/ChameleonMini-rebooted-bootloader@0578952

IAR AVR is needed to build it, evaluation version with 4kB limit is sufficient: https://www.iar.com/iar-embedded-workbench/#!?architecture=AVR

[slurdge]

@exander77 Nice! The original modified hex is there: https://github.com/emsec/ChameleonMini/blob/master/RevE/Firmware/Atmel%20DFU%20Bootloader/RevE-atxmega32a4u_104_modified.hex

Where did you find the original source?

[exander77]

@slurdge From the Microchip Technology Inc., but finding it on their site is next to impossible, all prebuilt bootloaders for AVR including sources are available here: http://ww1.microchip.com/downloads/en/DeviceDoc/AVR1916.zip

[exander77]

@slurdge How did you flashed bootloader?