Author Topic: XMEGA32A4 - Monitoring RX TX - Extracting or flashing firmwar  (Read 977 times)

0 Members and 1 Guest are viewing this topic.

Offline TantratronTopic starter

  • Frequent Contributor
  • **
  • Posts: 413
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Hello community, attached a picture of a power amplifier being controlled by XMEGA32A4

There is a 24 Vdc bus from which 3.3 Vdc bus is generated to power the XMEGA32A4 and other circuits. There is only a telecom interfacing bus (RX TX GND and 3.3 Vdc) as UART which can connected to UART-USB transceiver or for example, the RX-TX of an arduino DUE board..

The only way to get the equipment running is shorting RX with TX so stand alone mode.

I was told that it is possible connect the RX-TX to a computer which would put the internal firmware to run (like ON OFF) as well as read some internal parameters (temperature, frequency, power...) being computed inside the equipment.

Is there a simple way if connecting an arduino DUE board RX TX to simulate the ON OFF or extract the XMEGA32A4 firmware (assembly code) in order to understand its protocol ?

Any suggestions are more than welcome.

Thank you, Albert

 

Online T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 22436
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: XMEGA32A4 - Monitoring RX TX - Extracting or flashing firmwar
« Reply #1 on: July 27, 2024, 11:12:14 am »
Which is what, orange TXD, blue RXD?  Maybe others, there's a lot of USARTs on the XM/A4.

Datasheet: https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8069-8-and-16-bit-AVR-AMEGA-A4-Microcontrollers_Datasheet.pdf



PDI pins taken out to test points so if there's any snooping around of firmware, it's through here.  Interface is simple enough, any classic AVR programming adapter I think will suffice, even AVRISPMKII supports PDI.  Device may be locked, in which case there's a hacking process to *maybe* read it out anyway.  Whatever stimulus the pins are looking for, or what console if any is present, and in what format, you're completely on your own.

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 
The following users thanked this post: Tantratron

Offline TantratronTopic starter

  • Frequent Contributor
  • **
  • Posts: 413
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: XMEGA32A4 - Monitoring RX TX - Extracting or flashing firmwar
« Reply #2 on: July 27, 2024, 11:34:56 am »
Hello Tim,

Attached the datasheet of the telecom interface, note the board is part of a RF plasma lighting system but we can ignore the 0-10V dim and the Occupancy sensor signal. What really is of interest is to first understand how to emulate the RX-TX bridge by software then see how to pool or observe any additional parameters sent by the board but I don't know the protocol structure.

Do you think that by programming an arduino DUE it is possible to read the AVR assembly program stored inside the chip by connecting the BLUE and ORANGE signals in the connector ?

Albert
 

Online T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 22436
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: XMEGA32A4 - Monitoring RX TX - Extracting or flashing firmwar
« Reply #3 on: July 27, 2024, 12:48:44 pm »
Do you think that by programming an arduino DUE it is possible to read the AVR assembly program stored inside the chip by connecting the BLUE and ORANGE signals in the connector ?

Do I think that by programming an Arduino Due it is possible to solve the Riemann hypothesis?

Beats the hell outta me.

Understand what you're asking:
- You haven't presented any evidence about what these pins do.  They're named suggestively, but that doesn't mean they are used that way, or are at all times.  All *I* see are a couple traces on a PCB.  I don't have a clue what you know about this thing so far, and I certainly can't (and, without a budget, won't) figure that out for you.
- I see the pins are wired to a well-known MCU, cool. So what are they doing with them?  Are they GPIO sometimes?  USART exclusively?  What baud?  What encoding?  Is it binary or ASCII?  What is the command set?  etc. etc. etc.  There are limitless possibilities here.
- If it is a command interface, can those commands be used to exact desired control over the device?  Or to extract firmware, or other hacking-related goals?
- If not, can those commands be abused, discovering bugs in the interface? Are there parsing errors, buffer overruns, ACE exploits, etc. possible?
- If so, can enough bugs be harnessed to develop those hacking-related goals?

In the extreme, the control might be programmed to respond perfectly to the longest possible sequence expressible on the platform, i.e. enumerating a recursive sequence requiring a few kB of state (more if external memory is present, or EEPROM and Flash are used).  This will take approximately until the heat death of the universe to explore; good luck!

Or perhaps they've locked it with such a sequence that effectively encodes the solution to an otherwise-currently-unsolved mathematical problem, such as I alluded to above.  In which case, we literally cannot know at present whether such a thing is even provable, let alone in the affirmative.

In short, you're potentially asking for the solution to, if not the entirety of Computer Science as we know it, then at least whatever subset of the field fits within the chip in question -- while having given absolutely nothing to even start from.

I think you should appreciate, now, how unrealistic that question was.

Now, I don't say this to embarrass*.  And I don't say this as a dismissal.  (If I didn't care about this thread, I simply wouldn't respond.)  I say this, because I see a learning opportunity.  I see that something has gone amiss, that has led to a question this far out of proportion.  And I see a chance, perhaps, to address the situation.  And, I don't know you, I don't know your situation -- maybe this was a hasty question, maybe it was just sent without thinking about it much, a throwaway; maybe you're generally under stress and haven't thought about it clearly, maybe you lack background on these topics and don't understand quite what you're asking -- and I'm not calling out any of these possibilities, it all happens to us at some point or another, there's way more things out there to study than can fit within a single lifetime, and life is full of stresses, whether physical or mental.

