Hello everyone,
Please, just a question about repartitioning a PIT file via Odin. I´m a bit confused about information I have read about the result of the repartitioning operation.
In some forums appear to say the repartitioning operation via Odin is, first, a values rewriting of GPT entries, and after that any kind of formatting/wipe of all partitions.
In other words, if i repartition a PIT file exactly with the same values I have in my GPT table, does nothing occurs and the content of partitions keeps, or partitions data are lost?
Sorry about my english, and thank you for any answer you can give me.
D,
hi,
if i understand correctly, you would still be performing a repartition operation , which will destroy data during the process.
Although, if you have some experience with data/forensic recovery and can get the tools ported to your tab, it's likely
you may be able to recover a fair amount of what you lose without the data being corrupted.
That being said your repartitioning would need to succeed first.
The better approach for rescuing your data would be to pull the mmcblocks/partitions off of the device and onto
your pc [Linux] as img files through ADB [android debug bridge], BEFORE YOU PERFORM THE OPERATION.
That way if you fail in repartitioning [ which is highly likely]
your data will still be preserved on your pc. To be able to pull the information/data from the device, the device must be rooted
or have a custom recovery available with properly functioning access to/through adb for root functions and adb shell as root.
questions belong in q&a by the way.
m
hi,
if i understand correctly, you would still be performing a repartition operation , which will destroy data during the process.
Click to expand...
Click to collapse
Thank you for you answer. Well, what i´m trying to do is just an "experiment" resizing partitions. Of course there are other ways to do it, but what i´m thinking about is this:
Imagine the recovery partition was located in the first memory addresses, so, in one of the first GPT entries, and what i want to do is just modifiy size of last three partitions, so, three last entries in GPT table. If i create a new PIT file exactly with the same values that i have in the GPT table of the device but only modified values for the three last GPT entries, after perform a repartitioning via Odin and restart the device the recovery will be still there?
So, that is the sense of my question: Repartitioning does only write the values in the GPT table, or besides performs any kind of data lose in partitions (wipe,formatting...) ?
questions belong in q&a by the way.
m
Click to expand...
Click to collapse
Sorry and thank you, next time i´ll pay attention to it.
On older devices I had some success resizing partitions using parted in recovery mode via adb.
parted doesn't support ext4 as far as it's useful functions goes, you would have to create/resize any partition
as ext2 and reformat from there, cute approach but more hassle/trouble than it's worth.
for your experiment, be sure you can afford a new tab ! :silly:
i'm pretty sure your block layout is hardcoded in the bootloader. So you will probably end up creating
a very fashionable serving tray.
Meaning your device won't be able to find recovery partition, also there is likely a set amount of partitions allowed
by way of kernel if i remember correctly.
If your trying to get rid of that annoying no-execute permission in data thing, getting rid of FUSE would maybe get that done.
m
Thanks again for your answer. Experiment cancelled, currently no budget for a new tab.
Just a last -and sure a stupid- question, please: In your opinion, what would happen if i extract the PIT file from my device, and use itself to repartitioning via Odin? I mean, just specifying the PIT file and marking Re-Partition, other options (PDA,Phone,etc) unmarked? After restart, could work the tablet or I´ll get a brick?
Thanks again.
Regards.
D,
hi,
That's not a stupid question at all. I would suggest you read this thread all the way through
http://forum.xda-developers.com/tab-4/help/t530nu-pit-file-t2968498
also search via your preferred engine and XDA for terms/variations
samsung pit file signed odin heimdall
so far, the chances of repairing/modifying partition table on these newer devices [samsung] is slim/grim.
However maybe utilizing external/usb-otg storages to suit your needs would be a way to go. :good:
m
Related
I'm no expert when it comes to the topics of rooting and getting access to the emmc and all of that good stuff. I more specialize in ROMs and themes and stuff, the less complexed stuff lol
Someone has posted an idea in the general forums in relation to permanent root, I'm not sure if he posted it here or not. So here's what he wrote....and is it possible? Or does it have to be done manually first before this idea can happen?
Originally Posted by deliberate187
In order to unlock the phone, we have to figure out what the protected sectors are first and all related flags. If an Android app could be made to have direct read access to the eMMC filesystems (including write protect flags) and save a log to the SD card detailing these items, this would be ideal.
Then all that would remain is a program to undo the write protection (and re-do it if necessary to unvoid warranty)
If anyone is willing to create these programs, I would be more than happy to test them out on my own G2.
However, I think the keys to the mystery may lie in the recovery image, and/or in the bootloader itself. Has anyone disassembled these yet?
Click to expand...
Click to collapse
Sorry to have to tell you but this is all old information stuff we already know just are unable to do anything about it. Its harder then just coming up with an idea of something. Now if we knew a person that programed the g2 in htc factory then all would be good but as of now we just dont have the information we need to do anything
thanks
Thanks for the idea. Some people will be mad you didn't post in the root thread though.
File under "I'm no expert but..."
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
I've been able to get the system to change to r/w a couple times while wandering through root explorer. I have made subtle changes to certain folders such as moving txt files but nothing has ever been permanent. I can't really tell you how I did it either seeing as I can't replicate it on demand...I'm assuming it still gets written to cache despite being in the /system
Sent from my T-Mobile G2 using XDA App
heyy, I'm not punchie, I've got what the doctor calls a relaxed brain
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
deliberate187 said:
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
Click to expand...
Click to collapse
if you can figure it out, go for it and i wish you luck
deliberate187 said:
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
Click to expand...
Click to collapse
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
HamNCheese said:
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
Click to expand...
Click to collapse
Listen to this dude. Absolutely correct.
----------- FIXED ----------
Hey guys,
I'm encountering a terrible problem with my P6810 tab. Here is the story :
At first, I just did format /system/ (and /data/, cache and dalvik) in CWM before flashing a new Rom.
After reboot, the tab just got stuck on the "Galaxy Tab 7.7" logo. no bootloop, just stuck on static logo.
At this stage i could go to download mode and recovery, which I did.
I tried to reflash the rom, no success so then i tried to flash stock ICS firmware through Odin 1.85 : Stuck on flashing Factoryfs.img for several hours, so i had no choice but to reboot the tab. (i had no kies-related software running, neither my antivirus)
There, the tab got stuck on the "Firmware upgrade encountered an issue. please select recovery in Kies" screen, no way to go to either recovery or download mode (not even worth saying Kies didn't recognize the tab).
I've been struggling a few hours with that brick and finally managed to get acces to download and recovery modes again by flashing CWM with Odin alongside a PIT file with "repartition" ticked in Odin.
So there I could access recovery, I flashed CM9, everything went smooth. The tab rebooted and got passed the Galaxy tab 7.7 logo and went to the cm9 bootscreen but got stuck there (big desillusion right there).
So now in recovery, i can mount every partition but those two : /data/ and /sdcard/
I figured out by reading similar threads that the solution to my issue might be e2fsck through adb. I'm a complete noob to adb.
I can acces the adb shell but here are what the commands i've been reading about return me : (mmcblk0p9 is /data/ partition on P6810)
# e2fsck -fDC0 /dev/block/mmcblk0p9 :
e2fsck : Superblock invalid, trying backup blocks...
The superblock could not be read or does not describe as a correct ext2 filesystem.
If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else),
then the superblock is corrupt and you might try running e2fsck with an alternate superblock : e2fsck -b 8193 <device>
also had this once with this command :
bad magic number in superblock while trying to open /dev/block/mmcblk0p9
# e2fsck -b 8193 /dev/block/mmcblk0p9 :
Attempt to read block from filesystem resulted in short read while trying to open /dev/block/mmcblk0p9
Could this be a zero-length partition ?
# e2fsck -c /dev/block/mmcblk0p9 :
same as above
can you guide me with e2fsck or give me a link to a specific tutorial related to android e2fsck?
is there not a way in adb to like replace the corrupt partitions with freshly created ones ? or any other workaround ?
Any help will be appreciated a lot, i'm willing to donate to whoever provides me with a solution to get my tab running again.
Thanks for reading.
check this thread, very informative, helped me before
http://forum.xda-developers.com/showthread.php?t=1625675&highlight=bootscreen
Thanks a lot, already checked that one though.
Everything that worked for the guys in that thread doesn't work for me, or I'm too ignorant to find out the right e2fsck command...
Still no one able to provide some help please ?
It's weird that so many people are having the same issue on 7.7 these days, could it be related to the EU ban of this tab ?^^
Anyway, last day before i send it to Samsung
check this thread here it may help you solve your issue. All problems are coming from a brick bug in the ICS Kernel thats trigerred by wiping.
Thanks a lot, trying this right now
Can someone please post a (parted) print of a safe and working Galaxy Tab 7.7 (either of the two models) ?
I need the exact size of the /data partition
ISSUE FIXED Thanks to Zorbakun's last post. A million thanks dude.
However, the actual internal storage of my tab is now 50mb :silly: anyway i'll find a way to fix that too.
the actual internal storage of my tab is now 50mb
Hello Androguide.fr.
Did you manage to find a way to fix your shrink of internal storage? If so, would you mind to share the method. Thanks
Regards
Budi
cakrabayu said:
Hello Androguide.fr.
Did you manage to find a way to fix your shrink of internal storage? If so, would you mind to share the method. Thanks
Regards
Budi
Click to expand...
Click to collapse
Well yeah, didn't recover the 16gb but you can try to earn yourself some extra gigs by doing this once you created a fresh /data partiton :
this is an example for p6810, replace resize 9 with resize 10 if on a p6800
Code:
adb shell
parted /dev/block/mmcblk0
print
resize 9
It will ask you for start/end values, keep the same start value otherwise it will give you an error. A good idea is to resize the partition like + 500mb at a time, to avoid i/o errors you might get when creating/resizing large file systems.
Hope it helps, good luck.
I am about to have to do this myself, and i'm not a developer. i have accessed and navigated around my device through adb, but this level of complexity *almost* over my head. i just want to make sure i'm not going to permanently mess this up. also, someone in another thread tried flashing ICS with an older version of ODIN and now his tab won't even power on. which i'm trying to avoid... so after reading around these forums for a few days (it happened saturday morning--and i KNEW to avoid flashing from stock ICS recovery--i think i wiped /data-cache-dalvik with CWM 5.0.1) i'm pretty sure that failure to mount /data seems to be the super brick bug everybody's talking about. i bought the p6800 as an import in the US so i am without warranty... if anyone can help with a step by step guide for the masses or something... i'm intelligent, and quite computer literate/net saavy, but i'm not a mentat ("dune" reference)...
like, i'm having trouble figuring out how to install adb on windows. and how do i use parted when it's linux software? i've repartitioned HD's before, and i'm familiar with some command-line basics, but....
--going to bed now...my head hurts--
aletheus said:
I am about to have to do this myself, and i'm not a developer. i have accessed and navigated around my device through adb, but this level of complexity *almost* over my head. i just want to make sure i'm not going to permanently mess this up. also, someone in another thread tried flashing ICS with an older version of ODIN and now his tab won't even power on. which i'm trying to avoid... so after reading around these forums for a few days (it happened saturday morning--and i KNEW to avoid flashing from stock ICS recovery--i think i wiped /data-cache-dalvik with CWM 5.0.1) i'm pretty sure that failure to mount /data seems to be the super brick bug everybody's talking about. i bought the p6800 as an import in the US so i am without warranty... if anyone can help with a step by step guide for the masses or something... i'm intelligent, and quite computer literate/net saavy, but i'm not a mentat ("dune" reference)...
like, i'm having trouble figuring out how to install adb on windows. and how do i use parted when it's linux software? i've repartitioned HD's before, and i'm familiar with some command-line basics, but....
--going to bed now...my head hurts--
Click to expand...
Click to collapse
Try the .PIT file for the P6800 located here. You will lose all data, and part of your internal SD space. Looks like the brick happens consistently at the same point of the memory chip, so the same .PIT works for most people. If that doesn't help, you will need parted.
How can you use parted? It's a Linux program that runs in your tablet. You will adb shell to it, then you will have a Linux shell. Everything you put down there will run in your tablet, as if you were typing on it (think ssh, or remote desktop). I can't help you much more, because (knocks on wood) my tablet is still very much alive, and I don't use ADB that much.
Now, I don't know how it works in your country, but here in Brazil the Samsung service accepts warranties issued anywhere. It may be worth a shot.
aletheus said:
I am about to have to do this myself, and i'm not a developer. i have accessed and navigated around my device through adb, but this level of complexity *almost* over my head. i just want to make sure i'm not going to permanently mess this up. also, someone in another thread tried flashing ICS with an older version of ODIN and now his tab won't even power on. which i'm trying to avoid... so after reading around these forums for a few days (it happened saturday morning--and i KNEW to avoid flashing from stock ICS recovery--i think i wiped /data-cache-dalvik with CWM 5.0.1) i'm pretty sure that failure to mount /data seems to be the super brick bug everybody's talking about. i bought the p6800 as an import in the US so i am without warranty... if anyone can help with a step by step guide for the masses or something... i'm intelligent, and quite computer literate/net saavy, but i'm not a mentat ("dune" reference)...
like, i'm having trouble figuring out how to install adb on windows. and how do i use parted when it's linux software? i've repartitioned HD's before, and i'm familiar with some command-line basics, but....
--going to bed now...my head hurts--
Click to expand...
Click to collapse
I am working on writing a specific 7.7 guide to teach people the parted/e2fsck technique I use to revive my bricked p6810 everytime I want to flash a new rom or test my builds.
First, as pointed out, try to Odin the PIT file for your particular model (eg : P6800 16gb).
You got to know that the parted technique is a pain in the ass, that you'll have to do it quite often if you like flashing roms, and that your tab will have a much smaller internal storage.
I think the guide will be ready in a couple days but you can pm be if you need help before that, no problem.
Good luck with this superbrick curse
thanks guys for your help, i'm going to try to figure this out this afternoon. i'm in the US, so they don't even offer warranties on imports. i was told by a samsung rep in the US that they don't grant warranties to imported models. i will first try the modified PIT file, then i will try the more complex method. @Androguide.fr i will PM you if i have trouble with the more complicated method later. thanks!!!!
aletheus said:
thanks guys for your help, i'm going to try to figure this out this afternoon. i'm in the US, so they don't even offer warranties on imports. i was told by a samsung rep in the US that they don't grant warranties to imported models. i will first try the modified PIT file, then i will try the more complex method. @Androguide.fr i will PM you if i have trouble with the more complicated method later. thanks!!!!
Click to expand...
Click to collapse
I just finished writing the guide, it's here : forum.xda-developers.com/showthread.php?t=1862294
Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?
webdawg said:
Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?
Click to expand...
Click to collapse
What are you attempting to do?
Understanding and Hacking
I am trying to understand the device and search for potential exploit vectors. If I take out the inner SD card what type of data does the device still have on it?
It has to have something that starts the boot from the inner SD card. Does this something insert anything into the running code on the device? Can it?
Can, if the device has the type of storage I am talking about, the device record and store even a small amount of data?
I have heard of reference to NAND backups and even seen a quote about how the NAND backup util included in the recovery utils does not backup something. The something I am referring to is not the external SD card.
Web...
Strephon Alkhalikoi said:
What are you attempting to do?
Click to expand...
Click to collapse
Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
TheManii said:
Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions
Click to expand...
Click to collapse
webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2
Okay Then
cdzo72 said:
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2
Click to expand...
Click to collapse
Please. Unless you have an answer please do not reply. I know exactly what I am talking about. If the device does not have any NVRAM in it that one could flash to and only internal memory via SD card then just say this.
webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.
Strephon Alkhalikoi said:
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.
Click to expand...
Click to collapse
Your right. Did not realize it was him, work has an affect on my attention. Sorry Manni.
I am at home now. Let me try and expain myself.
I just do not get it. All the pages I have read and the research I have done everything tells me that everything is stored on the internal SD card.
But I still have this nagging thought from this page: http://www.rdtk.net/2011/06/25/using-streakmod-recovery/ that says this: the firmwares reside on the nand but in an entirely separate area. only stock recoverys can write to them under normal circumstances, you can probably read/write them manually but it’s dangerous as you can super-brick if you don’t know what you’re doing
What the hell is that guy talking about? The way I read it is that an entire subset of firmware exists on the device that only that one webpage has ever talked about. (That I have read)
I have read alot about BIOS hacks and how they function inserting code into Windows. Even legitimate code for paid services. Computrace.
I know about the Carrier IQ software. What I do not know about is the software outside the rom, recovery, boot partitions and such that exists on the Dell streak or any Android device.
I suppose my attitude comes from the ton of forum posts that I read with unanswered questions because people wanted to know why the OP is asking such a question.
I took Manii's post the wrong way because of your question Steven. Not to offend you and I understand why you ask. For example I just hate going into support channels and asking questions about an iptable rule and being told that I should relearn Linux networking because...well just because I did not understand one concept. I took it the same way here.
I apologize to all.
Web...
MTD based nands are more complicated then eMMC nands in this aspect, as MTD nands you simply cannot read from the 'hidden' portions of the nand. eMMC ones you can.
eMMC devices you can always read from any eMMC partition, so you can likely make complete backups including your modem (though no custom recovery does this by default, it's still a bad idea)
Fortunately for us, MTD seems to be 'obsolete', every device that launched with GB installed or newer uses eMMC.
Dell Streak 5/Partition layout - XDA wiki
Dell Streak Pro/Partition layout - XDA wiki
The S5 is a MTD device, the SPro is eMMC, note how the SPro has many more partitions.
The majority of them also exist on the S5, but the only way to access them (safely) is though a stock recovery.
You can write to them with fastboot, but some of them must be unpacked by an updater in the stock recovery. Simply flash them (specific ones) and you'll super-brick that would require JTAGging at a minimum to fix.
You simply cant read the other MTD partitions without JTAGing (it might be possible with a specificly modified kernal, but you dont gain anything doing this, if at all), assuming that the hidden parts are MTD partitions even. For all we know the controller could be directly writing onto NAND pages with their locs hardcoded (which would kinda be like partitioning, but without the formal partition tables(?) )
There's also is a small amount of memory that can only be written (afaik) via JTAG.
It contains your device's ID, such as Service tag and IMEI.
On tegra devices (at least the S7 and S10) it's the WP1 and WP2 partition.
It could be possible that it's on the NAND as a MTD partition, but if it is we dont know about it. It would be insane (and illegal, as changing your IMEI is illegal in most countries) to write to it, but so there's never been an example of it. I dont know where they are on the SPro, i'd need a live device to check.
The modem OS itself is stored on the nand, the modem processor knows (or the bootloader knows) how to feed it it's OS image.
Location breakdown:
NAND: <everything on the partition layout above, including the below>
/system
/firstboot
boot.img
recovery.img
amss.mbn
appsboot.mbn
dbl.mbn
dsp1.mbn
fsbl.mbn
osbl.mbn
DT.img
The innerSD
/data
/cache
Modem storage (lock state)
Device unique data (IMEI and Service tag)
RTC (the clock)
I dont know the exact terminology or the exact order of booting on qualcomm snapdragons (it's likely to be the same with all at least in the same generation)
But it's something like:
Press power button
CPU powers up
IPL loads <hardwired onto cpu>
Check if innerSD is valid (this is streak specific, device also locks up if it fails as the loader isnt robust enough to work around it)
Init modem and it's firmware <amss.mbn on older devices, non_hlos.bin on newer devices> (FYI modems are themselves complete 'system's in that they have their own ram and OS, basebands are complete OS images in most devices)
Check what button combos are pressed
Start booting:
If you pressed the recovery mode combo:
Load recovery SPL <dbl.mbn? + DT.img>
Display SPL menu:
Reboot
Load Recovery ("update from update.pkg")
Read from recovery.img and load it
Caliberate screen
If you pressed fastboot mode combo:
Load the fastboot loader <fsbl.mbn?>
If you pressed the download mode combo:
Go into download mode (for QDLtool)
If you did not press any combo: begin booting normally
Load dsp1.mbn
Load boot.bin
Linux kernal mounts and starts reading:
/system
/cache
/firstboot
/data
Android boots normally
Boot completes, you're at the lockscreen/home screen
I'm just making educated guesses at which *.mbn does what, as noone's really studied them to the point that they are willing to modify them.
Regardless they're signed so you cant modify them (we dont know per-se that the CPU checks the signatures on *.mbns, but I dont think any is willing to risk their device to try anyway)
The kernal images arnt signed, you can simply toss any kernal that is valid (otherwise it wouldnt boot)
When your device boots, the logo flashes 4 times:
1st logo: IPL and it's logo (possibly hardwired onto chip)
2nd logo: SPL and it's logo (stored in one of the *.mbns)
3rd logo: UBOOT and the kernal logo (stored with the kernal, sounds like a band name)
4th logo: bootimage.zip (whatever boot splash is with the installed rom
TheManii,
Thanks for the information. This is everything I wanted to know. If I have anymore questions I will ask later.
Web...
hy,
could someone please explain to me how many partitions the s4 has, why is it so hard to repartition the internal memory?
is all memory located on one chip and how is the partitioning handled, the partitioning information is surely not stored with the OS, so where is it?
where is the bootloader stored then and why is it so hard to unlock it, its just a piece of memory just like the OS right?, is it coded on a separate chip that cannot be rewritten? or hidden somewhere encrypted within some other process?
please guys some clarification here this cant be so hard!
re: partitions & bootloaders
adrovic.ad said:
hy,
could someone please explain to me how many partitions the s4 has, why is it so hard to repartition the internal memory?
is all memory located on one chip and how is the partitioning handled, the partitioning information is surely not stored with the OS, so where is it?
where is the bootloader stored then and why is it so hard to unlock it, its just a piece of memory just like the OS right?, is it coded on a separate chip that cannot be rewritten? or hidden somewhere encrypted within some other process?
please guys some clarification here this cant be so hard!
Click to expand...
Click to collapse
The partition table is stored in the PIT file (partition information table).
The reason it's so difficult to unlock bootloaders is that samsung and all the other cell phone
companies always try to make it as difficult as possible to do because the cell phone companies
frown upon people like the developers here who usually do succeed in unlocking the bootloaders.
It's getting more and more difficult for the developers to do with most cell phones now-a-days.
They don't like developers or end users messing around with the phones firmware or the bootloader.
Even the slightest modification of the PIT file will cause the phone to fail in
in such a way that only repair shops that has a JTAG burner can repair it. (expensive)
That's why NONE of the custom roms found here in XDA contain any PIT files.
If they did then during the flashing procedure it would over-write the stock one. (bad)
It's similar to the Windows MBR (master boot record) which if even slightly off
Windows will not boot.
In Windows a corrupt or missing MBR is a very easy thing to fix so its not a problem.
If the internal memory was repartitioned differently than stock default the phone would
become a shiny brick which would not even be flash-able with stock or any of the custom
roms or firmwares if the partition table is setup even slightly wrong.
Good luck, I would advise you to try to have more interest in becoming a developer of custom
roms here in xda rather than having so much interest in bootloaders and partition tables. LOL
Misterjunky said:
The partition table is stored in the PIT file (partition information table).
The reason it's so difficult to unlock bootloaders is that samsung and all the other cell phone
companies always try to make it as difficult as possible to do because the cell phone companies
frown upon people like the developers here who usually do succeed in unlocking the bootloaders.
It's getting more and more difficult for the developers to do with most cell phones now-a-days.
They don't like developers or end users messing around with the phones firmware or the bootloader.
Even the slightest modification of the PIT file will cause the phone to fail in
in such a way that only repair shops that has a JTAG burner can repair it. (expensive)
That's why NONE of the custom roms found here in XDA contain any PIT files.
If they did then during the flashing procedure it would over-write the stock one. (bad)
It's similar to the Windows MBR (master boot record) which if even slightly off
Windows will not boot.
In Windows a corrupt or missing MBR is a very easy thing to fix so its not a problem.
If the internal memory was repartitioned differently than stock default the phone would
become a shiny brick which would not even be flash-able with stock or any of the custom
roms or firmwares if the partition table is setup even slightly wrong.
Good luck, I would advise you to try to have more interest in becoming a developer of custom
roms here in xda rather than having so much interest in bootloaders and partition tables. LOL
Click to expand...
Click to collapse
thanks for the answer, but the question is how can this be so sensitive.
lets say for example one would take the pit file from the s4 google edition and put it on the samsung s4.
these 2 phones have identical hardware!
as you say the pit file is part of the FW and is just not being touched during the flashing process, but the pit file is being read out by some other peace of software, so basically that peace of software is the only thing that can verify the pit file, so if you also change that piece of software than everything should work just perfectly.
Misterjunky said:
It's similar to the Windows MBR (master boot record) which if even slightly off
Windows will not boot.
Click to expand...
Click to collapse
MBR and bootloader in the PC world, are two completely different things....
@adrovic.ad: Too many. List of Samsung S4 partitions
Partition information and the bootloader are both at a lower level than the OS, so neither would be stored with the OS. Both would be located in low level storage, which cannot be written without tools and software that cannot be discussed here. The bootloader transfers control of the hardware from the low level firmware to Android, and then sits quiet. As to why it's so difficult to unlock a bootloader, it isn't so long as you don't have a US S4 such as the SGH-I337. In that one, AT&T encrypts the bootloader to prevent modifications to the device. To break the encryption would require more time than the current age of the Universe.
Most Galaxy S4 devices don't have a locked bootloader.
It's harder than you think. It's probably much harder than I think, and I think it's hard.
Ever since I rooted and de-bloated my S6 I've wanted to re-partition it because it would free up over 2GB of unused space of my /system partition. The way I see it, there are two possible ways this could be done:
One, customising a PIT-file
A PIT-file is a file that can be flashed through ODIN. It tells the phone how to partition the internal eMMC storage. It's quite easy to modify and read, however, the phone will refuse to run it without a digital signature. To digitally sign a file one has to have a private key, a key which I'm guessing only Samsung has. So without a leak, we're at a loss.
Which leads us to possibility two:
Using LVM
LVM is short for Logical Volume Management and is a way to make "virtual partitions". It's much more complex than customising a PIT-file, but it's doable - it's been done on Android devices before. The author of that thread, steven676, has made a version of LVM for Android, and has included some nice documentation. Since I'm not an expert in Android I did run into some problems. I'm making this thread so that we may be able to sort them out together (read up here):
I'm going to give each step a status on how far we've come: problem; hopefull and done. As we figure out this further I'll update the steps.
Step 1: Gathering information problem
This is the only place I really got stuck. What I couldn't find out was the erase block size. Basically that's the smallest size of data that can be deleted from your flash memory at a time. He's referring to a tool called flashbench, which ran nicely in my linux VM, but I can't figure out a way to use that tool to benchmark the internal storage of the S6. I'm at a loss.
Step 2: Configuring LVM hopefull
I've read through his sample configuration file. It doesn't seem to be any trouble there.
Step 3: Creating a modified recovery hopefull
I'm assuming this wouldn't be a problem, we just have to compile a version of TWRP with the said changes.
Step 4: Creating LVM volumes on the device hopefull
Easy as pie. We should start the volumes on /dev/block/sda15 (system partition), and end them at the end of the flash memory. Four volumes in total: system; cache; hidden and userdata. The system volume should be the size of your system (obviously), the cache partition on my device is slightly above 200MB, so I'm assuming it's smart to keep it like that, I know the hidden partition is used for carriers to install their apps on, however I'm unsure if it's really needed. Could someone fill me in here? Lastly, the userdata volume should fill the rest of the flash memory.
Step 5: Creating a modified boot image hopefull
I know for a fact this is doable and it should be fairly easy. I just don't know how. I believe it would be fairly easy with Android Kitchen. I'll have to read up on this.
He's also included a step 6, but that's only for ROM developers to automate the process.
I'd be very grateful if someone could help with figuring out the erase block size on the S6, which seems to be the only major obstacle. I'll be sure to write a guide on how to use LVM on the S6 if I figure this out.