Author Topic: EEVblog #1144 - Padauk Programmer Reverse Engineering  (Read 21723 times)

amyk and 8 Guests are viewing this topic.

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 104
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #100 on: November 22, 2018, 11:02:57 am »
After checking the disassembly of the calibration again some things look suspicious:


;start measurment
0x002b:   0x2f02    MOV A, 0x02
0x002c:   0x0182    MOV IO(0x02), A  ;SP        ;setup SP to memory @0x02

0x002d:   0x1304    CLEAR [0x04]                ;zero memory @0x04
0x002e:   0x1305    CLEAR [0x05]                ;zero memory @0x05
0x002f:   0x2f55    MOV A, 0x55
0x0030:   0x0b82    MOV [0x02], A               ;store 0x55 in memory @0x02
0x0031:   0x2f00    MOV A, 0x00     
0x0032:   0x0b83    MOV [0x03], A               ;store 0x00 in memory @0x03

;16 bit loop (0x0055) times some operations
0x0033:   0x0006    LDSPTL                      ;load from memory where SP is pointing to A
0x0034:   0x0b04    XOR [0x04], A
0x0035:   0x0007    LDSPTH                      ;load from memory where SP is pointing to A
0x0036:   0x0805    ADD [0x05], A

0x0037:   0x1584    SL [0x04]                   ;rotate left 16 bit value
0x0038:   0x1685    SLC [0x05]
0x0039:   0x1004    ADDC [0x04]

0x003a:   0x1282    DECM [0x02]                 ;memory low byte -1
0x003b:   0x1083    SUBC [0x03]                 ;memory high byte -1 if carry set
0x003c:   0x1a40    T1SN IO(0x00).1  ;FLAG.CF   ;test for carry (0x0000 -1 => carry set)
0x003d:   0x3033    GOTO 0x033                  ;loop


At the beginning the SP is setup to point to a new location. SP / stack is never used anywhere after this point in calibration program.
So the only use could be from the undocumented instructions LDSPTL and LDSPTH. Also SP points to the memory which is initialized
with static values.

This lets me think LDSPTL/LDSPTL stands for "LoaD from SP Table Low" / "LoaD from SP Table High":
  LDSPTL   =>   A = [SP]
  LDSPTH   =>   A = [SP+1]

Then the above loop would be again some "obfuscation" crypto from PADAUK (XOR 0x55 ... smells like the magic value they love, known from IDE obfuscation).

The result in this case is just 0x11E4 which is then sent out via bitbang to the WRITER to "verify"  :-DD

The loop also serves the purpose to run for several cycles, so WRITER can measure the time it takes and use it for calibration.


JS

EDIT: The loop runs for exact 1040 cycles (including loop init)  :)
« Last Edit: November 22, 2018, 11:17:10 am by js_12345678_55AA »
Please support me by using the AFFILIATE link to LCSC when you order PADAUK parts or tools. With the rewards I can order more PADAUK components for research.

THANK YOU!
 

Online amyk

  • Super Contributor
  • ***
  • Posts: 5927
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #101 on: November 22, 2018, 02:54:49 pm »
I sorted the 13-bit instructions in opcode order; some interesting patterns emerge (notice ADD SUB ADDC SUBC AND OR XOR MOV), as well as possible present-but-undocumented instructions:

Code: [Select]
00000 00000000  NOP
00000 00000000  TRAP     // Assembler accepts, but same as NOP
00000 00000001
 ..      ..     ??
00000 00001111
00000 00010000  ADDC      A
00000 00010001  SUBC      A
00000 00010010  IZSN      A
00000 00010011  DZSN      A
00000 00010100
 ..      ..     ??
00000 00010110
00000 00010111  PCADD     A
00000 00011000  NOT       A
00000 00011001  NEG       A
00000 00011010  SR        A
00000 00011011  SL        A
00000 00011100  SRC       A
00000 00011101  SLC       A
00000 00011110  SWAP      A
00000 00011111
 ..      ..     ??
00000 00101111
00000 00110000  WDRESET
00000 00110001  ?
00000 00110010  PUSHAF
00000 00110011  POPAF
00000 00110100  ?
00000 00110101  RESET
00000 00110110  STOPSYS
00000 00110111  STOPEXE
00000 00111000  ENGINT
00000 00111001  DISGINT
00000 00111010  RET
00000 00111011  RETI
00000 00111100
 ..      ..     ??
