Error cannot read boot image header

Решил прошить Android в Fastboot и наткнулся на ошибку fastboot: error: cannot load ‘image’? Исправить ее очень просто! Как это сделать и необходимо чтобы она вновь не появлялась, можете узнать на сайте Android +1!

Итак, еще раз об ошибке cannot load ‘image’, вместо ‘image’ может быть указана любое имя twrp.img, recovery.img или еще что-то еще. Откуда взялась эта ошибка? Все дело в том, что утилита Fastboot которая используется для прошивки Android, распознает название прошиваемых файлов только в том виде как они указаны. Сейчас объясню на примере.

Предположим вам на форуме сказали что необходимо прошить recovery, дали команду:

fastboot flash recovery recovery.img

вы скачали файл, twrp-recovery.img, пишите в командной строке команду и получили ошибку cannot load recovery.img.

Все дело в том, что в Fastboot вы пытались прошить файл, которого не существует, правильно было бы написать команду в вашем случае:

fastboot flash recovery twrp-recovery.img

Теперь прошивка в Fastboot пройдет нормально!

Еще один момент который стоит уточнить, если вы скачали файл TwRP.img и будете прошивать его таким образом:

fastboot flash recovery twrp.img

То вы также получите ошибку, так как Fastboot чувствителен к регистру букв. То-есть, чтобы прошить файл TwRP.img необходимо было надо было написать команду так:

fastboot flash recovery TwRP.img

и последний момент, чтобы избегать большинства проблем, всегда размещайте прошиваемые файлы в одной папке с утилитой Fastboot!

У вас еще остались дополнительные вопросы? Задавайте их в комментариях, рассказывайте о том, что у вас получилось или наоборот!

Вот и все! Оставайтесь вместе с сайтом Android +1, дальше будет еще интересней! Больше статей и инструкций читайте в разделе Статьи и Хаки Android.

This post is to discuss how (L)ittle (K)ernel loads boot.img in arm architecture. The reference source code here is CodeAuora LA.BR.1.3.1-09730-8952.0.

download the reference code

$ repo init -u git://codeaurora.org/quic/la/platform/manifest -b refs/tags/LA.BR.1.3.1-09730-8952.0 -m LA.BR.1.3.1-09730-8952.0.xml
$ repo sync -cd -j32

code revision

• android-4.0.4_r1.2 BUILD_ID=IMM76I
• kernel 3.0.21 Sneaky Weasel

boot image format supported by this LK
In android: boot.img , we discuss boot image format. In this case, the boot image is customized by SOC vendors. This customized boot image has additional device tree part. The image in this part is called dt.img.

/*
** +-----------------+ 
** | boot header     | 1 page
** +-----------------+
** | kernel          | n pages  
** +-----------------+
** | ramdisk         | m pages  
** +-----------------+
** | second stage    | o pages
** +-----------------+
** | device tree     | p pages
** +-----------------+
**
** n = (kernel_size + page_size - 1) / page_size
** m = (ramdisk_size + page_size - 1) / page_size
** o = (second_size + page_size - 1) / page_size
** p = (dt_size + page_size - 1) / page_size
** 0. all entities are page_size aligned in flash

little kernel memory layout
Within the memory layout, LK loads boot image into SCRATCH_ADDR at first. In this case, SCRATCH_ADDR functions as temporary buffer.

static mmu_section_t mmu_section_table[] = {
/*           Physical addr,         Virtual addr,            Size (in MB),     Flags */
	{    MEMBASE,               MEMBASE,                 (MEMSIZE / MB),   LK_MEMORY},
	{    MSM_IOMAP_BASE,        MSM_IOMAP_BASE,          MSM_IOMAP_SIZE,   IOMAP_MEMORY},
	{    APPS_SS_BASE,          APPS_SS_BASE,            APPS_SS_SIZE,      IOMAP_MEMORY},
	{    MSM_SHARED_IMEM_BASE,  MSM_SHARED_IMEM_BASE,    1,                COMMON_MEMORY},
	{    SCRATCH_ADDR,          SCRATCH_ADDR,            512,              SCRATCH_MEMORY},
	{    MIPI_FB_ADDR,          MIPI_FB_ADDR,            42,              COMMON_MEMORY},
};

MEMBASE := 0x8F600000 # SDRAM
MEMSIZE := 0x00300000 # 3MB

BASE_ADDR        := 0x80000000
SCRATCH_ADDR     := 0x90000000

loads boot image from emmc into DDR

• find boot partition in emmc

int boot_linux_from_mmc(void)
{
......
	if (!boot_into_recovery) {
		index = partition_get_index("boot");
		ptn = partition_get_offset(index);
		if(ptn == 0) {
			dprintf(CRITICAL, "ERROR: No boot partition foundn");
                    return -1;
		}
	}
......
}

• load boot image header

int boot_linux_from_mmc(void)
{
......
	if (mmc_read(ptn + offset, (uint32_t *) buf, page_size)) {
		dprintf(CRITICAL, "ERROR: Cannot read boot image headern");
                return -1;
	}

	if (memcmp(hdr->magic, BOOT_MAGIC, BOOT_MAGIC_SIZE)) {
		dprintf(CRITICAL, "ERROR: Invalid boot image headern");
                return -1;
	}
......
}

• calculate image size

Assign image_addr as SCRATCH_ADDR.

int boot_linux_from_mmc(void)
{
......
	kernel_actual  = ROUND_TO_PAGE(hdr->kernel_size,  page_mask);
	ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask);

	image_addr = (unsigned char *)target_get_scratch_address();

#if DEVICE_TREE
	dt_actual = ROUND_TO_PAGE(hdr->dt_size, page_mask);
	imagesize_actual = (page_size + kernel_actual + ramdisk_actual + dt_actual);
#else
	imagesize_actual = (page_size + kernel_actual + ramdisk_actual);
#endif
......
}

• copy boot image to DDR

LK loads boot image into image_addr at first.

int boot_linux_from_mmc(void)
{
......
	dprintf(INFO, "Loading boot image (%d): startn", imagesize_actual);
	bs_set_timestamp(BS_KERNEL_LOAD_START);

	/* Read image without signature */
	if (mmc_read(ptn + offset, (void *)image_addr, imagesize_actual))
	{
		dprintf(CRITICAL, "ERROR: Cannot read boot imagen");
		return -1;
	}

	dprintf(INFO, "Loading boot image (%d): donen", imagesize_actual);
......
}

load kernel into DDR
Check if boot image is gzip format. If yes, decompress compressed kernel.

int boot_linux_from_mmc(void)
{
......
	if (is_gzip_package((unsigned char *)(image_addr + page_size), hdr->kernel_size))
	{
		out_addr = (unsigned char *)(image_addr + imagesize_actual + page_size);
		out_avai_len = target_get_max_flash_size() - imagesize_actual - page_size;
		dprintf(INFO, "decompressing kernel image: startn");
		rc = decompress((unsigned char *)(image_addr + page_size),
				hdr->kernel_size, out_addr, out_avai_len,
				&dtb_offset, &out_len);
		if (rc)
		{
			dprintf(CRITICAL, "decompressing kernel image failed!!!n");
			ASSERT(0);
		}

		dprintf(INFO, "decompressing kernel image: donen");
		kptr = (struct kernel64_hdr *)out_addr;
		kernel_start_addr = out_addr;
		kernel_size = out_len;
	} else {
		kptr = (struct kernel64_hdr *)(image_addr + page_size);
		kernel_start_addr = (unsigned char *)(image_addr + page_size);
		kernel_size = hdr->kernel_size;
	}
......
}

update kernel, ramdisk, atags address

