EEVblog #1144 - Padauk Programmer Reverse Engineering

[ataradov]

It usually ends up being more hassle than benefits for a tech company.

Tell that to Espressif. They were hiding stuff at first too, and then they quickly realized the power of the passionate community.

[drussell]

Adding support for  universal programmers like TL866 can help sell tons of 3cent microcontrollers.

No, it won't.  People don't one-off program things like this except in development and prototyping.  These are the kind of chip that you order by the thousands, pre-programmed with whatever code you need for your application.  99.9999% of these chips sold need to be programmed at high speed, in bulk, not one-offs in some desktop programmer, that simply makes no sense.

[drussell]

It's unclear to me what incentive they would have to publicly release the programming protocol though. It usually ends up being more hassle than benefits for a tech company. And here I don't think that the kind of customers interested in devising their own tools are the ones who would buy their MCUs by the millions. So...

Well, the people that buy them in the millions are going to get them mass-programmed, which the manufacturer or distributor will be set up with the equipment to do for you.  If you were using millions and wanted to program them in-house for some bizarre reason, they would still help you by either supplying the equipment or the engineering data to do that but that's very different than programming one-offs in a desktop programmer.

[js_12345678_55AA]

Hi,

For those curious people I wrote a little deobfuscator for PDK files (the compiled binary you get from IDE).

It's a command line utility called depdk which requires 2 parameters: inputfile and outputfile.

Example: ./depdk input.pdk output.bin

The header from the PDK file is thrown away and just the real (deobfuscated) binary data (which is written to the MCU) is written to the output file.

Compilation with gcc -o depdk depdk.c

Or use the attached compiled executable for Windows.

Have fun,

JS 

depdk.c

#include <stdio.h>
#include <stdint.h>
#include <string.h>

int main( int argc, const char * argv [] )
{
  if( 3 != argc ) {
    printf("usage: %s inputfile outputfile\n\n", argv[0]);
    return 0;
  }

  FILE* fin = fopen( argv[1], "rb");
  if( !fin ) { printf("Could not open %s for reading.\n", argv[1]); return -1; }

  FILE* fout = fopen( argv[2], "wb");
  if( !fin ) { printf("Could not open %s for writing.\n", argv[2]); return -1; }

  uint8_t hdrdata[0x100];
  if( sizeof(hdrdata) != fread( hdrdata, 1, sizeof(hdrdata), fin ) ) {
    printf("Error reading input file\n");
    return -1;
  }

  uint32_t version = *((uint32_t*)&hdrdata[0x08]);
  uint32_t datalen = *((uint32_t*)&hdrdata[0x20]);

  uint32_t extrahdr = *((uint16_t*)&hdrdata[0x26]) +
                      *((uint16_t*)&hdrdata[0x28]) +
                      *((uint16_t*)&hdrdata[0x2C]) +
                      *((uint16_t*)&hdrdata[0xD0]);
  if( version>=0x1c )
    extrahdr += *((uint8_t*)&hdrdata[0x49]);

  fseek( fin, extrahdr, SEEK_CUR );

  uint16_t key[0x10];
  memcpy( key, &hdrdata[0xE0], sizeof(key) );

  uint16_t kxorw7C92 = key[3]^key[14];
  uint16_t kxorw7E8A = key[7]^key[15];

  if( (version>=0x15) && (version<=0x17) ) {
    kxorw7C92 ^= 0x1234; kxorw7E8A ^= 0x5678;
  }

  uint16_t keyindex = 0;

  for( uint32_t fullpos=0; fullpos<datalen; fullpos+=32 ) {
    uint16_t data[0x20];
    if( sizeof(data) != fread( data, 1, sizeof(data), fin ) )
      break;

    uint32_t dataptr = 0;
    for( uint32_t j=0; j<4; j++ ) {
      uint16_t tmp_xor_key1;
      uint16_t tmp_xor_key2;

      keyindex += kxorw7C92;
      tmp_xor_key1 = data[dataptr];
      data[dataptr] += key[keyindex&0xF];
      dataptr++;
      key[fullpos&0xF] ^= tmp_xor_key1;

      keyindex += tmp_xor_key1;
      tmp_xor_key2 = data[dataptr];
      data[dataptr] = (data[dataptr] + kxorw7E8A ) ^ key[keyindex&0xF];
      dataptr++;
      key[kxorw7E8A&0xF] ^= kxorw7C92;

      keyindex ^= tmp_xor_key2;
      kxorw7C92 = data[dataptr];
      data[dataptr] += key[keyindex&0xF];
      dataptr++;
      key[kxorw7E8A&0xF] ^= 0x55AA;

      keyindex = (keyindex + kxorw7C92)>>1;
      kxorw7E8A = data[dataptr];
      data[dataptr] = (data[dataptr] - tmp_xor_key1) ^ key[keyindex&0xF];
      dataptr++;

      keyindex += kxorw7E8A;
      tmp_xor_key1 = data[dataptr];
      data[dataptr] ^= key[keyindex&0xF];
      dataptr++;
      key[kxorw7C92&0xF] += kxorw7E8A;

      keyindex ^= tmp_xor_key1;
      tmp_xor_key2 = data[dataptr];
      data[dataptr] = (data[dataptr] ^ kxorw7E8A) ^ key[keyindex&0xF];
      dataptr++;
      key[tmp_xor_key2&0xF] ^= tmp_xor_key1;

      keyindex ^= tmp_xor_key2;
      kxorw7C92 = data[dataptr];
      data[dataptr] += key[keyindex&0xF];
      dataptr++;
      key[tmp_xor_key1&0xF] += tmp_xor_key2;

      keyindex += kxorw7C92;
      kxorw7E8A = data[dataptr];
      data[dataptr] = (data[dataptr] + tmp_xor_key1) ^ key[keyindex&0xF];
      dataptr++;

      key[2] ^= tmp_xor_key1;
      key[4] += tmp_xor_key2;
      key[6] += kxorw7E8A;
      key[8] -= kxorw7C92;
      key[1] ^= key[15];
      key[3] ^= key[14];
      key[5] ^= key[13];
      keyindex += j;
    }

    if( sizeof(data) != fwrite( data, 1, sizeof(data), fout ) ) {
      printf("Error writing output file\n");
      return -1;
    }
  }

  fclose(fin);
  fclose(fout);

  return 0;
}

