If we are serious about unlocking the bootloader

TMcGrath50 said:

I don't know much about QPST, but I've become more familiar lately with eMMc functionality lately. I think it's a long shot, but it's a good idea none the less. I'm trying to correlate base addresses and binaries, and it's a mess.

My question to you Surge: have you ever heard of an OTA introducing a security loophole that didn't exist on older versions? I don't think Sammy has made any deep firmware modifications with the updates, so it's probably a waste of a thought. At least, none deep enough to affect the bootloader level binaries (probably, with the exception of closing the Loki loophole).

Sent from my SCH-I545 using xda app-developers app

---------- Post added at 06:25 AM ---------- Previous post was at 06:19 AM ----------

Do you think there's still anything to be learned from Dan Rosenberg's old S4 exploit?



http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html?m=1


Sent from my SCH-I545 using xda app-developers app

Click to expand...

Click to collapse

  kernel_actual  = ROUND_TO_PAGE(hdr->kernel_size,  page_mask);
  ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask);
  second_actual  = ROUND_TO_PAGE(hdr->second_size,  page_mask);

  dprintf(INFO, "Loading boot image (%d): start\n",
                                kernel_actual + ramdisk_actual);
  bs_set_timestamp(BS_KERNEL_LOAD_START);

  offset = page_size;

  /* Load kernel */
  if (mmc_read(ptn + offset, (void *)hdr->kernel_addr, kernel_actual)) {
                        dprintf(CRITICAL, "ERROR: Cannot read kernel image\n");
                                        return -1;
  }
  offset += kernel_actual;

  /* Load ramdisk */
  if(ramdisk_actual != 0)
  {
  if (mmc_read(ptn + offset, (void *)hdr->ramdisk_addr, ramdisk_actual)) {
  dprintf(CRITICAL, "ERROR: Cannot read ramdisk image\n");
  return -1;
  }
  }
  offset += ramdisk_actual;

  dprintf(INFO, "Loading boot image (%d): done\n",
                                kernel_actual + ramdisk_actual);
  bs_set_timestamp(BS_KERNEL_LOAD_DONE);

  if(hdr->second_size != 0) {
  offset += second_actual;
  /* Second image loading not implemented. */
  ASSERT(0);
  }

hdr = (struct boot_img_hdr *)buf;

  image_addr = target_get_scratch_address();
  kernel_actual = ROUND_TO_PAGE(hdr->kernel_size, page_mask);
  ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask) + 0x200;
  imagesize_actual = (page_size + kernel_actual + ramdisk_actual);
 
  memcpy(image_addr, hdr, page_size);
 
  offset = page_size;

  /* Load kernel */
  if (mmc_read(ptn + offset, (void *)hdr->kernel_addr, kernel_actual)) {
    dprintf(CRITICAL, "ERROR: Cannot read kernel image\n");
    return -1;
  }

  memcpy(image_addr + offset, hdr->kernel_addr, kernel_actual);

  offset += kernel_actual;

  /* Load ramdisk */
  if (mmc_read(ptn + offset, (void *)hdr->ramdisk_addr, ramdisk_actual)) {
    dprintf(CRITICAL, "ERROR: Cannot read ramdisk image\n");
    return -1;
  }

  memcpy(image_addr + offset, hdr->ramdisk_addr, ramdisk_actual);

  offset += ramdisk_actual;

TMcGrath50 said:

I've been meaning to comment on this for a long time. h311sdr0id suggested using the GS4 JTAG. JTAG is a dark, evil place. You will brick your phone. Or at least, I've bricked a phone trying to implement JTAG.

Essentially, this is what it does: JTAG is a hardware implementation that allows a manufacturer to hard reset a device and install its stock firmware back on the device. It puts the phone in software "no man's land," waiting for you to push an image to it. In short answer, probably, it would probably be possible to exploit the JTAG to reset the device and push MDK from QDL. BUT I've never seen anyone try to implement a JTAG exploit around a qfuse. That qfuse would complicate things exponentially... without an unbrick.img and a modified MDK tar, I have no clue how to implement it. Surge, can you get the signed 8960_msimage.mbn? If we could unbrick with the signed version, it might be possible.

My story: I use to have a Droid Charge, and a little bit of knowledge in electrical engineering. JTAG is a hardware piece, which requires hooking up a circuit to reset the phone. I had my circuit, it exploited, and then got stuck in QDL. I didn't have any unbrick method at the time, and the bootloader was still uncracked. Since then, the bootloader has become unlocked, so I could probably find a way to push an old firmware to the phone to get it up and running, but then I got a GS4 and gave up.

