Need help with DFU creation

Today, the only way to install Deviation is with the Walkera DFuSe tool. This is not-ideal for Mac/Linux users. the reason is that the Walkera DFuSe tool modifies the dfu file before transmitting it, and I'm trying to understand how that is done. I have a feeling that it is not static per-model, but instead is unique to every Tx.

I need more samples from Devo6, Devo8, or Devo10 radios to make sense of it.

What I need are USB traces of uploading a DFU file.

In WinXP I used to use usbsnoop:
www.pcausa.com/Utilities/UsbSnoop/
But it does not work in Win7

In Win7, it is theoretically possible to use logman:
blogs.msdn.com/b/usbcoreblog/archive/200...-usb-core-stack.aspx
But while I could capture the logs, I couldn't seem to capture the actual data transfer (which is what I need)

In the end, I used the demo version of USBTrace:
www.sysnucleus.com/usbtrace_download.html
which worked fine on my Win7 x-64 machine

You could also, likely use Wireshark in Linux running a Windows virtual-machine, though I didn't get around to trying that.

I would like a couple of folks who can install a usb snooper to capture the start of the dfuse tool (Tx in program mode, and plugged in, start DFuSe tool), and the installation of a dfu file (Upgrade).

I recommend taking a snapshot before installing a usbsnooper, as it is theoretically possible for it to mess up USB detection if something goes wrong.

The problem is that the logman logs don't seem to provide the actual data in the packet. There should be 1024bytes per packet during transfer, but I don't see that data in the .cap file.
the linux logs look ok (though there are no data packets in the initialization (that is expected), and if I recall I had a similar issue with linux truncating the data when I used it way back when)

Anyhow, with more investigation, I think the changes added by DFuSe are actually based on the contents of the firmware, not the Tx, so If I can figure out which bytes are used to compute the modified 'checksum' I'll be one step closer. It also means I probably don't need any more log captures at this time.

Thanks. I think I found the 'key' I need. It appears that it is transmitter specific.
Every tranmsitter has a unique serial number (in the MCU), and this is the value that is used to build the final DFU sent to the transmitter.

I'm not sure exactly why they do this except to ensure that the transmitter can only work in conjunction with the Walkera Dfuse tool. It does not in any way that I see help to secure their firmware (indeed we've been loading Deviation onto radios for 6 months without being aware of anything more than a keep-out region)

They use a different algorithm for each model, but the math is relatively simple. Again, I have no idea why they bother with all of this.

Tom_ate wrote: I have the same opinion as PB wrote earlier int this threat: With this checksum they have done nothing to securve writing to the TX - they have done it to prevent that the TX is written to with anything else than their own Dfuse-tool.

The thing I don't understand is why they went as far as they did. Ensuring only their dfuse tool could write to the Tx would have been very simple: change the dfuse format slightly. Instead you have a unique ID and different algorithms for different models. The latter could be useful to prevent loading a devo8 firmware onto a devo10, but since it is rebuilt by dfuse every time you load, you lose any such benefit.

There are a lot of 'security' measures in the Devo (like scrambling the DFU) but it turns out that every single one is poorly implemented (which is a good thing for us, as otherwise, the effort to install Deviation would be much higher)