CFW for KSGER/Quicko STM32 Soldering Stations

[jesusvallejo]

I was wondering how are you powering the target mcu? Have you desoldered it, or lifted all the Vcc legs? And do you have a scope to check the power glitch is successful at pulling down the Vcc rail?

im using a broken board with everything removed but the mcu, dont have a scope , but with the multi i can see the voltage droping a bit, so i think its doing it. the thing is , how is the mcu supposed to stop executing flash and start executing ram, i mean , loading it to ram does not tell the mcu to execute it or does it? there is little explanation on how the attack works ,and all i know is from the code , wich as stated before behaves strangelly as th provided bin is slower than the compiled version, the rooshel bin seems odly small and so on. also everything is wired correctly i have made some tests , uart works , boot and reset work etc.

[dreamcat4]

you also read the PDF paper too, yes? It explains in there the basic idea behind the attack. Hopefully to make it easier to understand what the code is doing. (edit) but also you will want to refer to the ST reference documents and specifications. It is difficult not to have a scope... to check the pull down time is long enough. Unfortunately i don't have a scope either here. Maybe a logic analyzer could see it (the glitch), if it is fast enough. Not sure.

[jesusvallejo]

you also read the PDF paper too, yes? It explains in there the basic idea behind the attack. Hopefully to make it easier to understand what the code is doing. (edit) but also you will want to refer to the ST reference documents and specifications. It is difficult not to have a scope... to check the pull down time is long enough. Unfortunately i don't have a scope either here. Maybe a logic analyzer could see it (the glitch), if it is fast enough. Not sure.

after rereading the paper, the way it tells the stm to boot from ram is via pulling up boot 0 AND BOOT1 , it does not metion it on the README but st is very clear about boot0 and boot1(pb2) having to be up in order to boot to ram, paper says:". Next,
we configure SRAM-booting via the BOOT pins.", anyway it still does not work


here is the attack in real time: , min 16 , the bin he uses is 1832 bytes !=  268 bytes of the bin they provided. i have seen he has updated the bins but still cant make it work, perhaps the mcu im trying it on is fake?

Success!!! after trying with another mcu i could do it, so first of all to see wich type of attack to perform is to check wether its legit or fake.if fake like cks , there are other easyer attacks.

[DavidAlfa]

I released the code! The spi still crashes without logic reason from time to time but for the rest is pretty good. As a preview it's ok!
Updated binaries for Quicko STM32F072/STM32F103 and KSGER 2.1s STM32F103RB ("Blue" 64-pin version)
They can be downloaded on their respective folders.

I think the compiler went crazy, at certain moment it got stuck inside a loop from the oled initialization that I haven't modified for ages.
Doing"while(value==0);" and value was 0! No sense. Added a nop instruction inside the while loop and started working again.
That stupid problems make me mad!

After finding a stable  ADC delay, try EMA filtering with a coefficient of 1 or 2! Higher might delay the signal too much (limited to 4 anyways)

[dreamcat4]

This is excellent news, from both of you!

Success!!! after trying with another mcu i could do it, so first of all to see wich type of attack to perform is to check wether its legit or fake.if fake like cks , there are other easyer attacks.

Jesus - have you tried identifying the mcu by connecting over swd with openocd? I believe there is another thread here on eevblog somewhere. Which explains how to read certain bytes. If i can find that thread then i shall come back and post the link.

[dreamcat4]

could not find the original thread. But here us another different thread

https://www.eevblog.com/forum/microcontrollers/cheap-bluepill-very-likely-it-has-fake-stm32-right/125/

it is necessary to load into memory a program over debug swd connection. For example after connecting via openocd. Then get the mcu to run the test program on itself. without having to write anything to the flash. If that makes sense.

[DavidAlfa]

This won't last long. Once the companies see their code compromised, they will use lvl2 protection, which permanently disables the debugging and can't be reversed by erasing

[jesusvallejo]

level two is also compromised, its more dificult but it is anyway. clone chips are far easyer as with some commands and swd you can dump the flash. mb they just stick to other stm32 versions as for the time being there is no info about other chips such as 072,101,etc 103 is older than 072 so mb some of this attack vectors are solved, if not it would a matter of (mb also changing some directions) compiling for m0 instead of m3. atually not possible to reuse the attack,  m3 uses fpb wich can patch code and use breakpoints , and m0 uses bpu , wich is only breakpoint (stated on reference manual). the attack needs the software patching in order to work.

[DavidAlfa]

Then they will end with the old school e-fuses . Once burned  it's over!
In fact I've seen cases where they physically damaged the programming pin by overloading it, causing the esd diode to short out.

[jesusvallejo]

Then they will end with the old school e-fuses . Once burned  it's over!
In fact I've seen cases where they physically damaged the programming pin by overloading it, causing the esd diode to short out.

yeah for sure, on the other thread there is a comment that makes it pretty obvious, the only way they can keep their products ownership is via firmware as the pcb once its sent to the pcb maker it is of "chinesse public domain" meaning anyone can buy the desing from the pcb maker  , so i guess they will do as you say. But as long as they use the stm32, and your firmware is avaible, we are safe.  Also stm32f0 is also compromised but is a bit slow and the firmware for the attack board is for stm32f052 https://www.aisec.fraunhofer.de/en/FirmwareProtection.html , i have also seen another using bus pirate https://gist.github.com/egirault/7b3fe7041e1bf5e2258ed5df7083f14d .

[DavidAlfa]

There are also anticopy chips, they are like spi memories, however inside there's a 128bit key and a encryption engine.

[jesusvallejo]

There are also anticopy chips, they are like spi memories, however inside there's a 128bit key and a encryption engine.

so i have tryed the last commit and i love the new gui. also ist working in both f103 and f072.

[DavidAlfa]

They should! I had tested both thoroughly

[jesusvallejo]

They should! I had tested both thoroughly

i could  reproduce twice an error: "ERROR IN: ../Drivers/graph LINE: 241" , use iron , let it sleep for a long time(30 mins or so) , and it freaks out.
Also no iron detection in 072 is more stable than 103.

[DavidAlfa]

I know, it's the bug I said. It happens randomly in the dma callback.
Iron detection is the same, for all, only the ADC pin is different...
I tested putting a 10 Mohm resistor between the amp input and vcc and it was more than enough  to force high level when floating.

The issue is in the SPI HAL handle State. File "stm32f0xx_hal_spi.c" line 3050.line
After the DMA is completed, it clearly sets it to "HAL_SPI_STATE_READY".

Then it calls the callback, where I change the oled row and send the next data chunk if not done yet.
And it fails is in the oledrow change. It suddenly returns "BUSY".

I added a check before the return of the offending funtion to catch the error. And it never triggers the breakpoint!
It's completely ridiculous!
stm32f0xx_hal_spi.c, HAL_SPI_Transmit,  line976.

Code: [Select]

error:
if(errorcode != HAL_OK){
asm("nop"); //<-- Breakpoint here, never triggers
}
  hspi->State = HAL_SPI_STATE_READY;
  /* Process Unlocked */
  __HAL_UNLOCK(hspi);
  return errorcode; //<-- So this should return HAL_OK!
}

However in ssd1306.c,  write_cmd, line 244, it receives HAL_BUSY!

Code: [Select]

uint8_t err=HAL_SPI_Transmit(oled.device, &cmd, 1, 10);
if(err!=HAL_OK){
Error_Handler(); //<-- But it breaks here! err==2(HAL_BUSY)
}

It's driving me crazy! If I omit the error and continue, it wil fail anyways in thenext SPI call.

[jesusvallejo]

I know, it's the bug I said. It happens randomly in the dma callback.
Iron detection is the same, for all, only the ADC pin is different...
I tested putting a 10 Mohm resistor between the amp input and vcc and it was more than enough  to force high level when floating.

The issue is in the SPI HAL handle State. File "stm32f0xx_hal_spi.c" line 3050.line
After the DMA is completed, it clearly sets it to "HAL_SPI_STATE_READY".

Then it calls the callback, where I change the oled row and send the next data chunk if not done yet.
And it fails is in the oledrow change. It suddenly returns "BUSY".

I added a check before the return of the offending funtion to catch the error. And it never triggers the breakpoint!
It's completely ridiculous!
stm32f0xx_hal_spi.c, HAL_SPI_Transmit,  line976.

Code: [Select]

error:
if(errorcode != HAL_OK){
asm("nop"); //<-- Breakpoint here, never triggers
}
  hspi->State = HAL_SPI_STATE_READY;
  /* Process Unlocked */
  __HAL_UNLOCK(hspi);
  return errorcode; //<-- So this should return HAL_OK!
}

However in ssd1306.c,  write_cmd, line 244, it receives HAL_BUSY!

Code: [Select]

uint8_t err=HAL_SPI_Transmit(oled.device, &cmd, 1, 10);
if(err!=HAL_OK){
Error_Handler(); //<-- But it breaks here! err==2(HAL_BUSY)
}

It's driving me crazy! If I omit the error and continue, it wil fail anyways in thenext SPI call.

what about waiting for the transmit to end as suggested in here: https://electronics.stackexchange.com/a/274685

Code: [Select]

I can see one problem for sure which is HAL related. The HAL_SPI_Transmit is not a ready to use function. It is a blocking SPI send function only without the blocking part.

So I do not know if there anything else wrong, but you certainly should wait after the SPI transmit as follows:

HAL_SPI_Transmit(&hspi1, &xy, 1, 1);
while(HAL_SPI_GetState(&hspi1) != HAL_SPI_STATE_READY);
You should wait for the end of the transmission, before moving on.

[DavidAlfa]

Yeah I also added these checks everywhere,  and as I said, the breakpoint never stops there.
It's in ready state before calling spi transmit.
It's in ready state when the spi transmit checks it.
And it's ready when it returns.
But then, at some point the return value randomly changes, by magic.
I will compare the oled routines against the older code, there's something weird going on.
The strange is that it fails very randomly.
Sometimes it works 20min, others just a few.
Or there's memory corruption by some wrong pointer or whatever, or I don't understand why.
It also happens with the graphics disabled, only updating the screen.