00000 01011111
00000 011ppppp  XOR       io-addr,A
00000 100ppppp  MOV       io-addr,A
00000 101ppppp  MOV       A,io-addr
00000 110aaaa0  STT16     ram-addr-even
00000 110aaaa1  LDT16     ram-addr-even
00000 111aaaa0  IDXM      ram-addr-even,A
00000 111aaaa1  IDXM      A,ram-addr-even
00001 dddddddd  RET       imm-data
00010 bbb0aaaa  T0SN      ram-addr.bit
00010 bbb1aaaa  T1SN      ram-addr.bit
00011 bbb0aaaa  SET0      ram-addr.bit
00011 bbb1aaaa  SET1      ram-addr.bit
00100 00aaaaaa  ADD       ram-addr,a
00100 01aaaaaa  SUB       ram-addr,a
00100 10aaaaaa  ADDC      ram-addr,A
00100 11aaaaaa  SUBC      ram-addr,A
00101 00aaaaaa  AND       ram-addr,A
00101 01aaaaaa  OR        ram-addr,A
00101 10aaaaaa  XOR       ram-addr,A
00101 11aaaaaa  MOV       ram-addr,A
00110 00aaaaaa  ADD       A,ram-addr
00110 01aaaaaa  SUB       A,ram-addr
00110 10aaaaaa  ADDC      A,ram-addr
00110 11aaaaaa  SUBC      A,ram-addr
00111 00aaaaaa  AND       A,ram-addr
00111 01aaaaaa  OR        A,ram-addr
00111 10aaaaaa  XOR       A,ram-addr
00111 11aaaaaa  MOV       A,ram-addr
01000 00000000
 ..      ..     ??
01000 01111111
01000 10aaaaaa  IZSN      ram-addr
01000 11aaaaaa  DZSN      ram-addr
01001 00aaaaaa  INC       ram-addr
01001 01aaaaaa  DEC       ram-addr
01001 10aaaaaa  CLEAR     ram-addr
01001 11aaaaaa  XCH       ram-addr
01010 00aaaaaa  NOT       ram-addr
01010 01aaaaaa  NEG       ram-addr
01010 10aaaaaa  SR        ram-addr
01010 11aaaaaa  SL        ram-addr
01011 00aaaaaa  SRC       ram-addr
01011 01aaaaaa  SLC       ram-addr
01011 10aaaaaa  CEQSN     A,ram-addr
01011 11000000
 ..      ..     ??
01011 11111111
01100 bbbppppp  T0SN      io-addr.bit
01101 bbbppppp  T1SN      io-addr.bit
01110 bbbppppp  SET0      io-addr.bit
01111 bbbppppp  SET1      io-addr.bit
10000 dddddddd  ADD       A,imm-data
10001 dddddddd  SUB       A,imm-data
10010 dddddddd  CEQSN     A,imm-data
10011 00000000
 ..      ..     ??
10011 11111111
10100 dddddddd  AND       A,imm-data
10101 dddddddd  OR        A,imm-data
10110 dddddddd  XOR       A,imm-data
10111 dddddddd  MOV       A,imm-data
110aa aaaaaaaa  GOTO      code-addr
111aa aaaaaaaa  CALL      code-addr
 

Offline spth

  • Contributor
  • Posts: 47
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #102 on: November 22, 2018, 05:51:54 pm »
Nice job js_12345678_55AA, really interesting. Will take an in depth look.

At the moment I also got the 13-bit ISA implemented in my infrastructure so I can disassemble PMS150 (C) ROMs. I noticed an interesting thing (I still have to look at the disasm). The PMS150 (without the C) has an order of magnitude less init code compared to the PMS150C (which seems to have code that more or less does the same stuff the 154C is doing).

I'm attaching the two listings if someone wants to take a look and start figuring it out.

(to discriminate what's "my" code and PADAUK's code, in both ROMs I only have the main which is simply incrementing a byte in memory, you'll find the inc [0x...]; goto @0x... as the last two instructions in both listings, that are the only two things not part of the init code)

Could you also add the 13-bit instructions to the documentation on GitHub?

Philipp
 

Offline spth

  • Contributor
  • Posts: 47
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #103 on: November 22, 2018, 05:56:36 pm »
After checking the disassembly of the calibration again some things look suspicious:


;start measurment
0x002b:   0x2f02    MOV A, 0x02
0x002c:   0x0182    MOV IO(0x02), A  ;SP        ;setup SP to memory @0x02

0x002d:   0x1304    CLEAR [0x04]                ;zero memory @0x04
0x002e:   0x1305    CLEAR [0x05]                ;zero memory @0x05
0x002f:   0x2f55    MOV A, 0x55
0x0030:   0x0b82    MOV [0x02], A               ;store 0x55 in memory @0x02
0x0031:   0x2f00    MOV A, 0x00     
0x0032:   0x0b83    MOV [0x03], A               ;store 0x00 in memory @0x03

;16 bit loop (0x0055) times some operations
0x0033:   0x0006    LDSPTL                      ;load from memory where SP is pointing to A
0x0034:   0x0b04    XOR [0x04], A
0x0035:   0x0007    LDSPTH                      ;load from memory where SP is pointing to A
0x0036:   0x0805    ADD [0x05], A

0x0037:   0x1584    SL [0x04]                   ;rotate left 16 bit value
0x0038:   0x1685    SLC [0x05]
0x0039:   0x1004    ADDC [0x04]

0x003a:   0x1282    DECM [0x02]                 ;memory low byte -1
0x003b:   0x1083    SUBC [0x03]                 ;memory high byte -1 if carry set
0x003c:   0x1a40    T1SN IO(0x00).1  ;FLAG.CF   ;test for carry (0x0000 -1 => carry set)
0x003d:   0x3033    GOTO 0x033                  ;loop


At the beginning the SP is setup to point to a new location. SP / stack is never used anywhere after this point in calibration program.
So the only use could be from the undocumented instructions LDSPTL and LDSPTH. Also SP points to the memory which is initialized
with static values.

This lets me think LDSPTL/LDSPTL stands for "LoaD from SP Table Low" / "LoaD from SP Table High":
  LDSPTL   =>   A = [SP]
  LDSPTH   =>   A = [SP+1]

Then the above loop would be again some "obfuscation" crypto from PADAUK (XOR 0x55 ... smells like the magic value they love, known from IDE obfuscation).

The result in this case is just 0x11E4 which is then sent out via bitbang to the WRITER to "verify"  :-DD

The loop also serves the purpose to run for several cycles, so WRITER can measure the time it takes and use it for calibration.


JS

EDIT: The loop runs for exact 1040 cycles (including loop init)  :)

