Announcement

Collapse
No announcement yet.

Lenovo Thinkcentre M720q, disable activated Computrace

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Lenovo Thinkcentre M720q, disable activated Computrace

    Not a BIOS request per se, but closely related. Please bear with me

    A while ago I found an old Lenovo Thinkcentre M720q in pieces in the electronics scrap bin at work. There was only some minor damage to the case, so collected everything and brought it home to let it dry and see if it still worked. It did

    Unfortunately Computrace has been activated on it. Since I'm using it as an emulation console with Lakka now, it's no big deal, but would be nice to get rid of the annoying message popping up when entering the UEFI setup, and also learn something along the way. I'm a complete newbie when it comes to UEFI hacking.

    Searched and read up some on the subject. Found the Lenovo BIOS Auto Patcher which was supposed to be able to disable Computrace. Set a supervisor password, dumped the UEFI, and tried the auto patcher on the image. No cigar, it only threw me an error message about the image being corrupt. Would guess it's a compatibility issue.

    Decided to try the manual approach instead. Found some info on editing the AbtState variable, "Then use an hex-editor and search for AbtState, a few bytes before the string you will find the header AA553F(h), to invalidate that variable make it AA553C(h)". Loaded the dump in UEFITool. There is no AbtState variable, but I did however find a ComputraceState variable, which I guess is an equivalent in older versions of Computrace/Absolute Persistence. See attached screenshots.

    Here I'm stuck though. If I had another M720q where Computrace wasn't enabled, I'd have tried dumping UEFI -> enable Computrace -> dump again -> compare dumps and look for changes in Computrace related variables, but unfortunately I don't.

    Perhaps somewhat of a longshot, but does anyone on the forums have some experience of disabling older versions of Computrace, and can shed some light on how to go on from here? Of course I could have asked for a patched BIOS, but where's the fun in that?

    Got a T56 programmer and have of course done backups of the UEFI EEPROM. Not afraid of trying things out
    Attached Files

    #2
    Made some progress with this.

    Found the ComputraceMessage variable. Partly figured out how the variables are structured, and changed the data byte from 0x01 to 0x00. No more nagscreen at least

    Still haven't managed to completely disable Computrace though. Changing the ComputraceState variable from 0x01 to 0x00 didn't help. I then tried what I believe to be the same approach as the linked message above suggests, invalidating the variable by changing the attribute byte. Originally it was 0x83 (Runtime, AsciiName, Valid). Quickly found an invalid variable, else with the same attributes (Runtime, AsciiName), and set the ComputraceState variable to the same value, 0x03. Loading the resulting image in UEFITool, the variable is now flagged as invalid.

    It did not work in practice though, still says enabled/activated in the UEFI setup. Thinking of trying to figure out how offsets works in varstores, and trying to change the variables written to when doing selections in the Computrace submenu as a next step. I'd of course love any pointers on how to go about this

    Also found what looks like a version number, "Computrace V90.945", if it's of any use.

    Comment


      #3
      So, looks like I finally managed to disable Computrace.

      Figured out how to work with those multi variable stores. Set the ComputraceState variable to 0x0 (was 0x1, Activated, before), and the apparently unnamed variable controlled from the Computrace menu to 0x2, Permanently Disabled (0x1, Enabled, before). Flashed and booted the system, and now everything Computrace related was gone from the setup menu.

      Did the two changes above to an untouched EEPROM dump in an effort to find the least amount of changes necessary to achieve what I wanted, and flashed it instead. Updated UEFI to the latest version, the changes seemed to have survived. Installed W10 on another SSD, booted it a few times, and even left the computer running overnight just in case. Scoured through the computer for rpcnet.exe and other traces of Computrace this morning, but couldn't find anything. Nothing in the firewall logs about the known Computrace domains and IP adresses either.

      Couldn't believe it would be that easy, I mean, there's nothing stopping them from making it a lot harder to reverse engineer by obfuscating stuff etc. Guess the result speaks for itself though, seems like it was enough to change two relatively easy to find variables

      Comment


        #4
        Hi , Thank you for your infos , i have same issue on a scrap m920 lenovo , can you help me understand how to mod it? I had dumped the file with fptw64 , i'm used to code but don't know much about bios .

        Comment


          #5
          Originally posted by catalin78 View Post
          Hi , Thank you for your infos , i have same issue on a scrap m920 lenovo , can you help me understand how to mod it? I had dumped the file with fptw64 , i'm used to code but don't know much about bios .
          Tried a lot of things and can't remember exacly what method finally worked, but my personal notes indicate that it might be enough to boot a UEFI shell and use setup_var.efi to edit those two variables:


          Set ComputraceState to 0x0:

          Code:
          setup_var 0x0 0x2 -i 0x27
          0x37633: VarStore Guid: E102C8AA-0F10-4A0E-90A7-A6F816089BB7, VarStoreId: 0x27, Size: 0x2, Name: "ComputraceState"


          Set unnamed Computrace related variable to 0x2 (permanently disabled):

          Code:
          setup_var 0x17 0x2 -i 0x1
          VarStoreId: 0x1, VarOffset: 0x17, Flags: 0x10, Size: 8, Min: 0x0, Max: 0x2, Step: 0x0 { 05 91 E2 1A E3 1A F1 29 01 00 17 00 14 10 00 02 00 }
          0x5EF83: OneOfOption Option: "Enabled" Value: 1, Default { 09 07 E4 1A 10 00 01 }
          0x5EF8A: OneOfOption Option: "Disabled" Value: 0 { 09 07 E5 1A 00 00 00 }
          0x5EF91: OneOfOption Option: "Permanently Disabled" Value: 2 { 09 07 E6 1A 00 00 02 }

          It would probably be a good idea to load your dump in UEFITool and verify that those variables reside in the same varstores/offsets in whatever UEFI version you've got installed first, instead of blindly using my setup_var commands. My M720q was on M1UKT5FA when I did the above.

          Would avoid doing it by directly editing and flashing an EEPROM dump without having a hardware flasher available.

          Comment


            #6
            It just hit me that I might have used IFRExtractor to find those varstores/offsets. There's a guide here. Start from "Extracting the necessary files" and keep going until you have the .ifr.txt file. You'll find the varstores/offsets in it.

            Comment


              #7
              Thanks for the information,

              I had managed to dump and extract and look at variables but i am unsure how to prepare to boot into uefi , maybe you can give me some pointers how to boot it if possible

              Below is what i have found in my dump but still trying to understand how these variables work .

              Click image for larger version