Now that being said, h311sdr0id claims to have pushed it into JTAG mode and brought it back into MDK. I suppose he didn't trip qfuse. No one's heard from him in a long time though. But I'm not sure how he implemented it--did he use a reset circuit to bring it to JTAG, like they did here: http://xdaforums.com/showthread.php?t=1000175 Or did he use a soft circuit parallel? There's no telling. But either way, JTAG is no place that the lay programmer should be. Even if we used his method and could successfully push MDK, I'd imagine there might be 11 people with this phone who could take advantage of it.

---------- Post added at 01:39 AM ---------- Previous post was at 01:34 AM ----------

Everyone please see the link I put in that post. It shows the JTAG process for the Captivate. My Charge had a similar method--you had to use a hard (physical) circuit to exploit JTAG.

Surge, everything I said in the above post was assuming the JTAG process was similar; that you needed a hard circuit and EE skills. But that being said, there are some devices where JTAG can be reset with a soft (programming) circuit. All devices have JTAGs. My PS3, for example, has a soft circuit. If the bootloader on it were unlocked, you could stick that thing in JTAG mode from your computer. My TV's JTAG, however, requires a hard circuit. If this phone would only require a soft circuit, one skilled programmer could make a tool that would exploit it and push MDK in Odin....

But my old Charge required a hard circuit, just like the captivate. It would seem Samsung likes hard JTAGs. And if that's the case, I wouldn't focus efforts too much on that approach, it's just not universal enough.

Click to expand...

Click to collapse

TMcGrath50 said:

Wow, that thread was really interesting. Did you notice that it was for i9505, and h311sdr0id comment on the forum and asked if it would work for I545? That thread must have been his inspiration for trying to apply that same method to I545.

That being said, you're right. It looks like you can use a soft method to put the phone into JTAG mode. That's phenomenal news, if someone knew how to do it. It looked like h311sdr0id was really close if he didn't actually succeed. But if we could get the phone into JTAG mode, we could probably get the phone into QDL mode and push commands via E:V:A or some other method to install a modified MDK.

But yes, we would absolutely need the debrick.imgs before we could really count on that idea. I'm not sure what JTAG mode is like on the GS4, but on my old phone, JTAG'ing the phone put it into a hard brick mode, and you HAD to have the debrick.imgs to restore it. JTAG mode literally bricked the phone. But once we had those imgs, we could get it into QDL mode and flash a bootloader from there. (I never did that, like I said in my old post). JTAG'ing I545 might put it into a hard brick that requires a debrick.img, though h311sdr0id seemed to get it out and back to MDK.

So we have two options: 1) Get a hold of h311sdr0id, and ask him how he implemented JTAG, or 2) start a WIP thread on the side for getting the debrick.imgs and wing it ourselves.

Click to expand...

Click to collapse

TMcGrath50 said:

Good point. I'm not really sure. I would think that the i9505 would be identical. Where did you get the impression that you should use the 8960 images?

Sent from my SCH-I545 using xda app-developers app

Click to expand...

Click to collapse

TMcGrath50 said:

Surge, I've been looking into a JTAG exploit, and this might be a lot more promising than I thought. It absolutely depends on the debrick.imgs, though. And whipping out a modified MDK image to push. Maybe using E:V:A. (I know nothing about that, but it's a method you brought up to pursue.) I've gotta figure out how he got around the qfuse, though. It seems like the method would trip it every time...

But I've confirmed that it's a soft circuit JTAG on all GS4 models. That's great news, but it means that if we can find an exploit, we'd have to build an executable, using ODIN, to flash this stuff. It would, most likely, end up being far too long and risky of a process to leave to simple directions.

More news will come as my investigation deepens.

Sent from my SCH-I545 using xda app-developers app

Click to expand...

Click to collapse

• We need someone who is more knowledgeable at reverse engineering/ can help build an .exe file that will execute files in a certain order or way (this might not be necessary as I can probably learn how to do it tonight after doing some research but if someone is good at both reverse engineering and building .exe's it'd be helpful.)
• I need someone on MDK with an MDK non-hlos and modem (doesnt matter if its a custom rom or not though) to build a debrick image and they will have to have a linux machine (or live cd) and I can give them instructions, ive asked people for this before but this time its going to be a larger file just to make sure (probably 500MB). Note: You will be giving me some personal information if we use this method, but I'll remove it and use my own efs I have backed up so no worries and I promise I wont repost/look into your info (ill delete it immediately).