[js_12345678_55AA]

Just some useful info for understanding the MCU family and how to program it:

http://svn2.assembla.com/svn/mcu/

The examples using older processor types with 8 cores but most of it should be "understandbale"

JS

[SeoulBigChris]

It's unclear to me what incentive they would have to publicly release the programming protocol though. It usually ends up being more hassle than benefits for a tech company. And here I don't think that the kind of customers interested in devising their own tools are the ones who would buy their MCUs by the millions. So...

Disclaimer: I’ve never run a semiconductor company.

My reaction is the opposite, when I see policies like this. As far as I know, Paduk is in the business of selling semiconductors, not programmers. I contend that it’s more hassle to maintain a closed programming protocol. This forces you into the chip programmer business, taking your attention away from your core competency. Releasing the protocol so the various chip programmer companies and hobbyists can support your ICs should reduce their hassle, not increase it.

I have a similar take on providing a custom and apparently closed compiler. Do they have aspirations of becoming a compiler company as well?

I suppose it’s possible that the insides of their chips are so revolutionary and proprietary, that opening up these protocols would be akin to revealing their trade secrets. But I think that’s unlikely in this case.

[ataradov]

With western companies there is a pretty benign explanation for why they don't release even the most trivial things - releasing something implies you will provide support. For whatever reason a concept of releasing things "as is" is not accepted.

But I doubt this is a problem for Padauk. Chinese companies have a habit of releasing a product and not providing any obvious support to the general public. And I like it - it lets us have products that we otherwise would not see, even if they are not well documented.

[SiliconWizard]

With western companies there is a pretty benign explanation for why they don't release even the most trivial things - releasing something implies you will provide support. For whatever reason a concept of releasing things "as is" is not accepted.

Yes, thus my "more hassle than benefits" point above.
Even if it's made clear you won't provide direct support, you're bound to one way or another. You will inevitably run into customers that will ask for tech support and make you waste significant time until they end up admitting they use unsupported tools.

