Related
Hi everyone I'm pretty new to the whole Android world, I've read a lot of stuff through this forum and in general through the internet but I haven't got to the point of really understanding this clear.
I performed the rooting and sim unlocking following the guide on this forum, so basically I had to install the ClockworkMod Recovery.
I read that having installed a custom kernel (or rom, not clear the difference) or a custom recovery (or bootloader, like CWM in this case) voids the warranty.
I also read that is pretty simple to restore the stock kernel/firmware by simply flashing it on with Odin, but what about the Recovery?
I found this post http://forum.xda-developers.com/showthread.php?t=1286432&highlight=stock+bootloader my questions are:
1. Is having the phone flashed with stock kernel (but a different than the original recovery, e.g. CWM) enough to bring the phone back in warranty conditions?
2. flashing the stock unrooted kernel following the above thread will restore also the original android recovery console?
3 if not is there a way of getting rid of CWM and restoring the original android recovery? (I read "just flash it with odin like you did with CWM, but where do I find the package (image) to flash?)
4 the stock kernel in the post seems to me "not official" in the sense that has been ripped from a user, is there any chance that we (SGHI777) will get something more official like the international kernels (GTI9001) that you can find on samfirmware?
5 this is extra, if I have a rooted GS2 (following the forum procedure so CWM+original kernel) will I be able to install official update through Kies? (I'm asking cause the unlock security flaw bugs me a lot...)
Thank you very much to everyone that will answer.
frabass said:
Hi everyone I'm pretty new to the whole Android world, I've read a lot of stuff through this forum and in general through the internet but I haven't got to the point of really understanding this clear.
I performed the rooting and sim unlocking following the guide on this forum, so basically I had to install the ClockworkMod Recovery.
I read that having installed a custom kernel (or rom, not clear the difference) or a custom recovery (or bootloader, like CWM in this case) voids the warranty.
I also read that is pretty simple to restore the stock kernel/firmware by simply flashing it on with Odin, but what about the Recovery?
I found this post http://forum.xda-developers.com/showthread.php?t=1286432&highlight=stock+bootloader my questions are:
1. Is having the phone flashed with stock kernel (but a different than the original recovery, e.g. CWM) enough to bring the phone back in warranty conditions?
2. flashing the stock unrooted kernel following the above thread will restore also the original android recovery console?
3 if not is there a way of getting rid of CWM and restoring the original android recovery? (I read "just flash it with odin like you did with CWM, but where do I find the package (image) to flash?)
4 the stock kernel in the post seems to me "not official" in the sense that has been ripped from a user, is there any chance that we (SGHI777) will get something more official like the international kernels (GTI9001) that you can find on samfirmware?
5 this is extra, if I have a rooted GS2 (following the forum procedure so CWM+original kernel) will I be able to install official update through Kies? (I'm asking cause the unlock security flaw bugs me a lot...)
Thank you very much to everyone that will answer.
Click to expand...
Click to collapse
On nearly all Samsung phones, recovery is a part of the kernel. Flash a new kernel, you've flashed a new recovery.
The stock kernel zImage is as official as it gets - nothing is more official than what was actually flashed into the device by the manufacturer and sold on launch day. The additional evidence that it's official is that it passes the bootloader signing checks, eliminating the "custom kernel" warning screen.
We won't see a samfirmware release until AT&T releases an update.
Stock rooted shouldn't affect OTA updates, however sometimes things you do WITH root (such as debloating) will interfere with OTAs.
Once an OTA update becomes available, expect its fixes to be integrated into ROM releases fairly soon.
FYI there are three components you should know about. Kernel>ROM>Modem
The kernel It's the core/kernel of an operating system. It's main functions are to interact with the hardware a.k.a. Device Drivers, to manage resources (things like memory management and processor time sharing a.k.a. multi-tasking), service interrupt requests, network services and the like. It also provides a System Call Interface (API) to the user space (apps running on the machine) so the apps can use system resources.
Now the why so many part... First of all in general there are MANY options available when compiling (building) the kernel. Things like CPU schedulers, file system support, system type support, etc. etc. etc. So there are many different ways to configure the kernel and that gives many options to "test" and see which might work better or not. Some of them are dead giveaways like compiling the kernel for MIPS and trying to run it on the SGS2 won't work but some are "tweaks" that may help a little or a lot, like CPU management options.
Second part of the why so many is the code. Again as mentioned above things like changing code to make the colors of the display more or less sharp (display device driver), make the file system faster (voodoo lag fix) or overclocking the processor, and different "modem" tweaks are all "enhancements" that people have made to the original Linux kernel source. So those things "creep" into existence over time, since there are many people working on them, and you see different versions of the Kernel from that as well.
Anyone that plays music can relate to the options available in that there are only 12 notes on a guitar fret board but millions (or more) ways to put them together to play music. There are certain things that have to be present in the Kernel (notes) but writing code to enhance them and/or combining options at compile time is much broader (music).
The ROM. ROM is actually Random Access Memory and we flash an image to the "ROM" (which it really isn't but I'll leave that one alone). The "ROM" in this case is the operating system (a version of embedded Linux), which is the basic software needed to run and admin the phone, things like the Kernel, bootloader, device drivers, and file system plus any user apps like the phone dialer, launcher, etc. that are included in the ROM. As you can imagine the possibilities of customization are almost endless when it comes to the ROM. Different kernels, different drivers, different apps and many combinations of those.
The modem is actually part of the kernel. It's the device driver for the phone hardware. Being that it's part of the kernel it "works with" other code that's elsewhere in the kernel and ROM that is "tweaked" for a particular phone in this case. So when you see "use an i777 modem with an i777 kernel" it's because the code in the modem is written to work with the other code in the kernel. It doesn't necessarily mean it will brick the phone and/or not work but it quite often means it won't work the best if it's not "matched".
Actually the modem is NOT part of the kernel. The modem firmware runs on an entirely separate processor (not one of the main application cores.) - the RIL (Radio Interface Layer - part of the ROM) bootloads that processor by sending the modem firmware to it via a serial port when the system boots.
The baseband processor is almost never listed in a phone's specs because it's a "hidden" part of the system. Very often a device like ours will have more CPU cores than just the advertised application processor cores. For example, early Qualcomm MSM7000-series chips had two processors, one for applications and one for radio. Some people labeled these chips as "dual core" even when they really weren't - the two CPUs were completely different.
Similarly, we have two ARM Cortex-A9 cores acting as applications processors, an unknown ARM core doing radio work (much simpler, slower, and power-efficient than the two A9s), and possibly another application-specific ARM core hidden in the GPS chipset. Maybe more.
This is a bit of a newbie question.. and I'm sure its overly simplified..
But..
I understand that the bootloader requires a signed image.
I think I understand that was done primarily to ensure a secure platform when running netflix in HD? And that it is built into the platform by TI (m-shield)?
Why can't the B&N developers work on a bootloader mechanism that would allow a custom unsigned rom to be booted from the SD slot only?
The bootloader would not have to be "unlocked" for that to happen.
The B&N rom would still be intact and secure. You couldn't access the netflix hd from the custom rom, but it would allow all the devs to work on updates to the OS and platform. B&N benefit as they can borrow what they want from that work, they keep the developer groups/customizers happy AND they keep a secure platform for the HD legalities?
This is all that would have to be done by B&N engineering as the encryption key within M-Scope would still have to be controlled.
the bootloader will still check the integrity of it regardless. If it does not pass the OEM signature, the image will not boot. The only way to bypass it is to use 2ndInit (which we build a rom around the existing OEM kernel, which is a nuisance), kexec ("kernel execution" by booting another custom kernel off the existing kernel. Double Kernel all the way!) or by convincing B&N to stop being such pricks and unlock our bootloaders. It seems that 2ndInit may be the best way atm because I think kexec may be disabled (correct me if I'm wrong). Best thing we can do right now to help the devs is to email, berate, smash B&N to convince them that unlocking the bootloader, or providing a BL unlock service like motorola and HTC is beneficial to them.
I don't think that they will be able to magically unlock it. From what I was reading about the TI m-scope platform, half the key is burned in during manufacture. I don't think it can be changed. The best they could do would be to release the mechanism to sign the image (their half of the key).
It sounds like they have a mechanism now to boot from the sd card in order to do the recovery. Is everyone sure that the sd card boot actually requires a signed image? Couldn't they make it so that it didn't with a signed release on their part?
It's undeniable it was B&N's intent to lock down the Nook Tablet.
Unless you're a developer and want the challenge, be a good consumer, vote with your wallet, and don't buy the Nook Tablet. It's pretty pointless to buy one anyway and complain or speculate what B&N should or should not do when they've already made their decision.
The only realistic thing I see happening (seriously, do people really think B&N would release their key?) is a new hardware revision in which the boot loader is unlocked. This will, of course, leave everyone who bought one now screwed.
This Guide has been written to aid users both old and new as a generalization of how the entire process of phone customization works. It is useful and relevant knowledge that will aid in the process of unlock, root, flash, and recovery. This is not a tutorial on unlocking your HBOOT, nor is it a tutorial of how to root your phone. It is a list of things you should know before, during, and after you complete the process. Below is everything I could think of to help guide you as you attempt to obliterate unlock your phone. There are risks involved and you may end up with an unusable device, this is not to be taken lightly. However I have included a basic troubleshooting guide as well. Should you run into trouble, it lists some of the most common issues. If all goes well then congratulations on unlocking your device.
ROOT This is a term used for everything here. Basically there are areas of your phone that are locked out. Root gives you admin or superuser privledges that can be used to modify things like build.prop or app data that you could not normally access. Typically during to root process an app is installed on your phone that governs which apps are given exclusive superuser privileges to modify your system. Superuser by CHAINSDD and SuperSu by CHAINFIRE are the only two apps I'm aware of.
S-OFF Security off, Basically the Holy Grail of Android customization. This disables the security allowing you to directly modify the NAND memory of your device. This in turn allows you to apply patches, device drivers and other niceties not normally available. This is why developers work tirelessly to enable S-OFF (Be sure to thank them for their amazing work).
HBOOT - This is your boot loader and is very similar to the BIOS on a PC, it basically performs POST (power on self test). It is responsible for flashing official software releases, enabling FASTBOOT and is basically the bouncer outside a club. This is what initially stops you from flashing unsigned code to your phone. OEMs have begun offering tools to unlock your boot loader and enabling the use of fast boot. Examples include HTC DEV Unlock, Samsung Odin, and Motorola's Unlock My Device.
Note: Depending on the security of your HBOOT you may or may not have access to the boot partition. Best example would HTC's HBOOT software. Unlocked it only offers access to FASTBOOT which in turn allows for recovery and flashing of ROMs. It does block flashing radios and other firmware
What does upgrading your HBOOT do? It adds support for new hardware (future phones) or fix bugs (break any chance you have of S-OFF, it may also bed your significant other but I have yet to confirm)
Should I upgrade my HBOOT? If a new firmware is released they may contain bug fixes, new radios, or newer versions of Android. If you want S-OFF and have yet to obtain it, no. Developers may find an exploit that can be used to obtain S-OFF. If you are stuck with S-ON and are waiting for S-OFF, again the answer is no. Developers may find an exploit to obtain S-OFF. If you don't care about obtaining S-OFF and you want to update your firmware, flash new radios, or simply want the bug fixes then this is the only option you have while S-ON if you are running stock. The only real benefit comes from what you can not flash with S-ON, basically radios or update for various drivers.
What does downgrading my HBOOT do? It falls back to the previous version of HBOOT, in some cases developers have released tools to downgrade to a previous HBOOT allowing users to then exploit the older boot loader and achieve S-OFF. Some people with S-OFF will upgrade but there is no real benefit, it often causes more problems with ROMs. They then attempt to return to previous HBOOT (very real potential for bricking your phone)
How do I upgrade my HBOOT? By installing an OTA or by using official ROM Upgrade Utility (RUU) To my knowledge there is no other method for upgrading HBOOT
Why do I need to downgrade HBOOT? As of right now, you don't. Do not trifle in what you do not understand.
Does rooting my phone require a certain HBOOT? Root is not dependent on HBOOT
Help, I upgraded my HBOOT and lost root! HBOOT has nothing to do with removing root, the RUU replaced your ROM with one that doesn't have superuser privileges.
RUU ROM Upgrade Utility, this is used to update your phone or revert it to a OEM factory state. The most common use of RUU in the community is to restore the original recovery and or re-enable S-ON
RECOVERY A very small type of operating system that resides on a part of your phone that is separate from Android. It is used by OEMs to install official OTA updates. Developers have created custom recoveries such as CWM, Amon Ra, and TWRP that allow a user to flash unsigned ROMs to the phone allowing for a greater degree of customization not offered by the stock operating system.
Nandroid Also referred to as a system back up. This is a copy if your phone's current system state. It creates duplicate images of your kernel and system including system settings, apps and app data, userdata, and or any mods. First and foremost, this is the most important thing to do after you flash recovery and before you flash a ROM. Should anything go wrong during the course of flashing a new ROM package (ROM/Kernel) and or should you wish to return to a stock state, restoring a Nandroid is the easiest and most effective way. Always be sure to back up your current system state prior to flashing a new ROM and or Kernel.
Note: Using Flash Image GUI will replace kernel from within OS. Be sure to create Nandroid before using this app to flash a new kernel.
ROM A package consisting of a boot image (kernel) and a system image (AOS or Android Operating System, I will now refrain from calling it AOS in fear that Apple may ruthlessly try to sue me for infringing on such a broad generalization to an operating system). ROM broadly refers to all of the phone's software. A custom ROM is any ROM that is modified from stock OEM or AOSP (for good measure, Android Open Source Project)
AOSP vs STOCK
AOSP Pure untainted Android OS maintained by users who want a clean open source mobile OS that is available for everyone. This is the base for ROMs like CM10 or Kanged. This is also the starting point for all OEMs
STOCK A build of Android that has been customized by an OEM. At first manufacturers used the opportunity to build custom skinned versions of Android. They supplied custom apps which they packaged into the ROM separate from the apps available in the market as a means to include exclusive features. This started a fierce competition between manufacturers who began making radical changes to the lowest levels of Android, including the kernel and framework. This led to slow, unreliable devices (frustrating for many developers who only have one real world device) that may have great hardware but poor software. In order to satisfy carriers OEMs may remove features or add many unwanted features. The most prominent issue stemming from this practice has been the Carrier IQ debacle. Roms like Venom and Mean use stock as their base.
Note: The most recent changes done by HTC and other OEMs are so extensive that they now offer their own SDK (Software Development Kit) for app developers to be able to write applications that are compatible with their framework
Kernel It is the layer between software and hardware. It allows the hardware and software to communicate with each other. The kernels must match the ROM Base and Version. Sense with Sense, AOSP with AOSP, ICS with ICS, Jelly Bean with Jelly Bean
CPU Governors A CPU Governor controls the frequency of the processor in response to the workload placed on it. If your phone supports multiple forms of governing, You will have the option to choose how it affects the performance and battery power consumed.
On Demand Pretty much the standard governor. The way it work is by ramping up the frequency to max in order to ensure responsiveness and then sampling the work load and scaling down the frequency to match. This is done by setting maximum frequency when the CPU is busy and gradually scales down as CPU reaches idle.
Interactive Governor Similar to On Demand, Interactive will dynamically scale the clock frequency as the workload demands. This is where the similarities end however. Rather then ramping clock speed to max when CPU is busy, interactive determines how to scale the CPU as it comes out of the idle state. When the CPU leaves idle, the governor sets a timer (pre-set by the developer). If the CPU use is intensive between leaving idle and timer expiring, governor will assume the system is under clocked and ramp to max frequency. It is better suited to handling intermediate clock speeds. Think of this as a faster, smarter On Demand
Performance I got a fever, and the only prescription is more cowbell! This sets the min frequency to the max. Your phone will burn, your battery will spring a leak, and you will see insane benchmark scores. This is obviously not a day to day solution.
Power Save Is anyone home? This will set you max frequency to your min. What a bore.
User Space This allows the user to set the frequencies. Better suited to the more advanced users
Input/Output Schedulers Determines "who goes first" by assigning which operations go to the storage volumes.
NOOP Scheduler This scheduler works on a sort of "first come, first serve" basis and will implement request merging. Its best for solid state drives and good on DB systems. It uses the least amount of CPU cycles per request. The one flaw I can see straight away is "less cycles = less performance"
Deadline Scheduler Used to minimize latency, it reserves five queues and schedules all I/O operations accordingly. This is an aggressive scheduler that runs at near real time speed. It is great for reducing latency and like NOOP, works best on solid state drives, db systems, and reduces latency in any I/O request. When system becomes taxed, this scheduler becomes very unpredictable.
Completely Fair Queue Scheduler This scheduler is scalable per I/O Queue, it distributes I/O bandwidth to all I/O requests fairly and equally. It helps maintain balanced performance through out and is great for multiple processors. The problem is when too many requests are competing for bandwidth, performance degrades.
Simple Input Output Scheduler This is as plain as it gets. No priority queues, no reordering or sorting requests, and the most basic merging. Minimum latency and low overhead, this is a simple and reliable scheduler.
BFQ Scheduler I would rather not risk getting into trouble with this acronym, lets just say the B is for brain and the F is a no-no word. I have not really used this scheduler but it's supposed to be good for USB data transfer, high definition video recording, video streaming, and is a fairly reliable scheduler. In my personal use I didn't get very good results.
MD5 It is basically a finger print for files, the developers use this to help regular users verify the integrity of the file. Most recoveries already support MD5SUM to prevent users from flashing corrupt files. Always verify the MD5 of any Kernel or ROM before flashing it to your phone
How to verify MD5 Hash
In Windows Like most useful utilities in Windows this is not supported, you can download a small utility that will load the file and display the Checksum Hash needed to verify.
In OSX Open a terminal and navigate to the folder your ROM is in and type md5 filename.ext
In Linux Again open terminal, navigate to folder and type md5sum filename.ext
In Android Open a terminal emulator, navigate to folder and use the same command used in Linux. Not surprising as Android is Linux but really neat! There are also apps for checking MD5 Hash Sum
Crossplatform Download managers and manager extensions for browsers like Firefox and Chrome may come with Checksum built in
Recovery As stated, most if not all recoveries will verify checksum hash. It is still good practice to verify by other means to avoid a bad flash
ROM Downloaders I don't really trust these or any large download on Android, sue me. Downloader apps should have a means to verify hash
NAND or N(OT) + AND Named after its basic operating principle, it is a form of non-volatile flash memory. Devices such as USB drives, cameras, mp3 players, and cellphones use NAND to store necessary firmware/software needed to operate. On Android phones the NAND memory is what holds all the information that powers your device. It is divided into separate partitions that are used to store firmware, the kernel and the system along with any other information such as contacts and cached data.
The Partitions are as follows
BOOT This Partition holds the HBOOT and Kernel and as the name suggests, is responsible for the allowing the phone to start. This is the most important Partition in your NAND memory.
SYSTEM This Partition is what holds our beloved Operating System. It contains the entire Android Operating System and the apps that come preinstalled on our phones.
RECOVERY Recovery can be thought of as our alternative boot partition. It holds the advanced recovery console that we need for flashing our phones.
DATA Also refered to as user data. This partition holds our contacts, messages, apps, and settings.
CACHE This is for the temporary storage of frequently used app components and frequently used data.
MISC This contains various bits of information like CID (Carrier or region identification), hardware configurations and various hardware/system settings.
SD_EXT Not to be confused with the Ext-SD shortcut on some phones (a way to access the external SD) This is not a standard Partition, it is an additional partition stored or your SD card that acts as another data partition. This allows you to install apps on your SD card and store data relative to the apps installed.
ADB Android Debug Bridge, it is used for development purposes but it has its usefulness
adb push This allows you to copy a file or directory to a phone
adb pull This allows the opposite, copy a file or directory from the phone
adb sync Copy host - phone if there are any changes present
adb logcat View phone log
adb install [ -l ] [ -r ] < file name > Push package file to phone and install it (-l means forward lock the app, -r means reinstall the app keeping its data)
adb uninstall [ -k ] Removes app package from phone (-k means keep data and cache directories)
adb reboot [bootloader] Reboots phone into the bootloader
adb reboot [recovery] Reboots the phone into the recovery
FASTBOOT A command line interface that can be used to directly flash the file system in Android, it is quite possibly the most reliable method to use if you know what you are doing. HBOOT must be unlocked (OEM or S-OFF) to have access to FASTBOOT
fastboot devices List all connected devices/phones
fastboot update Flash/re-flash a phone from update.zip
fastboot flashall Flash boot, recovery, and system
fastboot flash Flash a specific partition (partitions are boot, recovery, system, cache, and userdata)
fastboot erase Erase specified partition
fastboot reboot Reboot phone normally
fastboot reboot-bootloader Reboot into bootloader
fastboot -w Erase cache and userdata
fastboot oem lock Relock the boot loader
Flash Image GUI Created by member joeykrim, it is an Android app used for flashing recoveries and kernels from with in Android ROM. This is an easy to use tool for OEM Unlocked (S-ON) users to replace/update the kernel and or recovery before rebooting into recovery to switch ROMs. I have not used this myself so I can not determine how safe it is. Always verify MD5SUM
HTC Dumlock Created by TeamWin as a means to flash phones with OEM Unlock (S-ON) on HTC devices with HBOOT that do not allow for boot partition to be flashed. It is built in to TWRP, TeamWin also offer a Universal Dumlock solution compatible with other recoveries. It is probably the safest method for new users despite its seemingly complex nature. It is installed from recovery and run from within Android similar to Flash Image GUI but does not flash kernels. It makes a back up of your boot and recovery and then it takes the back up recovery and writes it to boot from within OS, your phone will then reboot (some phones must reboot manually, do not boot to recovery). From here on the recovery is running from within boot, you must then restore boot and then you will be allowed to flash a ROM like you would if the phone was S-OFF. Be aware that this is not the most ideal method as it writes to your boot partition 3 times (recovery, then restore boot, then kernel). Still this is the most flexible method for new users.
Uniflash Created by member MihailPro, this utility is a veritable swiss army knife of Android customization. It is basically several tools rolled into one. It supports and automates adb, fastboot, image editing/creation, manipulation of file system, back up and restoration of NAND partitions.
Features:
Flash
flash core (My guess is this is the flashall command; boot, system, recovery)
flash recovery
flash splash
flash radio
flash official and custom firmware (updates, patches and zip files)
Modify
edit Build.Prop
remove bloat
install or remove custom applications
copy to and from the device (internal, external memory) with the option to delete files
wipe user data, cache and perform factory reset
Image Creation
Basically back up and recovery
Note: This application is not compatible with HTC Sync, in order to use it please uninstall sync. Those of us with HBOOT 1.15+ still can not modify certain aspects of the memory but this application should at least make it easier to fastboot flash kernels, recovery and or ROM
PRI Product Release Instruction, the protocol used for the transmission of voice and data across Sprint's cellular networks. It may be updated from time to time to improve battery life and/or performance. It will also be updated when any drastic changes are made to the network. This directly affects the performance of your phone's voice and data
PRL Priority/Preferred Roaming List, It is a database used primarily by CDMA networks. It provides a list of network identifiers(service providers), wireless bands, and sub bands used to select the best service for roaming (example of bands/sub bands: PCS wireless band is 1850mhz to 1990mhz, divided into 6 blocks I believe. Sprint uses 1900, Block G if I'm not mistaken). Rather then giving you the best and most reliable option, the carriers choose which service providers to use (they have roaming agreements which help keep company costs down).
NV Non volatile memory, it contains info for MEID/ESN/EVDO and other credentials.
Radios These are basically drivers for the radios on your phone (basically firmware) They pertain to CDMA/EVDO, WIMAX, LTE, BLUETOOTH, WIFI and even NFC. They may be updated with patches or bug fixes to improve battery life and or performance.
Note: The only means of flashing new firmware on S-On unlocked devices is by using official HTC software
Basic Troubleshooting
**Please take the time to read all the relevant info I have posted prior to reading the troubleshooting section. I promise it will help you to better understand your phone and that is the entire purpose of this guide**
Note: To those of you with CWM Recovery, it is recommended that you use TeamWin Recovery as it is better suited for our phones.
Brick This is a very serious problem, your device is catatonic and will not respond to the usual methods of power on/off or sim-pull. In some cases the phone comes back when the battery dies and is recharged, this isn't very often. There are un-bricking tools written by OEMs when they screw up (Samsung / Motorola) and there are tools written by developers working on S-OFF. They notice a very real danger and will supply the tool just in case (this is not possible in all cases). Bricking can and will be permanent in many situations
Boot loop There a different kinds of boot loop situations (also referred to as soft brick, please do not cry brick in the forums if it is a boot loop) the most common are a mismatch of kernel and ROM.
Help, my phone is stuck in a boot loop or my phone is stuck on HTC! Not a problem at all. Hold down the power button and continue to hold it, the capacitive buttons will begin flashing and phone will reboot. After the screen turns off let go of power for one second and the press and hold power and volume down to boot into the boot loader. This is known as a simulated battery pull. HTC built this in as a fail safe to reboot your phone, and it gives us a chance to jump into the boot loader should anything go wrong. Once you have successfully made it to the boot loader read through these forms of boot loop to understand what went wrong.
Known forms of boot loop
Generic Boot loop You have a working recovery and now you have installed your first ROM. There's just one problem every ROM you try boot loops but if you restore your back up and it runs fine. This is common when you haven't taken the time to wipe your phone before you flash. You can use a wipe script to clean your phone or you can systematically wipe Dalvik, Cache, Factory Restore, and then wipe System. Now you can flash your custom ROM (HBOOT 1.15+ requires you to flash the kernel separately)
Help my phone won't boot past the splash screen similar to a generic boot loop, the most common fix is to wipe the phone before flashing your ROM. Wipe your dalvik and cache, the factory reset and wipe system. You can now flash your new ROM
Kernel Issue You have flashed a kernel that may be corrupt, originate from a different base, or is just not supported by the ROM (not really the case these days, most developers are willing to share tweaks and custom code) The result is a phone that boots to a black screen and will hang or reboot.
Note: HBOOT 1.15+ requires you to flash the kernel separately, all relevant info to do so is in this guide.
ROM Issue The kernel boots and luckily the ROM takes to the kernel but something in the kernel does not agree with your ROM. The result is a phone that will boot to android and promptly reboot.
Missing ROM Due to a misunderstanding, you have already wiped all ROM data from phone (cache, dalvik, and system) and fastboot flashed the kernel. Now phone hangs on HTC boot screen and will not load Android. Only the kernel has been flashed, the screen hangs because there is no OS to load. Fear not, return to recovery and flash the ROM package that your boot.image originated from. Now select reboot to system and wait for your phone to restart. The kernel will boot, your OS will load, and all will be right with the world.
Update.zip or update pmg.zip This is a doozy, the rewrite didn't take and you no longer have a working kernel or system image, phone will keep booting to boot loader. If you updated using fastboot this will be less frustrating then if it was placed on the root of your phone/SD card. If fastboot method was used just jump into recovery and flash a working ROM package or restore a back up. If updating from boot loader, remove the SD card and delete update. The boot loader will continue to automatically read update and flash it until you do so.
Bad kernel and or system image and recovery Phone will boot to boot loader, will not boot to OS and selecting recovery will boot to boot loader. All is not lost, simply fastboot recovery and or boot image (for those on HBOOT 1.15 and higher) and then flash ROM from recovery. This happens but it is very unlikely it will happen to you.
MISC
Help I just flashed the latest *insert ROM here* and my apps wont open (force close) This isn't the end all solution, but in many cases you just boot into recovery and select fix permissions. If you still have apps force closing and you know its not from the market, you may have to boot recovery and wipe the system and data, you will then need to re-flash the ROM
Help I flashed a new ROM/update/script and now I can't access my internal/external SD card Its OK, the SD card has been corrupted but you can reformat it with recovery itself or by using recovery to mount the card and formatting it by PC
Help the internal card isn't recognized by recovery or PC! (This is rare so make sure before attempting this fix) You're card is beyond a simple reformat, the physical address linking the card and or entire card is corrupt. Don't panic, you have to start clean. Back up the info on you external or remove it, make sure you have a ROM available on your PC. Go into recovery and repartition your phone, this will wipe all memory. You then load up a working ROM (a bad back up may be responsible or just reintroduce the problem), after you have flashed the ROM (HBOOT 1.15+ must fastboot kernel, unless S-OFF) go ahead and boot into android and restore your apps.
Help I repartitioned my phone and now I'm having trouble with my apps Not a problem, go into recovery and fix permissions.
My power button is broken! While I really don't recommend continued flashing of your phone without a power button, you can use built in menu options to reboot to recovery or adb reboot to recovery and or adb boot to fastboot.
Note: In the event that recovery is somehow damaged, phone may boot to boot loader depending on the state of your system. To the best of my knowledge, there is no way out if power button is damaged
Help my power button is broken and I'm stuck in the bootloader without Rom or Recovery Without the power button you can not choose recovery from the menu, so even if you flash TWRP you are stuck in bootloader. Flash recovery normally so that you have it after the problem is fixed. (Type fastboot flash recovery twrp.img) Now flash recovery again, only this time you will flash to boot. (fastboot flash boot twrp.img) This is a workaround to get into TWRP. Now we reboot the phone and flash the rom. (Type fastboot reboot) Wipe the phone as you normally would. (Dalvik, Cache, Factory reset, System) Install a Rom that has a kernel installer and reboot.
I can't seem to get my GPS to lock onto my location You can try using an app called GPS Tools, it will clear any data and reset GPS
How do I check to make sure my ROM/Kernel isn't damaged? Open zip file prior to flash or verify MD5 Checksum Hash
How do I check MD5? Read my section on MD5 verification
How do I flash ROMs? You can use Regawmod but I recommend you use HTC DEV Unlock. The basic process for this is simple. Register to HTC Developer website, go to unlock device and select other. Follow the simple instructions to enable adb and request token(Its a unique identifier for each phone). The website will then ask for token and send an email with further instructions. Once you have unlocked the boot loader you will now have access to fastboot. You have 2 methods of flashing recovery, you may fastboot flash the recovery image or use the update zip provided by TeamWin (Make sure the zip or image is compatible with your phone and verify MD5 sum to ensure no corrupt files are flashed). Once recovery has been flashed, its best to boot into recovery and make a back up of your phone's current state. Now before attempting to flash any ROMs, boot back into stock Android and download Goo manager from the market. Once installed, open app and from the menu select install open recovery script. This will ensure you have the latest recovery incase the one you just flashed is out of date. It will also enable you to use yet another alternative method to reliably flash your phone. As always, please read all relevant information before you attempt to unlock or flash your device. There are guides to help you posted on the forums. Good Luck!
Note: HTC Device Drivers must be installed prior to using HTC Dev Unlock, it should be covered in the HTC's unlock instructions.
Help the RUU failed and my phone is stuck in boot loader Try running it again or failing that, flash twrp in fastboot, then flash a kernel from which ever rom package you wish to flash and flash rom in twrp. If you really want to update it would probably be better for you to flash a stock rom with a stock recovery and perform an OTA update. If you relocked your boot loader, just flash the unlock_code.bin which you can get by unlocking through HTC DEV
Help my Android has super ceded Isaac Asimov's Three Laws of Robotics You gave it root, what did you expect to happen. It's the ghost in the machine man, Sky Net has to happen eventually.
So a brooding teenager with a hatred for machines really is our only hope for survival? God no, an emo teenager is never the solution
I think this is it for the most part, everything here should help most users troubleshoot their phones by themselves.
Thank you thank you thank you
Oh yea FIRST lol
Sent from the depths of hell
---------- Post added at 01:13 AM ---------- Previous post was at 01:07 AM ----------
Btw nice write up suggestion if i may would be add link to my flashung thread that also has rx's link to his thread about everything just a suggestion
Sent from the depths of hell
didnt I shoot you, damn those incredible recoveries they save just about anything if you know how to use them. Also, I believe that post has inevitably given me some form of carpal-tunnel. That or I'm just tired of typing typing typing. ALSO, I thought about linking the guides but that would make it more of a tutorial style and I clearly state it is not a tutorial, all the relevant information is on XDA or linked by other members
om4 said:
didnt I shoot you, damn those incredible recoveries they save just about anything if you know how to use them. Also, I believe that post has inevitably given me some form of carpal-tunnel. That or I'm just tired of typing typing typing. ALSO, I thought about linking the guides but that would make it more of a tutorial style and I clearly state it is not a tutorial, all the relevant information is on XDA or linked by other members
Click to expand...
Click to collapse
Very true well sorry bout carpel tunnel and all that lol very informative tho if used that is
Sent from the depths of hell
These people better use it lol, I some what ignored the gf to write this and I suspect she will be forgoing all extra-curricular activities in retaliation
I've been a bit confused on this: If I have S-OFF already, flashing a new RUU isn't going to be a problem; right? All I would have to do is re-install a rooted ROM to be back to where I am now (using CMX)?
if you want the new radios you can flash a zip that has the new radios without changing your hboot
om4 said:
And for the love of God clear your Wallet settings before you do anything. Menu > Settings > Reset Google Wallet. This can not be done anywhere else, you have been warned
Click to expand...
Click to collapse
Actually, I think it has been proven that you don't have to clear Wallet settings. I can't remember where I read it, but the problems when the phone first came out were problems with the app itself. I have flashed around 5-6 times with a full wipe without clearing the settings and Wallet works fine. I use it every day.
sofla2 said:
Actually, I think it has been proven that you don't have to clear Wallet settings. I can't remember where I read it, but the problems when the phone first came out were problems with the app itself. I have flashed around 5-6 times with a full wipe without clearing the settings and Wallet works fine. I use it every day.
Click to expand...
Click to collapse
well 1.22.651.3 did reset some of the phones that had bricked the secure element but not all of them, there are users who havent taken the new updates either so better safe then sorry. I added it as an after thought just to be safe but if its no longer a concern I can remove it
om4 said:
well 1.22.651.3 did reset some of the phones that had bricked the secure element but not all of them, there are users who havent taken the new updates either so better safe then sorry. I added it as an after thought just to be safe but if its no longer a concern I can remove it
Click to expand...
Click to collapse
No, probably best to leave it to let people know there was a problem, especially if for some reason they are still on the original software.
sofla2 said:
No, probably best to leave it to let people know there was a problem, especially if for some reason they are still on the original software.
Click to expand...
Click to collapse
Out of curiosity I looked at the change log for Wallet, all data is stored in the cloud now. So if I'm understanding this correctly, the secure element problem appears to have been bypassed
om4 said:
Out of curiosity I looked at the change log for Wallet, all data is stored in the cloud now. So if I'm understanding this correctly, the secure element problem appears to have been bypassed
Click to expand...
Click to collapse
That is a possibility
Arrghh!!?!?!! A developer called MihailPro just released a tool aptly named Uniflash that now makes a good chunk of this irrelevant. Oh well, it makes things easier for everyone here. I guess I could always add troubleshooting scenarios, unless a dev thinks of a way to automate that as well lol
om4 said:
Arrghh!!?!?!! A developer called MihailPro just released a tool aptly named Uniflash that now makes a good chunk of this irrelevant. Oh well, it makes things easier for everyone here. I guess I could always add troubleshooting scenarios, unless a dev thinks of a way to automate that as well lol
Click to expand...
Click to collapse
I will have to search for that. Also, Joeykrim's Flash Image GUI works great! I have used it on a few of my compatible devices. It takes 5-10 seconds to flash an img
Sent from my EVO using Xparent SkyBlue Tapatalk 2
om4 said:
Arrghh!!?!?!! A developer called MihailPro just released a tool aptly named Uniflash that now makes a good chunk of this irrelevant.
Click to expand...
Click to collapse
This still deserves a sticky.
Here is the link for more info on Uniflash, for those interested: http://forum.xda-developers.com/showthread.php?t=1859261
Added basic information on Uniflash, i was trying to add it earlier but my internet hates me
side note: those who took the time to read and learn about the info I posted will most likely be able to name the adb/fastboot commands this program automates...not very useful but it shows how easy these tools become when you understand the underlying process
Pretty good write up, but the key is whether people actually read it
Rxpert said:
Pretty good write up, but the key is whether people actually read it
Click to expand...
Click to collapse
thats always the case and a major problem with american education lol
Wileout suggested I post links to the tools and guides on how to root. I sincerely thought about it but theres a major issue with that, if I post links for tutorials or links for the tools I listed the reader is more likely to skip reading and go straight to the tool. Then we end up with more people asking for help
Posting links to other threads also puts the burdon on you for keeping the information up to date. I'd suggest leaving out anything that changes rapidly
Rxpert said:
Posting links to other threads also puts the burdon on you for keeping the information up to date. I'd suggest leaving out anything that changes rapidly
Click to expand...
Click to collapse
pfft...thats half the guide now and I wrote that thing at 2am this morning
Hey guys!
I'm not an experienced dev or programmer and messing with aboot partition and stuff is certainly a risky thing. But im annoyed by Samsung's new Firmware Architekture, in detail the new locked Bootloader.
After days of excessive Google'ing i found this impressive posting: http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
I'm not really a programmer so we will need experienced Dev's to step forward and to get rid off this damn Knox Bootloader.
@dev' s
What do you think ?
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:
Code:
if (!boot_into_recovery) {
index = partition_get_index("boot");
ptn = partition_get_offset(index);
if (ptn == 0) {
dprintf(CRITICAL, "ERROR: No boot partition found\n");
return -1;
}
}
else {
index = partition_get_index("recovery");
ptn = partition_get_offset(index);
if (ptn == 0) {
dprintf(CRITICAL, "ERROR: No recovery partition found\n");
return -1;
}
}
if (mmc_read(ptn + offset, (unsigned int *) buf, page_size)) {
dprintf(CRITICAL, "ERROR: Cannot read boot image header\n");
return -1;
}
This code is straight out of lk's implementation. Next, after performing some sanity-checking of the boot image, which contains a custom header format, the function loads the kernel and ramdisk into memory at the addresses requested in the boot image header:
Code:
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;
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:
Code:
if (check_sig(boot_into_recovery))
{
if (!is_engineering_device())
{
dprintf("kernel secure check fail.\n");
print_console("SECURE FAIL: KERNEL");
while (1)
{
/* Display tampered screen and halt */
...
}
}
}
/* Boot the Linux kernel */
...
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!
Click to expand...
Click to collapse
Regards
You do realize this has been for a whileee now, right? This is djrbliss' loki exploit.
http://forum.xda-developers.com/showthread.php?t=2292157
... yes i do. Question is: will this work in similar ways on a international gt-i9505/ i9500 ?
*Hier könnte ihre Werbung stehen* *
Try it. But only on the qualcomm variants.
Does aboot still allow a boot.img to be loaded from emmc before signiture checks? If so another loki-like exploit is possible. Could use qpst and flash a custom emmc maybe and change the modem back to MDK but another exploit would need to be found first.
Sent from my cm_tenderloin using xda app-developers app
silentscreamer said:
Hey guys!
I'm not an experienced dev or programmer and messing with aboot partition and stuff is certainly a risky thing. But im annoyed by Samsung's new Firmware Architekture, in detail the new locked Bootloader.
After days of excessive Google'ing i found this impressive posting: http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
I'm not really a programmer so we will need experienced Dev's to step forward and to get rid off this damn Knox Bootloader.
@dev' s
What do you think ?
Regards
Click to expand...
Click to collapse
A few people have already pointed this out but LOKI is actually a bootloader exploit that was used for AT&T MDB and MDL firmwares so LOKI'd custom recoveries and Kernels could be put onto the phone. You can find more information about it in the bootloader exploit thread in original development. This exploit also worked (after a little modification) on earlier Verizon S4s and is now being ported to other phones with locked bootloaders. However, the MF3 firmware update from AT&T patched the LOKI exploit so it can no longer be used with MF3 bootloaders.
So, for MF3 S4s, LOKI is not an option any more, however, the idea of still trying to get the bootloader unlocked is an ongoing process. You can do a search for the topic and you should see several existing threads present themselves. It is important to read the information in those threads in order to better understand where the process is at. And before you think, "well maybe this will work...or can this be tried...", understand, it probably has been tried an did not work.
This isn't to say it is a lost cause or shouldn't be pursued, it's just about realistic expectations. Basically, without Samsung's encrypted signing Key, or a means to generate it, or a reliable way to put a separate bootloader on the phone, it is a stuck project. SafeStrap, creates an entirely new environment for a ROM(S) to exist on a phones internal SD card, therefore, once again, sidestepping the original bootloader.
Search for other threads (about this subject) and contact some of the people that have similar interests from those threads. I won't drop any names because I'm not sure who is still investing time and who has moved on. That will be for you to decide. But please, before posting anything else about this or asking any more questions, search, read, and learn about what has already been done and you will find yourself with a much better understanding about what can be done. Good luck.
Exploit for local Linux Kernel (K2.6.37-3.8.9)
scott14719 said:
A few people have already pointed this out but LOKI is actually a bootloader exploit that was used for AT&T MDB and MDL firmwares so LOKI'd custom recoveries and Kernels could be put onto the phone. You can find more information about it in the bootloader exploit thread in original development. This exploit also worked (after a little modification) on earlier Verizon S4s and is now being ported to other phones with locked bootloaders. However, the MF3 firmware update from AT&T patched the LOKI exploit so it can no longer be used with MF3 bootloaders.
So, for MF3 S4s, LOKI is not an option any more, however, the idea of still trying to get the bootloader unlocked is an ongoing process. You can do a search for the topic and you should see several existing threads present themselves. It is important to read the information in those threads in order to better understand where the process is at. And before you think, "well maybe this will work...or can this be tried...", understand, it probably has been tried an did not work.
This isn't to say it is a lost cause or shouldn't be pursued, it's just about realistic expectations. Basically, without Samsung's encrypted signing Key, or a means to generate it, or a reliable way to put a separate bootloader on the phone, it is a stuck project. SafeStrap, creates an entirely new environment for a ROM(S) to exist on a phones internal SD card, therefore, once again, sidestepping the original bootloader.
Search for other threads (about this subject) and contact some of the people that have similar interests from those threads. I won't drop any names because I'm not sure who is still investing time and who has moved on. That will be for you to decide. But please, before posting anything else about this or asking any more questions, search, read, and learn about what has already been done and you will find yourself with a much better understanding about what can be done. Good luck.
Click to expand...
Click to collapse
hey guys, are these two links new methods or just more links to the Loki method?
http://m.h-online.com/open/news/ite...irculation-Update-1863892.html?from-classic=1
and
https://patchwork.kernel.org/patch/2441281/
What you want to achieve by this exploit?
This exploit has been designed to boot modified and thus unacceptable boot.img/recovery.img because of security enforcement on ATT/VZW models.
I9505 allows to boot any modified boot.img/recovery.img, thus there is no point for this explorer.
As for KNOX flag: it's set before aboot.img and affects TrustedZone. You cannot affect this flag from even aboot.img context.
Since Knox Bootloader : aboot downgrade does not work anymore *
silentscreamer said:
Since Knox Bootloader : aboot downgrade does not work anymore *
Click to expand...
Click to collapse
on Qualcomm devices, downgrade usually prohibited by qFuse. If you will find the way to flash an older aboot then you will end up with hard brick because qFuse is checking not only while flashing, but also while booting. Signatures of all bootloaders include status of qFuse set. Blown qFuse invalidates all previous valid signatures.
I don't recommend to find the other way to downgrade tz, sbl1-3, rpm and aboot parts if it's not possible to do in Odin. Risk of hard brick is very high!
And, by the way, as i've mentioned above, Knox flag is checked on much earlier stage (TZ) than aboot. You won't gain anything by replacing aboot to an older version.
I could really use something if you guys have it... im hard bricked and vzw model s4 isnt supported my any of the regular " unlock boxes" i mean i checked Riff, easy Jtag, Medusa, NS Pro, octopus!!! nothing... so I need some support. something I can throw on my phone when I wire it up to at least get me to the bootloader?>?? thx a bunch guys.
I think best buy can flash latest firmware on crapped out phone..
lgkahn said:
I think best buy can flash latest firmware on crapped out phone..
Click to expand...
Click to collapse
they probably can. AT&T did it on my bricked s4 now im mf3 though...
Guys, this horse is already well dead and apparently still being beaten.
Short of some astounding exploit being found this may not ever happen if you ever went past the original release firmware.
As jcase and others have said, it comes with the device and most/all knew going in - eyes wide open.
The alternative is to wait for a dev device and pay for it when it is made available.
(Doesn't work for Sprint but we don't seem to face these issues... yet.)
Edit:
By request the thread has been re-opened as it is a central point to collaborate on S4 bootloaders.
Things have also changed with 4.3 that now include more than Verizon and AT&T.
For example, Sprint is now seeing similar restrictions as the Note 3.
I would though kindly request this: Let's keep it relevant and on topic.
Let's not let this turn into a "Can I haz an unlocked bootloader" thread. We all have better things to do.
Ill start taking the RSA way
Okay,
So I can start cracking, this might take months or years, idk, but its worth a shot.
If I do crack it, Ill get 80% of that nice fat bounty
Whoever patches it gets 20% of that nice fat bounty
So first ill need, the rsa certificate/key (doesnt matter) that verifies aboot.mbn, or if you can, sbl1.mbn (stored in PBL, so prob not unless u can dump it)
Next Ill need the signature u want me to crack (for sbl1.mbn, u cant miss the 256 bytes). This is so I can verify it if I do get it cracked)
Finally, the offset of where to sign.
And thats all
Also, if u patch it, I sign it, and u test it, because i have no verizon, nor a Galaxy S4.
There, thxs!
sir best of luck to you, i have been wanting to run aosp based roms, but cant. i hope to look forward to testing this
tcf38012 said:
Okay,
So I can start cracking, this might take months or years, idk, but its worth a shot.
Click to expand...
Click to collapse
Why do you need an unlocked bootloader if you have already have a quantum computer
We dont want this thread to get locked again. Read garwynn's post.
Has anyone been able to resurrect/boot off their sdcard by using a debrick image or by writing an entirely new emmc to their sdcard? The reason I ask is because im pretty sure its the sbl2 located in modem.bin thats causing aboot to fail the revision check. If you dump mmcblk0p2 then mount modem.bin by using:
Code:
adb shell su 'dd if=/dev/block/mmcblk0p2 of=/mnt/extSdCard/backup/mdm.bin bs=512'
adb pull /mnt/extSdCard/backup/mdm.bin
Then mount in linux using:
mount -o loop mdm.bin /mnt/mkdirhere
You can compare sbl1 and sbl2 inside the mounted modem to the sbl1 and sbl2 in mmcblk0p3 and mmcblk0p4 from the odin image of whatever build your on. I think sbl2 is calling aboot. Anyone have more info? If we dd the sbl1 and sbl2 from an unlockable builds odin image and get the corresponding apps.mbn maybe we can figure something out. Also I checked the mounted modem's sbl1 and sbl2 from the dev edition vs consumer and the RSA encryption of the dev edition is referred to in the modem sbl2, which might explain the different odin failure messages one recieves when trying to flash an aboot from the dev edition vs a consumer edition see here http://forum.xda-developers.com/showthread.php?t=2483619
Sent from my SCH-I535 using xda app-developers app
Hello,
I wonder if the I9505 has the same functionality to boot from a special prepared SD-Card , like a newer I9300 I just had in my hands...
http://forum.xda-developers.com/showthread.php?p=47234165#post47234165
In this case we accidently managed to access SDCARD MODE by only a key combination, without shorteing the internal resistor.
If yes, this maybe could be a possibility to downgrade the I9505 bootloader.
However, DO NOT test this without a special prepared SD-Card or you will brick your device immediately cause your working bootloader will be overwritten.
Maybe someone with I9505 and a JTAG can test this procedure on I9505 and report back...
BR
Robert
Rob2222 said:
Hello,
I wonder if the I9505 has the same functionality to boot from a special prepared SD-Card , like a newer I9300 I just had in my hands...
http://forum.xda-developers.com/showthread.php?p=47234165#post47234165
In this case we accidently managed to access SDCARD MODE by only a key combination, without shorteing the internal resistor.
If yes, this maybe could be a possibility to downgrade the I9505 bootloader.
However, DO NOT test this without a special prepared SD-Card or you will brick your device immediately cause your working bootloader will be overwritten.
Maybe someone with I9505 and a JTAG can test this procedure on I9505 and report back...
BR
Robert
Click to expand...
Click to collapse
i would say you can use a "sd card" that you have nothing on, i'll go and see if i have one somewhere
and i think we also need sboot.bin but we ain't having that file
Hello out there,
it might be an easy question for some of you, so please be so kind and help me out: I highly appreciate your answers.
--
The Samsung Bootloader, which can't be changed due to the burning of the eFuse (yet I do not understand, why one can't use the same method of digitally signing an own bootloader and load it onto the flash without burning the eFuse) boots from a certain file on the flash, which should be Linux-Standard /boot/vmlinuz.
Why can't one backup the whole flash with Samsung Tools and install an own Linux System to boot from?
I now know that the kernel protection is based on a google development, where several virtual machines are loaded and one of those is then the Android System and Kernel, with a Platform where the Apps can be started from (Dalvik) and this virtual machine can be checked for manipulations - so to speak: Software protection = of no use for me or my choice to implement or program my own version of such a protection, but it has nothing to do with a hardware based (knox) protection. Is this correct?
(I do not want to blow the fuse, but use a custom rom. Any solution for this?)
--
I could analyse the open source code of Android and maybe able to initialize an update process, which might replace the whole file system, but doing so might be a bit dangerous if you don't know what you're doing.
Thanks for answering.
TheLazyGuyDE
TheLazyGuyDE said:
(...)
(I do not want to blow the fuse, but use a custom rom. Any solution for this?)
(...)
Click to expand...
Click to collapse
You have already received an answer in your previous threads.
So I don't understand why you keep asking the same thing.
Let me specify my question:
I asked the question in relation to a customization of the bootloader, but I didn't ask it in relation to probably existing Tools, maybe from Samsung (I don't know), which might backup the flash and may be able to put something onto the flash or is this not possible? Why should I change the bootloader (and blow the fuse) if I have all the functionality I need already on the phone? - That's the question.
I've heared something about "download mode" where you can communicate with the smartphone and I've watched a custom rom installation.
I think the installed bootloader is able to backup and restore. But will installation of a custom rom do anything that isn't reversible (like blowing the fuse)?
Or is it fully reversible if I some day re-install the backup I made prior to installing the custom rom?
Is it possible to directly mount the flash under Linux?
Is the bootloader itself directly in the knox-chip? How should the chip otherwise recognise that the bootloader changed?
(a brief overview would be nice)
As you can see: I am very careful and I don't want to do anything wrong, which I'd definitely repent later on. "Just go ahead" without careful planning is not my style. That's the reason why I want to know everything before I start.
I appreciate every answer.