rtos interactions - the GM/Chevy MyLink HMI 2.5 devices are similar...

[ilikenwf]

However despite having the reboot disabled, any time I try to do anything with any of the OSAL lib related functions, the HMI reboots.

Here's my version of the lib...any thoughts?

https://send.vis.ee/download/8edb9373f02a95f1/#qC-WyEipNmdMYdcgrvLwww

[ilikenwf]

I should add it could be potentially some watchdog process, or perhaps even some kind of static pid filtering.

Likewise, I'm not sure if your units have this, but GM has an "eol" related set of tools that can read but not write a lot o the calibrations and settings.

[ilikenwf]

...I haven't published it yet but I did modify the rtos code in my copy of this repo to use the lib on GM HMI 2.5 devices, but they are newer and so despite the function calls being mostly the same they have a syscall to reboot hard coded in the lib itself:

void eh_reboot(undefined4 param_1,undefined4 param_2,undefined4 param_3)

{
  int iVar1;
  ssize_t sVar2;
  undefined4 local_44;
  undefined4 uStack_40;
  undefined4 uStack_3c;
  undefined4 uStack_38;
  undefined4 local_34;
  undefined4 uStack_30;
  undefined4 uStack_2c;
  undefined4 uStack_28;
  undefined4 local_24;
  undefined4 uStack_20;
  undefined4 uStack_1c;
  undefined4 uStack_18;
  undefined2 local_14;
  
  if (*(char *)(pOsalData + 0x1037) == '\0') {
    OSAL_trace_callstack_secure(param_1,param_2,param_3,0);
  }
  iVar1 = FUN_4121909c();
  if (iVar1 == 0) {
    local_44._0_1_ = 'r';
    local_44._1_1_ = 'e';
    local_44._2_1_ = 'b';
    local_44._3_1_ = 'o';
    uStack_40._0_1_ = 'o';
    uStack_40._1_1_ = 't';
    uStack_40._2_1_ = ' ';
    uStack_40._3_1_ = 'd';
    uStack_3c._0_1_ = 'i';
    uStack_3c._1_1_ = 's';
    uStack_3c._2_1_ = 'a';
    uStack_3c._3_1_ = 'b';
    uStack_38._0_1_ = 'l';
    uStack_38._1_1_ = 'e';
    uStack_38._2_1_ = 'd';
    uStack_38._3_1_ = ' ';
    local_34._0_1_ = 'd';
    local_34._1_1_ = 'u';
    local_34._2_1_ = 'e';
    local_34._3_1_ = ' ';
    uStack_30._0_1_ = '/';
    uStack_30._1_1_ = 'o';
    uStack_30._2_1_ = 'p';
    uStack_30._3_1_ = 't';
    uStack_2c._0_1_ = '/';
    uStack_2c._1_1_ = 'b';
    uStack_2c._2_1_ = 'o';
    uStack_2c._3_1_ = 's';
    uStack_28._0_1_ = 'c';
    uStack_28._1_1_ = 'h';
    uStack_28._2_1_ = '/';
    uStack_28._3_1_ = 'd';
    local_24._0_1_ = 'i';
    local_24._1_1_ = 's';
    local_24._2_1_ = 'a';
    local_24._3_1_ = 'b';
    uStack_20._0_1_ = 'l';
    uStack_20._1_1_ = 'e';
    uStack_20._2_1_ = '_';
    uStack_20._3_1_ = 'r';
    uStack_1c._0_1_ = 'e';
    uStack_1c._1_1_ = 's';
    uStack_1c._2_1_ = 'e';
    uStack_1c._3_1_ = 't';
    uStack_18._0_1_ = '.';
    uStack_18._1_1_ = 't';
    uStack_18._2_1_ = 'x';
    uStack_18._3_1_ = 't';
    local_14 = 10;
    write(DAT_4125cc94,&local_44,0x31);
  }
  else {
    fprintf(stderr,"rebooting (to prevent: touch %s\n","/opt/bosch/disable_reset.txt");
    sleep(1);
    iVar1 = open("/sys/devices/platform/dexcep/trigger_exception",1);
    if ((iVar1 < 0) || (sVar2 = write(iVar1,&DAT_41245fe8,1), sVar2 < 0)) {
                    /* WARNING: Subroutine does not return */
      reboot(0x1234567);
    }
  }
  *(undefined *)(pOsalData + 0x1037) = 0;
  return;
}

[ilikenwf]

...despite having disable_reset.txt in the requested location, it still reboots. I wonder if the RTOS is detecting my activities?

[ea]

If i remember correctly , the communication with RTOS is somewhat fragile and would be prone to crashing which in turn causes reboots. But i'm not exactly sure what could be the problem.

Which parts of the OSAL library were you trying to interact with?

Also, how did you get a shell on the GM unit?

[ea]

also, i seem to recall having a lot of problems dynamically loading the osal library and resolving the symbols properly. Check out. Check out dynload.c and make sure it loads properly.

[ilikenwf]

Just trying to read a register from OSAL - if there are dynload issues I wouldn't see much of anything if it were segfaulting but I suspect this is something in that library. I even tried commenting out the return without luck.

For maps, I think ford, gm, nissan at the least all use the same provider and file formats...

For rooting:
On software version 15.x bosch units there are serial pads. I followed this guide:

For higher versioned ones I think I know how to root but haven't tried it yet. This is only for bosch HMI 2.5 units for GM and it's family of brands.

How to root 15.x:
https://www.cameraloops.com/forums/topic/468-hacking-the-gm-hmi-25-module/?do=findComment&comment=1307

