Need software for Intelligent universal programmer lk48

[coromonadalix]

Anyone tried 4.10 to 4.20 ?

[stj]

maybe they cant brick the 3.10 based units.
why include a 4.10 rom with the fix unless 3.10 cant write to the mcu!
either way,nobody has been bicked by the license patching- if there is a bricking routine then it's checking the hardware rather than the software.

[stefankd]

they could have bricked and then un-bricked a programmer while using a logic analyser or debug-pod on the atmel.
it's also possible they just analysed how it interacted with the programmer and wrote a black-box replacement complete with a patched eprom to not try to check it again.

using an mcu as protection only buys time, it's not actually secure.
i work with arcade equipment, such mcu use is common and regularly cracked.

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, the MCU only enables it when the authentication is done successfully. so, that was an extra "catch" to make it harder to understand what's going on, i.e. it needed both the software to be patched and the PCB be modified.

there is another dump on the web for free loll was supposed to be an original, wich i doubt, see the contents vs the submitted one (the fix ?)

that 2nd one is even more obviously wrong, that is just "standard" test pattern to see if every byte of a memory can be written and read properly. also, do not forget that ATtiny12L has 1K of Flash and 64bytes of EEPROM. so, at least, I presume a proper dump either consists of 2 files with 1024 and 64 bytes in size or one file with size of 1088 bytes.

anyway, one more time - if your programmer stops working and there is nothing obvious that is blown, then most likely its U62 and maybe some day a real solution will be found.

[coromonadalix]

there is another dump on the web for free loll was supposed to be an original, wich i doubt, see the contents vs the submitted one (the fix ?)

[stj]

they could have bricked and then un-bricked a programmer while using a logic analyser or debug-pod on the atmel.
it's also possible they just analysed how it interacted with the programmer and wrote a black-box replacement complete with a patched eprom to not try to check it again.

using an mcu as protection only buys time, it's not actually secure.
i work with arcade equipment, such mcu use is common and regularly cracked.

[stefankd]

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 that "ATTiny 12L" cannot be dumped and replicated due to its security features and hence the empty "ATTiny 12L" dump included in "LabTool-FIX.rar". that is what makes most sense to me at the moment and actually puts all those things nicely together.

[stefankd]

the rule about links is simple,
you cant link to sites that charge for downloads.
i'm not even sure you can name some of them!

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

[stj]

the rule about links is simple,
you cant link to sites that charge for downloads.
i'm not even sure you can name some of them!

[stefankd]

would you share in private this labtool-fix thing ?

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 computer. so, it could be they keep statistics the same way how many times "Security Check Error!" occurred and brick after particular number (ATtiny1x has both Flash for the MCU code and EEPROM memory) or it could be the security measures are further relaxed when OEM units is used with the AEC-branded soft, etc.

also, how many young people, not knowing the history - if their programmer fails today, will even suspect it was bricked due to security measures - in my opinion they will just decide that 15-20 years old programmer time to die just came and not that it was perma-bricked as part of security measures.

worst of all scenarios is if U62 cannot be eliminated, i.e. if on top of its security-related functions it has also other functions like initialization of some of the other ICs, etc and so without some form of functioning U62, the work is just impossible, i.e. that it cannot be fully eliminated, but it needs it code be replaced with custom one that still performans that other not-security-related tasks.

one last thing to mention, because I believe I've already mentioned everything I know or rather that I don't know, but in I believe it was 2012 there was another "hack", i.e. "clone" of just U62 (not a whole units like in 2007-2008) and the hackers sold on places like eBay that as hardware kit called "lab tool-FIX kitt" (yes, "kitt" written with double "t"). that hardware kit consisted of W27C512 (with some form of FW 4.10 on it) and "ATTiny 12L" - I remembered about that now, because above I mentioned that U62 has both Flash and EEPROM memory and "ATTiny 12L" has 1K of Flash and 64bytes of EEPROM to be exact. so, definitely "ATTiny 12L" is compatible with U62.

[toriman]

Hi,

Thank you all.
This thread is great.

Regards
tOri

P.S. aec.com.tw is now stuck at 404 error seems server is alive. maybe they change or rebuild something hard?

[stj]

1.xx is for the 40pin programmer (NOT LV i dont think)
2.xx is for the older 48pin programmer,
3.xx is for the xp
4.xx has the string "uxp" in it.
makes me wonder if 3.xx doesnt use the usb port?

https://www.mikrocontroller.net/atta...abTool-FIX.rar

[coromonadalix]

stefankd would you share in private this labtool-fix thing ? i would like to check a few things in it ...

but the 4.20 firware was dumped if i recall, and i did backup mine (chipmaster 6000 xpu) both seems to be identical, i never had the older ones

this page has 2x 4.20fw dumps ?? https://www.stevenrhine.com/?p=133699

Even an old 2.20 too ??? and an XP 3.30 ??

Thks for your patience

[stefankd]

what's this about 4.10?

...
i'v only seen 3.10

the significance of FW version 4.10 is that the original unit that was "cloned" in 2007 and based upon which all those counterfeit units were made had that FW version and hence it was the FW version that was installed on all "cloned", i.e. counterfeit, units. so, it's an original FW made by AEC, but because of that found both on genuine and fake units - as result of that all perma-bricked including genuine units were running that FW. however, just at the time, i.e. 2007-2008, it was the latest FW version available and thus what most of the units were running. there is also at least version 4.20 of the FW - I don't know for any newer. BTW, maybe, it's rare 4.10 unit survived to this day due to the perma-bricks. maybe, one of my hypothesis is that FW 3.10 lacks "infrastructure" to talk with U62 in way it can perma-brick it (i.e. by that I mean it provides only "read", but not "write" access to U62). that can give one explaination why no perma-bricks are reported here (at least not yet).

does anybody have a dump?

please, refer to 2nd paragraph of my post above about the "LabTool-FIX.rar" - it contains FW 4.10 dump. however, maybe that is not the "exact" 4.10 dump from an original unit, because it's FW 4.10 that claims can fix and recover perma-bricked units. also, thinking more about it - maybe "LabTool-FIX.rar" contains "empty" U62 "ATtiny1x" MCU dump, because if it's really patched to address the perma-brick, maybe how they "severed" the U62 communication still needs basically an empty ATtiny1x present - maybe to stop some negative responses for a missing ATtiny1x altogether on the data-bus. IDK, but that is the 4.10 dump available at the moment at least to me - I haven't any original FW 4.10 made from an working original unit to compare with what is inside "LabTool-FIX.rar".

if i still had the xp i would be tempted to strap a logic analyser to that atmel mcu

presumably all the communication is encrypted. at least the "re2" logs that AEC own tool generates is total none-sense of bytes (again at least to me those bytes make no sense at all) . BTW, the "custom exe" they generate to reprogram the U62 based on logs such as "re2" is totally individualized per unit - I don't know based on what - some cryptographic negotiation (and per unit Keys) or based on SN or what, but AEC own "custom exe" that can recover one unit cannot run on another. however, I know nothing about it, really and those are total guesses.

[EDIT] also, I think installing any 4.10 on 3.10 unit with U62 present is very risky, beyond risky! IMHO, if someone wants to hack and investigate - best would be to de-solder and remove the working U62 and try different FW versions, patches, etc without U62 present and chance that working U62 be destroyed, i.e. be perma-bricked. maybe capturing U62 communication is OK, but only with currently installed FW in the unit like 3.10 and not change to 4.10.

[stj]

what's this about 4.10?
does anybody have a dump?
i'v only seen 3.10

if i still had the xp i would be tempted to strap a logic analyser to that atmel mcu

[stefankd]

thks for the info's and pointers ...

no problem, in fact as I said it's a very long story and I shared just very small fraction of it, because in the past those were so expensive and they are still very useful - it was very painful to anyone ending with a perma-brick, but not real solutions were found.

there is 15 years old file called "LabTool-FIX.rar" - still available for download after so many years - I won't post link here, because it's in a 3rd party forum and I am not sure if that is allowed. it contains copy of the FW 4.10 and an empty (i.e. wrong, because it's just impossible to make one) U62 "ATtiny1x" MCU dump - that's why it's reported as not really working, but I don't know much about it - in fact it's interesting if the included FW 4.10 is the original one or patched version to remove some of the protections, i.e. in case the FW "talks" to U62, not just the software, which definitely "talks" to U62. again, I cannot tell, because I myself don't have FW 4.10 dump from an original unit.

also, there is tool called "Lt48uxp_utils.exe" that is made by AEC, but its real purpose is not clear to me - it creates "re2" dump files, which are like more detailed "rep" files that their main software creates during "Self Test" - it seems those "re2" dump-files contain very detailed information for the Cryptographic-Security State of the U62 MCU.

Hi!
I have now two MINATO1881XP units. One was upgraded to XP and have a translucent sticker. This may explain, in light of what you wrote, why my programmers work and were not blocked despite "cheating". Interestingly, I'm using the software without any major problems. Every now and then, a "Security Check Error!"

P.S. I checked my both programmers and they have 3.10 firmware running (far away from 4.10 ;-)

yeah, Minato units are very common to have an upgrade sticker, i.e. that earlier 48/48LV unit was upgraded to XP or even to UXP - I have saved picture of such programmer in my archives - attaching it.



also, those stickers glue by now is very weak and always need to look very carefully to determine by other means the exact model - I have a friend who scored Minato unit upgraded to UXP for next to nothing, because the sticker felt off and it was sold by the presumption that it's just 48LV. so, always look the back of Minato unit not what it says on the cover for model: 48/48LV has 2x DB9 ports, XP has no USB port, UXP has USB port.

My best guess about "Security Check Error!" and why they don't permanent brick in such case is that they receive answer from the U62 that tells them it's original unit from some of their OEM Partners. It's still wrong answer for AEC-branded software, hence error is generated, but as I said it will be a huge disaster if they brick an OEM unit just because the user "by mistake" installed/executed the AEC-branded software version instead of the OEM-branded versions of the software. In the past I compared the same EXE from AEC-one and Minato-branded of the same software version and they hardly have any same bytes - they looked like totally separate builds.

in any way, those programmers will really be freed and serviceable/repairable, when someone manage to make them work without U62 - when I was young, I have such ambition to try, but I never did and back then I even buy some empty ATtiny12 MCUs - the board has space even to install DIP-8 socket for the U62, i.e. easy to replace or for doing experiments without need to solder.

BTW, AEC website is still down and so maybe - that's it for them and 14.30 will be the last ever software release...

[toriman]

Hi!

Thank you @stefankd for detailed info. It is very interesting and it seems to confirm my fears about the possibility of killing the programmer. I have now two MINATO1881XP units. One was upgraded to XP and have a translucent sticker. This may explain, in light of what you wrote, why my programmers work and were not blocked despite "cheating". Interestingly, I'm using the software without any major problems. Every now and then, a "Security Check Error!" message appears and the program switches to demo mode. After a software restart, everything works normally until the next message appears. Now I'm wondering if I can safely debug and patch the code without the risk of hardware lockup. I found some places referencing Software Security Error procedure, so it would only be a matter of time to find a good patch for it. We don't know if new updates will be released and whether they will be harmful to our devices. Perhaps AEC has stopped working in the business, as you wrote. Let's wait and be careful in the future.

Anyway

I don't care about this error, so I'd rather leave everything as it is now since it doesn't really bother anyone Risk will be minimized low as possible.

Regards
tOri

P.S. I checked my both programmers and they have 3.10 firmware running (far away from 4.10 ;-)

[coromonadalix]

stefankd thks for the info's and pointers ...

[stefankd]

hi All, i've just registered to this forum, because of your discussion in this thread and so I can participate and comment on few of your points.

BTW, AEC website is down for several days already - I am not sure what is the case - maybe they went out of business?! I see that as highly unlikely to happen so suddenly, but it's also highly unlikely website of a functioning company to be down and offline for such a prolonged period of time.

can render the programmer unusable/bricky like counterfeits

actually, in 2007 when the faked/cloned UXP units flooded the market, AEC bricked them all and it's a perma-brick, i.e. it's permanent and it cannot be fixed (more how they achieved that I will explain in my comment to stj below) - they did it even on the expense of the original units - by that I mean they bricked even their own genuine units. however, for the original units they provided very complicated recovery procedure. it's a very long story, I will share more details below, but it's one reason I wonder why what you're doing here haven't resulted in such perma-bricks (yet) and I have few ideas, all of them of course just possible hypothesis: 1) all faked/cloned UXP units were with FW version 4.10 and thus all known bricked units (even the genuine ones) were with FW version 4.10. so, maybe their software checks the FW version first and if the unit has FW different than 4.10 doesn't consider it can be a faked/cloned unit and thus doesn't care to perma-brick it; 2) based on SN or something else they determine you're using OEM unit like Dataman, etc and that's why they don't perma-brick it - that will be a disaster for their OEM partners and like Dataman, etc and their customers, because their OEM partners don't have the ability to recover such units plus all faked/cloned units were Labtool-branded and maybe OEM-branded one are excluded from such radical security measures.