Well, 0x55 is a value commonly used in self tests (you'll also see it used as a pattern in memory testers, etc). It has every other bit set, so if there is any interference between adjacent lines it can help detect that. Maybe the program above is one that their test enginers designed to test the ALU? E.g. by making the final result depend on nearly all logic gates or connections in the ALU working correctly?

Philipp
 

Offline gdelazzari

  • Contributor
  • Posts: 15
  • Country: it
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #104 on: November 22, 2018, 06:15:19 pm »
SP / stack is never used anywhere after this point in calibration program.
So the only use could be from the undocumented instructions LDSPTL and LDSPTH.

Uhm, don't assume that because the init code initializes the SP it means that he init code uses the stack/SP register. The init code may very well be just initializing it for the user program and stuff.

Also SP points to the memory which is initialized with static values.

It may just be that they had to store some values and instead of touching the upper memory where the MiniC compiler usually places user variables (at least that's what I noticed) they preferred to use the first locations given they will be overwritten by the first push on the stack so "who cares". Maybe for a more "defined" undefined behaviour  :-DD
I mean, unless you fill your ram with vars and you have variables in 0x00, 0x01, ... you'll never end up reading by accident the values that the init code put somewhere, which is coherent with the fact that they're trying to totally hide the init code and its internal working/effects from the user.

This doesn't mean your hypothesis is wrong, IMHO it is very likely that those two instructions act on the stack in that way. But I just wanted to share my thoughts to look at that in a more objective way.
 

Offline gdelazzari

  • Contributor
  • Posts: 15
  • Country: it
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #105 on: November 22, 2018, 06:21:43 pm »
Could you also add the 13-bit instructions to the documentation on GitHub?

Even better, as soon as I have some time I'll try to find a rule to derive the 13-bit ISA from the 14-bit one. Trust me, after writing by hand dozens of instructions to implement them in the disasm, I can tell there is A LOT of symmetry. I still didn't go in depth but seems it is just something like one bit missing. As soon as I figure that out I'll probably write a tool to do a mass-conversion from the 14-bit docs already up and eventually adjust by hand. Unless someone is already documenting the 13-bit one.

Also, js_12345678_55AA, I had a pull on the docs repo fixing some stuff that is still unfixed after your last commit (a couple of instr swapped IIRC), maybe you want to check that out.
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 104
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #106 on: November 22, 2018, 11:06:21 pm »
Also, js_12345678_55AA, I had a pull on the docs repo fixing some stuff that is still unfixed after your last commit (a couple of instr swapped IIRC), maybe you want to check that out.

Sorry, I did not see the pull request. I merged it now and added you as a project member to github.

JS
Please support me by using the AFFILIATE link to LCSC when you order PADAUK parts or tools. With the rewards I can order more PADAUK components for research.

THANK YOU!
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 104
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #107 on: November 22, 2018, 11:33:20 pm »
After reading your comments, resting a bit and looking at the init code again I think I found the real purpose.

It is a CHECKSUM of the code in ROM.

-> the value 0x0055 is the code size (it grows and shrinks when I compile programs with more/less code, verified with IDE)
-> LDSPTL and LDSPTH needs to be 2 different instructions so it can load indirect the low and high byte of the code memory
-> Since code memory can be bigger than 8 bit the pointer to load from needs to be 16bit -> they use the memory where SP is pointing to to store 2 bytes (the pointer to code memory)
-> the XOR, ADD and ROR is just the checksum algorithm they use

LDSPTL: A = LowByte(CodeMem([SP 16bit]))
LDSPTH: A = HighByte(CodeMem([SP 16bit]))

The 16 bit loop counter in init code also serves as pointer into code mem. So it calculates backwards a checksum of all *used* code memory (excluding unused space and special data at end of chip, IDE inserts the real code length in init code).

Only question left is... What are the MSB of LDSPTH when we only have 14 bit stored. Either they read as '1' or as '0'. Experiments with real hardware will show.


Since reading code memory is always a potential thread for chip readout security it would be understandable why this instructions are not in PADAUK user manual.

But with this method we can now store 14 bit tables instead of 8 bit only per instruction word

JS
Please support me by using the AFFILIATE link to LCSC when you order PADAUK parts or tools. With the rewards I can order more PADAUK components for research.

THANK YOU!
 

Offline gdelazzari

  • Contributor
  • Posts: 15
  • Country: it
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #108 on: November 23, 2018, 02:37:14 am »
The checksum thing makes sense only if the programmer is not able to read back the OTP whenever it likes (which I guess is the case). Does that mean you can only verify the code if you disabled "security" or before the calibration phase?

Also worth noting that the PMS150 (non-C version) doesn't have any code like that by looking at its listing (I uploaded it some posts ago). That in fact makes sense, I just checked and the non C version doesn't have the "security" feature you can enable/disable. This mean the programmer can get away calculating the checksum just by reading the OTP which can always be read.
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 109
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #109 on: November 23, 2018, 03:14:12 am »
There might be an explanation why they do all these checks from another post:

Back in 2006 I was talking to a uC manufacturer in China about their 4 bit uC then costing $0,11 and lower with high volume we were discussing. It could replace $0,40 of logic on our boards so quite interesting with massproduction.
There were some bizar quirks in those things. They were manufactured for one single goal: cheap toys.
The manufacturing process was not as you expect from fabs these days with a result that in your firmware at boottime you had to test the ram since unknown bits would (not could) be dead and you had to make a map so not to use that byte in ram. Also upto 2% of the devices would have problems in the alu or other critical parts. I asked how I could know that the first code would run ok if the ram was not to be trusted. The answer was you could tell from the end product if it worked or not. :-DD
I couldnt believe this but had it b&w in an email.
They probably also sell 100% tested uCs that had no flaws but that was pricewise much less interesting.
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 109
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #110 on: November 23, 2018, 04:07:54 am »
Actually they even hint to that in their product description. That or low ESD tolerance as that doesnt seem to be selling argument for the cheapest chips.
I guess we will see once someone has programmed a few.

PMC150:
**Very stable performance.
**Using 0.5um OTP process with High EFT proprietary design
**Allow using at high EFT requirement products such as home-appliances and durables etc.
**Operating temperature range: -40°C ~ 85°C

PMS150:
**Valuable price
**Using 0.5um OTP process
**Good for battery or DC power based products but required higher noise immunity
**Not supposed to use in AC RC step-down powered or high EFT requirement applications
**Operating temperature range: -20°C ~ 70°C

PMS150C:
**Very Competitive price
**Using 0.18um OTP process
**Good for battery or DC power based products, such as toys or premiums etc.
**Not supposed to use in AC RC step-down powered or high EFT requirement applications
**Operating temperature range: -20°C ~ 70°C
« Last Edit: November 23, 2018, 04:13:14 am by DocBen »
 
The following users thanked this post: oPossum

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 104
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #111 on: November 23, 2018, 11:01:06 pm »
Hi,

I just got my ICE today... and when you connect it and start debugging you can bring up a disassembly window (no opcodes of course but good to verify our stuff).

I created a new project (name "P2") for PFS154 with the following sample code in "P2.C" (no real purpose, just to check the init code):
Code: [Select]

#include  "extern.h"



void<>FPPA0 (void)
{
  .ADJUST_IC  SYSCLK=IHRC/2    //  SYSCLK=IHRC/2


  while (1){}
}

Then I compiled it and now we got 2 outputs:
 
  - "P2_IDE_LST.txt" is what I got from IDE).

  - "P2_DIS_LST.txt" is from my disassembler using the opcodes we found out


You can see that they hide the "secret" checksum calculation part by inserting a bunch of NOPs (actually ICE really executes NOPs only there). There are also some funny instructions in their output (e.g. when there is an undefined IO)

left from IDE / right from custom disassembler
Code: [Select]
...
00000008     MOV ---- A      /         0x0008:   0x019b    MOV IO(0x1B), A  ;
...
00000033     NOP             /         0x0033:   0x0006    LDSPTL       
00000034     NOP             /         0x0034:   0x0b04    XOR [0x04], A
00000035     NOP             /         0x0035:   0x0007    LDSPTH       
00000036     NOP             /         0x0036:   0x0805    ADD [0x05], A
00000037     NOP             /         0x0037:   0x1584    SL [0x04]   
00000038     NOP             /         0x0038:   0x1685    SLC [0x05]   
00000039     NOP             /         0x0039:   0x1004    ADDC [0x04] 
0000003A     NOP             /         0x003a:   0x1282    DECM [0x02] 
0000003B     NOP             /         0x003b:   0x1083    SUBC [0x03] 
...


Unfortunately when I try to make a program with the undocumented instructions LDSPTL and LDSPTH it compiles fine, but ICE also inserts NOPs there so I can not test their behavior (I need to wait for PFS154 to arrive so I can play with the real IC).

Anyway, our opcode table looks very accurate. :)