*Well, any more than necessary: occasionally, a shock is necessary to rouse the mind, but one must be careful not to overdo it and induce paralysis instead.  Maybe I've gone well past that point already... unfortunately, I don't really know.

But such is life. In the process of studying, we can prioritize and select topics useful and important to us.  If this be the gap here -- I would just kindly suggest asking about the basics first: what about this thing don't you know, what would be useful to know, and starting from there.  It's okay to tell us about where you're coming from, what you know, what you want to do.  And it helps us help you: we can better answer questions, when we know what level of complexity to write within.  Don't ask about something you (again, perhaps) don't understand -- but absolutely do ask about what you need to know to understand it, build up to it.

Cheers,
Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline TantratronTopic starter

  • Frequent Contributor
  • **
  • Posts: 413
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: XMEGA32A4 - Monitoring RX TX - Extracting or flashing firmwar
« Reply #4 on: July 27, 2024, 01:12:26 pm »
Hello Tim (T3sl4co1l - TeslaCoil)  ;D

I repeat my simple question, is it feasible to extract or read the stored software inside a XMEGA32A4 through the RX and TX pins.

Maybe I'm wrong of course, my assumption was that RX and TX signal pins were used for (1) the protocol communication (UART) and (2) used to flash the firmware.

Otherwise could you point to an easy tutorial explaining how a developper does program (upload) such chip and eventually how is it possible to extract (download) the firmware which was flashed in the first place.

Thank you from France, sorry I'm not english fluent

« Last Edit: July 27, 2024, 01:16:54 pm by Tantratron »
 

Offline TantratronTopic starter

  • Frequent Contributor
  • **
  • Posts: 413
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: XMEGA32A4 - Monitoring RX TX - Extracting or flashing firmwar
« Reply #5 on: July 27, 2024, 02:15:12 pm »
The other question which I want to learn and understand.

Many times I've seen boards with RX and TX where the board is running fine by physically wiring or bridging RX-TX so RX = TX. If RX and TX are not connected, the board will boot but stay waiting and doing nothing.

What simple software routine interface could I write (i.e. arduino DUE or arduino MEGA via one of its RX-TX pins connected to the board discussed in this thread) to emulate or make think the  RX and TX are connected or mirrored ?

Thank you in advance for your time, Albert
 

Online T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 22436
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: XMEGA32A4 - Monitoring RX TX - Extracting or flashing firmwar
« Reply #6 on: July 27, 2024, 02:51:35 pm »
You must've missed why I circled the pads in the image.  If you read the device datasheet (linked), you will find the chip uses the "PDI" protocol for programming.  You need only connect these pins to a programming adapter to further investigate the device.

What method you use to obtain such a programmer, is up to you. Perhaps there is an Arduino version you can use with your board, if you must.  Most likely you will need the AVRDUDE tool as well.

Again, regarding your question: it is impossible to know whether it is feasible.  It might be trivial, or it might be physically impossible.  I doubt AVRs are so secure for the latter to be true, but proving so is a very different matter.

The most basic start would be probing with an oscilloscope or logic analyzer.

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline TantratronTopic starter

  • Frequent Contributor
  • **
  • Posts: 413
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: XMEGA32A4 - Monitoring RX TX - Extracting or flashing firmwar
« Reply #7 on: July 27, 2024, 02:57:50 pm »
Ok many thanks Tim where I've checked now with lens and concentration the traces in that zoning, so indeed the test points TP16 and TP17 are for PDI (Programming Debugging Interface) as you taught me.

As for the RX-out (orange wire) and TX-in (blue wire), they are respectively connected via some passive components to PD3 and PD2 of the XMEGA32A4..

So whatever I could expect to say extract or read the firmware, it will be only through TP16 and TP17.

I'll first try to use my SALEAE Logic analyzer to observe RX=TX sequence then what happens when RX and TX not connected.

Albert
 

Offline TantratronTopic starter

  • Frequent Contributor
  • **
  • Posts: 413
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: XMEGA32A4 - Monitoring RX TX - Extracting or flashing firmwar
« Reply #8 on: July 27, 2024, 04:35:30 pm »
PDI pins taken out to test points so if there's any snooping around of firmware, it's through here.  Interface is simple enough, any classic AVR programming adapter I think will suffice, even AVRISPMKII supports PDI.  Device may be locked, in which case there's a hacking process to *maybe* read it out anyway.  Whatever stimulus the pins are looking for, or what console if any is present, and in what format, you're completely on your own.

I now start to understand what you meant about PDI programming by reading this article https://microchip.my.site.com/s/article/How-to-program-an-AVR-Microcontroller, in particular near the end this sentence... PDI programming: PDI is the new two-wire proprietary debug interface for ATxmega devices. It can download code into the flash application and boot memories, EEPROM memory, fuses, lock-bits, and signature information. A minimum of four wires is needed to connect the AVR debugging Tool to the target board using the PDI interface. These signals are Vcc, GND, DATA, and CLK. The CLK line is driven by the debugging tool and the DATA line carries half-duplex communications between the debugging tool and the target.

Note that I use MacOS system to do most stuff in my lab (arduino, GPIB...)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf