Related
do a system dump on the phone? The ones posted here are missing things, you would REALLY be helping me out with my ROM and I'd make you a tester and you'd get all the updates first
ballerx43 said:
do a system dump on the phone? The ones posted here are missing things, you would REALLY be helping me out with my ROM and I'd make you a tester and you'd get all the updates first
Click to expand...
Click to collapse
haven't rooted (waiting on all you guinea pigs to die from unsafe doses, haha) but willing for "the cause." rooted lots of devices and have experience testing and with odin, etc. which of the root methods would you like for me to apply and would you like me to factory reset beforehand? that is if someone else hasn't already provided this for you of course...
Root method doesn't matter. Preferably as close to stock as possible. And a factory reset would be appreciated so I don't have to go through and delete everything out
Sent from my SPH-D710 using XDA App
reading through the methods posted on here... they all modify the kernel through odin, wouldn't that render the dump useless as a base???
Unfortunately I just read that myself and realized your right....
Sent from my SPH-D710 using XDA App
although iI'd like to have another Dev chime in
Sent from my SPH-D710 using XDA App
The "root" is really just a modified kernel image (referred to as a zImage, named for it being gzip compressed). That image contains both the kernel itself and tiny in-memory startup disk called the initramfs. That initramfs contains a base set of drivers and commands to get the kernel from boot to execution of userspace things like the rest of the Linux and Android environment.
The one you're downloading from zedomax is not the stock kernel (although, provided Samsung's download is good, it's essentially identical) and a custom-built initramfs that has drivers for things like the cell radio and wifi cobbled together from other SGS2 models that have published firmware and other devices that use similar hardware and therefore will accept similar drivers. Because that initramfs is custom-built, it has nothing from the stock image.
When you're "rooting" in Odin, you're uploading the zImage partition into the memory of the phone, which overwrites the stock image that was there in the first place. Thus begins a chicken and egg scenario. We can't read the stock image without root access, and we can't get "proper" (i.e., bug-free) root access to the system without reading the stock image.
Until Sammy releases a downloadable firmware (which includes that stock zImage in the file), we can't get at it. And you should be cautioned against installing a root kernel unless you know the consequences and can live with the bugs until a "proper" version can be built.
TL;DR: Wall of text. Please read it, people.
timdorr said:
The "root" is really just a modified kernel image (referred to as a zImage, named for it being gzip compressed). That image contains both the kernel itself and tiny in-memory startup disk called the initramfs. That initramfs contains a base set of drivers and commands to get the kernel from boot to execution of userspace things like the rest of the Linux and Android environment.
The one you're downloading from zedomax is not the stock kernel (although, provided Samsung's download is good, it's essentially identical) and a custom-built initramfs that has drivers for things like the cell radio and wifi cobbled together from other SGS2 models that have published firmware and other devices that use similar hardware and therefore will accept similar drivers. Because that initramfs is custom-built, it has nothing from the stock image.
When you're "rooting" in Odin, you're uploading the zImage partition into the memory of the phone, which overwrites the stock image that was there in the first place. Thus begins a chicken and egg scenario. We can't read the stock image without root access, and we can't get "proper" (i.e., bug-free) root access to the system without reading the stock image.
Until Sammy releases a downloadable firmware (which includes that stock zImage in the file), we can't get at it. And you should be cautioned against installing a root kernel unless you know the consequences and can live with the bugs until a "proper" version can be built.
TL;DR: Wall of text. Please read it, people.
Click to expand...
Click to collapse
thanks for the in depth explanation. thats what i was surmising in less knowledgeable terms haha...
Hello,
Im not sure if anyone was aware, but the source code for the kernel is available from the Acer website. Im not sure if this would help with the dev of roms or cracking the bootloader. Thought I would throw it out there.
Its available on the Acer support page under the A100, and is around 100mb
mvan4310 said:
Hello,
Im not sure if anyone was aware, but the source code for the kernel is available from the Acer website. Im not sure if this would help with the dev of roms or cracking the bootloader. Thought I would throw it out there.
Its available on the Acer support page under the A100, and is around 100mb
Click to expand...
Click to collapse
Yeah, I saw that. Doesn't make a difference though, we need a unlocked bootloader before a custom kernel we can make with that is useful.
Back in my Xperia x10 days they were able to find a way to crash the stock kernel and were able to load custom kernels with a locked bootloader. Its probably not feasible considering it was a much older kernel version and from a different manufacturer...but one can only hope right? lol
Don't know if it helps, but the thunderbolt also came with a locked bootloader and devs figured out how to flash a custom kernel. The custom was also locked but supported what they needed it to. It was flashed with the same process as our flashing updates manually. Maybe some of the tbolt devs could help?
Sent from my A100 using Tapatalk
We could do a custom rom that through 2nd-init, but so far its been an uphill battle trying to figure it out. I'm not a kernel developer, but I've done some work modifying and working with cm7 kernels but nothing to this scale.
I do know that we wouldnt be able to change the kernel on this device or a modified recovery because there's some checking going on with the checksum of the disk images.
@crossix
Have you seen this thread in the Nook Tablet forums?
They found a way around the the bootloader problem.
I was thinking the above. Maybe we can make a work around through the kernal code. I havnt done programming on this low of a level but can scan through to see if and what checks there are and if there are any loopholes... I like to think they have a backdoor somewhere in there...
Excuse me, I was wrong. The tbolt with its locked bootloader was solved a little differently. I think what they did was flash an entirely different bootloader to it. One that was still encrypted but unlocked. Don't know if that's possible in this case but thought it was something to mention.
Sent from my LG-VM670 using Tapatalk
Maybe we should talk to nemith and fattire and they may have some suggestions. I am no where shilled at this level of development to talk intelligently to them. My development skills lie in the .Net field and at the application level. So I am not much help.
@painter... i have been looking through the nook forums that you referred to and i certyainly think that this is possible route to go with the a100. this is also way above my skillset, however i will be more than happy to do what i can if there are any developers interested. i have been doing alot of research into the locked bootloader and this is the most promising news that i have heard so far. I wish we could get more devs interested in this little tablet because it has great potential if we could get past the bootloader.
What Ill do later is download the code again, had before, but accidentally deleted it, and look through some of the more important code to see what can be found. Why would Acer put up the source code if there isnt a way to alter the kernel? Seems counter-intuitive to put it up without a purpose...
here is some info on 2nd init, if anyone smarter than me is interested in having a look.....good luck!..... http://cvpcs.org/blog/2011-06-14/2nd-init._what_it_is_and_how_it_works
mvan4310 said:
What Ill do later is download the code again, had before, but accidentally deleted it, and look through some of the more important code to see what can be found. Why would Acer put up the source code if there isnt a way to alter the kernel? Seems counter-intuitive to put it up without a purpose...
Click to expand...
Click to collapse
Because they have to, its required by gpl to make the source public. Just because they make it public, doesnt mean that it'll compile properly though. But, in this case it does compile cleanly and with it we could probably take bits and pieces of cwm for the a500 and get it to work (their gpl version not thor's recovery). How to do that tough with our current encrypted recovery I dunno.
I looked at the thread and it definitely looks like something doable but what offset would we use and how would we tell the boot partition to go look for a custom recovery when we cant even open it to alter its contents since it and the recovery partitions are both encrypted.
If you make a image of either partition using dd and try to mount it and read its contents you see gibberish rather then editable files in the images. might be able to poke at it with a hex editor, but that's beyond my skill level.
Sent from my MB860 using XDA App
Im still in the extraction process, and it is a rather large image. Its around 500mb compressed. I can take a look into it, but cant make any promises that Ill find anything at all. I understand the gpl and whatnot, and the partitions being encrypted, and am just hoping that somewhere in the kernel is a clue as to what is being done that can help us along the way to cracking this thing.
I didnt think of this until now, but is the newer A500 encrypted? If s, maybe we can find the difference between the older and the newer version somehow and see what they are using. Just a thought, could be completely wrong.
from what I understood (I could be completely wrong though) one of the newest updates that brought the a500 up to 3.2.1 changed their encryption method so itsmagic (their security hole) no longer worked. The work around for that was to downgrade to 3.2 and install cwm / itsmagic and them flash a recovery 3.2.1 image.
Sent from my MB860 using XDA App
Hmm, Not sure. Ill look around. Im still trying to root my tab, have been unsuccessful thus far, and about 3 hours into trying..
is there any benefit in opening the device and sniffing around? I know the bootloader's encrypted but some of it might not be? That's how GeoHot found the first iPhone unlock exploit; by shorting two pins or something?
I also know it's possible to read NAND chips with an Arduino to some extent. I dunno, just talking out loud...
Never thought of finding a way through the hardware itself. I have never opened my Acer, probably wont. I have a Chromebook and they only way to install another OS on it was to flip a switch and pop the cover off, since it has a button thats enabled with the case on that prevents writing to specific portions and whatnot... Good thought. Maybe someone will look into this further.
A100 teardown
http://www.techrepublic.com/blog/it...eardown-lots-of-tech-crammed-into-7-case/3028
Sent from my PG86100 using Tapatalk
I think its very nifty that it has an expansion slot for a cellular chip. All the specs I can find on the 3g a101 show it as having half the RAM. Wonder what it would take to pop a 3g chip in there and get it working. :-\ You would probably have to flash the firmware from the 101 to get it to see the chip...
Hi,
I've done a search and apologies I can't find the answer to this one.
I'm running the excellent Android Revolution 6.3.1 ROM.
How do I change the size of the installed System ROM partition versus the Internal partition (the latter is where you install apps that aren't stored on your SD card)?
If the procedure differs depending on ROM just let me know - then I'll be happy to re-post in the Android Revolution Development thread.
I really need to do this. I've plenty of space on the System ROM partition as I've uninstalled system apps I didn't want, such as HTC's weather stuff (prefer Beautiful Widgets for weather). However, I'm running low on my Internal phone's space and microSD card.
It's appreciated I can just convert an app to be stored on the System ROM partition; but doing so means my Titanium backup procedure won't be as efficient. I could explain what I mean but hopefully that's not necessary!
I'll be sure to thank any reply.
Cheers.
I don't think there's a way, and even if there is, it's too dangerous...
very possible, but also not so easy. it has been done and is used on desire and wildfire, and they call it custom mtd partitions. it contains 2 scripts you flash through recovery and requires full phone format except 4 sd. DO NOT FLASH THOSE ON DHD, im pretty sure it will mess something up. the scripts should be modded to work with dhd. i have no idea how to do that
---------- Post added at 08:25 PM ---------- Previous post was at 08:07 PM ----------
http://forum.xda-developers.com/showthread.php?t=1233340&highlight=custom+mtd
Thank you both.
I'm really surprised this isn't something that's done to the point the clever people have created a tool for the DHD. I mean, everyone who uses custom ROMs tweaks things and will find themselves removing unnecessary system apks.
I'm guessing it's not terribly easy because the partition allocation is perhaps set by the hboot version, and the scripts above maybe mod that. I may throw this question to the Android Revolution thread.
Cheers again, and if anyone has any suggestions please fire away!
maybe because dhd has a pretty large internal storage already...
another thing is that sense roms use up most of system partition and its not worth the hussle to add 100-150 mb to 1.2 gb. a bit different story if you go aosp
It's not impossible. The point is the risk is to big, messing with partitions is one of the easiest ways to brick your phone, and DHD already has quite enough of storage space...
if im not mistaken bricking is unlikely because you dont touch hboot or radio. i was using this on wildfire and it worked great. the risk as far as i can understand is loosing your partition info resulting in complete data loss(internal). could be wrong though...
Remember CWM 3.0.2.6? If you tried to format an sd-ext partition with it, an error in the code made it modify internal partitions and bricked many phones... If something goes wrong you can't reason with your device "don't mess up my hboot, only system and data", they are still on the same memory chip...
Sent from my Desire HD using XDA
not in detail, but i do remember the problem with cwm, but not ehat it was.
i didnt say it is impossible, but unlikely. and maybe im under the influence of all the "bricks" from failed rooting with aahk. a lot of people just doesnt seem to understand what brick means.
and about them being on the same chip, doesnt really matter too much because your not reffering to phisical but logical adresess. if you can explain to me a bit more about those things id be really grateful, cause its allways nice to learn something new.
i do agree that playing with lower level stuff such as this increases the risk of bricking if you dont know exactly what you are doing or make mistakes. thats why i dont mess with it myself.
original thread:
http://forum.xda-developers.com/showthread.php?p=7061471
I'm not an expert on this, I'm just posting my opinions based on mine and other people's experience.
Once I made a horrible mistake of using the built-in Windows partitioning tool for some partition resizing. End result: Partitions overlaping, luckily no data loss, but un-mountable/invisible, managed to get my data out with linux, and even that wasn't easy. However, the OP from the thread you posted says that it can't really go wrong, and even if it does, it's fixable with fastboot, can't argue with that, I guess he knows what he's doing. I quite possibly could be wrong, and unfortunately, don't have time right now to research this, but I think that hboot is on the same memory chip as the other partitions, which leads to the partition table being there also, so if you mess up the partition table, you may end up not being able to boot to hboot, therefore bricking your phone.
Once again, this is my understanding of things, if you have time to do some research to confirm it or prove me wrong, please post it here, I'd like to widen mu knowledge too.
Thanks gain everyone for your input. It's a bit disappointing there's been no tool made to do this with our phone or for a particular ROM, but I can't complain since I wouldn't know how to do it myself!
I guess no one saw the need for it, but we got a nice little discussion going on right here. Do some research, jump in, and maybe some day you will make it yourself...
to be honest i didnt read the thread carefully, i only skimmed through since i dont need extra space. what i was saying was only my understanding of things and what o remembered from using it on my wildfire. but, if i remembered correctly, in the thread i posted, op also says that theoretically it should work on multiple devices because the script reads the needed info from the phone. and to clarify on the spot, nobody should try this based on my sometimes inacurate memory. from the learning point of wiew, im interested in learning and thats why i post (or read) here might give it a shot one day when im bored, but first i need to read that thread carefully to better understand how and what it does
Hi guys!
I think the need of repacking and repacked images for every kernel-rom combination is a huge nuisance.
What would be if ROMs would contain their ramdisk on the system partition, and the kernels would just contain a minimal ramdisk that loads the ROMs ramdisk?
One idea:
My first idea would break compatibility with system recovery zips, so a little modified:
There would be a new "ramdisk" directory on system partition, that would containt all the ramdisk files a ROM should have, except the system folder.
So it would contain:
bin
etc
data
...
init.rc
...
and so on.
The init in the actual ramdisk would mount system first, and then make the links:
/bin -> /system/ramdisk/bin
/etc -> /system/ramdisk/etc
/data -> /system/ramdisk/data
...
and then we would include init.rc from /system/ramdisk.
Of course all the ROMs would need to change, but after that, there would be no need for repack. Also for the old ROMs, factory ROM, some could still repack.
That's a nice idea! I thought a little bit about it and here are my thoughts (a novice, please don't laugh at me :silly:
if I understand your idea correctly, your intention is to store the specific ROM's ramdisk in the rootfs, and make a global, generic ramdisk which will be stored in all the kernels.
Upon loading the kernel's ramdisk, it will know to take the ROM's ramdisk from the rootfs (upon mounting it?) and run whatever is in it, thus eliminating the need for repacking.
Do correct me if I'm talking absolute rubbish, but wouldn't this be a security risk?
Currently with S-ON, you actually can't change the kernel's ramdisk, but if the ramdisk will be stored in a writeable filesystem...?
Freezeil said:
That's a nice idea! I thought a little bit about it and here are my thoughts (a novice, please don't laugh at me :silly:
if I understand your idea correctly, your intention is to store the specific ROM's ramdisk in the rootfs, and make a global, generic ramdisk which will be stored in all the kernels.
Upon loading the kernel's ramdisk, it will know to take the ROM's ramdisk from the rootfs (upon mounting it?) and run whatever is in it, thus eliminating the need for repacking.
Do correct me if I'm talking absolute rubbish, but wouldn't this be a security risk?
Currently with S-ON, you actually can't change the kernel's ramdisk, but if the ramdisk will be stored in a writeable filesystem...?
Click to expand...
Click to collapse
On s-off phones ramdisk can be changed on the fly with repacking, and reflashing the kernel if rooted. There is no more security risk in this, than that. And system is ro mostly, so file corruption isn't something to be afraid of either.
Sent from my HTC One X using xda premium
Xmister said:
On s-off phones ramdisk can be changed on the fly with repacking, and reflashing the kernel if rooted. There is no more security risk in this, than that. And system is ro mostly, so file corruption isn't something to be afraid of either.
Sent from my HTC One X using xda premium
Click to expand...
Click to collapse
I agree, other than the fact that repacking+reflashing the kernel on S-ON devices can only be done manually, by a person (which is the device owner, most of the time), and most of the One X's out there are S-ON and not S-OFF...
Sure, a malicious coder can write evil code in the kernel, but that's relatively less threatening since most kernels have their sources published.
If the ramdisk will be placed on a rw fs (or a ro, but it matters not because of the user elevation rooted users can achieve easily), we are adding the risk of malicious code accessing and changing that ramdisk, without the user's knowledge.
Still, this seems like a nice programming challenge, so I'm up for the task. Will start reading the init's code and see how to do it
Guys i would like this thread kept with minimal off topic please, i have already deleted three posts here...
thanks
-Lloir, Section mod
Is anyone really seriously responding to this?
What would be the advantages of modifying Android layout for 1 device only, its so annoying to see this stuff here when even a s-off thread is locked.. currently when all the sources are going to a way whereas all the basic files are device independent makin this even more.. timewasting effort and still we have the same issues. You just lock every rom dev to a ramdisk instead of a kernel dev to a ramdisk.
This is only usefull with a locked bootloader. I never implement this, another reason is that i spend more time getting my stuff aligned with the mainline that is giving me more succes then randomly adding stuff the a system partition.
Oh and btw when youre system partition gets messed up or altered or whatever you wish you had a decent ramdisk. Not to forget the huge amount of users ending up like that and flooding the forums with questions.
TripNRaVeR said:
Is anyone really seriously responding to this?
What would be the advantages of modifying Android layout for 1 device only, its so annoying to this stuff here.. when all the sources are going to a way whereas all the basic files are device independent.
Click to expand...
Click to collapse
Adding 1 directory is not an "android layout modification". They are moving there, yet it isn't independent between the ROMS even on the same phone.
This is only usefull with a locked bootloader.
Click to expand...
Click to collapse
That's what 99% of us have.
Oh and btw when youre system partition gets messed up or altered or whatever you wish you had a decent ramdisk. Not to forget the huge amount of users ending up like that and flooding the forums with questions.
Click to expand...
Click to collapse
If your system messes up you are probably can't boot android either. What the r=1 user do this time? Goes to recovery, wipe, if that doesn't help, reflash.
Since we have different kernel and ramdisk for recovery, this is not a problem.
Xmister said:
That's what 99% of us have.
Click to expand...
Click to collapse
Lol 99% of us DOESNT have this, if we did we cant flash custom roms.
Adding 1 directory is changing Android layout, Google doesnt have it, you want it on /system you alter the layout. Plain simple.
Also if anyone, like me, doesnt like to include youre mod users still need to repack between roms who contain that dir and roms who dont have that dir. That repacking also requires the same kernel edits so basicly you just move the repacking arround.
TripNRaVeR said:
Lol 99% of us DOESNT have this, if we did we cant flash custom roms.
Click to expand...
Click to collapse
Sorry, I was reading S-ON in my mind, I don't know why.
But then it's not only useful for locked devices. It helps just in what it says in the title.
Also if anyone, like me, doesnt like to include youre mod users still need to repack between roms who contain that dir and roms who dont have that dir. That repacking also requires the same kernel edits so basicly you just move the repacking arround.
Click to expand...
Click to collapse
Yes, it can only work if there are enough ROMs taking the change.
And right, call it a layout modification. Why is adding 1 directory bad for anything? It won't break compatibility over anything.
Xmister said:
Sorry, I was reading S-ON in my mind, I don't know why.
But then it's not only useful for locked devices. It helps just in what it says in the title.
Yes, it can only work if there are enough ROMs taking the change.
And right, call it a layout modification. Why is adding 1 directory bad for anything? It won't break compatibility over anything.
Click to expand...
Click to collapse
I dont want to call it bad, i just dont think this developer discussion, as we all know, and probably you also, this kinda stuff is only stuff to think about. As long as the whole community isnt adopting this it will never happen.
As you also state, it only works when enough roms are using it.. THAT is my problem here, currently we need to repack because of compat. issues sometimes.
Cool that sucks i know, you come up with this idea, without proper thinking people say cool lets do that.
When building roms, some devs like this and some devs dont like this, that will happen you can count on that. If you have 3 devs that dont use it you could end up doing MORE repacking then we need to do now.. that is what i'm trying to explain..
Therefore i said cant believe this is seriously looked into at a high mod level dev section. Hope i made my point clearer now
TripNRaVeR said:
I dont want to call it bad, i just dont think this developer discussion, as we all know, and probably you also, this kinda stuff is only stuff to think about. As long as the whole community isnt adopting this it will never happen.
As you also state, it only works when enough roms are using it.. THAT is my problem here, currently we need to repack because of compat. issues sometimes.
Cool that sucks i know, you come up with this idea, without proper thinking people say cool lets do that.
When building roms, some devs like this and some devs dont like this, that will happen you can count on that. If you have 3 devs that dont use it you could end up doing MORE repacking then we need to do now.. that is what i'm trying to explain..
Therefore i said cant believe this is seriously looked into at a high mod level dev section. Hope i made my point clearer now
Click to expand...
Click to collapse
So your point is: "They won't use it anyway"
And why would need more repack? If half of the ROMs would use it, there would be half as much repack needed.
And in the section rules it says even overriding a notification widget should go in this forum. It's not S-OFF forum, it's Dev related forum, such as my idea.
Sent from my HTC One X using xda premium
Lets all be honest and say: people (users) are lazy...
So if they CAN, they WILL go for the non-repack option
Now, as I am a normal User I am not sure what the exact mechanics are behind this.
But as far as I understand it would be less work for the kernel devs.
They only have to take the "minimal" ramdisk, and put it in their kernel.
The rom makers will have to do "more" work.
But it is work they already are doing, most roms are released with a specific boot.img/kernel.
Some romdevs already are making their own kernels to get some functions (within the ramdisk) to work!
They will gladly adapt to a new way of using ramdisks...
Now I suggest to X Mister, Go for it!
Make a tutorial for rom devs, make a tutorial for kernel devs, and make a tutorial for users.
Make it easy for everyone to use this method!
Now I get what Trip is saying, when we have S-Off we won't need this..
This is very true, but S-Off is most likely not going to happen any time soon.
So in the mean time, why not try it for this device?
- I know this is not really a dev related post, but nor were the last 8 or so
Does anybody have any information about how to modify the HBOOT image, or installing an entirely different boot image (e.g. Das U-Boot) onto this device? Or on any device? I've searched various forums for posts regarding HBOOT but not finding any regarding this.
I recently found my G2 (and G1!) buried in storage. I'd forgotten how much I enjoyed using them, especially the G2. I did the root thing, installing TWRP and a KitKat-based ROM, but it is terribly slow, not least of which for its reported 384M usable RAM.
I like to think I've got a pretty good idea as to how Android devices (generally) boot up, and was thinking I've got a fair amount of practice under my belt building my own Linux kernels, and how I'd really like a Raspberry Pi (or variant), but this device already has everything I'd need for a "SBC"-style device.
If I could slap Das U-Boot on there, I think it'd be pretty easy to (try to) boot a Linux kernel and shell and then figure out laboriously what to do for hardware drivers. (For that matter, what's the G2's capability re: USB OTG?) If it's a matter of making actual changes to HBOOT to tell it to load something other than Android (or kernel followed by Android), I'd be fine with researching that and then doing the laborious building an optimized kernel and drivers.
I could also be talking out my ass and have not, in fact, really understood the Android booting process. But I need a project and it would be really cool if I could work on this, I just don't really know where to look beyond what I've read. I did read one sequence where somebody reported on how they actually did a dual-boot Debian/Android setup (literal dual-boot, not a Debian chroot, which involved him modding the boot image for his LG Optimus). I haven't had time to follow through with it to be sure I can apply any of his findings to HBOOT, but I suppose that might be the best place to start.
One other thing -- if I modify HBOOT and break something, is that a brick, or can I arbitrarily swap out boot images even if they don't work? Or, more directly, will I have a means to re-burn the original image even if I were to completely wipe it? Will fastboot or adb recognize the device and be able to communicate with its filesystem? Not that I'm worried too much about bricking it, but it'd be nice to minimize that chance before I just bite the bullet and try another boot image and cross my fingers.
Hi @dwkindig,
You don't need to install a bootloader other than HBOOT to install non-Android software. For instance, I have recently ported postmarketOS to the HTC Desire Z. So if you need a project to work on, check it out. There are a lot of things you could help out with .