JS
Please support me by using the AFFILIATE link to LCSC when you order PADAUK parts or tools. With the rewards I can order more PADAUK components for research.

THANK YOU!
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 109
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #112 on: November 24, 2018, 02:21:32 am »
Hi,

I just got my ICE today... and when you connect it and start debugging you can bring up a disassembly window (no opcodes of course but good to verify our stuff).


Is there any way you could determine the type of fpga they are using?
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 104
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #113 on: November 24, 2018, 02:34:09 am »
Is there any way you could determine the type of fpga they are using?

I will try. Without removing the cover it looks like the surface of the big IC was "chinese polished" (with Dremel  :)).

Will post some pictures later.

JS

EDIT:
USB enumeration shows this:
VID: 0x0797
PID: 0x7002
Device String: "LGS_DEV FX2-HID 0.01"

« Last Edit: November 24, 2018, 02:36:17 am by js_12345678_55AA »
Please support me by using the AFFILIATE link to LCSC when you order PADAUK parts or tools. With the rewards I can order more PADAUK components for research.

THANK YOU!
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 109
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #114 on: November 24, 2018, 02:50:43 am »
EDIT:
USB enumeration shows this:
VID: 0x0797
PID: 0x7002
Device String: "LGS_DEV FX2-HID 0.01"

