Database Users

developing for the DSTL1 / N21

I want to try developing for the DSTL1 / N21
There are quite a few interesting things we can do...
Success has been been seen by xda-devs such as JesusFreke, Amon_RA, Haykuro, and Cyanogen (yes there others) in the field of Android ROMs. The ground work is there, porting and developing can commence.
Why do this?
Current ROM 1.5 - has many problems...
Unofficial ROM 1.6 - is a GREAT improvement, but makes one hungry for something better...
It would be awesome to have some success in this field. I know this device is capable of so much more, but I believe the implementation of the system is the issue. This is not the phone developers fault, as they have their own company agenda, but we could improve our own performance and satisfaction .
For example, my device (1.6 rooted) lags with having only ~50% CPU utilization and ~50MB RAM free...
Overclocking (i mean forcing full CPU capacity - 624Mhz) the CPU has barely helped and only aided battery drain...
Relevant comparison of G1 vs DSTL1 (N21) are
RAM - G1: 192MB vs DSTL1: 128MB
CPU - G1: 528Mhz vs DSTL1: 624Mhz
These specification comparisons say that G1 can run a better ROM than DSTL1? I don't think so. DSTL1 only loses in RAM, which can be made up for using swap!
Devs had success with techniques using: App2SD, swap, ext3, and BFS (faster file system). I believe we could do something impressive here! There are pros and cons to this.
Developers and Testers would be needed. A team of 5 developers and a few testers should be able to get us on the right track. We would definitely need Linux experience, or the desire and ability to soak up all the info on Google
A Linux kernel is a must for this phone, we would have to compile our own... It would be nice to preserve DUAL SIM, but in reality we might have to give up this luxury, as it is proprietary code, unless a new ROM is made backwards compatible (which is possible).
Cyanogen's Github is available for knowledge osmosis http://github.com/cyanogen
A DSTL1 Recovery by Amon_RA (based on Cyanogen's Recovery) is already in Beta...
Cool things are possible. Could I find some developers willing to donate their free time?
Please limit responses to dev talk.

reserved for later

crzyruski,
Believe it or not the very luxury you talk about giving up(dual sim) is the reason why may of us bother to buy these phones(DSTL1\N21) in the first place. Other wise we might as well go with a mainstream phone such as hero etc.

chrismotto said:
crzyruski,
Believe it or not the very luxury you talk about giving up(dual sim) is the reason why may of us bother to buy these phones(DSTL1\N21) in the first place. Other wise we might as well go with a mainstream phone such as hero etc.
Click to expand...
Click to collapse
Its a possibility that I'm not going to ignore, so I stated it.
The point is that the current OS is lacking. Initially we would want to port and learn from porting of the quality ROMs available now. Those obviously don't support dual-SIM.
Progress needs to start from somewhere. When someone releases a new port or ROM not all pieces work... look at the Eclair (2.0) port, half the features don't work!
If enough heads came together we could probably retain dual-SIM, common this is linux and I've seen the most amazing development come to realization. I just need the teamwork because it might take me a whole year in my spare time...

Having a kernel working
Hi,
the most important IMHO is having a kernel working, built from sources.
Obviously, some closed source drivers must be rewritten, notably the NXP5209 (the GSM modem), if we want the device to be useful (i.e. if we want to make phone call).
My first attempt of booting with a custom kernel was unsucessfull (black screen), which brings to the second point: the lack of some sort of console for kernel debuging.
Any idea regarding the NXP? Anyone is aware of some opensource driver or specs?
Any idea also regarding kernel debugging in the N21/DSTL1?
sfabris

@sfabris
I will try to find info for the questions you have.
My initial work will be to make an emulator so we can test on PC and not our devices (because we need them functional for every day life )
Have you checked out how other modders have done kernel modifications?
Namely JF and Cyanogen?
I can't begin to comprehend so I'm glad you took the initiative with this.
Lets make some progress

sfabris said:
Obviously, some closed source drivers must be rewritten, notably the NXP5209 (the GSM modem), if we want the device to be useful (i.e. if we want to make phone call).
Any idea regarding the NXP? Anyone is aware of some opensource driver or specs?
Click to expand...
Click to collapse
Maybe we have it all wrong???? Maybe its PNX?
PDA DB reports DSTL1 as having Nexperia PNX5209 (ARM946) Phone Controller.
http://pdadb.net/index.php?m=specs&id=1714&view=1&c=general_mobile_dstl1
A similar Android with this phone controller is WayteQ X-Phone (TechFaith Lancer)
http://pdadb.net/index.php?m=specs&id=1801&view=1&c=wayteq_x-phone_android_techfaith_lancer

crzyruski said:
@sfabris
Have you checked out how other modders have done kernel modifications?
Namely JF and Cyanogen?
I can't begin to comprehend so I'm glad you took the initiative with this.
Lets make some progress
Click to expand...
Click to collapse
As I'm forced to HTC G1 until I'll wait the replacement for my N21 I'll go in detail on the kernel boot process on other hardware.
A fast way to test kernel in our every day device is kexec which should work also on ARM.

sfabris said:
A fast way to test kernel in our every day device is kexec which should work also on ARM.
Click to expand...
Click to collapse
As far as I understand, kexec is a program that can run a new kernel on the fly...
So I could try a new kernel right from my device without reflashing?
have you tried this? Or is this still theory?

crzyruski said:
As far as I understand, kexec is a program that can run a new kernel on the fly...
So I could try a new kernel right from my device without reflashing?
have you tried this? Or is this still theory?
Click to expand...
Click to collapse
I've tried it on x86, never on arm.
Support is there also for arm, but this not imply that also the Marvell PXA is supported.
It's basically the same way of booting Android from WM via haret.
Fastest way to boot your new kernel or to crash your machine

I have created an emulator.
FYI, LCD density should be 120.
Edit: Technically the density is 133...

files prevent recovery-RA-DSTL1-v1.2.3 from loading
I have been wrestling with the beta recovery-RA-DSTL1-v1.2.3
Amon_RA retrofitted his own recovery image to work for the DSTL1 (N21)...
IT HAS AWESOME POTENTIAL.
Currently ADB RECOVERY SHELL + ROOT is the only thing that is functional.
But I haven't been able to get in touch with him to continue work on it.
The following files prevent me from booting into RA's Recovery, so I remove them:
- e2fsck
- mke2fs
- parted
- tune2fs
Once I am in ADB RECOVERY SHELL I can push them back on and do what I need to do.
Unfortunately the changes are persistent so if I were to reboot and try Recovery Mode again, it won't load
What is so special about those four programs that prevent my recovery from loading?????

is there any ways to update the firmware of N21
hi,
i'm just buy a sciphone n21 (actually is already in our office for 2 weeks but find it now:-( )
and i've to face myself in a situation that i can't use this phone:-( since i buy this phone because:
- i assume that google apps auto sync contact and calendars. unfortunately this phone has not google apps by default.
- and has dual sim support.
so my question: is there any way to upgrade it to a firmware which support is?
can i do anything to use my phone?
thanks in advance.
regards.

crzyruski said:
I have been wrestling with the beta recovery-RA-DSTL1-v1.2.3
Amon_RA retrofitted his own recovery image to work for the DSTL1 (N21)...
IT HAS AWESOME POTENTIAL.
Currently ADB RECOVERY SHELL + ROOT is the only thing that is functional.
But I haven't been able to get in touch with him to continue work on it.
The following files prevent me from booting into RA's Recovery, so I remove them:
- e2fsck
- mke2fs
- parted
- tune2fs
Once I am in ADB RECOVERY SHELL I can push them back on and do what I need to do.
Unfortunately the changes are persistent so if I were to reboot and try Recovery Mode again, it won't load
What is so special about those four programs that prevent my recovery from loading?????
Click to expand...
Click to collapse
e2fsck is a filesystem check utility for ext2
mke2fs is for ext2 filesystem creation
parted is a partitioning tool
tune2fs is for change some filesystem parameters (usually checking interval)
I've read that recovery from Amon-Ra creates automatically 3 partitions (ext2, swap and FAT32). So those commands whould probably mean ext2 filesystem creation. I'm sure Amon-Ra could give us more information on this subject because he added them to the image.
Have you checked your SD card?.
PD: I'm waiting for my N21 . So I can't test yet.

andferno said:
e2fsck is a filesystem check utility for ext2
mke2fs is for ext2 filesystem creation
parted is a partitioning tool
tune2fs is for change some filesystem parameters (usually checking interval)
I've read that recovery from Amon-Ra creates automatically 3 partitions (ext2, swap and FAT32). So those commands whould probably mean ext2 filesystem creation. I'm sure Amon-Ra could give us more information on this subject because he added them to the image.
Have you checked your SD card?.
PD: I'm waiting for my N21 . So I can't test yet.
Click to expand...
Click to collapse
Thank you for that insight.
I am not sure what RA's recovery would have done on its own...
but I have initiated and completed successfully a partition of my SDCard that includes FAT32, swap, and ext2.
Now that I have done this, for experimentation really, I don't know how to use it and what it gives me.
Obviously the swap is useless because I would need a cooked Android ROM that would actually utilize swap.
ext2 is probably for apps2sd... which I tried unsuccessfully - probably because of my own mistake.
I will continue trying and report again later.
As far as Amon_RA, he mentioned he was working on upgrading all the recovery images he has put out to the next version - thus we will be in queue until this comes to pass. Maybe we can just skip this version and go to the next

N21 vs DSTL1: stock comparisons
I have completed the comparison of recovery images of the DSTL1 and N21.
For this test I used an original mtd2.img from my DSTL1 and an original mtd2.img from Slemmen's N21.
The recovery images are identical:
Both mt2.img are 4,194,304 bytes
Both mtd2.img-kernel are 2,141,616 bytes
Both mtd2.img-ramdisk.gz are 386,645 bytes
What is also interesting to note is that the two boot images i inspected were also identical.
The DSTL1 boot image is one that came with the 1502 update from General Mobile (which may or may not be identical to the original).
The original N21 boot image, thanks to ikarishinjisan, is identical to the DSTL1 boot image:
Both mt1.img are 4,194,304 bytes
Both mtd1.img-kernel are 2,141,816 bytes
Both mtd1.img-ramdisk.gz are 148,671 bytes
*Notice how both recovery and boot are the same size... must be padded?
*Notice how boot kernel is 200 bytes more than recovery kernel.... interesting...
On a side note:
Bootloader is identical as expected: both ikarishinjisan's and my mtd0.img are 1,048,576 bytes.

If things are going to go custom, it might make some sense to put ext3 filesystems on these things.. ext3 is just ext2 with journalling, which could be helpful since phones can just die/get dropped/lose connection with battery/whatever.

Also, this can be done with the tools already there..
mkfs.ext2
tune2fs -j

dnfm said:
Also, this can be done with the tools already there..
mkfs.ext2
tune2fs -j
Click to expand...
Click to collapse
Are you referring to the Amon_RA's custom recovery?
I can't get tune2fs onto the recovery without trickery, definitely not noob friendly... until we figure out why.
But great suggestion
I'm guessing the ROM must be coded to make use of ext3, otherwise its worthless?

The kernel would need to be configured to support ext3.

[Devs Needed]Behold 2/II Updated Information for Root/ROMS

I have mine rooted, there is something very interesting about the way Samsung did this. This phone has like 20 different partitionssee below, however I think I know how the phone is able to restore root and the recovery after boot. These 20 partitions include copies of each other. For example if you do su on terminal emulator and then you type "cat /proc/partitions" it will list all the partitions. Notice how some partitions have different labels but are the same size. These are the respective back ups(i think). The only partition that I know is "stl9" or "st9" is the system.
I tried flash_image recovery and said it wasn't a recognized partition as the BH2 also does not have mtd. cat /proc/mtd produces nothing. Hope this helps.
Oh 1 last thing it seems I may have found an exploit with the device management.apk. It has the option to run a bootloader/bootstrap test, could this be exploited to install customer recovery? Its just a thought...
Can someone with root, compile busybox for install on the Behold 2. I am sorry I only have Windows 7.
Terminal Output:
See the areas highlighted in BOLD. The G1 has half the number of partitions and mtd has output.
$ export PATH=/data/local/bin:$PATH
$ su
# cat proc/partitions
major minor #blocks name
137 0 513024 bml0/c
137 1 2048 bml1
137 2 512 bml2
137 3 512 bml3
137 4 1024 bml4
137 5 23040 bml5
137 6 6144 bml6
137 7 23040 bml7
137 8 6144 bml8
137 9 226304 bml9
137 10 8192 bml10
137 11 512 bml11
137 12 40960 bml12
137 13 1024 bml13
137 14 173568 bml14
138 9 210432 stl9
138 12 25088 stl12
138 14 157696 stl14
179 0 1982464 mmcblk0
179 1 1982338 mmcblk0p1
#
Click to expand...
Click to collapse

Samsung is doing their best to screw us here aren't they?
I have an ubuntu partition, but it will be a bit before I can compile. I'm writing up guides to overhaul the current UI.

having trouble with adb in ubuntu. I'll retry tomorrow, but this could take a while. Probably best for someone else to take this one on.

What's the output for 'mount'?

I posted this on alldroid.org today ,,, samsung seem to have used some of its bada OS and or UI in the behold 2 ,.,,.,. I was wondering if someone could download their SDK and see what they can find out ,.,,., maybe it could help us with ROOT .,.,....,.,
SDK link http://developer.bada.com/apis/docs/commonpage.do?menu=MC01040000&mtb1=&mtb2=
''Re: Important Behold 2 Discovery / 1st step to Custom Roms
They are similar but for that method you need 'new PcStudio', which does not recognize the behold 2,.,..,.,.,
BTW the galaxy (( samsung i7500 )) is almost the same as the behold 2 ,,,, same hardware but the behold 2 has a lot more memory ,.,,..
http://androidforums.com/samsung-i7500/ ... rom-s.html
one interesting thing i did find this weekend while doing some research was that (I think ) samsung has implemented some of its BADA Os on the behold 2 look at the video and let me know what you think
http://www.gsmarena.com/samsung_finally ... s-1311.php ''''
PS:;: (thanks to yatimameiji) this was just found and hopefully it can help you look in the right place '''''To get the recovery menu ,.,,.,. when you do vol. down+call button+power and the triangle comes up .,. then do home + power ., recovery menu,''''''' I got it up but cant select anything and there's the e:can;t open cache and some others

Finally some posts back. I thought no one was going to respond and I was going to delete this thread. So this is great news that we can now enter recovery mode. Also I know whats plauging the device with the battery issue. It seems the phone is reading the battery as 1440 mah and the battery is tagged 1500mah. This can be confirmed by using BetterCut and adding the shortcut Battery read.

dan0zone said:
I posted this on alldroid.org today ,,, samsung seem to have used some of its bada OS and or UI in the behold 2 ,.,,.,. I was wondering if someone could download their SDK and see what they can find out ,.,,., maybe it could help us with ROOT .,.,....,.,
SDK link http://developer.bada.com/apis/docs/commonpage.do?menu=MC01040000&mtb1=&mtb2=
Click to expand...
Click to collapse
It seems so close to the Android Developer Site. Did AOSP give some code to Samsung as a base?

I believe so ,I remember reading that it was going to be like the OPhone project , but samsung wants to use this like they use touchwiz on all their touch screen phones ,.,..,.,

ok so i was playing around with my samsung behold2 today, all i found was recovery mode (voldown+call+power) and fastboot (dpadleft+power). im currently installing the android sdk as we speak, after that will play around with this a bit more.

We had a good look at this over at androidforums (behold and galaxy sub forums).
It seems they are using some secure bootloader, and those other partitions (which almost corespond in size) seem to be the original partition in a security container.
I had assumed that on boot if the main partition is modified it would simply reflash it. However we have now been able to 'persistant root' the phone. (check in the behold section on androidforums). We hijack the playlogo file, and insert the shell commands to execute the exploit executable on every boot. This happens after init.rc so making custom roms is going to be a bit of a headache.
Whats strange tho is why it doesnt recognise the system partition was changed when we mod playlogo. Perhaps it just wipes the bin and xbin directories and reextracts them. That would make life alot easier.
I was going to sell my galaxy and switch to a behold, but I couldnt find one cheap enough. So i've stopped looking at all this now.
Hope that helps anyway.

well we have made some head way ..,,.,., we can now flash between builds for the behold2 via ODIN_flasher . For now we have two builds an older build and the one shipped with the phone .,.,.,. so what i think we need is a way to edit the .tar files within the flasher but keep the partition structure that samsung has in_place .,,,. What i have notice is that if you connect to ddms , and go to the system info tab or allocation tracker , you will see that samsung has renamed every thing as a kernel, even the browser .,.,., if we get our hands on sammy's build environment maybe we can make sense of their madness,.,.,..

Odin isnt actually anything new. We've been using it with the galaxy for a while now.
The phones' bootloader contains a download mode, which also forwards to the AMSS's OEMBL in download mode. Odin simply forwards the files to this bootloader without doing anything clever. This is why you can take ANY update from NPS and apply it using odin as is.
We have tried flashing galaxy partitions onto the behold, but as i said in an earlier post there is a secure bootloader and it simply rejects the images.
I havnt downloaded this H6 leaked behold image, but it probably just contains yafs images, probably in a security container. You could unyaffs them, modify and yaffs them up again. Just modifying them is trivial. I'm pretty sure that the bootloader will just reject any modified images tho. Sorry but I don't think this is going to get you anywhere.
On a security unlocked phone like the galaxy we just edit the system or recovery images and flash them back using Odin. Similarly fastboot can also do it. On the behold however i'm pretty sure it wont accept anything that isnt signed.
The only interesting thing to try would be to try to flash the galaxy bootloader onto the behold using odin. We have both the arm9 and arm11 bootloaders if you'd like to try. This is VERY VERY VERY risky and in all likelyhood will brick your phone. But if it works you should be able to manage partitions simply like with the galaxy.
The very first thing you guys should look at is to compare the system image of the galaxy and the behold. Check if there is a security container around the behold one or not. If there is, attempt to exploit it (change length fields, change offsets, create oversized image - the usual stuff).
I think there are only 2 routes to acheive what you want:
- quick route
Use a userland exploit, like the current root. Then use the persisitant root idea to run a script which modified your filesystem on boot - possibly extracting a custom rom from the sdcard onto the system partition.
- Slow route
Try to find a flaw in the secure bootloader, or some other exploit to allow you to flash a modified bootloader.
You're idea of just editing the firmware files directly is really unlikely to work.

Thanks for your input Kam ..well it just a thought , I knew the signing would of been the issue ( same as with the G1 roms and themes ) .,.,., I know someone will figure it out .,.,.. I would love to help with getting this going , but I work 14 hour days ,., I should get a second behold2 soon so I can use one for testing ,,, well till i brick it .........
I'm gonna browse some of the galaxy forums to see how they doing it ,., I """think""" the galaxy is closer to stock android than the behold2 is .,.
BTW , H6 image you talking about , is that one posted by sammydroid ? because he also has a J6 image , H6 is older .

Yeah thats the one. I have a galaxy, and not a behold so my interest in this is kinda limited. I only really got into it because i was going to switch to the behold.
Personally I think you guys are better off just using the persistant root to modify the OS after boot for now.

Samsung Source Code
Does this help at all?
http://opensource.samsungmobile.com/download/OpenSource/SGH-T939_OpenSource.zip
Appears to be the build source for the existing rom. Don't have access to a *nix box to dig into it right now...

Here's the tutorial to install busybox for behold 2.
http://www.myhangoutonline.com/2010/01/08/install-busybox-on-behold-ii/

kam187 said:
Odin isnt actually anything new. We've been using it with the galaxy for a while now.
The phones' bootloader contains a download mode, which also forwards to the AMSS's OEMBL in download mode. Odin simply forwards the files to this bootloader without doing anything clever. This is why you can take ANY update from NPS and apply it using odin as is.
We have tried flashing galaxy partitions onto the behold, but as i said in an earlier post there is a secure bootloader and it simply rejects the images.
I havnt downloaded this H6 leaked behold image, but it probably just contains yafs images, probably in a security container. You could unyaffs them, modify and yaffs them up again. Just modifying them is trivial. I'm pretty sure that the bootloader will just reject any modified images tho. Sorry but I don't think this is going to get you anywhere.
On a security unlocked phone like the galaxy we just edit the system or recovery images and flash them back using Odin. Similarly fastboot can also do it. On the behold however i'm pretty sure it wont accept anything that isnt signed.
The only interesting thing to try would be to try to flash the galaxy bootloader onto the behold using odin. We have both the arm9 and arm11 bootloaders if you'd like to try. This is VERY VERY VERY risky and in all likelyhood will brick your phone. But if it works you should be able to manage partitions simply like with the galaxy.
The very first thing you guys should look at is to compare the system image of the galaxy and the behold. Check if there is a security container around the behold one or not. If there is, attempt to exploit it (change length fields, change offsets, create oversized image - the usual stuff).
I think there are only 2 routes to acheive what you want:
- quick route
Use a userland exploit, like the current root. Then use the persisitant root idea to run a script which modified your filesystem on boot - possibly extracting a custom rom from the sdcard onto the system partition.
- Slow route
Try to find a flaw in the secure bootloader, or some other exploit to allow you to flash a modified bootloader.
You're idea of just editing the firmware files directly is really unlikely to work.
Click to expand...
Click to collapse
Have a second unit on hand now (for about a week) so bricking isn't a concern and can/will try these options... but need guidance. can jump on irc for assistance... anyone interested? The above seems totally possible.... but out of my league without help.

Thanks to MobileBand we had some succees Managed to get the galaxy system onto the behold. Force close problem at the moment but stay tuned.
PS. its fastttttttttttttttttttt

Let me publicly state that kam187 ROCKS! Kudos on the work last night!
Behold owners; start getting hyped... this is the break we've been looking for!

love the work
love you guys work man i have 140mb free on my behold 2 thats with out task manager its blazin fast but always wanted to do something differnent with it can you pleaseeeeeeeeeeee lol ( : ) : post a rom and turt

Archos gen8 bootloader crack (disable signature check)

" PWNED " :-D
As you know, Archos bootloaders check digital signatures of init and recovery kernels, so you need to install SDE to use custom kernels, and it somehow "watermarks" the device.
Good news everyone! I've disassembled both bootloaders, found the code which checks signature, and replaced it (first instructions of verify_hash function) with "return 0" which is "mov r0, #0; bx lr" in ARM assembly. It's much the same hack as on Archos 5, thanks EiNSTeiN from archos.g3nius.org for reverse engineering previous generation.
Archos gen8 boots using OMAP boot ROM from internal eMMC card. Primary bootloader ("boot0") is in 0x20000 bytes after the first sector of internal flash (i.e. at 0x200) and secondary bootloader is written into rawfs, /mnt/rawfs/avboot. boot0 contains image size and loading address in first 8 bytes.
So, here is the patch:
1) boot0: replace 8 bytes at 0x7520 from the beginning of mmcblk0 from 7F402DE9003091E5 to 0000A0E31EFF2FE1.
2) avboot: replace 8 bytes at 0x14424 in avboot from 7F402DE9003091E5 to 0000A0E31EFF2FE1 (same patch). 0x14424 from avboot beginning is usually 0x14824 from the beginning of mmcblk0p1 (avboot comes first in rawfs, just after 2 blocks of header).
Of course you need root to do it. I've done it on my Archos 101, then changed 1 byte in recovery image - it boots into recovery without problem (before the hack it didn't boot into this 1-byte changed recovery).
And of course do it with caution and at your own risk DO NOT replace the bytes if you find other original data at these offsets! Bad boot0 or avboot means bricked Archos. There must be some sort of test point (something connected to OMAP SYS_BOOT5 pin) to boot from USB, or a boot UART interface, so debricking the device must be possible, but it would require some effort to find it, find a proper bootloader and use it.
If someone wants to see IDA database, I'll send my.
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.

Great work! With this base, can yout get something like CW to run?

I'm so waiting for him to come back and say April fools.

I'm gonna screw him up if this was an april fool

First, if this is an April fools, I will find you and hurt you.
Second, what does all that mean anyway? Does that mean Cyanogen on Gen8 is near? Does it have anything to do with roms?

vitalif said:
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.
Click to expand...
Click to collapse
Maybe you should increase that number of post by explaining how you did this.

)))) No it isn't an April fool, my device now really has a modified recovery. Ridiculously modified (1 byte changed), but that's the proof!
Check the patch by yourself )) all you need to write to mmcblk0 is a standard linux dd tool... which is included into standard Archos busybox...
wdl1908 said:
Maybe you should increase that number of post by explaining how you did this.
Click to expand...
Click to collapse
In fact, it was not hard, and if I knew ARM assembly language before, it would be even easier... All I had to do is to find bootloader on the flash (boot0 is obviously in its beginning, and avboot is on /mnt/rawfs), copy it to computer, download IDA, feed bootloader to it and find functions similar to ones described on archos.g3nius.org (BigInteger_ModulusEnter, RSADecipher, etc). It also could be simpler, as BigInteger_ModulusEnter is mentioned inside an ASCII string inside data section... But I've found them by text search also there is a magic "ZMfX" in first 4 bytes of avboot and some other magic inside init and recovery... One also could use them to find interesting points in bootloader.
At first I've started disassembling with the wrong base address, but bootloader has code which copies itself to the correct one in the very beginning, so I've changed it and started over. In fact, it has size and address in first 8 bytes, so this also could be simpler...
So the hack is done, what needs to be done by now - utilize it and create some custom ROM or simply flash urukdroid without SDE...
chulri said:
Great work! With this base, can you get something like CW to run?
Click to expand...
Click to collapse
CW == ClockWorkMod recovery? I don't have any experience with CWM porting yet, but in theory yes, the hack gives us the ability to run custom recovery images.

Don't know alot about the bootloader, but what advantage does this have?

SWFlyerUK said:
Don't know alot about the bootloader, but what advantage does this have?
Click to expand...
Click to collapse
Hm. I'll explain... Bootloader is the program which starts up the device, similar to bootloader on your PC signature check in bootloader prevents us installing modified Linux kernel, initial ramdisk and recovery images. So, for example, we can't have netfilter in kernel without installing SDE, we can't have ClockWorkMod recovery on Archos at all, and we can't, for example, change MMC card splitting into 512M mmcblk0 for system + remaining for "internal SD" with data.
With signature check removed, all this is possible.
The underlying idea of all this signature checking is probably protecting f**king DRM... I HATE IT !!!!!! And hate companies promoting it =) When you install SDE on previous generation archos (5it), it removes drm keys from device memory (this is the "watermarking" mentioned on Archos site). It makes device unable to play the content buyed for it anymore... Not a big deal, but unpleasant. I don't know if this is the same on gen8.
In detail: Archos 101 has OMAP3630 processor. The "0-stage" (very-very first stage) bootloader, i.e. program which gains control after processor power-up, is hard-coded into one-time programmable area on the processor itself and is named "OMAP boot ROM" (similar to PC BIOS). The boot ROM can continue device booting process from different devices including SD/MMC card, NAND flash, UART (serial port) or USB interfaces. The boot sequence is determined from physical pin connection configuration. Our Archos boots from internal eMMC card.
So, OMAP boot ROM loads primary Archos bootloader, without checking any signatures or checksums, and simply transmits control to it. Primary bootloader sets up some processor configuration and then reads secondary bootloader (avboot) from flash. Then, it checks its MD5-RSA digital signature using Archos public key. If signature is incorrect, it hangs the device (goes to infinite loop). So if we modify avboot without removing signature check from boot0, device would be bricked. If signature is correct, control is transmitted to avboot. Avboot determines what system we want to start by pressing different keys, loads it, checks signature if system is init (normal system) or recovery, sets up configuration for Linux kernel and transmit control to Linux.
Interesting facts:
* According to the code, boot0 can use rawfs or FAT filesystems for boot partition.
* During boot process, various messages are printed to serial console. avboot even has some code for receiving commands over serial connections.
* OMAP processor boot sequence can be configured via special memory area which remains unchanged after soft reset, and this configuration will override one determined by physical pin configuration. This does not give us much profit, but is also interesting...

Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?

SWFlyerUK said:
Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?
Click to expand...
Click to collapse
Whats being done will have no affect on performance of the device. It will however, allow a lot of work that can contribute to better performance on the device. That is assuming that we can put on a modified clockworkmod recovery on these devices without bricking them.

He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App

JBO1018 said:
He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App
Click to expand...
Click to collapse
Archangel will give you temp root without using SDE.

He said root with r/w access. Archangel won't do that, the file system is still protected.

pbarrett said:
He said root with r/w access. Archangel won't do that, the file system is still protected.
Click to expand...
Click to collapse
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.

wdl1908 said:
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.
Click to expand...
Click to collapse
To be correct, there is no write protection on internal MMC at all, there is readonly rootfs which is mounted from a squashfs archive (squashfs is compressed readonly filesystem commonly used on Linux Live CDs), so you can't modify _files_ on it while it is mounted. But, nothing stops you from updating it as a whole.

Urukdroid
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.

So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?

shrewdlove said:
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.
Click to expand...
Click to collapse
I think he has already seen this thread but you can ask him
lechuckthepirate said:
So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?
Click to expand...
Click to collapse
Yes you are^^ but the thing is you have to port cyanogen to our gen8^^ and this must be done by a or more devs
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )

Lennb said:
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )
Click to expand...
Click to collapse
this isn't a problem for cyanogen (v7 = Android 2.3.3) because we have the source.

[GUIDE] Re-partition your device using REPIT

You might have seen this guide on XDA, but is out-dated and only seems to work on stock firmware. What about people people running CM13, will it work, or will it brick your device?
This guide is updated and works with CM13 tested by me, it was also written with the i9300 16GB model in mind.
FAQ: next post
I take NO responcebility for any bricks, that's on you. Exactly like rooting, or installing anything 3:rd party (right?). Either is is my responsibility if any data is lost.
If you don't follow the guide, and adventure on your own, there's no one to blame but yourself when **** hits the fan.
Now, let's have a look at my partitions before modifying them (kB):
Code:
Filesystem Total Used Available Use% Mounted on
mmcblk0p8 1032088 17732 1014356 2% /cache
mmcblk0p12 11901576 6355436 5546140 53% /data
mmcblk0p12 11901576 6355436 5546140 53% /sdcard
mmcblk0p10 564416 8964 555452 2% /preload
mmcblk0p9 1548144 632704 915440 41% /system
mmcblk0p3 20144 9568 10576 47% /efs
As you can see, stock paritioning is bad. /preload and /cache has a lot of available space which takes up a lot of unnecessary space.
We can minimize all the partitions and use the space to increase your internal storage, neat; let's do it!
1. Check for buggy eMMC chip
First of all we'll be checking if your chip is possible to SDS (sudden death syndrome) which basicly corrupts your eMMC (internal storage) chip.
This only effects the 16GB model, if you're on another model just skip to the flashing part.
A. Download the app eMMC Brickbug Check app from the Play Store.
B. Check eMMC
Check if your device has the following under eMMC chip:
Type: VTU00M
FwRev: 0xF1
If the values match, you should update to the latest ROM + kernel available ASAP, which should fix SDS, if you don't; your eMMC chip might corrupt under the process of flashing REPIT.
2. Flashing guide
A. Before we begin
- Make sure that you're running the latest version of TWRP (i9300, i9305). Any other recovery and the script will NOT work.
- Do NOT continue if you're running stock, or planning to do so. This script is only tested on official CM13.
- Make sure you're plugged into a power source, and not a computer; or else partitions may fail to un-mount.
- Do a backup of your rare cat images so they don't get lost in the worst scenario.
- (optional) If you want to configure the script, see this.
B. Download required tool
We'll be using ourselves with the tool REPIT made by @Lanchon.
Without it I wouldn't make this guide as it is the only(CN) flexible tool for modifying partitions in Android.
Download the required flashable zip file: [updated 2017-01-22]
- i9300 - here
- i9305 - here
Make sure you DON'T rename it; copy it to your device.
C. Boot into recovery - volume up + home button + power button when powered off
D. Flash the zip file
- This process is a really long one, do NOT interrupt the process.
- If the flashing fails, it may tell you that it copied itself to /tmp, navigate to /tmp and flash the script again.
- If x partition fails to un-mount, try un-mounting it via TWRP > Mount.
Inside TWRP navigate to Install > Navigate to saved REPIT and select > Swipe to confirm flash.
3. Done!
You may now restart your device and verify the extra utilized internal storage.
It's not that hard eh? That's because @Lanchon did a great job on his project available on GitHub. Him and I worked closely on #22 to add support for the i9300.
After re-partitioning (still kB):
Code:
Filesystem Total Used Available Use% Mounted on
mmcblk0p8 32240 4200 26404 14% /cache
mmcblk0p12 13457732 574316 12199796 4% /data
mmcblk0p12 13457732 574316 12199796 4% /sdcard
mmcblk0p10 8048 4120 3520 54% /preload
mmcblk0p9 1548144 638168 909976 41% /system
mmcblk0p3 20144 9568 10576 47% /efs
It seems like we've gained 1.5GB in local storage, hoorah! Totally didn't steal from other partitions
Worth it? (my opinion)
Unless you REALLY need that 1.5GB of extra storage; NO, not at all.
On Android 6+ (CM13) sd-cards are now implemented like normal internal storage. Just buy a 8GB micro sd-card which costs a couple of bucks these days and save yourself some trouble.
Not only that, recently a user possibly got SDS (sudden death syndrome, do your own research) after flashing REPIT. Did my own research and I updated the guide with a step to check for this buggy eMMC chip.
Credit:
- @Lanchon for REPIT.
- @forumber2 for original guide.

QnA:
The questions are kinda copied from the old guide.
Q: Why is /cache a large partition?
A: It's because stock software updates saves in the partition. The partition was extended(CN) when upgrading to Android 4.3, as the update was so large, the cache partition had to be as well. AOSP does NOT use the partition when updating.
Q: What is the /preload partition for?
A: It's only really used if you bought the phone locked. Many mobile operators put in extra apps, and bloatware too in the partition only utilized in stock firmware; and even then... There's some random Samsung crap too. REPIT minimizes the partition.
Q: Any consequences of flashing?
A: Yes, you will NOT be able to install stock firmwares (assuming that you're not running stock). A undo is easy as the script is so flexible.
You will also burn a lot of eMMC life cycles using REPIT so don't do it often, and I hope you've read 1. where I covered the buggy eMMC chip thingy.
Q: Something went wrong with flashing the zip file!
A: Please upload the REPIT log usally found in the folder where you placed the flashable zip file to dropbox, or https://paste.tinyw.in; apparently pastebin doesn't like long logs. Can also be in /tmp. Otherwise you can copy the whole TWRP log found in /tmp/recovery.log, /cache/recovery/log or /cache/recovery/last_log. NEVER copy the whole log and make a post out of it, you're spamming the thread by doing so. Issues with REPIT should NOT be reported here, instead go to the REPIT GitHub page here.
Q: I want to undo these changes!
A: Since @Lanchon is taking over this thread :laugh:, ask him. Sorry for me not doing my homework.
Q: How about the x GB model?
A: They all work, REPIT is designed to assign any leftovers to the partition we use.
More questions? Bring them on.

Reserved #2

May be it's better to give proper credits too considering it was a big mess up in past.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery

nicesoni_ash said:
May be it's better to give proper credits too considering it was a big mess up in past.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery
Click to expand...
Click to collapse
Woops, I made the guide in notepad++, and accedently removed some lines when editing it; including a better credit to @Lanchon; adding in a new one now.

Hawaii_Beach said:
Woops, I made the guide in notepad++, and accedently removed some lines when editing it; including a better credit to @Lanchon; adding in a new one now.
Click to expand...
Click to collapse
I meant in your op too.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery

Btw, is it possible to modify this script somehow so that you can reformat the /cache partition to f2fs? Afaik the minimum size is 100mb.

Sincci said:
Btw, is it possible to modify this script somehow so that you can reformat the /cache partition to f2fs? Afaik the minimum size is 100mb.
Click to expand...
Click to collapse
No, I'm sorry. It is already known, on GitHub: #8.
The minimum size of /cache? The script sets /cache to 32240kB which is 32MB..

nicesoni_ash said:
I meant in your op too.
Click to expand...
Click to collapse
OP?

Hawaii_Beach said:
No, I'm sorry. It is already known, on GitHub: #8.
The minimum size of /cache? The script sets /cache to 32240kB which is 32MB..
Click to expand...
Click to collapse
After I read your conversation with @Lanchon on git, it seems to me that there is no need to wipe data and it will still work, it's that right?
OP - Original Post basically referred to first post.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery

nicesoni_ash said:
After I read your conversation with @Lanchon on git, it seems to me that there is no need to wipe data and it will still work, it's that right?
OP - Original Post basically referred to first post.
Click to expand...
Click to collapse
Yes, you don't need to wipe /data. It just makes things faster; as you wont have to move the content around. Without wiping, it will take a longer time to re-partition.
The script will NOT wipe /data except you add +wipe to -data=max (-data=max+wipe-i9300)
OP has so many meanings, it's f***ed.

Hawaii_Beach said:
On Android 6+ (CM13) sd-cards are now implemented like normal internal storage. Just buy a 8GB micro sd-card which basicly costs a couple of bucks and save yourself some trouble.
Click to expand...
Click to collapse
hi, thanks for the guide!
actually, the external sdcard will always be slower than the internal eMMC. also, the extra free space gets auto-TRIMmed in /data, making the whole eMMC (and thus your phone) faster. also, adopted storage diminishes the total reliability of your phone and data (more devices can fail).
in all, i'd recommend anybody with less than 2 or 3GB free space in /data to REPIT; it's safe and easy.
---------- Post added at 05:35 PM ---------- Previous post was at 05:22 PM ----------
Sincci said:
Btw, is it possible to modify this script somehow so that you can reformat the /cache partition to f2fs? Afaik the minimum size is 100mb.
Click to expand...
Click to collapse
REPIT does not support f2fs for now.
(future support will not include wipe without resizing, as f2fs does not support that yet.)
but you can get what you want anyway:
"-cache=0.03125+wipe"
actually means
"-cache=0.03125+wipe+ext4"
given that ext4 is the default FS for "cache".
"wipe" means format, and never mind what was there before. even if it was something that wasn't ext4 at all, it will succeed.
so you can use:
"-cache=0.0976+wipe"
to get exactly 100MiB-sized cache (in ext4)
then, afterwards, use TWRP to format cache in F2FS
and you'd get what you want.
but...
DON'T!!!
dont use F2FS in ANY partition besides /data! it makes NO sense!
F2FS has an overhead of about 100MB, so basically you would be creating a /cache that is unable to hold any files at all. (ext4 has 5MB overhead.)
and why have a dysfunctional /cache? what for? to have problems? incompatibilities?
certainly not performance, because cache is NEVER used in android. so why do it?
it's soft of a crazy fad, like /system in f2fs.
/system, the one partition we never write to, lol
---------- Post added at 05:39 PM ---------- Previous post was at 05:35 PM ----------
nicesoni_ash said:
May be it's better to give proper credits too considering it was a big mess up in past.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery
Click to expand...
Click to collapse
thanks!
no credit required!!! the GPL allows him to do as he pleases, as long as he doesn't remove the license or claims copyright.
but anyway, thanks for the credit appreciated!
and thanks for invaluable help to port to i9300!!
---------- Post added at 05:43 PM ---------- Previous post was at 05:39 PM ----------
btw, i should start thanking the people who helped with the ports in the comments of the device port file. so far 2. i will back-credit when i get the time.
and i9305 and others are probably trivially supported, i just need the dumps done.

Lanchon said:
really long stuff going on
Click to expand...
Click to collapse
The thing is that not only could REPIT be ported to i9300, but any other Samsung device, right? They all run TouchWiz; for example s4, s5, s6? Have anyone even checked partitions on those devices?
The thing with partitions and the Android community is that almost no one discusses it. If you do a google on partitions on Android; very Little information / threads exist.

Lanchon said:
hi, thanks for the guide!
actually, the external sdcard will always be slower than the internal eMMC. also, the extra free space gets auto-TRIMmed in /data, making the whole eMMC (and thus your phone) faster. also, adopted storage diminishes the total reliability of your phone and data (more devices can fail).
in all, i'd recommend anybody with less than 2 or 3GB free space in /data to REPIT; it's safe and easy
Click to expand...
Click to collapse
To be honest, I never cared about storage speed (same goes for trim), not a heavy user on my phone, and have never been, just doesn't go well when I'm the operator. As long as it doesn't take 1 year to copy my secret .mp4's (ransom.mp4 and many more), there's no worries.
About failure, it's like running a computer. If you shut down a computer without sending signals (unplug from wall etc), it may damage the harddrive; right? Same here. Right?
Any how, If I ever run out of space on my i9300, I'd just add a sd-card. I don't save anything important on my device that doesn't get backed up via TWRP. But..
that's never going to happen! Because my OnePlus One is coming back from RMA service! (finally after 4 months (not kidding)). kinda off topic, but hey; it's my thread right :good:

Hawaii_Beach said:
The thing is that not only could REPIT be ported to i9300, but any other Samsung device, right? They all run TouchWiz; for example s4, s5, s6? Have anyone even checked partitions on those devices?
The thing with partitions and the Android community is that almost no one discusses it. If you do a google on partitions on Android; very Little information / threads exist.
Click to expand...
Click to collapse
lol about the quote
besides the name playing on samsung's PIT files, REPIT can actually work on any device with TWRP support. but the partition layout in most newer devices is friendly enough not to bother. even the stock i9300 layout is sort of friendly. highly problematic are only the devices that shipped before ICS with android 2.x (galaxy S2) or devices that shipped with non-emulated internal sdcard.
discussion is low volume because partitioning is considered 'dangerous'. and it can be, you can brick if you mess up. the idea of REPIT was to make it safe by encapsulating a bit of knowledge of each device in the device port file. motivation was that S2 users suddenly all needed to repit: their devices stopped working after a nightly flash because of /system being too small, it was a mess, lol.
btw, since you asked before, that's the reason why porting is needed: because you can't trust users not to make mistakes with full freedom. users that want full freedom have other tools: gdisk, parted, mkfs.xxx, resize2fs, etc.

Lanchon said:
lol ab...
Click to expand...
Click to collapse
Yeah, I know that other devices doesn't even need to touch the partitions, as it is a waste of time. (so is this??)
edit: still, maybe I want a extra 1.5gb on my s6 Active or whatever.
edit: by for today, it's 00:00 here..
discussion is low volume because partitioning is considered 'dangerous'. and it can be, you can brick if you mess up. the idea of REPIT was to make it safe by encapsulating a bit of knowledge of each device in the device port file. motivation was that S2 users suddenly all needed to repit: their devices stopped working after a nightly flash because of /system being too small, it was a mess, lol.
Click to expand...
Click to collapse
Dangerous!? I've seen way more people fu** their IMEI number (including ME on MINE i9300) by doing something dumb to the /efs content (totally didn't try to unlock the phone), that's dangerous. (got 0049)
The phone was just lying round until I got around to fix it, not going to get into details as XDA doesn't allow this stuff. It was really fustrating as people said that reflashing stock would get back the IMEI (should apparantly work, etc etc).
yet again side tracked, but i'm the operator right? :good: :highfive:

@Lanchon
Since we are talking abt partitions, I would like to ask a question that's not related to this tool but the other way mentioned in first post by flashing a zip file with manually entering the size in script file.
I tried that a while back on my s3 and it worked great. I was on kitkat that time and it was fine till lollipop came. So I flashed lollipop but since the system size was only about 500mb, it failed to flash so I made another zip with system size to 800mb and flashed it again. Although everything went fine but after flashing a new rom or restoring my old backup phone always showed some encryption error and asked to factory reset and even after doing that, still showed the same error even though I never encrypted anything. So the only option was to flash stock with pit file and change the partitions to stock size and then restore or flash a new rom.
I was never able to partition my phone after that coz that error always came back. I have op2 now so all molding goes on it and s3 is like a backup phone but I am still interested to know what was that all about and what could I do to fix that or whether my emmc worn out?
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery

Hawaii_Beach said:
Dangerous!? I've seen way more people fu** their IMEI number (including ME on MINE i9300) by doing something dumb to the /efs content (totally didn't try to unlock the phone), that's dangerous. (got 0049)
The phone was just lying round until I got around to fix it, not going to get into details as XDA doesn't allow this stuff. It was really fustrating as people said that reflashing stock would get back the IMEI (should apparantly work, etc etc).
yet again side tracked, but i'm the operator right? :good: :highfive:
Click to expand...
Click to collapse
well... effing the bootloader i way worse than borking /efs, believe me.
now, trying to hack /efs WITHOUT A BACKUP (!!) is big jesus f*cking christ sh*t u talking lol!!!

Lanchon said:
well... effing the bootloader i way worse than borking /efs, believe me.
now, trying to hack /efs WITHOUT A BACKUP (!!) is big jesus f*cking christ sh*t u talking lol!!!
Click to expand...
Click to collapse
Hahahaha yep. Didn't know the risk dude.

nicesoni_ash said:
@Lanchon
Since we are talking abt partitions, I would like to ask a question that's not related to this tool but the other way mentioned in first post by flashing a zip file with manually entering the size in script file.
I tried that a while back on my s3 and it worked great. I was on kitkat that time and it was fine till lollipop came. So I flashed lollipop but since the system size was only about 500mb, it failed to flash so I made another zip with system size to 800mb and flashed it again. Although everything went fine but after flashing a new rom or restoring my old backup phone always showed some encryption error and asked to factory reset and even after doing that, still showed the same error even though I never encrypted anything. So the only option was to flash stock with pit file and change the partitions to stock size and then restore or flash a new rom.
I was never able to partition my phone after that coz that error always came back. I have op2 now so all molding goes on it and s3 is like a backup phone but I am still interested to know what was that all about and what could I do to fix that or whether my emmc worn out?
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery
Click to expand...
Click to collapse
well i cannot answer about scripts and procedures unknown to me but...
an encrypted disk typically is made of 2 things:
-the encrypted disk 'surface' or area (ie: the data)
-and metadata (data describing the data, ie: data describing the encrypted disk)
metadata typically contains:
-cipher info
-and the disk surface encryption key (generated at random), itself encrypted with the access key (such as a passphrase).
why the indirect key? without it:
-changing the passphrase (say, your phone lock pattern) would be a very dangerous operation that would require reading, reencrypting and writing the complete disk, would take a huge amount of time and would drain your battery completely
-erasing the disk would similarly take a long time.
with it:
-when changing the passphrase you just need to reencrypt the surface key with the new passphrase and rewrite the metadata.
-when erasing, just wipe the metadata.
for example the metadata in recent android phones with hardware backing store for keys probably contains:
-cipher info
-and the disk surface encryption key (generated at random), itself encrypted with a secondary key (also random).
the secondary key lives in the hardware keystore. it's generated there and can never leave that processor. the keystore will decrypt the surface key during boot, only if the main processor informs the right passphrase (say, the PIN or pattern). a 4-digit PIN would be very easy to bruteforce, except that the keystore throttles down guesses, and can even wipe the key (rendering the disk forever unreadable) after so many bad guesses.
the keystore should be tamper-proof: a silly small processor, but resistant to voltage spike attacks, rays, etc and decapping to read the storage, to pick up signals in traces, to inject signals in traces, to chip modifications, etc. think of it as the chip in any recent credit card or even some sim cards, but on the main circuit board.
anyway back to metadata in android: it needs to be stored somewhere. the obvious place is an ultra small metadata partition containing just the raw metadata, no file system or anything of the like. this is simple and works great, except for one detail: older phones don't have this partition. basically this means that an android upgrade couldn't give you encryption.
so android can use a "crypto footer": with this scheme the encryptable partition (say /data) has a file system that is 16KiByte short of filling the actual partition, and the 16KiB footer follows. the footer is the metadata.
when you repartitioned before, you probably created a file system that used the complete partition area. there was no space left for the footer, so encryption couldn't be enabled.
you could have solved your issue today by flashing repit with all-default parameters: repit always resizes the encryptable partition's file system to make room for the footer, if not already there.
in REPIT, these commits add general and ext4-particular support for crypto footers:
https://github.com/Lanchon/REPIT/commit/591961adb180a6a03594053a846b698240b4d507
https://github.com/Lanchon/REPIT/commit/de3d3af9813afef7de3a798ce5314c0fb210e30f
https://github.com/Lanchon/REPIT/commit/5c3360b572ff25c7c01d796cabb9400066451ec3
this configures the footer on the i9300:
https://github.com/Lanchon/REPIT/blob/f46b0aafdfeb7860be17a315b4aceb43966325f9/device/i9300.sh#L85

Info about loop support 7.0+ EMUI [magisk, supersu etc]

Since many people seem to ask continuously if magisk work with nougat and why supersu sr3 flashable zip by chainfire doesn't work ill try to explain it here.
Since M huawei has updated the kernel to work with nougat they seemed to break some important stuff. Or disabled it. I cannot tell for sure. And since sources aren't out we can't tell for sure if it's disabled or just broken.
Supersu and magisk is relying on loop to get it system less. This requires a .img which is being mounted to the path which is being executed on boot. But with loop being broken or disabled the phone will for some reason not handle this well.
But this is the reason why supersu and magisk isn't working when trying to install it reboots twrp notice that even if you manually patch boot so it contains all info related to magisk or supersu images it won't help you. Because you'll not be able to use magisk since the system will not boot. Due to loop is broken or disabled.
So there will be no magisk for nougat? And when will it come if it'll be working?
Wait until kernel sources are dropped.
So can we get magisk working?
Well yes.
Our best shot is to actually create a folder in /data which is being symlinked to / or if we do a similar approach on how supersu works on nougat. But for now we can't mount images and that's why everything fails.
Hope this sum up things for you.
Sent from my CUBOT_MANITO using Tapatalk

You're far more competent with Android development than me -- is it possible to fork Magisk and modify it to use a ramdisk instead of loop mounting? The Honor 8 has plenty of free RAM, we would probably do a 256MB ramdisk with no issue. Ramdisks don't require loop mounting so conceptually we should just be able to modify the mount / unmount, flash, and image update sections of the script.

Telperion said:
You're far more competent with Android development than me -- is it possible to fork Magisk and modify it to use a ramdisk instead of loop mounting? The Honor 8 has plenty of free RAM, we would probably do a 256MB ramdisk with no issue. Ramdisks don't require loop mounting so conceptually we should just be able to modify the mount / unmount, flash, and image update sections of the script.
Click to expand...
Click to collapse
Hmm maybe. As said we could do a similar approach on how supersu and phh works on nougat. The only downside would be placing all in ramdisk due to lack of storage space. Since it'll be filled too fast.
It could work in theory but not sure if it'll actually work properly
Sent from my CUBOT_MANITO using Tapatalk

LastStandingDroid said:
Hmm maybe. As said we could do a similar approach on how supersu and phh works on nougat. The only downside would be placing all in ramdisk due to lack of storage space. Since it'll be filled too fast.
It could work in theory but not sure if it'll actually work properly
Sent from my CUBOT_MANITO using Tapatalk
Click to expand...
Click to collapse
Has anyone from XDA (or elsewhere) actually got a "contact" at Honor/Huawei that has ever done anything positive for them (in the engineering/development realm)?
It doesn't appear that Honor 8 nougat is supported at all to me, but some things that could easily done with their "private source" of the Nougat kernel would be of great use and would not cause them to look as if they were being generous with their code. (I don't know why they're such dorks about it, but they are).
For example: IF you have some "insider" at Honor, please ask them for the stock emui loadable module (via modprobe or lsmod) for mount.loop support. That would solve the problem as there's not some reason why we can't find a way to load it during startup. If you guys get that, then you probably won't care about them probably never releasing the kernel source. I have no expectations for this company. Nice phone, but they lied about their development support. Too bad, because Kirin 9xx's are becoming nicer and nicer and in some ways are nicer than the heavily supported SD's, which are supported to a much larger extent.
Oh hell. We have working TWRP, so in theory, (and if we get the magical module for loop mount) we could root edit from TWRP and add the modprobe {modname-loop.ko) to whatever is the equivalent of rc.local or one of the startups (rc1.d, etc).
Getting someone to fork, develop and test the magik (sp?) code for one case and one kernel seems like a lean chance.

hachamacha said:
Has anyone from XDA (or elsewhere) actually got a "contact" at Honor/Huawei that has ever done anything positive for them (in the engineering/development realm)?
It doesn't appear that Honor 8 nougat is supported at all to me, but some things that could easily done with their "private source" of the Nougat kernel would be of great use and would not cause them to look as if they were being generous with their code. (I don't know why they're such dorks about it, but they are).
For example: IF you have some "insider" at Honor, please ask them for the stock emui loadable module (via modprobe or lsmod) for mount.loop support. That would solve the problem as there's not some reason why we can't find a way to load it during startup. If you guys get that, then you probably won't care about them probably never releasing the kernel source. I have no expectations for this company. Nice phone, but they lied about their development support. Too bad, because Kirin 9xx's are becoming nicer and nicer and in some ways are nicer than the heavily supported SD's, which are supported to a much larger extent.
Oh hell. We have working TWRP, so in theory, (and if we get the magical module for loop mount) we could root edit from TWRP and add the modprobe {modname-loop.ko) to whatever is the equivalent of rc.local or one of the startups (rc1.d, etc).
Getting someone to fork, develop and test the magik (sp?) code for one case and one kernel seems like a lean chance.
Click to expand...
Click to collapse
Many people probably have but won't try get people fired because of leaks
Their working on to get in touch though
Sent from my CUBOT_MANITO using Tapatalk

Perhaps @MishaalRahman can push on behalf of all of us as a representative of XDA to get the kernel source released faster, and built correctly for once.

Telperion said:
Perhaps @MishaalRahman can push on behalf of all of us as a representative of XDA to get the kernel source released faster, and built correctly for once.
Click to expand...
Click to collapse
I'm not sure how much clout I would have, but it wouldn't hurt to ask.

I think @svetius is more into this.
You should ask him about it tbh
Afaik he's the on that handles this
Sent from my CUBOT_MANITO using Tapatalk

in my p9 lite emui 5.0 magisk is successfully installed !
it worked by flashing a modded boot.img created by @HassanMirza01 and by setting selinux to permissive
big thanks to @Paolo83 because he found this method

@simo255 lol

simo255 said:
in my p9 lite emui 5.0 magisk is successfully installed !
it worked by flashing a modded boot.img created by @HassanMirza01 and by setting selinux to permissive
big thanks to @Paolo83 because he found this method
Click to expand...
Click to collapse
please state more info about which image you use, whether you have stock firmware installed and which steps you took in twrp to install supersu and consecutively, magisk.