Walkera RX reverse engineering

More
19 Aug 2012 20:33 #1144 by Gall
Walkera RX reverse engineering was created by Gall
Hello,

I did very preliminary analysis of newer Walkera RX schematics.


Receiver RX2636H-D, as found on new V120D02S.
MCU: XMEGA32A4
Accelerometer MMA8452Q, I2C, at SDA/PC0 and SCL/PC1 (pins 10, 11)
Gyro ITG3205, I2C, at SDA/PE0 and SCL/PE1 (pins 28, 29)
Servos connected to:
RUDD = PE2/OC0C (pin 32)
ELEV = PD3/OC0D/TXD0 (pin 23)
AILE = PD2/OC0C/RXD0 (pin 22)
PIT = PD1/OC0B (pin 21)
THRO = PC2/OC0C (pin 12)
AUX input connected to PA5/ADC5 (pin 1)
Three potentiometers are just providing constant voltages to ADCs:
RUDD EXT = ADC11/PB3 (pin 7)
ELEV/AILE EXT = ADC10/PB2 (pin 6)
ELEV/AILE G = ADC9/PB1 (pin 5)
Dual LED is at PD4 (pin 24), red, and PD3 (pin 23), green. Active low. Green seems to be not used in stock firmware.
Dual switch is at PD5 (pin 25), unused, and PD6 (pin 26), ADJ-WK.
An unidentified unsoldered 4-pin component goes to pin 33 (PE3). Another two soldering points go to ground, the fourth pin is nc. Looks like pushbutton.
Pins 13?,14-16 (SPI) go to CYRF6936.
Telemetry not traced yet, sorry.

Receiver RX2632V-D, as found on MiniCP:
CPU: the same
Gyro: the same, but wired in place of accelerometer (10, 11)
Accelerometer: none, but empty pads for MMA8452Q. Wired to 28, 29, respectively.
Servos: pins 21-23 (same), not sure about order.
Motors: npn+pnp driver for each motor and a dual FET, PWM comes from pins 12 and 32 (like THRO and RUDD outputs above)
LEDs and switches: no switch soldered, but there's space for one. LEDs and switch swapped, PD3, PD4 (23, 24) go to switch, PD5, PD6 (25, 26) to the LED. Led is dual too, green unused, red at PD6.
Potentiometer at ADC11/PB3 (7), place for another one wired to pin 6 (ADC10/PB2)
Telemetry: motor temperature input at 43 (PA3/ADC3), similar unsoldered 2-pin input at 44 (PA4/ADC4), battery voltage at PA5/ADC5 (pin 1).
CYRF connected in the same way.

Coming soon: QR Ladybird receiver.

All receivers have power supply made from LTIZ (or similar, "PH01" on my V120, completely unreadable on MiniCP). The V120D02S has 15uH coil. They say there's 10uH coil on MiniCP (I crashed it, sorry, replaced with 10uH and it works fine). An unidentified SOT23-5 with text "L04A" (MiniCP) or "JJ-TO8" (V120D02S) then, probably an LDO. Power to the MCU comes from this chip.

Both receivers have test points at PDI_DATA and PDI_CLK.

I also tried to analyze the firmware as downloaded from Walkera. No success yet but they're definitely XORed by a random 16-byte code. First 512 (?) bytes are very similar (FFs? 00s? EEPROM?) and may be used to guess the XOR code. After unXORing, all files have many bytes matching between them. But not AVR code yet...

I think about writing a custom firmware from scratch.

Please Log in or Create an account to join the conversation.

More
19 Aug 2012 21:24 - 19 Aug 2012 21:24 #1145 by PhracturedBlue
Replied by PhracturedBlue on topic Walkera RX reverse engineering
Very cool information. I'm not very familiar with AVR programming. Is it possible to download the firmware from the device itself? Are you sure it is purely an XOR? The Devo Tx uses a partial rotate for encryption (not very secure). Each Tx model uses a different code, I'm not sure if you'll run into the same issue on the Rx. Also does the AVR have an interrupt jump table? If you have known or semi-known data it can make finding the codes easier.

Do you have a specific goal for writing a custom Rx firmware? I don't see as much benefit as for the Tx, but maybe I'm being short-sighted.
Last edit: 19 Aug 2012 21:24 by PhracturedBlue.

Please Log in or Create an account to join the conversation.

More
20 Aug 2012 07:56 - 20 Aug 2012 08:07 #1148 by wuselfuzz
Replied by wuselfuzz on topic Walkera RX reverse engineering
I had the idea to use a 3-axis stabilized walkera rx as a complete quadcopter controller, including the RX part.

Here's some hi-res images:

wuselfuzz.de/crapcopter/rx2433.png

wuselfuzz.de/crapcopter/rx2435_gyro_bottom.jpg
wuselfuzz.de/crapcopter/rx2435_gyro_top.jpg
wuselfuzz.de/crapcopter/rx2435_programming_wires.jpg (this is what I'm also currently using to dump SPI data)
wuselfuzz.de/crapcopter/rx2435_top.jpg
wuselfuzz.de/crapcopter/rx2435pins.txt

The gyros are Invensense IDG-650 and ISZ-650, connected to ADC inputs.

uC on the older RXes is an atmega48168. Interestingly, it had the whole ISP interface disabled, the controller didn't even react on a programmer attached to the ISP pins. The connections were correct, though, dumping SPI works just fine. You can do that by using a parallel programmer. Which is probably what happens in mass productions by using some spring contact header on the whole chip. I'd expect the code protection fuse set, too.

Since my UFLY did a horrible chicken dance recently, I might even take up this project again, I have another basically new RX2435 and might replace the uC on that with a non-locked atmega328.
Last edit: 20 Aug 2012 08:07 by wuselfuzz.

Please Log in or Create an account to join the conversation.

More
20 Aug 2012 09:39 #1152 by Gall
Replied by Gall on topic Walkera RX reverse engineering

PhracturedBlue wrote: Very cool information. I'm not very familiar with AVR programming. Is it possible to download the firmware from the device itself?

Not tried it yet but this is very unlikely. AVR has a read protection fuse. I don't believe this fuse is left unset.

PhracturedBlue wrote: Are you sure it is purely an XOR?

No.

But I'm sure that every *.bin file has many repeated bytes at its beginning. It is mostly periodic with 16-byte period. Assuming that the file starts with some 512-byte sparse block (most bytes either 00 or FF, only some bytes differ) I got an 16-bit XOR key. This key is different for all RXs. After XORing *.bin to this key I got a byte sequence that is very similar for all RXs. It starts around byte 512.

PhracturedBlue wrote: Also does the AVR have an interrupt jump table? If you have known or semi-known data it can make finding the codes easier.

It has but it is just table of 16-bit addresses at the very beginning. No asm commands here, so looks more like completely unknown data.

The preamble of AVR code should probably have CLI command or something like it. And there are register addresses of SPI and I2C that should be used everywhere.

PhracturedBlue wrote: Do you have a specific goal for writing a custom Rx firmware? I don't see as much benefit as for the Tx, but maybe I'm being short-sighted.

My primary goal is to be able to modify hardware.

Every Walkera RX has some unpopulated parts on the board or unused connectors. I want to use them to add extra channels for controlling navigation lights or something. Also MiniCP has no accelerometer but has place for one, what if I install one?

Also it is theoretically possible to make a multi-protocol receiver or to extend existing DEVO protocol.

Please Log in or Create an account to join the conversation.

More
20 Aug 2012 09:44 #1153 by Gall
Replied by Gall on topic Walkera RX reverse engineering

wuselfuzz wrote: I had the idea to use a 3-axis stabilized walkera rx as a complete quadcopter controller, including the RX part.

Here's some hi-res images:


Thanks!

No surprise that SPI programming is disabled. They probably use a gang programmer in mass production.

ATmega**8 should have more compicated firmware since it has less PWM outputs. More software code and more freedon.

All XMEGA receivers should be alike. I heard Blade has XMEGA too, is it right? I do not own any Blade. If so, there are chances to make "all-in-one" firmware for both newer Walkera and Blade.

Please Log in or Create an account to join the conversation.

More
20 Aug 2012 10:29 #1154 by FDR
Replied by FDR on topic Walkera RX reverse engineering
Ladybird has the XMEGA32A4 too...

I was wondering if these MCUs have enough power and outputs to handle brushless motors directly (3 outputs each) which would only required an additional power mosfet to drive each coil...

Please Log in or Create an account to join the conversation.

More
20 Aug 2012 12:03 - 20 Aug 2012 12:04 #1155 by Gall
Replied by Gall on topic Walkera RX reverse engineering

FDR wrote: Ladybird has the XMEGA32A4 too...

My Ladybird is on the way. I'll draw its schematics as soon as I receive the shipment.

FDR wrote: I was wondering if these MCUs have enough power and outputs to handle brushless motors directly (3 outputs each) which would only required an additional power mosfet to drive each coil...

Most likely yes. XMEGA has sophisticated timer and event handling circuit that allows for motor controlling without CPU usage at all.

In fact, all the servos in Walkera stock receivers are connected to PWM outputs. So in C code it takes just
SOME_PWM_REG = x;
to move a servo or change brushed motor RPM.

AFAIK, SuperFP has 5-wire servo connectors and the MCU handles servo feedback as well.
Last edit: 20 Aug 2012 12:04 by Gall.

Please Log in or Create an account to join the conversation.

More
20 Aug 2012 13:48 #1156 by PhracturedBlue
Replied by PhracturedBlue on topic Walkera RX reverse engineering

Gall wrote:

PhracturedBlue wrote: Are you sure it is purely an XOR?

No.

But I'm sure that every *.bin file has many repeated bytes at its beginning. It is mostly periodic with 16-byte period. Assuming that the file starts with some 512-byte sparse block (most bytes either 00 or FF, only some bytes differ) I got an 16-bit XOR key. This key is different for all RXs. After XORing *.bin to this key I got a byte sequence that is very similar for all RXs. It starts around byte 512.

Well, the Devo uses a conditional rotate (if bytes are within a certain range, then rotate them by 6/7/8/10/12 positions depending on Tx). If they combined something like that with an XOR, you could find the base key and still not have valid AVR code. However, the scheme they used on the Devo left us with a lot of code intact which made it easy to figure out the rotate code. That is why I asked about the vector table. Often all of the unused ones will point at the same address which makes for a nice repeating patern of a semi-known value (must be in the code space)

Please Log in or Create an account to join the conversation.

More
20 Aug 2012 13:57 - 20 Aug 2012 14:00 #1157 by Gall
Replied by Gall on topic Walkera RX reverse engineering
If they're using two-stage obfuscation, the code for the 2nd stage seems to be the same for all models. At least after XOR all the files look very similar:

MiniCP:
97 51 A4 0E A1 AD A7 0E E3 F0 B5 2B DE 1B B4 2B ... 04 60 92 C0 ...

V120D02s:
97 51 A4 0E A1 AD A7 0E E3 F0 B5 2B DE 1B B4 2B ... FB 9F 6D 3F ...

And there are parts like insertions - the same byte sequences are shifted.

I think the only advantage of decrypting this is the ability to encrypt our own firmware for the stock bootloader. And the ability to flash the stock firmware back after playing with custom firmware.
Last edit: 20 Aug 2012 14:00 by Gall.

Please Log in or Create an account to join the conversation.

More
01 Feb 2013 07:57 - 01 Feb 2013 12:42 #5877 by RW9UAO
Replied by RW9UAO on topic Walkera RX reverse engineering
have one more things. i take compiled code for xmega32a4 and New120D02S_V1.bin
first bytes is a JMP interrupt table. i compare both and generate XOR sequiens. it have strange error, after decoding JMP table look good, but code messy. need more calculating. files:
#include <stdio.h>
void main(void){
FILE *fp_input, *fp_output;
unsigned char buffer[16];
//for http://www.walkera.com/en/upload/helicopter/New120D02S_V1.zip
unsigned char XOR[16]={0x89, 0xc7, 0x26, 0xb4, 0xdf, 0x65, 0x26, 0xa1, 0xb7, 0xca, 0x5f, 0x0c, 0x70, 0x33, 0xb9, 0xba};
int i, c;

fp_input=fopen("input.bin", "rb");
fp_output=fopen("output.bin", "wb");

for(i = 0; i < 1590; i++){

	fread(buffer, sizeof(buffer[0]), 16, fp_input);
	for(c = 0; c < 16; c++){
		buffer[c] ^= XOR[c];
	}
	fwrite(buffer, sizeof(buffer[0]), 16, fp_output);
}

fclose(fp_input);
fclose(fp_output);
}
add: true XOR key for new v120d02s heli (RX-2636H-D)
add2: link to a russian forum with details www.rc42.ru/forum/4-720-20688-16-1359720834
sorry, russian letters only.
Last edit: 01 Feb 2013 12:42 by RW9UAO.

Please Log in or Create an account to join the conversation.

More
16 Feb 2013 05:36 #6425 by bityfne
Replied by bityfne on topic Walkera RX reverse engineering

Gall wrote:
AUX input connected to PA5/ADC5 (pin 1)


hi all, i googled to the best of my ability and could not find what the 5th AUX port is for. i've found only 2 mentions of it, here being 1. i'm not an engineer, obviously, i'd be very grateful if one of u guys would help me out.

Please Log in or Create an account to join the conversation.

More
04 Mar 2013 11:13 #7325 by Hexperience
Replied by Hexperience on topic Walkera RX reverse engineering

Gall wrote: If they're using two-stage obfuscation, the code for the 2nd stage seems to be the same for all models. At least after XOR all the files look very similar:

MiniCP:
97 51 A4 0E A1 AD A7 0E E3 F0 B5 2B DE 1B B4 2B ... 04 60 92 C0 ...

V120D02s:
97 51 A4 0E A1 AD A7 0E E3 F0 B5 2B DE 1B B4 2B ... FB 9F 6D 3F ...

And there are parts like insertions - the same byte sequences are shifted.

I think the only advantage of decrypting this is the ability to encrypt our own firmware for the stock bootloader. And the ability to flash the stock firmware back after playing with custom firmware.


Gall, were you thinking to create a new bootloader or use the stock one? Are you still looking at this project? I'd like to see added functionality on the 2703h-d as well and I'm very interested to see how you guys make out on this.

Cheers

There are 10 types of people in this world. Those that understand binary and those that don't.

Please Log in or Create an account to join the conversation.

More
04 Mar 2013 12:22 #7326 by Gall
Replied by Gall on topic Walkera RX reverse engineering
Yes. Unfortunately I'm very short of time. But at least I don't like "magic numbers" in the code, so everything that is not documented should be rewritten...

Please Log in or Create an account to join the conversation.

More
13 Mar 2013 00:57 #7666 by RoGuE_StreaK
Replied by RoGuE_StreaK on topic Walkera RX reverse engineering
As it seems semi-relevant to this thread, just wondering if anyone knows if channel 5 is used/available in any way on the Walkera FBL RXs? ie. in Hexperience's FBL Setup guide it says that channel 5 is unused, and that the gyro setting is on channel 7; does that mean it's essentially just a 6ch receiver, or is it really 7ch (or more) but with a blank channel for some reason?
I haven't found any reference anywhere online as to what is happening with this "missing" channel. Would be interesting if there's a pinout just sitting there waiting to be tapped.

Please Log in or Create an account to join the conversation.

More
13 Mar 2013 05:26 #7670 by FDR
Replied by FDR on topic Walkera RX reverse engineering
They use ch5 for the gyro when the number of channels is 6, for example in case of the DEVO 6.
AFAIK deviation now always reports/sends at least eight channels, so we have the gyro channel on ch7...

Please Log in or Create an account to join the conversation.

More
26 Apr 2013 09:09 #9220 by richardclli
Replied by richardclli on topic Walkera RX reverse engineering
Actually, I think of one interesting point in writing the RX firmware. That is to build a RX with telemetry function together in a small form factor. Just only I/O codes needed, no need the codes for balancing a helicopter. I think this should not be difficult anyway.

Please Log in or Create an account to join the conversation.

More
26 Apr 2013 10:42 - 26 Apr 2013 10:43 #9225 by Hexperience
Replied by Hexperience on topic Walkera RX reverse engineering

richardclli wrote: Actually, I think of one interesting point in writing the RX firmware. That is to build a RX with telemetry function together in a small form factor. Just only I/O codes needed, no need the codes for balancing a helicopter. I think this should not be difficult anyway.


Yes, that would be a great thing to do. I still hope Walkera comes out with a third generation RX with at least 1 analog telemetry line. All I really need on 90% of my planes and helis is the flight pack voltage.

As far as the codes for balancing the heli, what I'm looking for is simply the ability to alter the values of the existing firmware. For example the RX2703h-d is a very nice 6 axis gyro/rx but if you want to change something such as the tail stop speed you can't. Total pie in the sky wishes I know, but after using the tarot zyx and the pc software I dream of the same thing for the Walkera RX/Gyros.

I know that simply hacking the existing firmware is not exactly the mission statement of this web site... ;) But if anyone has any ideas for custom firmware on the RX, it's this group of guys...