But I doubt this is a problem for Padauk. Chinese companies have a habit of releasing a product and not providing any obvious support to the general public. And I like it - it lets us have products that we otherwise would not see, even if they are not well documented.

Possibly, but again why would they? That would still take some time to gather the bits and pieces in a consumable form for third parties, and possibly bother with uploading updates on a regular basis, etc. They may not even have a proper internal documentation themselves (that would be bad, but yes, that really happens!)

And I doubt they are interested in customers that will buy for a few bucks of their ICs.  I also doubt that, maybe contrary to Espressif that have different products and targets, a large community of small companies or even amateur users would really help their business.
 

[Bud]

The video was painful to watch. Too many cuts.

[FrankBuss]

I contacted Padauk, will get a programmer and an ICE (unfortunately you need a different ICE than the one you can use for the PMS150C) for their new PMC884 chip with 8 cores and samples of the chip. Joe from Padauk sent me a datasheet for it. It is a bit strange why they don't publish it on their webpage: He says because it can be too difficult to program, maybe they don't want too many support requests. Anyway, he says the datasheet is not confidential and I'm allowed to show it to others for review:

http://www.frank-buss.de/tmp/pmc884.pdf

It is not really a multi-core chip, more like a mult-thread chip, because e.g. if you enable 2 cores and run it at 8 MHz, each core will run effectively at 4 MHz, round-robin. But still very useful for things like bitbanging on one core and application logic on another core, without the overhead of interrupts or complicated programming.

[Hypernova]

he says the datasheet is not confidential and I'm allowed to show it to others for review

Funny as the red watermark on every page reads "PADAUK confidential document"

[Sjaak]

How about disassembling the programmer? Not expecting a regular mcu in there that can be read back but can give some clues howmany voltage levels there are, and even some silkscreen markings that provide info about signalnames.

[FrankBuss]

Funny as the red watermark on every page reads "PADAUK confidential document"

Maybe it was confidential at some point, but it really doesn't make sense to hide it. This hardware thread concept looks very useful to simplify application development, without much drawbacks for power consumption or issues with real parallel cores, like synchronization and race conditions etc.

[Hypernova]

Funny as the red watermark on every page reads "PADAUK confidential document"

Maybe it was confidential at some point, but it really doesn't make sense to hide it. This hardware thread concept looks very useful to simplify application development, without much drawbacks for power consumption or issues with real parallel cores, like synchronization and race conditions etc.

What they made is a Barrel Processor which is a pretty old concept, so not sure what they have to hide. I have a real dislike for companies that take the confidential-by-default route.

[FrankBuss]

This is interesting, I didn't know the barrel processor concept.

The datasheet for the PMC884 says at one position it is patent pending, and at another position it is patented. I couldn't find an existing patent, only this:

https://patents.google.com/patent/US20050166170

Has the same name (FPPA), but looks like something completely different. But with the barrel processor I wonder if this counts as prior art and they can't patent it.

Meanwhile Joe told me the price for the PMC884: it is US$0.40 in larger quantities (but less than 100k). Don't know if this makes sense, because you could get 13 of the cheap 3 cent PMS150C for this price But might be still useful if you need it small in one IC.

[js_12345678_55AA]

I found some strings in "USB_Driver" folder inside of "Writer.PDK" (can be deobfuscated with small modified depdk).

Looks like the programmer uses 5V, 7.5V for VDD and 8V, 12V for VP (programing)

<<<  IC O.K. >>>
F/W Ver : 1.23 
DC Power Fail. 
DC Low Power.   
DC High Power. 
H/W VDD keep Hi.
H/W VD 5V fail.
H/W VDD 7V5 fail
H/W VDD 5V fail.
H/W VP 8V fail.
H/W VP 12V fail.

Maybe this helps interpreting the captured data.

[atc1441]

Hi, i think i found one Padauk chip in the wild.

It is in one of these STC Auto Programmer USB-TTL but i am not 100% shure eBay auction: #202070246074


As you see in the attachment the pinout is the same it is the tsop8 chip the other one is an CH340 Clone

[js_12345678_55AA]

Hi, I spent some time (actually a lot more than I wanted) to find out and write down all known instructions for the small type (1 core) processors (1 core processors start with a "1" like PMC154. PMC2... has 2 cores and PDK8... has 8 cores ).

The 1 core processors (the cheap ones ;-) ) do have a compact (14-bit) instruction set. The multi core processors seem to have a 16-bit instruction set.
Note: 14/16 bit instructions does not mean it is a 14/16 bit processor. They are all tiny 8 bit processors. Just the length of one instruction is 14/16 bit.

Here is a direct link:

https://free-pdk.github.io/PADAUK_FPPA_14_bit_instruction_set.html 


I also created a github project. Everybody is invited to contribute:

https://github.com/free-pdk

It just started with a single "documentation" repository. Next might be a disassembler and a simulator.


Have fun,

JS

[FrankBuss]

That's really nice, you can add me if you like, my github name: FrankBuss
I could try to implement a FPGA emulation for it. This would allow realtime simulation in hardware (except for the ADCs) of the chip with all peripherals.

[rhodges]

Here is a direct link:
https://free-pdk.github.io/PADAUK_FPPA_14_bit_instruction_set.html 

Nice work! It looks like you might have all the important instructions decoded. Maybe it would be useful to have a program to parse the compiler output every time and alert if a "new" instruction comes out. After a while, we could be pretty confident about the instruction coding.

Thanks! I recently decided to move from PIC to STM8 for personal projects, but you are tempting me to rotate my brain 90 degrees to go back to PIC thinking...

[chicken]

I'm tempted to add support for this architecture to radare2. https://github.com/radare/radare2

[js_12345678_55AA]

It looks like you might have all the important instructions decoded. Maybe it would be useful to have a program to parse the compiler output every time and alert if a "new" instruction comes out. After a while, we could be pretty confident about the instruction coding.

Actually I used the data sheets of all PMC/PMS1xx processors and typed in every possible instruction in the IDE and monitored the compiler output. So for sure the compiler will not generate more / unknown instructions from our code.

The holes are most likely unused spaces or instructions which they planned to implement but did not work out correctly. For instance AND IO,A / AND A,IO / OR IA,A / OR A,IO  are somehow missing and would fit perfectly in the "0x0100...0x017F" hole.

One way to try the "undocumented" instructions is to manually create the binary, inject these instructions and observe the result (like it was done decades ago for 6502).
Since OTP would be a bit painful for this I already ordered the FLASH based PFS154 (now waiting for it to arrive).

On the other hand, if the normal compiler does not create them, also a disassembler does not need to know them. Invalid instructions are a common thing which even exist on modern CPUs like ARM and Intel.

[DocBen]

Hi thank you for your work thus far.

@ js_12345678_55AA: Could you post the modifications you made to deobfuscate the PDKs in the USB_Driver directory?

Also: in the USB_Driver/USB directory there seems to be the firmware for the programmer (in obfuscated form):

P5SP_BOOT_UPDATER.fw
P5SP_G1.fw
P5SP_G2.fw
P5SP_TESTER.fw

from Dave's video the P5SP files could be for an STM32F072V8T6
and from the strings in the FPPA_IDE.EXE it seems to know how to upload them to the programmer

[DocBen]

From the strings in FPPA_IDE.exe you can also gather voltage information from their test program of the programmer (P5SP_tester.fw):

0x63421c 70 69 Please remove all IC, and check VDD,\nVPP(PA5), PA0 / 3 / 4 / 7 is 0 V
0x634264 30 29 Please check VPP (PA5) = 4.6V
0x634284 31 30 Please check VPP (PA5) = 11.3V
0x6342a4 24 23 Please check VDD = 5.5V
0x6342bc 24 23 Please check VDD = 7.5V
0x6342d4 24 23 Please check VDD = 3.3V

and a list of instructions:

