Xaver wrote:

> but so
> far, I haven't found any project addressing this.

Because there is no sense do perform a re-engineering under the given 
circumstances. It's much easier to do the whole work self again.

The major part of the work is to collect the details of the programming 
strategies for the several targets. It's a job für cheap practicants 
(but not to cheap).

The remainder (create hard- and software for the programmer itself) is a 
trivial task for any expirienced embedded developer team.

If you want tu circumvent this:
-use windows
-use the provided software
-and die

While the PC application is well protected, the USB channel seems like 
an easier starting point. Using Wireshark, I captured a .pcapng file 
that contains the entire process, from connecting the programmer to the 
USB port to closing the application.

The capture includes the following steps: connecting the programmer to 
the USB port, launching the RT809H.exe application, selecting the memory 
type (NM27C512), which triggers the transfer of configuration data to 
the FPGA, inserting a blank memory chip (all 0xFF) into the socket, 
reading the memory chip's content, and finally closing the application.

The communication is extensive, consisting of 28,754 USB packets in 
total. I am sharing this capture for analysis. Interesting activity 
occurs on endpoints 1.3.0, 1.3.1, 1.3.2, and 1.3.3. The FTDI chip 
switches into MPSSE mode, possibly emulating JTAG.

The process becomes particularly interesting around packet 8867, which 
seems to be a query from the application to the programmer, with the 
response in packet 8869, possibly identifying an unprogrammed FPGA. 
Other noteworthy packets include 8949, 8951, and 8953, though their 
purpose remains unclear. Similarly, packets 9021, 9023, 9303, 9305, and 
9307 are worth investigating further. Packets 9375 and 9377 appear to be 
similar to 8867, likely forming another query-response pair, while 
packets 9441 and 9443 also stand out.

The transfer of the FPGA configuration occurs in packets 9445, 9741, 
9879, 10175, 10315, and 10605. I manually compared the beginning of the 
payload in packet 9445 with the start of the file ALGO_M27C512.DAT and 
the end of the payload in packet 10605 with the file's end, excluding 
padding bytes of 0xFF. The data matches, confirming the configuration 
transfer. Packets 10967, 10969, and 10971 are noteworthy but their 
purpose is unclear. Packets 11039, 11041, 11107, and 11109 likely 
involve identifying the loaded gateware. Packets 11175, 11177, and 11179 
are also noteworthy.

At some point in the communication, the software detects memory 
insertion or contact. The application visually displays a bitmap of the 
memory socket with pins highlighted in red when there is no contact. 
This behavior could correspond to packets such as 12977, 12979, 12981, 
or 13245, which might represent a delayed response.

The commands to read the memory chip seem to be in packets 28537 and 
28539, with the read data transferred in packet 28541 and completed by 
packets 28631 and 28633. The remainder of the capture involves closing 
the application.

I also tried replicating the USB communication using a Python script. 
The frame recordings are stored in separate .json files, and the FPGA 
configuration is identical to the file found in the RT809H.exe 
application's /LIB folder or extracted from the .pcapng file. This 
approach prevents the code from becoming unnecessarily large. The script 
is still in its early stages and currently lacks a proper reset 
sequence, so I need to power cycle the programmer before each launch. 
Receiving and writing data to the M27C512 is not yet functional, but 
Wireshark shows that a significant amount of 0xFF data is being 
transmitted, suggesting that data is being sent to the PC.

Xaver