Name:	image.png
Views:	82
Size:	21.8 KB
ID:	3604218Kind Regards,

              Comment


                #8
                There's no built-in UEFI shell in Lenovos implementation, you need to load it from a bootable USB stick instead. Here's one way to create one. Also copy setup_var.efi to the root of the stick once you're done with creation.

                I'm no expert, just read up on it some when I needed to disable Computrace on my M720q and never revistited the subject, so take this with a grain of salt:

                What's in your screenshot is the 1 byte (8 bits) long unnamed variable at an offset of 0x17 bytes from the beginning of varstore 0x1, that can have the values 0,1 or 2, and controls the computrace activation. With Computrace activated, it has the value 1 (enabled). You want to set it to 2 (permanently disabled).

                Since the UEFI setup won't let you deactivate Computrace from the menu once it's activated (it would of course entirely defeat the purpose of Computrace if you could simply turn it off from the menu) there are two options left:

                1) Find the variables in your raw dump, edit them, and flash the modified dump. This involves hex editors, changing another variable with a known offset in the same varstore, redumping, comparing dumps, and hopefully finding the bytes that controls Computrace activation, or finding the varstores in the dump by their patterns and edit the variables. This is of course very dangerous if you don't have a hardware programmer and can restore an untouched dump to your computer if you edit the wrong bytes. Also, I'm really not the right person to try to guide through this with my very limited knowledge of the subject, and being a non-native English speaker.

                2) What I suggested you to try first, changing the variables with setup_var.efi. This is a "softer" approach than the above, setup_var.efi will change variables the proper way by issuing commands to UEFI. The worst case scenario is that you manage to change the wrong variable, but that can of course be reset. The only potential problem with this method is that it's technically possible for the manufacturer to lock down variables, not allowing changes on a booted system. According to my notes there was nothing that indicated this was the case for those two variables in the M720q though.

                Your screenshot shows that the unnamed variable is in the same varstore/offset as in my computer, so the command I gave you for that (setup_var 0x17 0x2 -i 0x1) will do the trick. You probably want to double check that the ComputraceState variable resides in varstore 0x27 and is the only variable in that store on your computer too before issuing the command for that (setup_var 0x0 0x2 -i 0x27) though

                Comment

                Working...
                X