Edit:
I updated all the other boards. Ksger with software i2c should be ok, as they don't use the spi dma.
I don't know if the bug happens with the hardware i2c too.


I also added active power limitation. Before, it was a fixed value (0-100%) applied to the PWM duty.
Now it's limited in watts.
The iron routine takes the last power supply reading, the heater impedance (new option added in the menu) and the power limit setting, and adjust the max pwm duty.
This value is then applied to the PID calculation.
So, if you set 30W, the power will be always 30W, independently of the power supply voltage, as long as it's enough to apply that power into the load.
This wil be very useful, specially for low power tips. Each profile has its own power limit. By default: C245=150W, C210 and T12=80W




Edit 2:
Also made some changes in the graph so it will display temperatures between 200 and 500°C for better accuracy.
Showing lower temps is pretty useless. Also some other changes for increased stability/smoothness while not making it too laggy.
Now it's 7°C/pixel which should give enough precision to see oscillations.

About the iron detection: It's a shame, but hardware modding will be necessary in most cases.
The wake pin is usually not connected to an ADC pin

Edit 3:
Also, I don't know if it was a lucky shot or what, it's been running well for the whole night without crashing.
Latest build video:

[mastershake]

i have 2 of the 3.1s units. both have boards inside that say oled v3.0 but they both have stm32f102 chips. is this compatible with those or only 101 and 103? hoping so! thanks

[DavidAlfa]

Yes, I didn't made for the 102 before as nobody asked.
Also, some 102 versions have 10KB RAM which was too low for older fw versions.
I can make a build for you to test if you want,but I don't have these boards to test, so please take in count that although it should work, and I will try to help with any issues that could appear, I won't take any responsibility, it's all at your own risk 

I need a picture of the actual board. Is it 48 or 64-pin? There is a crazy ammount of ksger boards out there.

Is it like this one but with a 102?

[mastershake]

yes that is exactly what it looks like pcb wise the actual part number on the chip is stm32f02r8t6 it is 64pin. i can take some pics today but its identical to that style. sucks i was hoping they were 103's. how much difference if any will it make in performance of the unit with these 102's seems they cheaped out on them i have not seen them mentioned to many places so im bummed i got them even though my orders for them were far apart time wise. is it worth getting 103's and changing them out at all if so which version would you recc. new to stm32 but im trying to learn as much as i can. not new to this type of work though. thanks again

[DavidAlfa]

Not really a difference in performance.
A little slower than the 103, but will work perfectly fine, 36 or 48MHz are a lot more than needed.
I will make a build in a while. Check later!

Edit: Done! try it out.

[mastershake]

awesome thank you! will give it a go when i get done with work later tonight. will let you know, if i want to order some spare stm's in case which would you suggest i order?

appreciate it!!

[dreamcat4]

About the iron detection: It's a shame, but hardware modding will be necessary in most cases.

Yes... it seems like that was always going to be the case. Due to certain difficulties. Hope that you do not feel too bad about that. What is important is that we can give a very clear instructions, examples. For how to correctly do the necessary hardware modifications. That is not going to be confusing anybody.

Latest build video:

Overall really impressive video. Amazed that you can do the graphing feature at all, on these low powered devices. And also the realtime bar meter along the bottom. It looks so responsive the updating rate. Really excellent!

A suggestion for the Main menu, because it has a really big text, which fills up the whole screen... You do not have to do that. Because displaying only 1 menu item at once, it makes it impossible to see how far to turn the dial for multiple steps at once. Seeking 1 step at a time is slower.

Instead f that... if you just use the exact same 4 line display as already in the submenus. Then it is possible to see where you are scrolling to. As then the screen can display the -1 before entry, and the +1 after entry. With the selected entry in the middle. This would be easier see more of the menu.

That was my only UI suggestion for this, as the default hardware configuration, I think? Cannot remember now.

My other suggestion requires hardware mod. To add 2nd, 3rd push button(s). Either for dedicated: up/down/ok/back navigation. Or for: iron on/off. Or to select a saved preset temperature with 1 click. Reason: because not everybody loves rotary encoders. If i can just press 1 button, by feel alone, and without having to check the display. Then can keep eyes looking through the microscope. That is faster.

Another one of my annoyances with rotary encoder: When you press in the dial to click. Sometimes it also rotates by accident. And selects the wrong item. Perhaps if we can duplicate the push button with re-wiring?To have a separate physical button just doing the same thing? IDK.

[DavidAlfa]

I would take the 103 which is the most common, but it's not extrictely needed

[jesusvallejo]

I would take the 103 which is the most common, but it's not extrictely needed

just be sure to buy it from a reputable source as the risk to get a clone is pretty high(rs-components,farnell,arrow,digi,etc), the problem is there is not stock anywhere , or wasnt a month ago or so.