int boot_linux_from_mmc(void)
{
......
	/*
	 * Update the kernel/ramdisk/tags address if the boot image header
	 * has default values, these default values come from mkbootimg when
	 * the boot image is flashed using fastboot flash:raw
	 */
	update_ker_tags_rdisk_addr(hdr, IS_ARM64(kptr));

	/* Get virtual addresses since the hdr saves physical addresses. */
	hdr->kernel_addr = VA((addr_t)(hdr->kernel_addr));
	hdr->ramdisk_addr = VA((addr_t)(hdr->ramdisk_addr));
	hdr->tags_addr = VA((addr_t)(hdr->tags_addr));
......
}

static void update_ker_tags_rdisk_addr(struct boot_img_hdr *hdr, bool is_arm64)
{
	/* overwrite the destination of specified for the project */
#ifdef ABOOT_IGNORE_BOOT_HEADER_ADDRS
	if (is_arm64)
		hdr->kernel_addr = ABOOT_FORCE_KERNEL64_ADDR;
	else
		hdr->kernel_addr = ABOOT_FORCE_KERNEL_ADDR;
	hdr->ramdisk_addr = ABOOT_FORCE_RAMDISK_ADDR;
	hdr->tags_addr = ABOOT_FORCE_TAGS_ADDR;
#endif
}

DEFINES += CRYPTO_BAM=1
DEFINES += SPMI_CORE_V2=1
DEFINES += ABOOT_IGNORE_BOOT_HEADER_ADDRS=1

#define SDRAM_START_ADDR                   0x80000000

#define DDR_START                          get_ddr_start()
#define ABOOT_FORCE_KERNEL_ADDR            DDR_START + 0x8000
#define ABOOT_FORCE_KERNEL64_ADDR          DDR_START + 0x80000
#define ABOOT_FORCE_RAMDISK_ADDR           DDR_START + 0x2000000
#define ABOOT_FORCE_TAGS_ADDR              DDR_START + 0x1E00000

move kernel, ramdisk and device tree to correct address

int boot_linux_from_mmc(void)
{
......
	/* Move kernel, ramdisk and device tree to correct address */
	memmove((void*) hdr->kernel_addr, kernel_start_addr, kernel_size);
	memmove((void*) hdr->ramdisk_addr, (char *)(image_addr + page_size + kernel_actual), hdr->ramdisk_size);
......
}

setup atags
This version of LK supports loading device tree from dt.img. It also supports decompress dt.img if it is compressed in gzip format. The LK also supports loading device tree appended to kernel.

int boot_linux_from_mmc(void)
{
......
#if DEVICE_TREE
	if(hdr->dt_size) {
		dt_table_offset = ((uint32_t)image_addr + page_size + kernel_actual + ramdisk_actual + second_actual);
		table = (struct dt_table*) dt_table_offset;

		if (dev_tree_validate(table, hdr->page_size, &dt_hdr_size) != 0) {
			dprintf(CRITICAL, "ERROR: Cannot validate Device Tree Table n");
			return -1;
		}

		/* Find index of device tree within device tree table */
		if(dev_tree_get_entry_info(table, &dt_entry) != 0){
			dprintf(CRITICAL, "ERROR: Getting device tree address failedn");
			return -1;
		}

		if (is_gzip_package((unsigned char *)dt_table_offset + dt_entry.offset, dt_entry.size))
		{
			unsigned int compressed_size = 0;
			out_addr += out_len;
			out_avai_len -= out_len;
			dprintf(INFO, "decompressing dtb: startn");
			rc = decompress((unsigned char *)dt_table_offset + dt_entry.offset,
					dt_entry.size, out_addr, out_avai_len,
					&compressed_size, &dtb_size);
			if (rc)
			{
				dprintf(CRITICAL, "decompressing dtb failed!!!n");
				ASSERT(0);
			}

			dprintf(INFO, "decompressing dtb: donen");
			best_match_dt_addr = out_addr;
		} else {
			best_match_dt_addr = (unsigned char *)dt_table_offset + dt_entry.offset;
			dtb_size = dt_entry.size;
		}

		/* Validate and Read device device tree in the tags_addr */
		if (check_aboot_addr_range_overlap(hdr->tags_addr, dtb_size))
		{
			dprintf(CRITICAL, "Device tree addresses overlap with aboot addresses.n");
			return -1;
		}

		memmove((void *)hdr->tags_addr, (char *)best_match_dt_addr, dtb_size);
	} else {
		/* Validate the tags_addr */
		if (check_aboot_addr_range_overlap(hdr->tags_addr, kernel_actual))
		{
			dprintf(CRITICAL, "Device tree addresses overlap with aboot addresses.n");
			return -1;
		}
		/*
		 * If appended dev tree is found, update the atags with
		 * memory address to the DTB appended location on RAM.
		 * Else update with the atags address in the kernel header
		 */
		void *dtb;
		dtb = dev_tree_appended((void*)(image_addr + page_size),
					hdr->kernel_size, dtb_offset,
					(void *)hdr->tags_addr);
		if (!dtb) {
			dprintf(CRITICAL, "ERROR: Appended Device Tree Blob not foundn");
			return -1;
		}
	}
	#endif
......
}

