How To Switch User On Microsoft Surface When Prompted For Another User's Password

Question

I'm developing an embedded application on STM8S using STVD IDE and Cosmic C compiler. I'm trying to read FLASH memory byte by byte to calculate CRC. Following is my code snippet:

uint32_t crc32_buffer(const uint8_t *buf, uint32_t len)
{
    uint32_t index = 0;
    uint32_t crc = 0xFFFFFFFF;
    uint32_t flashIndex = 0;
    uint8_t *ptr = buf;
    volatile uint8_t value = 0;
    volatile uint8_t i = 0;

    for (index = 0; index < len; index++)
    {
        value = *ptr;
        flashIndex = (crc & 0xFF) ^ value;
        ptr++;
        crc = (crc >> 8) ^ table[flashIndex];

        if(bytesCntr >= 2685)
        {
           i++;
        }
    }

    return ~crc;
}

The code works fine until 2694 bytes are read from the FLASH. Viewing Memory in the debugging session, I make sure that the next byte in the FLASH has value of 0C. Checking the value of ptr, I make sure it has the address of this 0C byte in the FLASH (which is 0x8B15). However, value variable always get the value of 8B instead of 0C after ptr is dereferenced.

I also tried to exclude unnecessary variables so it be like this:

crc = (crc >> 8) ^ table[(crc & 0xFF) ^ buf[index]];

But the table index was not as it should be as the memory location was read as 8B instead of 0C.

I found that the byte before and the byte after address 0x8B15 are read correctly. Only this address is read wrongly.

UPDATE-1

The disassembly of the value = *ptr; is as following:

LDW X, (0x11,SP)
LD  A, (X)
LD  (0x13,SP),A

When reading the byte at address 0x8B15, if I put a breakpoint at the second assembly line and then the value in the memory location is read correctly as 0C. However, if I put the breakpoint at the third assembly line instead, I find that register X has 0x8B15 (the right address) but register A has 0x8B (the wrong value).

UPDATE-2

I added an if statement inside the for loop for debugging (to put my breakpoint). I found that the code saved in memory byte which is read wrongly is always the code inside this if statement. The disassembly of this code always have something to do with SP. Even if I changed the code, the problematic memory byte is always the first instruction in the if statement. And I also noticed that the wrong read value is always 0x8B regardless what is the right value. Here is the disassembly saved in this memory location:

0x8b15 <crc32_buffer+104>   0x0C01 INC   (0x01,SP)  INC   (_CRC_ONGOING_s,SP) 

Solution 1

If there was another possible user account on any Windows 8 (ish) device, then there should be an arrow to the top left of the picture for the user account you're on. That would take you to another screen with usernames and pictures to select who to login as.

So, if that is not there then it is unlikely that another account exists that can be used. Sounds like you need to talk to whoever you borrowed it from to evaluate and ask them to create a guest account or something temporary for you.

Solution 2

Microsoft has a pretty good tutorial on how to do it. Excerpted from here.