The FPPA_IDE.exe has some strings in it refering to:
L.G.S. TECHNOLOGY CO. ,LTD
K.K.K. TECHNOLOGY CO. ,LTD
Kent Lee Developer Studio Version 2014 and an email adress lgs.........@yahoo.com.tw
http://home.kimo.com.tw/lgs............/WEB_EXE_.jpg
D:\\KentLee\\Custom\\PDK80\\Source\\Refer\\Test_IC\\Wrt_ROM\\Wrt_ROM.txt

Also the device string you found is included in the exe along with some others:
x6337ec 17 16 IDW-360 FX2-HID
0x633800 17 16 PDK-ICE FX2-HID
0x633814 17 16 LGS-DEV FX2-HID
0x633828 17 16 LGS_DEV FX2-HID

0x6338d4 21 20 Writer : PDK3S-P-002
0x6338ec 30 29 Writer : PDK3S-P-002 (No Cap)
0x63390c 21 20 ICE    : PDK3S-I-002
0x633924 21 20 ICE    : PDK3S-I-003
0x63393c 17 16 SOCKET : EV3-004
0x633950 24 23 ICE    : PDK3S-I-004(*)
0x633968 21 20 ICE    : PDK5S-I-S01
0x633980 21 20 ICE    : PDK5S-I-S02
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 109
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #115 on: November 24, 2018, 03:03:07 am »
BTW the FX2 chip used has its firmware programmed on the fly (ie when connecting to USB into its onboard RAM), so it should be possible to experiment with it without any risk of bricking it.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2087
  • Country: de
    • Frank Buss
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #116 on: November 24, 2018, 03:09:45 am »
I got my ICE today as well. Here is a high resolution image: https://i.imgur.com/8yef37g.jpg

The FPGA has no markings. It might be possible to capture the JTAG init sequence, if it doesn't store the configuration data inside the FPGA, because looks like there is no external configuration flash memory.

The USB device is a CY7C68013A, with high speed USB (480 Mbps) and an integrated 8051 CPU, that can be booted through USB (there is an interesting project, which implements a communication through such a Cypress chip to a FPGA over USB, FPGALink). So this could be a very flexible construction, booting first the firmware of the 8051, then booting the FPGA bitstream, all over USB. But I think it might be easier to develop a new emulator than trying to reverse engineer this. Would be nearly impossible to decode the FPGA bitstream back to the HDL code.

"usb-devices" shows the same as js_12345678_55AA wrote:

Code: [Select]
T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=03 Dev#=  9 Spd=480 MxCh= 0                                                                                                                                             
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1                                                                                                                                                 
P:  Vendor=0797 ProdID=7002 Rev=80.01                                                                                                                                                                         
S:  Manufacturer=PADAUK                                                                                                                                                                                       
S:  Product=LGS_DEV FX2-HID 0.01                                                                                                                                                                             
C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=500mA                                                                                                                                                                       
I:  If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid   
So Long, and Thanks for All the Fish
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 109
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #117 on: November 24, 2018, 03:17:33 am »
I got my ICE today as well. Here is a high resolution image: https://i.imgur.com/8yef37g.jpg