boot linux

int boot_linux_from_mmc(void)
{
......
	boot_linux((void *)hdr->kernel_addr, (void *)hdr->tags_addr,
		   (const char *)hdr->cmdline, board_machtype(),
		   (void *)hdr->ramdisk_addr, hdr->ramdisk_size);
......
}

typedef void entry_func_ptr(unsigned, unsigned, unsigned*);
void boot_linux(void *kernel, unsigned *tags,
		const char *cmdline, unsigned machtype,
		void *ramdisk, unsigned ramdisk_size)
{
	unsigned char *final_cmdline;
#if DEVICE_TREE
	int ret = 0;
#endif

	void (*entry)(unsigned, unsigned, unsigned*) = (entry_func_ptr*)(PA((addr_t)kernel));
	uint32_t tags_phys = PA((addr_t)tags);
	struct kernel64_hdr *kptr = (struct kernel64_hdr*)kernel;

	ramdisk = (void *)PA((addr_t)ramdisk);

	final_cmdline = update_cmdline((const char*)cmdline);

#if DEVICE_TREE
	dprintf(INFO, "Updating device tree: startn");

	/* Update the Device Tree */
	ret = update_device_tree((void *)tags,(const char *)final_cmdline, ramdisk, ramdisk_size);
	if(ret)
	{
		dprintf(CRITICAL, "ERROR: Updating Device Tree Failed n");
		ASSERT(0);
	}
	dprintf(INFO, "Updating device tree: donen");
#else
	/* Generating the Atags */
	generate_atags(tags, final_cmdline, ramdisk, ramdisk_size);
#endif
......
	/* do any platform specific cleanup before kernel entry */
	platform_uninit();

	arch_disable_cache(UCACHE);

#if ARM_WITH_MMU
	arch_disable_mmu();
#endif
	bs_set_timestamp(BS_KERNEL_ENTRY);

	if (IS_ARM64(kptr))
		/* Jump to a 64bit kernel */
		scm_elexec_call((paddr_t)kernel, tags_phys);
	else
		/* Jump to a 32bit kernel */
		entry(0, machtype, (unsigned*)tags_phys);
}

conclusion
This post goes through the code flow in which how LK loads boot.img into DDR, sets up kernel, ramdisk, atgas, and then jump to kernel. LK is arm 32-bit. If kernel is arm 32-bit, LK could jump to kernel directly. If kernel is arm-64 bit, LK couldn’t jump to kernel directly. We’ll cover this topic in another post.

Tags: Little Kernel

This entry was posted on September 22, 2015 at 5:22 pm and is filed under android, bootloader. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.

Launched in April 2013, the Samsung Galaxy S4 is expected to be one of the top-selling smartphones of the year, having sold 10 million units in its first month of sales. While the majority of released models include an unlocked bootloader, which allows users to flash custom kernels and make other modifications to the software on their own devices, AT&T and Verizon branded devices ship with a locked bootloader that prevents these types of modifications. In this post, I’ll provide details on how Samsung implement this locking mechanism, and publish a vulnerability in the implementation that allows bypassing the signature checks to run custom unsigned kernels and recovery images.

