more findings (which i am going to organize in separate points below) and a questions that someone reading here might be able to help with (it will be very appreciated):
1. "the ICTEST.exe": it turned out it's doing the communication with the device in a different (you can say more efficient) way than how that's done in Windows. initially, it made my head spin not getting what's really going on, but in essence - in DOS (at least "ictest.exe") is reading back the nibbles in a way that results in 1st Least-Significant-Nibble (LSN) is read/returned and then the Most-Significant-Nibble...
stefankd
Member
Last Activity: 08-27-2026, 08:19 AM
Joined: 07-05-2026
Location: Sofia
-
it's just what they did is very inefficient - come on - almost 1000 lines of code in C just to get the DEV_ID and FW_VER. even more the SPP with Nibble encoding is just small portion of the overhead, in fact the smallest one. IMHO, the biggest overhead comes from the use of Jungo WinDriver and the way how they implemented that additional layer. it also adds another problem, as I already mentioned:
and that way making the current state of what I did not possible to be actually open-sourced (at all) - it's mostly useful experiment for understanding the communication...Leave a comment:
-
I am not sure I understand what you mean, because my goal is to port the DOS tool "ICTEST.exe" (available only for 48/48LV) to Windows in order to have Bit-banging capabilities from the host and thus be able to implement custom programing algorithms for unsupported devices. also, if you follow the analysis here:
https://hackmii.com/2009/02/48uxp_sw/
and compare 48/48LV and 48XP/UXP Bit-streams for the same chips - they are the same, i.e. basically that means the schematic of the Top-Board inside of those programmers is the same.
now,...Leave a comment:
-
fixed that problem and it's not related to:
and so I still cannot do proper WinDriver's "multi-transfer" as described in "perspective B", but that is irrelevant for the time-being - that will be important when work on replacing the original AEC *.SYS, but currently my replacement EXE is finally able to "call" the original AEC *.SYS and instruct it to do the WinDriver's "multi-transfer".
so, the problem from "from perspective A" of course was memory corruption - I still don't fully understand...Leave a comment:
-
good news and bad news:
* the good news is that i managed to fix all WinDriver related structures and memory allocations, i.e. no longer BSoD and crashes. that lead to proper communication between my own EXE client and AEC *.SYS LPT drivers - I can send commands to the *.SYS and receive proper answer - the example below is the first Command send by AEC original EXE, "Get_Driver_Version" (its ID is 0x2f), but this time send by my own EXE and obviously the answer is correct (please, note that "LTKP1 Driver V1.58 for ADVANTECH EQUIPMENT CORP." is no where coded in...Leave a comment:
-
of course, I've already done that - otherwise how I would have found how to patch the original AEC *.SYS and the EXE to work with WinDriver 5.03 (instead the original v5.05 used by AEC) and without such patch - nothing further is really possible (or possible, but involves a lot more work to write code to emulate the whole WinDriver environment instead just use it).
essentially, we don't need custom bitstreams as far as there is way to control the pin bit-banging and the voltages from the host like "ICTEST.exe" is doing for 48/48LV, which is still...Leave a comment:
-
made key progress on that, because i succeeded in patching "LTKP1.SYS" and the EXE to use "Jungo WinDriver v5.03" - why that is crucial first step - because AEC used WinDriver v5.05 to develop the LPT drivers, which is long gone. however, version 5.03 is still available and "archived" for example here:
http://old-dos.ru/index.php?page=fil...show&id=105703
the *.SYS and the EXE have 2 checks - very easy to find using 0x1F9 (505) as a clue - just change it to 503 (0x1F7) and that's it. so, while I did it with...Leave a comment:
-
that's actually very complicated and since there is no way to analyze the XC3030A bitstreams and thus create our own such bitstreams it leaves really only one option - if there is XC3030A bitstreams and/or FW functions that allows:
1) pin bit-banging from the host
2) control the DACs output/the voltages of each pin
which will make possible new programming algorithms (for unsupported devices) to be implemented from the host, i.e. use the current software for what it already supports and above to allow adding new device support with the algorithm...Leave a comment:
-
yep, I totally agree with you! those 0x34, 0x31, 0x30 seems to be just ASCII for each digit of the FW version, i.e. ASCII 0x34 = 4, ASCII 0x31 = 1, ASCII 0x30 = 0 and hence firmware "4.10" and the other 2 bytes form "48", i.e. the ID of the programmer.
indeed, the software is just a front-end, it selects and sends the "program" from those "*.rez" files for each particular IC and hence the actual bit-banging of the pins is done entirely in hardware and it's done in such way and so the actual programming algorithm...Leave a comment:
-
my main point though is different and it is that there is no "pp: rd" on my log anywhere and yet the FW revision information is properly exchanged, which leaves only 2 possibilities (IMHO):
1) there is bug in QEMU logging, i.e. what I wrote in my previous post as possibility about the "pdebug() calls" and that is why no such "pp: rd" is logged (BTW, that is now ruled out as you will read below)
or
2) if QEMU logs everything properly, since obviously there is no any read-backs of the Parallel Port "DATA"-register,...Leave a comment:
-
you're probably right and so far even that simple comms log I cannot make any sense of it - it's consistent though - by that I mean every time I run AEC software that is the log I get after the software shows "Labtool-48 found" and "Firmware version: 2.20".
however, I see nothing in that log that can resample anything "structured", I mean I was expecting to see something like "GET_FW_VER_COMMAND" send and then response with "2.20", but I see nothing like that to a point that I wonder if in QEMU source code:
...Leave a comment:
-
I forgot to mention that the above log was made when using FW 2.20 unit with "ICTEST.exe" from software v3.71. so, according to the Archive.org copies of AEC website:
and FW 2.20, I believe is just version of 2.10 for the next production, i.e. with minor changes to reflect the next production batch, but not any changes in the communication protocol. so, we can say that up to FW 2.20 the communication protocol is the same. (and is what is in the log I made).
then again according to the Archive.org copies of AEC website:
...Leave a comment:
-
thank you, those are great!
yeah, in that regards AEC programmers are one of the most freedom-friendly.
BTW, for those of you that like number puzzles - I built modified QEMU:
https://github.com/qemu/qemu/blob/ma...har/parallel.c
with un-commenting:and passing the HW LTP port on my motherboard to that modified QEMU allows to capture the AEC software communication with the programmer - the below log:Code://#define DEBUG_PARALLEL
...Code:pp: rccc pp: wcce pp: rcce pp: wccc
Leave a comment:
-
thank you all for the PDFs/URLs! IMHO, at this point, it's best if someone is interested enough to setup some web place where people can put their AEC archives, etc and build up the collection to as full as possible, instead of dealing on file-per-file basis. BTW, I've found here:
https://asix.tech/_museum/programmers/aec/
DOS software (v4.61, the latest is v4.71, but v4.71 is available on Archive.org) for the original 48/48LV model.
what is unique about the above URL is that it hosts probably the only copy left on the web...Leave a comment:
-
do you have "Model-1881UXP_ALL.pdf" ("Model-1881UXP Version 14.20 Device List" document) as well? or any other "Version 14.20 Device List" PDF? I mean anyone know which exact devices support was added between those 2 latest versions 14.20 and 14.30?
I used to try checking AEC website as often as I can and so I can get consecutive versions of the software together with the PDF in order to know, which exact devices support was added between 2 versions and maybe some day with comparing such 2 consecutive versions figure out how to add device...Leave a comment:
-
that is one of the many possible options, i.e. maybe FW 3.10 doesn't provide write-access to U62.
i believe 4.10 was included just because that FW was on the original unit they owned/cloned - by "they" - I mean the hackers, not that's any proof 3.10 cannot write to U62.
so far true, but...
...the pure software licensing check you no doubt patched otherwise the software will be useless and in "Demo Mode", but using the AEC-branded software patched in such way on...Leave a comment:
-
thanks, those are interesting scenarios and options. I myself know almost nothing about those things even over 10 years ago I "cracked" a PCB protected with an MCU from cloning, the idea of the protections was as follows: the MCU and software do cryptographic authentication, it was easy to "sever" the software from not doing such authentication and still "thinks" the authentication passed and the PCB is genuine, i.e. the easy part was to cut the software to "speak" to the MCU altogether, but then one of the power-rails on the PCB was disabled,...Leave a comment:
-
just to add: now, decades later, thinking more about it and due to the obvious similarity in the names of "LabTool-FIX.rar" and the actually working hardware kit "lab tool-FIX kitt", I start to believe that whoever made "LabTool-FIX.rar" is someone who bought hardware kit "lab tool-FIX kitt" from the hackers that were able to clone U62, fix a perma-bricked unit with it and then made "LabTool-FIX.rar" with dumping the included W27C512 and "ATTiny 12L" in the hardware kit "lab tool-FIX kitt" not actually realizing...Leave a comment:
-
thanks for the clarification of those rules. it's still good you found the link on your own and shared it here. it's also amazing it survived 15 years and it's still available. if someone still can find working original unit with 4.10 and dump the FW from it - I guess it will be still useful for comparison with what is inside "LabTool-FIX.rar"....Leave a comment:
-
it seems @stj already posted the link to the file and he did from the exact 3rd party forum I mentioned I was not sure it's allowed to be shared.
IMHO, the biggest problem is that we don't know under what circumstances the software decides to perma-brick.
all kind of very evil scenarios are possible: for example, we know the programmer keeps usage statistics for how many times its used and that is saved in some of the eeproms, because its statistic that survives particular installation, i.e. it moves together with the programmer when it's connected to another...Leave a comment:
No activity results to display
Leave a comment: