EEVblog #1144 - Padauk Programmer Reverse Engineering

[EEVblog]

David looks at the pins on the Padauk PMS150 programmer for potential reverse engineering.

TLDR; It doesn't look easy to reverse engineer this protocol, it's messy with lots of voltage levels, as Padauk said it would be.
Just buy the programmer for now!
There is also a Flash/EEPROM re-programmable version of the chip, the PFS154C.

[BrianHG]

Looks like the first generation PIC16C54 programming levels, with fewer active IOs.  The old PICs used to use half the IOs to be programmed with wacko voltage transients and some analog levels thrown in as well.

[ataradov]

Voltage levels on I/Os are probably not important, they are just matching the supply voltage, but it would probably work fine as long as you cross the threshold.

Just use a logic analyzer to grab their logical level. Clamp it with diodes if needed, although I suspect that simple current limiting resistors will be sufficient.

[FrankBuss]

Regarding the different voltage levels: Old EPROMs required this, too. For example some algorithms verified if it was programmed correctly at 6V and 4V. So might be that the highest voltage phase is the programming phase, and two other low voltage phases are verify, and maybe a normal voltage phase for reading the ID etc.

[Smokey]

Is anyone else a little confused by this?

Did I miss part of the video or something or did you not tell us how long the total programming time is? 
ms, seconds, tens of seconds?  That's kind of important to get an idea of the amount of data capture required.

Also did you intentionally grab the least capable data acquisition device possible?  We all know that lab is jam packed with high end gear that almost never gets used.  I'm pretty sure there are at least a couple multi-thousand-dollar deep memory 4 channel MSOs with real level triggering on the digital channels that should be more than capable.  I'm also pretty sure you can take the couple 4channel Keysight scopes sitting around, time correlate all the analog channels between scopes, and dump all that to a PC for a full time deep memory data dump.

It's one thing if you want to do some simple Arduino project video for beginners and don't want to scare viewers off by using test equipment they probably won't have.  It's another thing to do a real engineering project like reversing an uC programming procedure with only toy test equipment and then sound surprised when it didn't all just work out and you couldn't get all the data you needed.

[FrankBuss]

In a Youtube comment David said the big scopes are still all in boxes, because of their move.

[Smokey]

In a Youtube comment David said the big scopes are still all in boxes, because of their move.

Ahhh.  Well that explains some things. 
It would be nice to put a big huge disclaimer at the beginning of the video that you actually know the equipment you are using is not the right tool for the job and will probably never have the capabilities to succeed and that you are really just playing.

Question:
Do you guys typically read the youtube comments?  Mark me as a "no".

[westfw]