Both the AT&T (SGH-I337) and Verizon (SCH-I545) models utilize the Qualcomm APQ8064T chipset. As described in my previous blog post on Motorola’s bootloader, Qualcomm leverages software-programmable fuses known as QFuses to implement a trusted boot sequence. In summary, each stage of the boot process cryptographically verifies the integrity of the subsequent stage, with the trust root originating in QFuse values. After the early boot stages bootstrap various hardware components, Samsung’s APPSBL («Application Secondary Bootloader») is loaded and run. This bootloader differs between «locked» and «unlocked» variants of the Galaxy S4 in its enforcement of signature checks on the boot and recovery partitions.

A quick glance at aboot (adopting the name of the partition on which this bootloader resides) revealed that it is nearly identical to the open source lk («Little Kernel») project, which undoubtedly saved me many hours of tedious reverse engineering. By locating cross-references to strings found in both lk and aboot, I was able to quickly identify the functions that implement signature verification and booting of the Linux kernel.

The central logic to load, verify, and boot the Linux kernel and ramdisk contained in either the boot or recovery partitions is implemented in the boot_linux_from_mmc() function. First, the function determines whether it is booting the main boot partition, containing the Linux kernel and ramdisk used by the Android OS, or the recovery partition, which contains the kernel and ramdisk used by the Android recovery subsystem. Then, the first page of the appropriate partition is read into physical memory from the eMMC flash storage:

This is still essentially identical to lk‘s implementation, with the addition of code to copy the individual pieces of the boot image to the image_addr location. Finally, the function performs signature verification of the entire image. If signature verification succeeds, the kernel is booted; otherwise, a tampering warning is displayed and the device fails to boot:

The is_engineering_device() function simply returns the value of a global variable that is set at an earlier stage in the boot process based on whether or not the chipset ID (an unchangeable hardware value) of the device indicates it is an engineering or production device.

Examining the check_sig() function in more detail revealed that aboot uses the open-source mincrypt implementation of RSA for signature validation. The bootloader uses an RSA-2048 public key contained in aboot to decrypt a signature contained in the boot image itself, and compares the resulting plaintext against the SHA1 hash of the boot image. Since any modifications to the boot image would result in a different SHA1 hash, it is not possible to generate a valid signed boot image without breaking RSA-2048, generating a specific SHA1 collision, or obtaining Samsung’s private signing key.

The astute reader will have already noticed the design flaw present in the above program logic. Notice the order in which the steps are performed: first, aboot loads the kernel and ramdisk into memory at the addresses requested by the boot image header, and then signature validation is performed after this loading is complete. Because the boot image header is read straight from eMMC flash prior to any signature validation, it contains essentially untrusted data. As a result, it’s possible to flash a maliciously crafted boot image whose header values cause aboot to read the kernel or ramdisk into physical memory directly on top of aboot itself!

Exploitation of this flaw proved to be fairly straightforward. I prepare a specially crafted boot image that specifies a ramdisk load address equal to the address of the check_sig() function in aboot physical memory. In my malicious boot image, I place shellcode where the ramdisk is expected to reside. I flash this image by leveraging root access in the Android operating system to write to the boot block device. When aboot reads the supposed ramdisk from eMMC flash, it actually overwrites the check_sig() function with my shellcode, and then invokes it. The shellcode simply patches up the boot image header to contain sane values, copies the actual kernel and ramdisk into appropriate locations in memory, and returns zero, indicating the signature verification succeeded. At this point, aboot continues the boot process and finally boots my unsigned kernel and ramdisk. Victory!

Thanks to ralekdev for the helpful exchange of ideas and suggestions.

56 comments:

Thank you very much for this. I won’t be getting an SGS4, but in general I find it exponentially more valuable to have understanding and an exploit, than simply believing in magic.

At May 23, 2013 at 11:41 AM , Michael Berger said.