The FPGA has no markings. It might be possible to capture the JTAG init sequence, if it doesn't store the configuration data inside the FPGA, because looks like there is no external configuration flash memory.


Does the FPGA have markings on the bottom? It doesnt look dremeled on the top to me.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2087
  • Country: de
    • Frank Buss
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #118 on: November 24, 2018, 03:33:56 am »
I got my ICE today as well. Here is a high resolution image: https://i.imgur.com/8yef37g.jpg

The FPGA has no markings. It might be possible to capture the JTAG init sequence, if it doesn't store the configuration data inside the FPGA, because looks like there is no external configuration flash memory.


Does the FPGA have markings on the bottom? It doesnt look dremeled on the top to me.

I just ordered one of these PLCC remover from China. Will report back in 4 weeks when it arrives :)
So Long, and Thanks for All the Fish
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 109
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #119 on: November 24, 2018, 03:55:10 am »
I just ordered one of these PLCC remover from China. Will report back in 4 weeks when it arrives :)

I try to anticipate these things and ordered my 3.5$ FX2 dev board a week ago  ;)
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 11686
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #120 on: November 24, 2018, 04:55:27 am »
Hi,

I just got my ICE today... and when you connect it and start debugging you can bring up a disassembly window (no opcodes of course but good to verify our stuff).


Is there any way you could determine the type of fpga they are using?
Could be a CPLD - plenty of PLC44 options showing on Digikey for that package. If there is 5V anywhere that would narrow it down a lot.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 109
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #121 on: November 24, 2018, 05:16:36 am »
Could be a CPLD - plenty of PLC44 options showing on Digikey for that package. If there is 5V anywhere that would narrow it down a lot.

I'm kind of hoping for a XC9572XL. It could very well be a cpld because the newest version (5S
-I-S02B dated 2017/7/24) of the ice also uses a socketed plcc44.

On second thought a CPLD probably does not have enough memory on board to emulate a full chip so must be something else.
« Last Edit: November 24, 2018, 05:40:49 am by DocBen »
 

Offline gdelazzari

  • Contributor
  • Posts: 15
  • Country: it
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #122 on: November 24, 2018, 05:46:12 am »
I'm reporting a conversation between me and js_12345678_55AA regarding planning of what to do next (and how) if anyone wants to share its thoughts. Not sure why I didn't directly post here in the forum thread, sorry for that  :-//

The things of most interest are probably the assembler and the syntax

Quote
Hi,

>Hi, do you have any plans to upload your disassembler (and eventually assembler if you have one) to the GitHub organization?

Sure I will do (I just want to structure it a bit more, will take 1-2 days)


>I also have tools in a preliminary state working with the 13-bit and 14-bit ISAs, which unfortunately is duplicate work but I wanted to disasm some listings so I proceeded anyway in implementing them, but that was not a lot of work so it's not a problem for me to trash everything if we want to keep your infrastructure.

All of the code I did is also just for experimentation. Most likely it will be replaced by better implementations later. So no need to keep / stick to something from me right now.


>Also I think we should define a bit how we want to proceed with the assembler.

I did not start with an assembler implementation. Maybe this is something you/somebody else want to try?
I'm already busy reversing stuff and find out how things are connected.
Today my WRITER and SIMULATOR arrived. So now I can start to work with real hardware :-)


>Some stuff to be discussed may be:
>- syntax quirks (how to represent various kind of values/addresses), asm directives, macros, defines, includes, etc...

I did not really investigated on this. I just used a syntax which I thought was good enough for first tests.
Mainly I used the syntax PADAUK used in their manuals. Just to distinguish between RAM / ROM / IO we would need to invent something. Note: The "." syntax is mainly used to represent a special bit (8051 assembly). "[ ]" are used for normal memory access. "WORD PTR" is usually used for 16 bit address references, ... I think we should adapt already known schemes so it easier for others to understand

Creating a document defining the syntax of the assembler would be a good starting point.

I think during implementation of assembler some changes will be required. Since the disassembler is fairly easy to adapt I consider it to follow any syntax changes the assembler creator might need to do.


>- whether to deviate from PADAUK's ASM syntax and implement something of our own, or whether to implement their same syntax for compatibility; or even both at the same time (i.e. a flag to choose the syntax)

One syntax please :-). As close as possible to PADAUK syntax with just some extensions for direct memory/io access.


>- what binary format we want to use across the open source toolchain, i.e. just the raw ROM content on a .bin file, or keeping their PDK format for compatibility with their OTP Writer, or have our own format, or a mix of these three things, or whatever :)