I think you can probably decide that the pins not present on the SOT-6 package (PA0 (7) and PA7 (2)) are not particularly relevant to the programming spec...  (the programmer may check their presence to determine chip type, but if they were needed for the actual programming, there wouldn't be any way to program the SOT-6 version.)

[HKJ]

I would look for the actual data protocol first, then the voltage levels and I doubt the chip will remember any state after a power cycle.

The first operation is probably reading some sort of chip identification.
Programming may be split into program memory and one or more configuration memories.
At least data memory needs an address and one or more data bytes for each programming pulse (Address may be auto increment).
Verification can be for each byte/block programmed or another run when finished.
Some programming algorithms consist of short pulses with a verification between each, when data match a couple more pulses are done to secure the data.


If this sort of protocol can be determined, it will probably be easier to see what voltage levels are used for each operation.

[ali_asadzadeh]

Maybe their strategy is to sell programmers ! Maybe they are copying the analog devices blackfin lines, selling the Dev tools and programmers so high that they would kill the product itself eventually, ask them so share the info! like rigol shard their way of hacking their scope to sell even more!!!! 

[rjp]

There is also a Flash/EEPROM re-programmable version of the chip, the PFS154C.
 

https://lcsc.com/product-detail/Others_PADAUK-Tech-PFS154-S16_C317613.html

thats a ripoff, 11c each in small quantities!

[Whales]

The padauk IDE, is AFAIK, the only way to create binaries for this platform.

Does this IDE let you access the output binaries yourself?  Or are they sent to the programmer directly without giving you access?  Comparing these binaries to the data waveforms would be useful.  You could observe if data is being shift-clocked in with the need for extra cycles (or similar).

If not, then finding out how the programming protocol works is only a tiny bit of the puzzle   

[modrobert]

Perhaps the programmer uses session encryption to the micro based on a unique serial number (read only) in the micro, to mitigate knockoffs (or "midnight batches" in approved factories) being produced.

Look for differences in initial handshake between different micros in the same batch.

[FrankBuss]

The padauk IDE, is AFAIK, the only way to create binaries for this platform.

Does this IDE let you access the output binaries yourself?  Or are they sent to the programmer directly without giving you access?  Comparing these binaries to the data waveforms would be useful.  You could observe if data is being shift-clocked in with the need for extra cycles (or similar).

If not, then finding out how the programming protocol works is only a tiny bit of the puzzle 

I guess you can use strings in the IDE, and they probably don't encrypt this, otherwise the microcontroller would be too complex. But even without strings, you can use inline assembler ("nop" etc.). Even if you don't know the encoding of the opcodes (but I guess you could look at the programming file), you could use 3 x command A, 4 x command B, and 5 x command C, and then search for a 3 x, 4 x, 5 x pattern. With this you could even reverse engineer the opcode encoding.

[glarsson]

Perhaps the programmer uses session encryption to the micro based on a unique serial number (read only) in the micro, to mitigate knockoffs (or "midnight batches" in approved factories) being produced.

This is a 3¢ micro controller. To cheap to serialize during manufacturing.
Also, is there any economy in cloning a 3¢ part?

[js_12345678_55AA]

Hi,

I had a quick look with IDA on the IDE generating the PDK output file after compilation.

The PDK file consists of a 256 byte header containing a 32 byte initialization "key" @0x000000E0

After the header is written the compiled binary is obfuscated (the algorithm used can not be called encryption ;-) using the initialization key from header @0x000000E0 and some magic values like "12345678h" and "55AA" and a lot of 16 bit XORs. It reads 32 byte chunks from the binary and obfuscates them in 4 loops, 2 bytes a at once in 4 statements.

It will not take me long to re-create the en/decrypt for this section, just some days I guess.

Small teaser:

I used the default program for 154C and inserted:

A = 'T';
A = 'E';
A = 'S';
A = 'T';

in the FPPA0 function right after the comment "// Insert Initial Code"

The IDE creates a memory segment of the unencrypted compiled binary @0x7EA90000
The binary section was 4kByte in total initialized with static values (seems they fill up the complete memory region the MCU can hold).

This is what I found somewhere in the memory section after compilation:

542F
452F
532F
542F

(54 = T, 45 = E, 53 = S )

-> first opcode we can learn from this is (seems to be a little endian design):

MOV A,<imm>   ->  <imm> 2F


In case somebody wants to play with IDA, the function to write "encrypted" files with header is located @0x0041B0DE


JS

[js_12345678_55AA]

Some more opcodes... maybe somebody recognizes them (looks like 14 bits are used per opcode, but it not seems to be a PIC)

00 00 : NOP
67 00 : PCADD A
70 00 : WDRESET
72 00 : PUSHAF
73 00 : POPAF
75 00 : RESET
76 00 : STOPSYS
77 00 : STOPEXE
78 00 : ENGINT
79 00 : DISGINT
7A 00 : RET

9[ I ] 01 : MOV PA,A //IO
D[ I ]01 : MOV A,PA //IO

[PTR]1 03 : IDXM A,PTR
[PTR]0 03 : IDXM PTR,A

[M] 0B : MOV [MEM],A
[M] 0F : MOV A,[MEM]

[M] 13 : XCH M

IM 2F : MOV A,IMM

POS 30 : GOTO POS //POS is on WORDS
POS 38 : CALL POS   //POS is on WORDS

FF 3F : ? ? ? used as filler, maybe invalid opcode

----
I defined a function on top of "Project.C and you can just write assembler inside

void fun(void)
{
  MOV A,'T'
label1:
  MOV A,'E'
  GOTO label1
  //...

  //RET is inserted automatically from miniC
}

The function is placed in compiler output memory directly at start. Just 4 bytes in front of it which looks like this:
00 00  //NOP ?
09 30 //GOTO ...

They seem to come from "Project1.PRE" from the ".JMP FPPA0" directive

----

Have fun,

JS

[FERCSA]

Looks like it's a FPPA, Field Programmable Processor Array.

Here is some useful links:
http://fellong.blogspot.com/2007/07/fppa_14.html
http://www.hy-star.com.tw/tech/MCU/mcu.html

[FrankBuss]

The FFPA is their MCS11 chip, with 8 cores. Unfortunately I can't find it anywhere to buy. This would be a very interesting chip, similar to the Parallax Propeller, just a bit smaller, and presumably cheaper. The PMS150 has only one core.

But the more I think about it, I guess they developed it on their own and it is not a PIC clone or a clone of any other microcontroller. They couldn't have used the original die anyway, because PICs need 4 cycles and more per instruction, and the Padauk instruction set claims to need only one cycle for most instructions. And while very similar to the PIC instruction set, they have a few more instructions than PIC, especially their MCS11 flagship, like the wait instruction, which stops the CPU until an IO pin changes, which makes perfect sense for 8 cores, because it makes it easier to write fast bitbanging code for protocols like SPI in one dedicated core for the communication. But it is odd that they do such obfuscating, as if they want to hide something.

Maybe all their chips use the same die, and the other 7 cores are just disabled by software in the lower end chips? This would be a good reason for them not to publish the programming protocol

[free_electron]

This multilevel voltage programming is classic for PROM style devices.
This chip may very well be a true prom ( fuse or charge based ) and not a windowless eprom.

The reason for the multilevel voltages is to prevent accidental in-the-field corruption of the prom due to someone wiggling the pins in the wrong sequence.

They have analog comparators on the io pins used for programming ( simple window comparator made from 2 op-amps and a resistive divider. The op-amps aren't even real op-amps .. more like 4 transistors each, kind of how you make a schmitttrigger structure )

You can initialize and probably 'read' while within normal voltage on VCC. Meaning , below programming voltage. But you can't destroy anything.

Once programming voltage is applied other comparators come into play. These work between VCC and VPP (Programming voltage). One level is used for one function , another level for another function.

for example (hypothetical)
- send command to prepare for programming inside the VCC levels.
- turn on vpp
- set 6 volts on control pin : reset programming shifter
- set 7 volts : enable shifter
- now using the other pin : clock in data
- set 12 volts : burn
- set 9 volts : read back bits into shifter
- set 8 volts : turn shifter around ( the digital pin is now an output and you can read back the bits )

so these voltage all mean something : they control the on-chip programming logic.

This reminds me of the mechanism used to control trim bits in many devices. The advantage is that these voltages never will be applied int he fiedl and the entire 'programming' block is disabled.

the 'programmer' is nothing more than a simple shift register.
The fact that you pass from 5 volts VCC to 7 means you transitioned through 6 and thus caused a reset !!!

Then reverse engineering this be mindful of that.. if you see more than 1 level change : they have transitioned through a state !.

They could also use a multilevel self clocking mechanism.
 rise to 8 means  clock in a 0 . drop to 6 means clock in a 1. rising or dropping back to 7 means : advance counter a tick....

so the sequence

Code: [Select]

 
7878786768676867
 0 0 01 101 101

if the voltage transitions directly form 6 to 8 or 8 to 6 there is an implied '7' meaning : clock !  be weary of these things.
The on-board electronics is kept to a minimum in  area.... to make the chip cheap.

[glarsson]

IF this device is a fusible link PROM device then it probably requires well controlled slopes on the programming pulse. Too fast rise time and the metal splashes over the silicon. Too slow damages the silicon due to localized heating or the bit will not program correctly.

Are fusible link PROMs manufactured today?

[TK]

Padauk is not making any money selling the programmer, so why don't ask them for the programming protocol?  Adding support for  universal programmers like TL866 can help sell tons of 3cent microcontrollers.

[PA0PBZ]

It looks to me that a lot could be learned from the original programmer, like how the pins are controlled?

[ataradov]

Padauk is not making any money selling the programmer, so why don't ask them for the programming protocol?

The have been asked and they refused to provide any information.

[SiliconWizard]

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...