Thank D.R. for letting us know about the technical details. Awesome find with the Little Kernel OSP! Excellent security research.

At May 23, 2013 at 12:09 PM , Anonymous said.

Thank you sir, you rock.
Well written and executed.

At May 23, 2013 at 12:54 PM , Anonymous said.

That’s a great hack. Thank you for this.

At May 23, 2013 at 1:09 PM , Anonymous said.

It is ridiculous how good you are at this stuff.

Thanks from the entire SGS4 community!

At May 23, 2013 at 2:11 PM , mdeslaur said.

Dan, as usual, you rock 😉

At May 23, 2013 at 3:42 PM , Unknown said.

Hopefully you are well compensated for your intelligence 🙂

At May 23, 2013 at 4:49 PM , MR. Green said.

Very nice! This is a great expoit and pretty easy one too 🙂 good job on noticing the lk similarities.

At May 23, 2013 at 6:21 PM , RPFerg said.

does this root the phone?

At May 23, 2013 at 9:42 PM , Anonymous said.

Good post . Thanks a lot.

At May 23, 2013 at 9:52 PM , Anonymous said.

hey could you take a crack at the pantech bootloader for the flex

At May 23, 2013 at 11:10 PM , Anonymous said.

I will never be this smart.

At May 24, 2013 at 12:00 PM , Anonymous said.

the correct design would likely not solely involve verifying the signature on eMMC but also when copying into RAM calculating a SHA2 and comparing with the verified image. This will be to mitigate a TOCTOU style attack.

At May 24, 2013 at 7:58 PM , Unknown said.

Could Samsung have signature-checked the boot header to make sure it doesn’t load ontop of aboot, not overwriting checkSig()?

At May 25, 2013 at 2:32 PM , Unlock iPhone 5 said.

Can you do some hack to unlock iPhone 5? Thank you!

At May 25, 2013 at 10:17 PM , Unknown said.

At May 26, 2013 at 12:26 PM , Anonymous said.

So we have learned today that it is otherwise POINTLESS for carriers and manufacturers to ‘lock’ their bootloaders, or roms, etc.

the lesson to be learned here: if you are designing something make it possible to ‘lock’ your ROM and bootloaders with cryptographic keys of extreme and lengthy strength. Otherwise, just GIVE USERS THE DARN KEYS FROM THE START!

At May 26, 2013 at 5:28 PM , Anonymous said.

Can you do the same thing to a iPad mini?

At May 27, 2013 at 6:31 AM , Sam said.

YES please. Thank you! Was so tired of touchwiz. NOW I can see why you waited until Verizons phone was out.

At May 27, 2013 at 10:34 AM , heroe13 said.

Would you elaborate more on how to Root SGs4? Thanks a million.

At June 3, 2013 at 1:50 PM , Anonymous said.

So I’m curious, why couldn’t this exploit be use to replace the aboot image with an image that is patched to always see the qfuse unblown? thus effectively unlocking the bootloader without needing loki to flash kernels and recoveries.

At June 4, 2013 at 10:58 AM , Dan Rosenberg said.

Anonymous:
I’m not sure what QFuse you’re talking about, since whether a Galaxy S4’s aboot is «unlocked» or not is not dependent on a QFuse.

You can’t replace aboot itself because signatures are validated at each stage of the boot chain (pbl -> sbl1 -> sbl2 -> sbl3 -> aboot). Writing a tampered aboot would cause sbl3 to fail signature validation.

At June 5, 2013 at 1:13 AM , Anonymous said.

Dan I meant the QFuse for loading kernels or recoveries not a QFuse for aboot. But the second part of your reply answered my question. I thought maybe aboot would check the signature when loading a new aboot I didn’t know it checked it every time you boot.

At June 6, 2013 at 2:05 AM , iphone & ipad & ipod repairs in toronto said.

I like this blog and the statements which you have used in this blog.I found so many things in this page so i saved it in my favourite.

At June 11, 2013 at 11:19 PM , accessoire-galaxy-note said.

Thanks for the info 🙂