I think we should use the PDK format. The creation for a "liberated" WRITER seems to be the most difficult part which most likely will take the longest time.


>- if it makes sense to keep the ISA description open enough so that it can be imported by someone that wants to implement for instance an SDCC backend or a radare2 plugin to disasm, etc... or just keep it simple and hard coded in the tools

The ISA is so small and simple, everyone can adapt and implement it for a disasm within a few hours. So I think there is no need to be generic here.


>Also, regarding an hypothetical PC simulator (not real time, maybe cycle accurate, or even not) for debugging only:

Why "hypothetical PC simulator"? I finished this task already  8)


>- how that would be presented to the user, i.e.
>- a GUI? With what features? I/O interaction?
>- some kind of simulation you launch and outputs a waveform file in some standard format for inspection later (and that can also accept an input waveform file or some kind of description of what to do with the inputs - i.e. after 0.1s set PA.3 high etc...)
>- a command line tool like GDB where you can single step, inspect memory and regs, run, pause, etc...
>- a combination of some of the things above
>- ...

I was having a look at a 8051 emulator which uses ncurses ( https://github.com/jarikomppa/emu8051 ). This simulator I plan to repurpose for the front end.


>- we'll need our own init code if we want to create a full toolchain you can use from start to finish without touching PADAUK's tools, what should be done in that regard? Should we replicate PADAUK's code (eventually improving it) or do something else? Maybe have different init code options i.e. if you don't need precise clock speeds you can free up space by not having the calibration code, or you can chose to have it, you can have the ROM checksum or not, etc...

The init code is tied to the WRITER which I think we should stay compatible with (see comment above).
Usually this kind of things (init code) is implemented in include (.INC) files which the developer gets automatically in his project when he starts a new project (e.g. from a empty project template).
Then it up to the developer to modify / delete stuff from init code or use different/optimized implementations.


>- least important thing in this message but cool: a library of pre-made routines for stuff like SPI, UART, etc... could be made and optimized by the community. Like a collection of include files "spi.inc" "uart.inc" you can just bring in and use would be pretty cool

Personally I prefer simple sample projects with code snippets I can just cut and paste to my project. I don't like big libraries (like Arduino or STM32). Especially when every byte counts.


>The STM32 emulator you're working on is also vital in the toolchain I think, so keep that up. I started to play around with some methods of efficiently emulating the code on ARM Thumb by checking what assembly GCC generates for various approaches, and it seems like writing the time critical parts in assembly may be the easiest route... GCC insists on keeping the PC/ACC/ecc in RAM but having 12 general purpose registers I think the best thing is to assign the ACC, PC, SP, etc... to a couple of regs and avoid all the LDRs that just slow things down. Of course I may be wrong and there may be a way to write the C code in such a way that GCC does this by itself, but I still didn't find a way. I thought we could map every PADAUK's cycle to 8 cortex cycles with a CPU clock of 64MHz which sounds a reasonable choice given there's the ultracheap STM32F103C8T6 everywhere on eBay, Aliexpress, etc... that fits that frequency, staying in an 8 cycle frame might be viable if most of the stuff is in registers since most instructions take 1 cycle only. Did you make any progress regarding emulation on STM32?

After implementing the FLAG solver for AC and OV i recognized emulation will be quite complex.
Also keep in mind that you need to emulate the CLOCK, IO, PWM, INTERRUPTS, TIMER, WATCHDOG, ...
So I don't think a near real time emulation on STM32 will be possible.

But why not using FPGA? Simple ones are also very cheap. And one guy here in forum already said he would be able to create a FPGA version.


>Let me know what you think about my points and how we should proceed. If we can coordinate at least a bit the work that should be done (and how it should be done) I can start working on some tools.

Creating the assembler would be nice.
I really would love to have an assembler as soon as possible so I can automate tests for the simulator :-)
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 104
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #123 on: November 24, 2018, 07:04:05 am »
Does the FPGA have markings on the bottom? It doesnt look dremeled on the top to me.

Here comes the money shot:

Picture shows the ICE main IC (PLCC 44) from bottom.

Based on the top shape / edge / dot / corner  and the "SCD" marking on the bottom it most probably is a Xilinix.

Shape matches exact this drawing: https://japan.xilinx.com/support/documentation/package_specs/pc44.pdf  Most other PLCC44 FPGA/CLPD have marks on top / 2 edges / no dot in middle / ...



Happy hunting!

JS
« Last Edit: November 24, 2018, 07:19:27 am by js_12345678_55AA »
Please support me by using the AFFILIATE link to LCSC when you order PADAUK parts or tools. With the rewards I can order more PADAUK components for research.

THANK YOU!
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2087
  • Country: de
    • Frank Buss
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #124 on: November 24, 2018, 07:32:03 am »
Reverse engineering the writer firmware might be a good idea, but to be sure maybe would be good to record a programming sequence as well.