0x62dac0 16 15 MOV__A__IO_LIST
0x62dad0 16 15 MOV__IO_LIST__A
0x62dae0 16 15 XOR__A__IO_LIST
0x62daf0 16 15 XOR__IO_LIST__A
0x62db00 14 13 MOV__A__CONST
0x62db10 17 16 MOV__A__RAM_BYTE
0x62db24 17 16 MOV__RAM_BYTE__A
0x62db38 18 17 NMOV__A__RAM_BYTE
0x62db4c 18 17 NMOV__RAM_BYTE__A
0x62db60 18 17 IDXM__A__RAM_WORD
0x62db74 18 17 IDXM__RAM_WORD__A
0x62db88 17 16 LDTABL__RAM_WORD
0x62db9c 17 16 LDTABH__RAM_WORD
0x62dbb0 16 15 PUSHW__RAM_WORD
0x62dbc0 15 14 POPW__RAM_WORD
0x62dbd0 11 10 PUSHW__PCX
0x62dbdc 10 9 POPW__PCX
0x62dbe8 7 6 PUSHAF
0x62dbf0 6 5 POPAF
0x62dbf8 17 16 AND__A__RAM_BYTE
0x62dc0c 17 16 AND__RAM_BYTE__A
0x62dc20 14 13 AND__A__CONST
0x62dc30 16 15 OR__A__RAM_BYTE
0x62dc40 16 15 OR__RAM_BYTE__A
0x62dc50 13 12 OR__A__CONST
0x62dc60 17 16 XOR__A__RAM_BYTE
0x62dc74 17 16 XOR__RAM_BYTE__A
0x62dc88 14 13 XOR__A__CONST
0x62dc98 7 6 NOT__A
0x62dca0 14 13 NOT__RAM_BYTE
0x62dcb0 8 7 NEGC__A
0x62dcb8 7 6 NEG__A
0x62dcc0 15 14 NEGC__RAM_BYTE
0x62dcd0 14 13 NEG__RAM_BYTE
0x62dce0 16 15 CLEAR__RAM_BYTE
0x62dcf0 14 13 XCH__RAM_BYTE
0x62dd00 8 7 SWAP__A
0x62dd08 15 14 SWAP__RAM_BYTE
0x62dd18 6 5 SR__A
0x62dd20 13 12 SR__RAM_BYTE
0x62dd30 6 5 SL__A
0x62dd38 13 12 SL__RAM_BYTE
0x62dd48 7 6 SRC__A
0x62dd50 14 13 SRC__RAM_BYTE
0x62dd60 7 6 SLC__A
0x62dd68 14 13 SLC__RAM_BYTE
0x62dd78 18 17 NADD__A__RAM_BYTE
0x62dd8c 18 17 NADD__RAM_BYTE__A
0x62dda0 8 7 ADDC__A
0x62dda8 15 14 ADDC__RAM_BYTE
0x62ddb8 18 17 ADDC__A__RAM_BYTE
0x62ddcc 18 17 ADDC__RAM_BYTE__A
0x62dde0 8 7 SUBC__A
0x62dde8 15 14 SUBC__RAM_BYTE
0x62ddf8 18 17 SUBC__A__RAM_BYTE
0x62de0c 18 17 SUBC__RAM_BYTE__A
0x62de20 17 16 ADD__A__RAM_BYTE
0x62de34 17 16 ADD__RAM_BYTE__A
0x62de48 14 13 ADD__A__CONST
0x62de58 17 16 SUB__A__RAM_BYTE
0x62de6c 17 16 SUB__RAM_BYTE__A
0x62de80 14 13 SUB__A__CONST
0x62de90 14 13 INC__RAM_BYTE
0x62dea0 14 13 DEC__RAM_BYTE
0x62deb0 15 14 IZSN__RAM_BYTE
0x62dec0 8 7 IZSN__A
0x62dec8 15 14 DZSN__RAM_BYTE
0x62ded8 8 7 DZSN__A
0x62dee0 15 14 COMP__A__CONST
0x62def0 18 17 COMP__A__RAM_BYTE
0x62df04 18 17 COMP__RAM_BYTE__A
0x62df18 13 12 DELAY__CONST
0x62df28 16 15 DELAY__RAM_BYTE
0x62df38 9 8 DELAY__A
0x62df44 9 8 T0SN__CF
0x62df50 9 8 T1SN__CF
0x62df5c 9 8 T0SN__ZF
0x62df68 9 8 T1SN__ZF
0x62df74 9 8 SET0__CF
0x62df80 9 8 SET1__CF
0x62df8c 9 8 SET0__ZF
0x62df98 9 8 SET1__ZF
0x62dfa4 8 7 TOG__ZF
0x62dfac 8 7 TOG__CF
0x62dfb4 17 16 T0SN__IOBIT_LIST
0x62dfc8 17 16 T1SN__IOBIT_LIST
0x62dfdc 17 16 SET0__IOBIT_LIST
0x62dff0 17 16 SET1__IOBIT_LIST
0x62e004 16 15 TOG__IOBIT_LIST
0x62e014 18 17 SWAPC__IOBIT_LIST
0x62e028 18 17 WAIT0__IOBIT_LIST
0x62e03c 18 17 WAIT1__IOBIT_LIST
0x62e050 14 13 T0SN__RAM_BIT
0x62e060 14 13 T1SN__RAM_BIT
0x62e070 14 13 SET0__RAM_BIT
0x62e080 14 13 SET1__RAM_BIT
0x62e090 19 18 CEQSN__A__RAM_BYTE
0x62e0a4 16 15 CEQSN__A__CONST
0x62e0b4 20 19 CNEQSN__A__RAM_BYTE
0x62e0c8 17 16 CNEQSN__A__CONST
0x62e0dc 14 13 GOTO__ADR_ABS
0x62e0ec 14 13 GOTO__ADR_OFS
0x62e0fc 16 15 IGOTO__RAM_WORD
0x62e10c 14 13 CALL__ADR_ABS
0x62e11c 14 13 CALL__ADR_OFS
0x62e12c 16 15 ICALL__RAM_WORD
0x62e13c 15 14 LGOTO__ADR_ABS
0x62e14c 15 14 LCALL__ADR_ABS
0x62e160 5 4 RETI
0x62e168 11 10 RET__CONST
0x62e174 14 13 PMODE__P_MODE
0x62e184 8 7 STOPSYS
0x62e18c 8 7 STOPEXE
0x62e194 16 15 LDT16__RAM_WORD
0x62e1a4 16 15 STT16__RAM_WORD
0x62e1b4 7 6 ENGINT
0x62e1bc 8 7 DISGINT
0x62e1c4 8 7 WDRESET
0x62e1cc 6 5 RESET
0x62e1dc 9 8 PCADD__A

