Ucds

[Gwe89]

I know the ucds has an ARM chip has any one successfully managed to pull the firmware from any, I currently have 1 genuine my first ucds and 2 clones

[DGAlexandru]

It is a simple STM32 chip... that also has a bootloader mode.. but because it is protected/locked, any simple unlocking mechanism will wipe all flash contents

A good way of getting the FW would be to sniff and save USB comm. when a FW update is going on.
Another option which I tried and got stuck is to develop and write needed code in an another STM32 (like a killed clone ) to act as a real UC DS but put a lower verion and have the tool update it.
My code makes it behave like real one on the USB discovering process but I wasn't able to make it send other data.
STM has real nice developing tools.. but their examples are for USB to Serial converter, then comm. with COM port, not USB direct comm. using standard Win drivers (as UC DS tool also uses).

[Go4IT]

Besides that those tasks are intellectualy interesting, please keep in mind our ethics, that we are not Chinese copy-clone-sellers. The goal of this community should always be to understand how things working and make them behave the way we like

The STM32 will shurely have the fuses set to be read-protected and disabled the JTAG interface. This is the best way to avoid simply copy-clone them. You could decap the chip and use an electron mircoscope to get the bits out, but this is something for CN, not for us
Sniffing the USB-comm may give you update-data, but it could also be crypted. At least it will not contain the bootloader, which i expect to be special for the device. But for shure the UCDS team had not developed their own hardware, but simply put their firmware on an existing one.
So it's like on other HW-Plattforms, the only way to get what's inside, you need a way to put an trojan into the RAM of the chip and let it send the Flash contents. It's best promising heading into that direction...

[DGAlexandru]

At that time I wanted to see if I can repair the killed one.. and all I could do was to kill another one )

The interface interested me also because of that J2534 (Pass-Thru) protocol which is way better than ELM327 and it also has all 3 CANs that can be found in an Ford OBD2 port.
UC DS software that works with clones is usually too old for daily use, especially if you have an original one

PS: JTAG is still available

[Go4IT]

Really? Did you try to jtag it? Then you may use J-mem to load the contents down.

[DGAlexandru]

Yes, I tried.. but because is protected, you cannot read FLASH or RAM or configuration options.
You can read status of Internal Peripherals and Peripherals (CAN, TIM,ADC, DAC, SPI, DMA and so on)... but not of much use

JTAG interface is SWD (Serial Wire Debug) type with SWD_CLK and SWD_IO.
On the 5 pin "header" you find these two then Reset, GND and VCC 5V.
STM32F105RC is the one used in clones. It's VCC is 3.3V (VDD pins).
New Original versions have STM32F2xx and the PCB is slightly different.

STM32F105RC_UCDS_Clone.jpg

STM32F1xx have a special BOOT PIN mode (BOO in image) that on this PCB is connected to GND under the chip. If it is connected to GND then it boots from internal Flash (normal boot). If it is tied to VDD then it boots in BootLoader Mode which can be used to program the Flash area directly over USB. In this mode the chip boots from a special region that has bootloader code from STM32 and cannot be changed by user.
There is a 3rd boot mode, but can't remember now what it does.

STM32Fxx family chips are based on Cortex-M3 ARM 32bit CPU
JTAG / SWD connection to it can be done with JLINK using the command:

Code: Select all

JLink.exe -Device STM32F105RC -If SWD -Speed 1000 -JTAGConf -1-1 -AutoConnect 1

The output should be:

Code: Select all

SEGGER J-Link Commander V6.44g (Compiled Apr 18 2019 17:13:00)
DLL version V6.44g, compiled Apr 18 2019 17:12:10

Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware version: V8.00
S/N: abcdxyz :)
License(s): RDI,FlashDL,FlashBP,JFlash,GDB
VTref=3.313V
Device "STM32F105RC" selected.


Connecting to target via SWD
Found SW-DP with ID 0x1BA01477
Device was not unsecured. No action performed.
Device was not unsecured. No action performed.
Found SW-DP with ID 0x1BA01477
Scanning AP map to find all available APs
AP[1]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x14770011)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x411FC231. Implementer code: 0x41 (ARM)
Found Cortex-M3 r1p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 001BB000 SCS
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 001BB002 DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 000BB003 FPB
ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 001BB001 ITM
ROMTbl[0][4]: E0040000, CID: B105900D, PID: 001BB923 TPIU-Lite
ROMTbl[0][5]: E0041000, CID: B105900D, PID: 101BB924 ETM-M3
Cortex-M3 identified.

[Go4IT]

Usually if MCUs offer booting from external or internal Flash, the other one is disabled, so it's not possible to startup an sniffer software from external attached Flash/USB and read out the internal one... Maybe the only chance to get in is via a faked update?

[DGAlexandru]

Even in STM own BootLoader Mode you can access Flash content, but only if it is unsecured.
In order to try a fw update you need to know the byte sequence .. which, again, can be found only by sniffing a fw update.

[amplified]

One quick question, as i have ori and clone, but haven't installed the original software yet - am i safe to install both 1.26 and 2.xx and be very careful which one i use for which program? can i run the two on one OS ?

[DGAlexandru]

Yes, but be VERY CAREFULL