I did some tests. I have only some free PMC884 samples at the moment which Padauk sent me. I also bought some PMS150C chips from lcsc.com, as recommended by Padauk, but needs some time until I get them.

First I programmed a blinky program, with all 8 FFPAs and different output frequencies. This is the main file (full project is attached) :

Code: [Select]
// define pin names
Out0 BIT PB.0;
Out1 BIT PB.1;
Out2 BIT PB.2;
Out3 BIT PB.3;
Out4 BIT PB.4;
Out5 BIT PB.5;
Out6 BIT PB.6;
Out7 BIT PB.7;

// FPPA0 is started first
void FPPA0 (void)
{
.ADJUST_IC SYSCLK=IHRC/2, IHRC=16MHz, VDD=5V, Bandgap=On;

// set pins to output
$ Out0 High, Out;
$ Out1 High, Out;
$ Out2 High, Out;
$ Out3 High, Out;
$ Out4 High, Out;
$ Out5 High, Out;
$ Out6 High, Out;
$ Out7 High, Out;

// see datasheet "pmode": FPPA duty cycle, 1/8 for all 8 FPPAs
pmode 31;

// enable all FPPAs
fppen = 0xFF;

// generate test output
while (1) {
Out0 = 0;
.delay 1;
Out0 = 1;
.delay 1;
}
}

void FPPA1 (void)
{
// generate test output
while (1) {
Out1 = 0;
.delay 10;
Out1 = 1;
.delay 10;
}
}

void FPPA2 (void)
{
// generate test output
while (1) {
Out2 = 0;
.delay 100;
Out2 = 1;
.delay 100;
}
}

void FPPA3 (void)
{
// generate test output
while (1) {
Out3 = 0;
.delay 1000;
Out3 = 1;
.delay 1000;
}
}

void FPPA4 (void)
{
// generate test output
while (1) {
Out4 = 0;
.delay 10000;
Out4 = 1;
.delay 10000;
}
}

void FPPA5 (void)
{
// generate test output
while (1) {
Out5 = 0;
.delay 100000;
Out5 = 1;
.delay 100000;
}
}

void FPPA6 (void)
{
// generate test output
while (1) {
Out6 = 0;
.delay 1000000;
Out6 = 1;
.delay 1000000;
}
}

void FPPA7 (void)
{
// generate test output
while (1) {
Out7 = 0;
.delay 10000000;
Out7 = 1;
.delay 10000000;
}
}

/*
void Interrupt (void)
{
pushaf;

if (Intrq.T16)
{ // T16 Trig
// User can add code
Intrq.T16 = 0;
//...
}

popaf;
}

*/

I measured the following frequencies (AVDD needs to be connected as well, otherwise looks like the internal oscillator doesn't run) :

Code: [Select]
PB0: 203 kHz
PB1: 44 kHz
PB2: 5 kHz
PB3: 508 Hz
PB4: 50.8 Hz
PB5: 5.08 Hz
PB6: 0.5 Hz
PB7: 0.05 Hz

Nice about the PMC884 is that you can select the duty cycle scheme, e.g. if you want to run FFPA0 more than the other FFPAs. So this was just a first test to see if everything works.

Then I tried to measure the programming signals (as David already noted in his video, you can program the OTP chip as often as you want, if it is the same bitstream). But connecting GND of the scope to the GND pin of the microcontroller was not a good idea, because the programmer tests all pins for shorts and then doesn't start the programming sequence. But here is a nice GND point near the jumpers at the back:



Then I measured some pins. In David's video it was difficult or impossible to see the timescale. Here is an example for pin 3, this time with proper time scale, for the whole programming cycle:



This is a data pin. Pin 19 is a clock pin. When I zoom in, it looks like this:



Looks like about 1 us is the shortest signal length. Might be good to sample it with 10 MHz for higher resolution.

I don't know how many signals I need to scan in parallel, 2 might be enough with multiple passes, but maybe 4 would be better and easier to analyze later. If I use an 8 bit ADC, this would mean a data rate of 320 Mbits/s. Might be possible with high speed USB to transfer it in realtime on a PC. As you can see in the first scope image, the whole programming cycle needs about 800 ms (the spikes before and after are the detection of the programmer if there is a chip, which does it all the time). So a full sample with 4 channels would need only 32 MB. This could be even done with a BeagleBone and its PRUs, a simple external board with 4 ADCs and input stages for dividing the input voltage, and then recording it to memory.

But I don't have much time at the moment to build the board and program the Beagle Bone. Is there already such a thing I can buy, which records 4 channels with 8 bit at 10 MHz for 1 second?

PS: Anyone who wants to swap some PMS150C (or other Padauk) chips for PMC884? I have 100 x PMC884. Here is the datasheet.
So Long, and Thanks for All the Fish
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf