2017-12-13 08:32 AM - edited 2024-06-10 07:36 AM
Posted on December 13, 2017 at 17:32
In Cortex-M3, M4, etc, we can just check the DEBUGEN bit in DHCSR (the Debug Halting Control and Status Register)
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/CEGCJAHJ.html
But in Cortex-M0, that register is not accessible to the user code.
:(
So - is there any other way on an STM32L0 to detect when the debugger is connected?
#stm32l0 #debug
Solved! Go to Solution.
2017-12-13 11:31 AM
So digging a bit, BKPT instruction causes a Hard Fault when the debugger is not attached, and this is exploitable
Googling pulled this interesting thread, which has usable information
https://community.nxp.com/thread/424925
2017-12-13 08:37 AM
Most debug session will set at least DBG_CR_SLEEP
2017-12-13 08:57 AM
Arguably a CM0+ r0p1
I would look at the DBGMCU clocks and the bits in the DBG registers at 0x40015800..0x4001580F
2017-12-13 10:21 AM
Turvey.Clive.002 wrote:
I would look at ... the bits in the DBG registers at 0x40015800..0x4001580F
But those are the bits I'd be looking to set depending on whether the debugger was connected or not!
Something along the lines of:
if( debugger_connected() )
{
HAL_DBGMCU_EnableDBGStopMode( );
Without that, The ST-Link Utility seems to lose connection during STOP even with 'Enble debug in Low power mode' checked.
But Keil seems fine with it
2017-12-13 10:33 AM
Hmmm ....
Keil says that RCC_APB2SMENR.DBGSMEN is set, but RCC_APB2ENR.DBGEN is not set!
So it thinks the DBG clock is enabled during Sleep mode, but not otherwise?!
It does say that DBG_STANDBY, DBG_STOP, and DBG_SLEEP are all set in DBG_CR.
2017-12-13 10:41 AM
Sometimes the debugger sets things up, I'm looking for side-effects that can be seen. That's not working, so now I have a dog in the race I'll dig a little deeper
Prior discussion
2017-12-13 10:44 AM
Clive One wrote:
Prior discussion
https://community.st.com/0D50X00009XkeTOSAZ
Yes, I've just seen that - and linked here!
2017-12-13 11:31 AM
So digging a bit, BKPT instruction causes a Hard Fault when the debugger is not attached, and this is exploitable
Googling pulled this interesting thread, which has usable information
https://community.nxp.com/thread/424925
2017-12-13 11:47 AM
Clive One wrote:
this is exploitable
/external-link.jspa?url=https%3A%2F%2Fcommunity.nxp.com%2Fthread%2F424925
Wow - that is some sort of a Hackety-Hack of Hack Hall!!
:(
Many thanks for digging it up!
2017-12-13 11:56 AM
Yeah, a bit more hackary than I'd like.
It did cause me to rewrite my own handler for the CM0(+)
HardFault_Handler\
PROC
EXPORT HardFault_Handler
EXTERN hard_fault_handler_c
MOV R1, LR
LDR R0, =hard_fault_handler_c
MOV LR, R0
MOVS R0, &sharp4 ; Determine correct stack
TST R0, R1
MRS R0, MSP ; Read MSP (Main)
BEQ .+6 ; BEQ 2, MRS R0,PSP 4
MRS R0, PSP ; Read PSP (Process)
MOV R1, R4 ; Registers R4-R6, as parameters 2-4 of the function called
MOV R2, R5
MOV R3, R6 ;
mailto:sourcer32@gmail.com
BX LR
ENDP
//****************************************************************************
void hard_fault_handler_c(unsigned int * hardfault_args, unsigned int r4, unsigned int r5, unsigned int r6)
{
printf ('\n[Hard Fault]\n'); // After Joseph Yiu
printf ('r0 = %08X, r1 = %08X, r2 = %08X, r3 = %08X\n',
hardfault_args[0], hardfault_args[1], hardfault_args[2], hardfault_args[3]);
printf ('r4 = %08X, r5 = %08X, r6 = %08X, sp = %08X\n',
r4, r5, r6, (unsigned int)&hardfault_args[8]);
printf ('r12= %08X, lr = %08X, pc = %08X, psr= %08X\n',
hardfault_args[4], hardfault_args[5], hardfault_args[6], hardfault_args[7]);
printf ('bfar=%08X, cfsr=%08X, hfsr=%08X, dfsr=%08X, afsr=%08X\n',
*((volatile unsigned int *)(0xE000ED38)),
*((volatile unsigned int *)(0xE000ED28)),
*((volatile unsigned int *)(0xE000ED2C)),
*((volatile unsigned int *)(0xE000ED30)),
*((volatile unsigned int *)(0xE000ED3C)) );
while(1);
}
//****************************************************************************