Unbrick Yuneec camera using AmbaUSB tool

h-elsner · Monday at 10:22 AM

I'm trying to unbrick a CGO-ET from H520. The camera stuck in initialization, front LED remain white. The WiFi module which is often the reason for this behavior works in other cameras. It looks like the main board with the Ambarella chip has some problems. @Enrico Jorysch told me that there is a tool for this processor: AmbaUSB.
I found this tool here: http://pc.cd/iap7

Also I got the settings for some Yuneec cameras:

CGO3+, CGO-ET (H480), CGO-ET (H520) and possibly E50 have the same mainboard CGO3+_MB_V2.1.
Finally I got connection to the camera but a FW update was not possible. It flashes some parts but the firmware.bin file was not taken, it leads to timeout.

It looks like the tool don't like *.bin files and requests *.elf files. I found some .elf files for Yuneec cameras but none for E50, CGO3+ or CGO-ET.

Question: Has someone some ELF files with firmware for the CGOxx camera family? An ELF file contains the bin file and some more information for the FW.

Vaklin · Wednesday at 5:49 AM

I have a CHO4 camera, which stops on the middle of the startup sequence. The Android CGO4 says that something should be uploaded to the camera, but after that the problem still persists.
Is the CGO4 in the same line, which can be maintained with the discussed tool?

h-elsner · Wednesday at 8:37 AM

CGO4 is a Pansonic Lumix camera (I believer GH4). I don't know what video processor it has but I doubt that it is an Ambarella chip.

Vaklin · Wednesday at 10:56 AM

Try this:

https://dzone.com/articles/converting-a-raw-binary-file-into-an-elfdwarf-file

h-elsner · Wednesday at 4:02 PM

Vaklin said:
Try this:
https://dzone.com/articles/converting-a-raw-binary-file-into-an-elfdwarf-file

Thank you very much. This is a good hint. In a first step I could create an ELF file from CGO3+ FW. Hopefully it will be accepted.

The result is as following:

Code:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           None
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          57864524 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         5
  Section header string table index: 4

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .data             PROGBITS        00000000 000034 372f014 00  WA  0   0  1
  [ 2] .symtab           SYMTAB          00000000 372f048 000040 10      3   1  4
  [ 3] .strtab           STRTAB          00000000 372f088 0000a0 00      0   0  1
  [ 4] .shstrtab         STRTAB          00000000 372f128 000021 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), p (processor specific)

There are no section groups in this file.

There are no program headers in this file.

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type None is not currently supported.

Symbol table '.symtab' contains 4 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 NOTYPE  GLOBAL DEFAULT    1 _binary_cgo3_gb_[...]
     2: 0372f014     0 NOTYPE  GLOBAL DEFAULT    1 _binary_cgo3_gb_[...]
     3: 0372f014     0 NOTYPE  GLOBAL DEFAULT  ABS _binary_cgo3_gb_[...]

No version information found in this file.

Enrico Jorysch · Wednesday at 4:30 PM

h-elsner said:

Thank you very much. This is a good hint. In a first step I could create an ELF file from CGO3+ FW. Hopefully it will be accepted.

The result is as following:

Code:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           None
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          57864524 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         5
  Section header string table index: 4

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .data             PROGBITS        00000000 000034 372f014 00  WA  0   0  1
  [ 2] .symtab           SYMTAB          00000000 372f048 000040 10      3   1  4
  [ 3] .strtab           STRTAB          00000000 372f088 0000a0 00      0   0  1
  [ 4] .shstrtab         STRTAB          00000000 372f128 000021 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), p (processor specific)

There are no section groups in this file.

There are no program headers in this file.

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type None is not currently supported.

Symbol table '.symtab' contains 4 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 NOTYPE  GLOBAL DEFAULT    1 _binary_cgo3_gb_[...]
     2: 0372f014     0 NOTYPE  GLOBAL DEFAULT    1 _binary_cgo3_gb_[...]
     3: 0372f014     0 NOTYPE  GLOBAL DEFAULT  ABS _binary_cgo3_gb_[...]

No version information found in this file.

I'm curious to see what happens, so I'll be reading along

h-elsner · Thursday at 3:52 AM

The result reading an original ELF file is a bit different (it has a far more debug info available):

h-elsner · Thursday at 4:05 PM

With the the ELF file converted from cgo3+gb_3.2.34_LC2_A_firmware_30234.bin the Timeout problem disappeared but the ELF file itself was not accepted.
Error message:
2026-06-04-21:51:32.649: amba_elf.cpp[ 404]: cgo3+gb_3.2.34_LC2_A_firmware_30234.elf is not ARM ELF: 0!
2026-06-04-21:51:32.661: amba_elf.cpp[ 996]: Failed loading file cgo3+gb_3.2.34_LC2_A_firmware_30234.elf
2026-06-04-21:51:32.698: amba_usb_firmware_session.cpp[ 110]: cgo3+gb_3.2.34_LC2_A_firmware_30234.elf is an invalid ELF file!
The whole protocol is attached.

For now I give up.

Vaklin · Thursday at 6:35 PM

Try with ChatGPT.
Explain the problem. Give the first few kB from the bin, and so on.
It can disassemble them and to see what is inside and where probably should be stored.
In A7/A9 processors some loader.elf is used often.

Vaklin · Thursday at 6:43 PM

Also vid/pid, some sniffed communication between the tool and the camera. The first important step is to resolve the expectations of the tool and the camera.

Vaklin · Thursday at 6:45 PM

And the last. The bin file is probaly a linux like structure. An overall view with a hex editor can give something too.

h-elsner · 2026-06-06T07:17:56-0400

Together with @Enrico Jorysch we have finally found a way to unbrick the CGO-ET that I have on the table. It is a camera used by a fawn rescuer I want to support as godd as possible (I'm too lazy to stand up early in the morning to looking for those sweet animals before the get mowed away. So, I help with tech support).

It works only with Windows. Download and install 64bit version of AmbaUSB tool found here: http://pc.cd/iap7
Procedure tested with a CGO-ET of H520.

Connect the camera to USB with the USB port on the camera. Start AmbaUSB tool. Hold the tiny button near the USB port on the camera down and power it on. Hold the button until the gray arrow at the AmbaUSB tools go blue.
Settings are S2E.DDR3.EMMC as config and S2E (A9s) as Cip Filter. The FW file I have used is an official ELF file called "ETX_0.2.22_A.elf" (Ithouht it is for E10T but ...). Hit the blue arrow andwait until upload was successful.
After that the WiFi was back to work but the camera was not rcognizedby the the H520. Video stream was there but no thermal stream.
Next step was to prepare a SD card with CGO-ET firmware for H520(CGO-ET v2.34_A_H520).Rename the file to "firmware.bin" and copy it to an empty SD card. Put the SD card in the camera and power it on. Surprise: FW upgrade will start as usual (front LED blinking purple). After FW update the camera was accepted as CGO-ET and all works perfectly.

Conclusion:
If the camera stuck in initialization (Front LED remains white forever) and the exchange of the WiFi module isn't working then the camera main board is bricked. In this case a try to unbrick it with AmbaUSB tool is worth to do.
Unbrick a Yuneec camera with the official ELF files is possible in this case. Currently not tested with CGO3+ but works surprisingly with CGO-ET from H520 with a possibly not matching ELF file.

DoomMeister · 2026-06-06T08:42:59-0400

Fantastic job figuring this out and repairing a camera in support of a worthy cause!

It would really be nice if a contact within the old Yuneec organization would work with us to supply the files and apps needed to keep our legacy equipment up and running. Those of us using this equipment are not in the market to buy the newer and vastly more expensive systems they are designing and selling today.