At August 16, 2013 at 2:45 PM , Garron Shepherd said.

Any chance you’ll take a crack at any of their new firmwares?

At August 26, 2013 at 6:55 AM , Park said.

I have brand new galaxy, «galaxy s4 lte-a(E330S)».
but your program can not find check function in its aboot.img
Is there any way to crack this?

At September 13, 2013 at 7:38 PM , Armus said.

I’d like to know what changed in the vzw update that killed this.

At September 24, 2013 at 8:07 PM , stretched2thin said.

Any chance you can apply your talents to the LG Optimus L9. All dev attempts have failed.

At September 28, 2013 at 6:58 PM , Roanne Holmes said.

Very informative post about Exploiting Samsung Galaxy S4 Secure Boot, Galaxy S4 users will once again be able to move apps to their SD car, assuming the apps allow the option. There has been a Secure Boot Image added for use with Knox, but the bootloader itself still isn’t locked and is still easily rooted. Thanks for sharing.

At September 30, 2013 at 11:18 PM , Unknown said.

I don’t think he will. Everyone has given up on the new locks.

At October 6, 2013 at 6:22 AM , joao said.

It is possoble you turn a i9505 to i9505g?

At October 6, 2013 at 8:24 AM , justme said.

I’d love to see this masterpiece working 😉
Please share your work at http://forum.xda-developers.com/
Great Work!

At October 6, 2013 at 9:03 AM , Unknown said.

Thank you for the light in tunnel. Now we can override this Knox Crap.

At October 9, 2013 at 11:29 AM , Byron Tsigaras, EE said.

Can you please share your ida pro aboot.mbn loader plugin?

At October 26, 2013 at 9:42 PM , Anonymous said.

very very clever nice to have a little insight into how it works,thanks for the info

At October 27, 2013 at 3:25 PM , Anonymous said.

I am having a «Samsung Galaxy S4-i337 AT&T» which i got as a gift from US.
Model no: SAMSUNG-SGH-I337
ANDROID VERSION: 4.2.2
BASEBAND VERSION: I337UCUAMDL
KERNAL VERSION: 3.4.0-453947
SE.INFRA@SEI-46#1
SAT APR 27 17:06:05 KST 2013
BUILD NO: JDQ39.I337UCUAMDL
IMEI : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (I AM HESITANT TO POST IT)
NETWORK UNLOCK CODE : 5XXXXXXX

Currently i am staying in India, When i put a new 3g BSNL sim card in it , phone asked for network unlock code, unfortunately i didn’t know the importance of it and i entered some random numbers(more than 5 times) and now my network unlocking is permanently blocked by AT&T. I have contacted them they saying my phone is permanently locked and can use only with AT&T network sim card. I have tried to unlock with the method mentioned in XDA forums but unfortunately negative result. I have contacted Samsung , AT&T and BSNL service centers nobody could give a solution to my problem.
What can i do with my phone now to use it with BSNL sim card in India.
Thanks in advance. all genius people out there help me please.
this post is last hope.

At October 28, 2013 at 10:34 AM , Anonymous said.

I‘am using S4(SC-04E,DCM) now, my nuild is SC04EOMUAMF2, I am trying to modify the «aboot.mbn», can you help to locate the entry point by IDA, or give me some tips about mbn file?

I have already locate the strings in mbn by IDA, but I can find cross-references.

At November 1, 2013 at 6:28 PM , jake alstad said.

Nice read Dan! I am a developer interesting in researching an MF3 bootloader exploit. Any tips?

At December 12, 2013 at 12:47 AM , seesemichaelj said.

Great work Dan. I hate to be a noob (and I really should know the answer to this question..), but how did you figure out the aboot.mbn entry points? How big are the RAM/ROM sections, header, signature, and program? Are these features of ARM in general that I’m somehow missing, or is this specific to the partition? I’ve explored lk and still not finding a way to successfully disassemble the image. On another point, how would I know if the image is encrypted? I’m guessing I wouldn’t see legible output when I run the binary through ‘strings’, correct?