• Step 1: Plug in your Surface so you don’t run out of power during the refresh.
• Step 2: From the Windows sign-in screen, select Power Power icon in the lower-right corner of the sign-in screen.
• Step 3: Press and hold the Shift key. (If you're using the touch keyboard, select the Shift key.)
• Step 4: While the Shift key is still pressed or selected, select Restart.
  • If you get the prompt Restart anyway, select Restart anyway.
  • After your Surface restarts, the Choose an option screen will appear.
• Step 5: Select Troubleshoot > Reset your PC. Surface restarts and the Surface logo appears while Windows prepares to reset your Surface.
• Step 6: On the Reset your PC screen, select Next.
• Step 7: Choose either Just remove my files or Fully clean the drive. The option to clean the drive is more secure but takes much longer. For example, if you are recycling your Surface, you should clean the drive. If you are keeping your Surface, you just need to remove your files.
• Step 8: Select Reset. Surface restarts and the Surface logo appears during the reset process (this can take several minutes).

Don't use the "touch" keyboard, if you don't have a physical keyboard, select the Ease of Access icon in the lower right, then On-Screen Keyboard. Press the Shift key so it's toggled, then follow steps 4-8.

Comments

[Jean-François Fabre]

maybe unrelated but you may want to declare const uint8_t *ptr = buf;, to get rid of the warning.

[Steve Summit]

One of your screenshots mentions unsigned char near *. Is this actually a segmented architecture? near pointers can't cross segment boundaries, so that might have something to do with your problem.

[Salahuddin]

@SteveSummit Could you please explain more what you mean?

[Salahuddin]

@Jean-FrançoisFabre You are right, I should add const. It's value after xoring. Does it make a difference if it's before of after xoring?

[Jean-François Fabre]

no, my bad. it doesn't matter

[the busybee]

It depends on the optimization level: If both variables are mapped into the same space (like a register) you'd see this behavior. The compiler might have decided that the life time of value ends after reading it for the XOR. You might like to check the generated machine code. But this wont explain your second observation with the "compressed" expression.

[anand]

Something trivial but just in case if it is nand flash then read will be block based while code is reading byte by byte.

[Salahuddin]

Yes, sorry my bad.

[Guillaume Petitjean]

How did you program the flash ? Is it possible that some bytes have not been properly programmed (because of a software bug of a flash driver for example) ?

[Salahuddin]

@GuillaumePetitjean I build the project using STVD IDE then I run an external program on the PC which calculates the CRC for the S19 file and writes the calculated CRC in the S19 itself. Then I use a programmer tool from ST to read the S19 file and download it on the microcontroller. Finally, I start debugging using STVD IDE (I debug without reprogramming the microcontroller).

[Lundin]

One potential problem is that you didn't volatile qualify the access, meaning you could experience optimization hiccups. More likely though, is a plain stack overflow. 32 bit arithmetic is very cumbersome for a STM8, it will have to use various software libs that takes lots of time and probably a fair bit of stack. What you should do first of all when the bug hits is to check the stack pointer. Everything about this bug sounds like a stack overflow.

[Lundin]

@SteveSummit It's a 8 bit MCU so near simply means 16 bit addresses, whereas far would mean expanded memory beyond 64kib. Accessed in some MCU-specific way, bank selection registers or similar.

[Salahuddin]

I‘m out of ideas. Any suggestions?

[Lundin]

If not stack overflow, then maybe a memory corruption bug. Make sure to have all interrupts disabled and see if that changes anything. Oh, and always read the part errata.

[Salahuddin]

In one of my trials, I made sure that the only existing ISR is not called while reading this byte. But I‘ll try completely disabling interrupts.

[Salahuddin]

I tried disabling interrupts before reading and the re-enabling them but this didn’t solve the problem.

[Guillaume Petitjean]

If there is indeed no exception and your analysis is correct regarding the assemby code ("However, if I put the breakpoint at the third assembly line instead, I find that register X has 0x8B15 (the right address) but register A has 0x8B (the wrong value).") it's really weird and not linked to stack or to the C code. At what address your CRC code is executing ? May be there is a conflict between executing and reading the Flash ?

[Salahuddin]

@GuillaumePetitjean Yes, I noticed that many times the problem happens in the memory address where the executing code itself is stored in (as I wrote in Update-2)

[Guillaume Petitjean]

OK I didn't understand your comment. I bet there is a conflict in the Flash: you are executing and reading at the same address in parallel. I would not be surprised that it is not supported by the MCU. You can try to calculate CRC on a different memory area than the CRC function.

[Salahuddin]

@GuillaumePetitjean Sorry could you please explain more? I think the code should be the same and doesn't change during the project's lifetime. Regardless if it is being read or not. I noticed that the memory location which is read wrongly is the location that saves the if-statement in the code posted in the question. Every time I change the code but keep this if statement, the new location which saves the if-statement is read wrongly. When I tried to completely delete this if-statement, I found that another memory location - which is not in CRC calculation function - is read wrongly.

[Guillaume Petitjean]

STM8 has an Harvard architecture, meaning that access to instruction and data is done through 2 separate buses. Here, both I and D buses try to access the same address, so may be it is not supported by the architecture ? It is just an hypothesis. Generally speaking, I think it is not very clean to do that (some software is reading itself). Usually you would have some kind of bootloader (or kernel or whatever you call it) checking the rest of the software.

[the busybee]

@Guillaume There are microcontrollers behaving as described. But the STM8 family simply stalls its pipeline until the memory bus becomes available, according to its programming manual.

[the busybee]

@Salahuddin Would you mind to check the opcode of LD A,(X), please? The programming manual shows a value of 0xF6 without 0x90 before it. It is strange that A has 0x8B after executing it, which is the upper byte of the address in X. This could be done by LD A,XH with an opcode of 0x9E.

[Salahuddin]

I think I solved it. Thanks to @GuillaumePetitjean I tried to store the code of the function that calculates CRC in a seperate special memory section instead of .text using #pragma. It worked the first time and the calculated CRC matched the expected one. Then when I tried it again the problem appeared again. So I placed the code in the whole CRC module (i.e., source file) in that special memory section. And it worked. I can't believe it did.

[DaveB]

How would a user be created if you can't exit from the login screen? Is there a way to get to the preconfigured administrator account?

[nerdwaller]

You would need to be able to login (and typically the admin account isn't enabled by default when the main user is an admin), so again - you'd need to talk with the owner of the tablet. It would probably be frowned upon for me to tell you how or link to guides to tell you how to hack into Windows.

[DaveB]

I asked because there is a possibility that the person with the login could not longer be available and I wondered if the device would then be rendered unusable.

[nerdwaller]

If that's the case you could find guides online to reset the password (though you'd need to make adjustments for ARM hardware), otherwise a recovery image is available locally (if the owner didn't remove it yet). I think to access that you would hold Vol+ during power on (at least on my pro). If they removed it, then there should be a way to obtain the image from Microsoft or possibly floating around online.

[fixer1234]

External links can break or be unavailable, in which case your answer would not be useful. In this case, the link opens to a non-English page, so if there's a language setting, it isn't obvious. Please include the essential information within your answer and use the link for attribution and further reading. Thanks.

[kamranicus]

In this case, from Windows sign-in screen, click the Ease of Access icon and select On-Screen Keyboard. Press the Shift button. Then click the Power icon in the lower right, then Restart. Then when the Surface restarts, it should let you choose Troubleshoot and Refresh PC. This worked great on my Surface 2.

[harper]

In you "update" your write about an address of 0x87F5, but the register X has the value of 0x887F5. Is that a typo?

[Salahuddin]

@Lundin I checked the SP when the wrong byte is read and it was in range. For my uC, stack ranges between 0x17FF and 0x1400 and in my case SP = 0x17D8. Also, I made sure that SP doesn't change before or after reading this specific byte. It's the same when reading bytes before and after.