Serial:
https://www.cameraloops.com/forums/topic/468-hacking-the-gm-hmi-25-module/?do=findComment&comment=965

[ilikenwf]

I mean, I have an OBD2/passthrough device and can send calibrations to set the values that way, but having tools on device would be neat since as root, sshd listens and I can use ethernet via usb or connect it to my wifi AP and ssh in that way.

[ea]

Oh , that's pretty cool! I wasn't aware of that writeup for GM units.
Wonder if a similar exploit to mine would work on those so you wouldn't have to pull it out of the dash to connect to serial and enable ssh.
A quick look at the writeup suggest that the hardware is quite different, but the platform probably has a lot of similarities.

Hope my reverse engineering efforts are of help when figuring things out!
Keep me posted if you find something interesting.

Cheers,
ea

[ilikenwf]

Yes, it is!

If you'd like I could share a rootfs tarball that I sftped from one unit, along with some info and images of /dev/mtd*, and/or share a full emmc dump I made of another unit (but it's 32gb uncompressed because of the empty space).

I tried your exploit once already without any luck, so I would say they saw your repo and patched it... If you would have not disclosed online, you probably could have gotten a huge bug bounty or sold it to someone like beyond security.

Many of the similar libs and programs are used on the GM units, the units themselves have both a v850 MIPS computer on the board (which I don't currently have the programmer or tools for), and the i.MX6 Linux machine - they communicate via /dev/shm, using the weird OSAL layer.

Backups of the calibrations and such are kept in /dev/mtd1-9, generally 4 and 5, the others are all zeroed...but it is non volatile.

There's a programming header on the board, and while the adapters for it exist, they're meant to be used with a $450 programming device, so I haven't sprang for that yet.

I've had my truck since it was new, and only just now got brave enough to dig in because the used HMI units are affordable if you're a security researcher with an LLC like I am, as I can partially write them off. I've sadly managed to brick 3 of them so far, and have 2 more coming with no intention of killing them...

[ea]

I tried your exploit once already without any luck, so I would say they saw your repo and patched it... If you would have not disclosed online, you probably could have gotten a huge bug bounty or sold it to someone like beyond security.

there's probably some similar trick that would work.
If i didn't disclose it publicly like this, we wouldn't be having fun! I doubt anybody would have been interested in buying this vulnerability. There are many other present on the system but I went with this one because it's very reliable and fool proof to exploit. I do enough memory corruption vulnerability research as my day job already :)
Let me know when you publish your work, I'll definitely want to take a look!

[BuenGenio]

Yes, it is!

If you'd like I could share a rootfs tarball that I sftped from one unit, along with some info and images of /dev/mtd*, and/or share a full emmc dump I made of another unit (but it's 32gb uncompressed because of the empty space).

I tried your exploit once already without any luck, so I would say they saw your repo and patched it... If you would have not disclosed online, you probably could have gotten a huge bug bounty or sold it to someone like beyond security.

Many of the similar libs and programs are used on the GM units, the units themselves have both a v850 MIPS computer on the board (which I don't currently have the programmer or tools for), and the i.MX6 Linux machine - they communicate via /dev/shm, using the weird OSAL layer.

Backups of the calibrations and such are kept in /dev/mtd1-9, generally 4 and 5, the others are all zeroed...but it is non volatile.

There's a programming header on the board, and while the adapters for it exist, they're meant to be used with a $450 programming device, so I haven't sprang for that yet.

I've had my truck since it was new, and only just now got brave enough to dig in because the used HMI units are affordable if you're a security researcher with an LLC like I am, as I can partially write them off. I've sadly managed to brick 3 of them so far, and have 2 more coming with no intention of killing them...

I would really like a copy of your dump - I accidentally copied a bunch of files where they're not supposed to be and ran out of disk space - the system works, but I need a reference file list tree so I can clean up... :)

Thanks!

[ilikenwf]

My mega account got deleted, if I get a chance to share it sometime I'll try to remember and do so.

[ilikenwf]

Yes, it is!
If you'd like I could share a rootfs tarball that I sftped from one unit, along with some info and images of /dev/mtd*, and/or share a full emmc dump I made of another unit (but it's 32gb uncompressed because of the empty space).
I tried your exploit once already without any luck, so I would say they saw your repo and patched it... If you would have not disclosed online, you probably could have gotten a huge bug bounty or sold it to someone like beyond security.
Many of the similar libs and programs are used on the GM units, the units themselves have both a v850 MIPS computer on the board (which I don't currently have the programmer or tools for), and the i.MX6 Linux machine - they communicate via /dev/shm, using the weird OSAL layer.
Backups of the calibrations and such are kept in /dev/mtd1-9, generally 4 and 5, the others are all zeroed...but it is non volatile.
There's a programming header on the board, and while the adapters for it exist, they're meant to be used with a $450 programming device, so I haven't sprang for that yet.
I've had my truck since it was new, and only just now got brave enough to dig in because the used HMI units are affordable if you're a security researcher with an LLC like I am, as I can partially write them off. I've sadly managed to brick 3 of them so far, and have 2 more coming with no intention of killing them...

I would really like a copy of your dump - I accidentally copied a bunch of files where they're not supposed to be and ran out of disk space - the system works, but I need a reference file list tree so I can clean up... :)

Thanks!

mega dot nz/file/ rQ1AlD5J#CxFAORh2Ar-Jj3apmOQg2E7ljEWx1230gWEE5k_UHrk

let me know once you have it so I can remove the link please