At December 12, 2013 at 12:12 PM , Augusto Ferronato said.

Thanks so much Dan, but i have a problem
Well, i try to make my patch, but i have the response:

[+] loki_patch v2.1
[-] Failed to find function to patch.

Using SCH-i545 4.3

Some news about this?

At December 28, 2013 at 3:04 PM , Anonymous said.

Dan, would you care to take a look a little at this thread on XDA and give us some feedback if the (accidental) presence of SECUREBOOT:NONE would be of any help in fully unlocking the N9005? Thank you very much!

At January 15, 2014 at 1:53 PM , Anonymous said.

Samsung . naturally stupid

should be used in their next commercials .

At January 21, 2014 at 12:47 PM , InfoTech Review said.

Thank for sharing your idea about secure boot Galaxy S4

At February 8, 2014 at 2:29 AM , iPhone network check said.

Galaxy S4 is the best model of all Notes and SX models

At February 28, 2014 at 9:07 AM , spiderio said.

Can you do this for LG G2 kitkat version?

At February 28, 2014 at 11:32 PM , Unknown said.

Can you please look into the Lg g flex

At June 22, 2014 at 8:03 AM , Apavayan said.

Hey will it work for galaxy grand 2

At June 30, 2014 at 7:42 AM , Zibri said.

Please do the same on Samsung Galaxy Note3 SM-N9005

At July 6, 2014 at 9:23 PM , Anonymous said.

Please help us out with the AT&T and Verizon note 3

At July 30, 2014 at 11:24 PM , Anonymous said.

Dan is there a place I can download this unsigned image from, that you used to make your s4 boot?

At February 17, 2015 at 9:29 AM , Unknown said.

Unlocking your AT&T HTC Aria by remote unlock code is 100% safe. These phones were built to accept unlock codes. It is the same method service providers will use to unlock their devices. Cellphone unlocking is also 100% legal and will not void warranty on your device.
http://www.attphoneunlockingshop.us/

At March 10, 2015 at 4:16 PM , Anonymous said.

Hi Dan! How can I use this information to actually unfuse a smartphone? I’m programmer and enrolled in a Automation Engineering course, I already done some custom ROMs but I don’t know the firsts steps that I need to take in order to break the secure boot. I must enter in shell (via adb), debug some kernel object (with gdb) and call this function? Or must I change the kernel source, put this function call, recompile the ROM and upload? Or I need to change the machine code of the ROM binaries to hack this? Or I need to do this via a JTAG? Or I need to pull a partition and save to a file, edit this binary file in machine code to force that call and update the partition with this edited file? I know how to do things like this, but I don’t know how path I have to take.

At March 27, 2015 at 3:41 PM , Unknown said.

i have a s4 build i545vrufnk1 i have tried everything i could on line when in odin everything connects but when i try and start odin it fails any help would be great

At June 5, 2015 at 4:42 AM , Corky said.

Do you have a tool to unloki? I am trying to edit my boot, but it’s got loki and I’m new to this. I compiled loki_tool but came to realize this is for patching when a mod is already ready.

At June 7, 2015 at 11:22 AM , Anonymous said.

Hello, Dan,
great exploit. Do you know can it be applied to NEC Terrain? Or other way around: do you know that it cannot by the different nature of the boot lock? For the moment it was a problem that even root (temporary) cannot write to partitions. I found a snaky way and CAN write, so I can flash whatever on the internal memory. I can provide I hope everything upon your request.
Now I’m waiting for my other guys to disasm and decompile the aboot binary. Everything suggests that the story is VERY similar or identical to your findings in S4, LG, etc. I hope to find the address of the important function myself.
Will you, however, be able to help by supporting (or correcting) my findings about the function address. My problem is that I’m quite new for arm, android, etc. I’m pc c/c++/assembler guy.
What might you need? aboot image I guess and the boot image (or atleast it first portion as the image itself is big, 10M), correct?
Thanks in advance, Alex alex-kas at altaray dot com

Источник

Adblock
detector