There are also quite a few compiler directives, but they are all over the place

[DocBen]

The instruction list above seems to be a generic one, describing all theoretically available instructions.
The actually available instructions for a specific chip are given by the specific inc file in the INC_PDK directory and the symbol file (defined in the inc file and located in the Symbol directory)
(There is a lot of additional data in that file, maybe they also define what address modes can be used and which instruction can also use flags or io's as operands etc.)

example:
PMS150C (44 Instructions)
INSTRUCTION
CALL
GOTO
ADD
SUB
CEQSN
AND
OR
XOR
MOV
T0SN
T1SN
SET0
SET1
ADDC
SUBC
IZSN
DZSN
INC
DEC
CLEAR
XCH
NOT
NEG
SRC
SLC
RET
IDXM
STT16
LDT16
WDRESET
PUSHAF
POPAF
RESET
STOPSYS
STOPEXE
ENGINT
DISGINT
RETI
PCADD
SWAP
TRAP
NOP
LDSPTL
LDSPTH

PFS154 (52 Instructions)
INSTRUCTION
CALL
GOTO
ADD
SUB
CEQSN
CNEQSN
AND
OR
XOR
MOV
T0SN
T1SN
SET0
SET1
ADDC
SUBC
IZSN
DZSN
INC
DEC
CLEAR
XCH
NOT
NEG
SRC
SLC
NADD
COMP
SWAP
STT16
LDT16
IDXM
RET
LDTABL
LDTABH
WDRESET
PUSHAF
POPAF
RESET
STOPSYS
STOPEXE
ENGINT
DISGINT
RETI
MUL
NEGC
PCADD
SWAP
TRAP
NOP
LDSPTL
LDSPTH