There are 10 types of people in this world. Those that understand binary and those that don't.
Last edit: 26 Apr 2013 10:43 by Hexperience.

Please Log in or Create an account to join the conversation.

More
07 May 2015 14:38 - 07 May 2015 17:45 #32211 by moss
Replied by moss on topic Walkera RX reverse engineering
"... An unidentified SOT23-5 with text "L04A" (MiniCP) or "JJ-TO8" (V120D02S) then, probably an LDO. Power to the MCU comes from this chip. ..."
www.ti.com/lit/ds/symlink/lp2981-n.pdf <-- L04A
My broken (V120D02S) receiver has a "DX=712". Likely a 100mA 3.3V LDO. Pin-out is the same as LP2981-n, and many other fixed output LDOs. Current rating is related to heat generation. As these regs "burn up" excess voltage, heat-sinking is closely related to current capacity.
Temp rating is important for these guys as they may run hot with high input voltage.
Last edit: 07 May 2015 17:45 by moss.

Please Log in or Create an account to join the conversation.

More
17 Nov 2018 18:26 #71779 by galaxy76
Replied by galaxy76 on topic Walkera RX reverse engineering
Hi, I have a problem with an RX2636H-D receiver (Walkera V120D02S). I am very fond of this helicopter and have been flying there for years. Unfortunately, suddenly it does not bind to TX. The LED on the RX2636h-d flashes slowly as when the ID is cleared. It stays like this and the servo elevator seem crazy. they move without reason. I have not had any crashes. the defect began little by little. first the elevator servo went to the end of the stroke. then sometimes the bind with the TX was canceled, but after removing the battery and connecting it again, everything seemed to work. now it is no longer possible to establish a link with the TX. I would like to understand if the problem is to be found in some components such as a capacitor, or the processor xmega32a4 has been damage. I tried to put the firmware back, but it gives me a connection error.
I'm good at welding in SMD, but I do not understand much about software. I'm almost sure that the PD3 port (pin23) is damaged.

For example, could I buy an atmel xmega32a4 and replace it with the faulty one? and then flash the firmware? I suppose the bootloader is also necessary? Where can I find?
I'm sure you can help me.

Please Log in or Create an account to join the conversation.

Time to create page: 0.334 seconds
Powered by Kunena Forum