i dont see how they can brick the parallel port one

you cannot be more wrong on this - in 2007/2008 they perma-bricked both XP and UXP units, as I've already mentioned even their own genuine units. the key to that capability is "U62" located on the "Control Unit" board (i.e. the bottom PCB). that IC is MCU used for their security algorithms. they sanded down the IC markings (or on newer units even put fake markings on it) to further obscure it, but it's "ATtiny12" MCU. there is rumors the oldest units use "ATtiny11" MCU, but that doesn't really matter, because "ATtiny12" can run "ATtiny11"-code in compatibility mode plus they both are pin-compatible. so, their security code is probably "ATtiny11"-compatible, i.e. it doesn't use any extra "ATtiny12"-features. in any way, ATtiny11/12 MCUs cannot be dumped and hence replicated, because there is no known security hole/exploit that allows that to be done. most likely faked/cloned UXP units back in 2007 were made with "decapping" the MCU and reading under microscope the code inside it bit-by-bit (that's why all cloned/faked units use the same SN). so, if their software "decides" the unit must be bricked the user is f-ed beyond any way to repair it hence the perma-brick, because they re-write the MCU code with bad one.

BTW, maybe here is good place to mention that the first software version to support UXP is 6.0 and latest version known to work with "cloned" units (or if you wish safe to use even with original units as it cannot brick them) is 6.80. after that they implemented different levels of protections and version 7.30 already has the permanent brick "feature".

so, I am attaching here screenshot copy of their old PDF with the very complicated procedure how an original bricked unit (i.e. bricked by mistake) is recovered:




as you can read "custom exe" specific to each such unit that re-programs the content of the ATtiny11/12 MCU was manually prepared and issued by AEC to the owners of legitimate units. AFAIK, they no longer even provide such service.

UXP model to mess things up in the cypress fx2 usb to mcu interface, you would need to re-write the vid pid ... or reflash the eeprom who goes with it ?

i dont think they use the eeprom option,
i think they just download the firmware when the driver detects it.

there is "Atmel 24LC02B" (or similar) EEPROM that contains the USB VID/PID for FX2, based on those VID/PID the software loads appropriate version of the FX2 firmware each time. so, the FX2 EEPROM doesn't contain any firmware.

in conclusion there are 2 types of errors that the software reports "Security Check Error" those mean the Security ATtiny11/12 MCU responses are wrong and based on how wrong they are then the software can decide to perma-brick the unit. the other errors, those about "Demo Mode", are just related to the software license.

BTW, the 2 older 48/48LV models don't have Security MCU and at least I believe that is the main reason why they are limited to 4.67 version of the software - I believe, but that is just a speculation on my side, that if all Security MCU checks and "the permanent brick feature" are removed (patched) then probably newer software versions will work with 48/48LV too. of course, maybe the FW that is on XP/UXP control board also contains code that "speaks" to U62 and refuse to execute properly all its functions if U62 is bad. otherwise the safest would be to remove the U62 and patch the software until it works without U62 in place - that way there is no chance of perma-brick, because there is no U62 to be re-written by the software. unfortunately, currently if U62 fails for any reason - there is no way to repair the unit.

[stj]

i dont think they use the eeprom option,
i think they just download the firmware when the driver detects it.

[coromonadalix]

What i never saw, is a past due / over 2 years license file to check a few things in it, must surely works with the time and date of windows, not sure it would use some regisrty location of some sort , one of the trick was to include the license in the exec file ...

Once the usb drivers are installed, you can remove labtool folder completly and use it on a usb key etc ... but it still create the labtool folder in windows document ...

as for the UXP model to mess things up in the cypress fx2 usb to mcu interface, you would need to re-write the vid pid ... or reflash the eeprom who goes with it ?