flashing problem

[bogiton]

Has anyone managed to flash the compiled eep/hex files successfully onto the Chameleon?

If I run the ChameleonFirmwareUpgrade.bat script, while being in bootloader mode, I keep getting the following:

Checking memory from 0x0 to 0x7FFF...  Not blank at 0x1.
Erasing flash...  Success
0%                            100%  Programming 0x20 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?
There was an error with executing this command. Maybe your ChameleonMini is not in bootloader mode?

If I try to add the --suppress-validation argument to dfu-programmer.exe the process seems to be finishing without errors, but the result is a dead Chameleon. And then, the only way to revive it is by running the supplied "BOOT_LOADER_EXE.exe" which displays the following:

old_driver_bootloader
Erasing flash...  Success
Checking memory from 0x0 to 0x6FFF...  Empty.
0%                            100%  Programming 0x20 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x400 bytes...
0%                            100%  Programming 0x5800 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x7000 bytes...
load_success!

[iceman1001]

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

[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

[ghost]

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]

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

[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 ;-)

[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?

[slurdge]

@exander77 I flashed with a special hardware... Actually I'm still working on it, my goal would be to have a future proof method of "unlocking" the firmware. It was near what you did in the other thread. My basic assumption is that you should merge (or not, program data is not important at that point) program and bootloader (which is at the end), scramble, then force upload. It should unlock the bootloader with a correct version, from that point, I could flash without encrypting/scrambling etc. But the unlock part was done with a AVR mkII programmer.

[exander77]

@slurdge Do you have the pinout to flash through the programmer?

[slurdge]

Yep see here: https://github.com/iceman1001/ChameleonMini-rebooted/wiki/How-to-program-with-AVRISP-mkII

[securechicken]

@slurdge, @exander77 - it seems like tremendous discover here.
If I get it well, it sums up as:

• the original bootloader in RevE is somehow an Atmel-provided ATxmega32A4U DFU USB bootloader source, with changed default ISP I/O pining (PORTA instead of PORTC, and PIN6 instead of PIN3), and which is then patched, using GenerateBootloader.bat ;
• the resulting original compiled RevE bootloader is ChameleonMiniRDV2.0_ATxmega32A4U.hex provided in this repo;
• the compiled Atmel-provided ATxmega32A4U DFU USB bootloader source, with ISP I/O pining adapted for RevE, as it is supposed to be fed in GenerateBootloader.bat, is found as RevE-atxmega32a4u_104_modified.hex in emsec Chameleon-Mini repo. It would have to be renamed as atxmega32a4u_104_PA6.hex to work with GenerateBootloader.bat;
• we can access, and compile, the Atmel-provided ATxmega32A4U DFU USB bootloader source. Source is packed in ZIP file in this page from Atmel technical support centre. The source is originally attached to a Document of type "Application Note", called "Atmel AVR1916: USB DFU Boot Loader for XMEGA", which is notably linked in ATxmega32A4U product page;
• @exander77 already modified Atmel-provided ATxmega32A4U DFU USB bootloader source to reflect RevE non-default ISP I/O pining, in this commit from his repo.

So again, if I get it well and due to all this, we could probably do as follow to flash a Atmel-provided ATxmega32A4U DFU USB bootloader source to RevE (with tuned PINing), and get a fully unlocked RevE:

• scramble RevE-atxmega32a4u_104_modified.hex with crypto_operations.py from @slurdge in this repo: python3 ./Software/Tools/crypt_operations.py scramblehex RevE-atxmega32a4u_104_modified.hex RevE-atxmega32a4u_104_modified.hex.scramble
• flash the scrambled boot loader with dfu-programmer: sudo dfu-programmer atxmega32a4u erase --force; sudo dfu-programmer atxmega32a4u flash --eeprom --force --suppress-validation .RevE-atxmega32a4u_104_modified.hex.scramble;
• then start flashing any bootloader and firmware we want with regular dfu-programmer, without any scrambling and so.

And voilà?!

[slurdge]

@ShinHub , unfortunately, the bootloader isn't self-programmable as far as I know. So you would only program the bootloader into the program section of the device itself.
What you would need is a way to convince the initial bootloader to leave some "thing" unlocked. I didn't have the time to fully look into it, but it seems that the bits needed in order to be able to flash the bootloader are locked out.

[securechicken]

Sh*t. I will try however, in the name of science, and because I feel not skilled enough to diff AVR hex files.

[iceman1001]

ok, time to close? this issue is more of a documentation thing now.
Has the wiki been updated with all that is new and relevant from @slurdge @ShinHub @bogiton
then I will close this.

[securechicken]

@iceman1001 I created a page for the summed up info on bootloader.

[tjt263]

so what was the final solution here?

[slurdge]

Look at the wiki, for example https://github.com/iceman1001/ChameleonMini-rebooted/wiki/Flashing-Linux-(Unix)#flashing-the-reve-rebooted-device

[iceman1001]

For the sake of your own sanity, may I suggest you find your way in the discord server found here https://discord.com/invite/QfPvGFRQxH

[iceman1001]

Bye bye, Enjoy your ban.

[exander77]

@bjenky

I have spent almost 1000$ trying to get the machines you promote to work and they haven’t done anything but stress me out and make me lose sleep.

Who promotes anything, you tard? This is Github and OpenSource project that targets these machines. But if you pay me 1000$, I will flash your machine myself. :D

I really am at the bottom of my rope and I really have been up for days trying to get “your” products working.

Wtf, is wrong with you?

[iceman1001]

@exander77 leave it be. This is closed.

[exander77]

@iceman1001 Sorry, I had a lot of spam from this thread, so I at least reacted.