Alientek T80/T80P

[vulpes2]

Looks like Alientek released their own irons that use JBC cartridges as well, the pricing seems reasonable too. The T80 uses C210 cartridges, and the T80P uses C245 cartridges. I'm creating an issue to keep track of these two devices in case anyone is interested. From the teardown pictures, the build quality is similar to the S60P, but it does come with an aluminum case instead of plastic.

Teardown images I found on reddit: https://old.reddit.com/r/soldering/comments/1cm03vg/jbc_style_usb_soldering_iron_roundup_teardown/

Porting requirements

1. ✅ Supported processor: CH571F, RISC-V
2. ✅ 192KB of flash
3. ✅ 16KB RAM
4. ✅ Device has one or more heating elements that can be controlled by a main temperature sensor
5. ❔ I'm not sure if the board has a cold junction sensor or not
6. ✅ Means of the user updating the device without opening
7. ❌ Known pinmap for the microcontroller

Soft requirements

1. ✅ USB-PD
2. ❌ No schematics available
3. ❔ No idea if the vendor is friendly or not
4. ❔ Needs reverse engineering or schematics for confirmation
5. ✅ Not an STM32 clone

[Ralim]

These should be doable for support; but to be honest I'm unlikely to prioritise them just due to time. If someone would want to pick up the work for porting to these I'm happy to provide help.

[gammeflamme]

https://github.com/user-attachments/assets/402540d0-a60c-483f-b0f4-71ba28cceb6a https://github.com/user-attachments/assets/b15057de-8180-4012-ab60-3363d3df7512

Some scans from a T80P to help with schematic reverse engineering. Would love to have some open source firmware on this thing, I miss having live wattage readout.

[hattesen]

I have just received a T60P and have ordered a T60, which seems to be virtually identical hardware. I will prioritize to try to reverse engineer and create a schematic diagram (in KiCAD) and make that available in a GitHub repository along with a generated PDF version. I can assist with testing new firmware, but I don't have the resources to help with the required IronOS changes.

Would the Alientek T60(P) development happen in a git branch of the IronOS repository, with pull requests, until officially supported?

[vlad-mod]

After some looking around i found out that .atk file is just plane firmware with attached binary header of 32 bytes, Sniffing with wireshark while updating firmware shows that first 32 bytes of .atk file are not send to the device, while rest of file is sent without any modifications. It looks like first 16 bytes are name. I managed to modify .data section of firmware and modified one of used sprites(2 vertical bars). Provided update tool did not complain when uploading modified firmware.

[vlad-mod]

swd seems to be disabled, didnt spend much time with that but there is active communication and all connection tries didnt yield any meaningful results.

[vlad-mod]

I've managed to decompile upgrade app and found header definition:

|41 54 4B 2D 50 54 54 38 30 50 00 00 00 00 00 00|     3A   |      28     |  2D 01   |  64 00  | 61 3F |       4C 40 01 00       | E9 07 |   04   | 1D  |firmware...|
|                 name 16 bytes                 | data_len | encrypt_pos | app_addr | app_ver |  crc  | size of firmware 4bytes | year  | month  | day |firmware...|

I've also managed to compile custom firmware that just sets one of the pins to high, calculated correct crc and flashed it to the device. But it seems like firmware must be somehow encrypted, original firmware can be partially decompiled, but some parts are corrupted or dont make any sense, and flashed firmware does not in fact work.

For example, here is part of vector table from original firmware(decompiled with radare2)

0x00000020      6f7f2f35       jal t5, 0xf7372     
0x00000024      6f6f6f6f       jal t5, 0xf671a  
0x00000028      6f6f6f6f       jal t5, 0xf671e        
0x0000002c      006f           ld s0, 24(a4)                
0x0000002e      ef67007f       jal a5, fcn.0000681e    
0x00000032      6f796f6f       jal s2, 0xf7728        
0x00000036      6f6f6f6f       jal t5, 0xf672c     
0x0000003a      6f6f6f6f       jal t5, 0xf6730          
0x0000003e      6f6f6f6f       jal t5, 0xf6734         
0x00000042      6f6f6f6f       jal t5, 0xf6738          
0x00000046      6f6f006f       jal t5, fcn.00006736      

first entry must be jump to the reset handler, but instead it jumps to some strange address outside of flash ( entire flash size, including built in bootloader, is 0x7FFFF)

One of the solutions is to rewrite the entire firmware with a custom bootloader and IronOS, but this requires use of wchisp and shorting one of internal pins to the ground, which isnt that bad, and seems to be only solution. Moreover i accidentally cleared the entire flash while playing with wchisp, so for me this is the only solution.

[m1nl]

I've managed to decompile upgrade app and found header definition:

|41 54 4B 2D 50 54 54 38 30 50 00 00 00 00 00 00|     3A   |      28     |  2D 01   |  64 00  | 61 3F |       4C 40 01 00       | E9 07 |   04   | 1D  |firmware...|
|                 name 16 bytes                 | data_len | encrypt_pos | app_addr | app_ver |  crc  | size of firmware 4bytes | year  | month  | day |firmware...|

I've also managed to compile custom firmware that just sets one of the pins to high, calculated correct crc and flashed it to the device. But it seems like firmware must be somehow encrypted, original firmware can be partially decompiled, but some parts are corrupted or dont make any sense, and flashed firmware does not in fact work.

For example, here is part of vector table from original firmware(decompiled with radare2)

0x00000020      6f7f2f35       jal t5, 0xf7372     
0x00000024      6f6f6f6f       jal t5, 0xf671a  
0x00000028      6f6f6f6f       jal t5, 0xf671e        
0x0000002c      006f           ld s0, 24(a4)                
0x0000002e      ef67007f       jal a5, fcn.0000681e    
0x00000032      6f796f6f       jal s2, 0xf7728        
0x00000036      6f6f6f6f       jal t5, 0xf672c     
0x0000003a      6f6f6f6f       jal t5, 0xf6730          
0x0000003e      6f6f6f6f       jal t5, 0xf6734         
0x00000042      6f6f6f6f       jal t5, 0xf6738          
0x00000046      6f6f006f       jal t5, fcn.00006736      

first entry must be jump to the reset handler, but instead it jumps to some strange address outside of flash ( entire flash size, including built in bootloader, is 0x7FFFF)

One of the solutions is to rewrite the entire firmware with a custom bootloader and IronOS, but this requires use of wchisp and shorting one of internal pins to the ground, which isnt that bad, and seems to be only solution. Moreover i accidentally cleared the entire flash while playing with wchisp, so for me this is the only solution.

Hey, just curious if you were successful with this? I was also considering erasing flash completely - couldn't really figure out the obsfuscation algorithm however I didn't really spend much time on this...

Another option is to dump the FW and compare it with obfuscated version but I don't have any experience with WCH chips.