• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root Porting ClockWorkMod to the Kyocera Rise

I really don't think they violated open source rules. But I could be wrong. In order for Google to be involved we have to prove what they violated.
 
So I got a custom kernel to flash and now idk whats going on
(^^^but i have an idea^^^)
This is the command line args needed to get it to boot:

'no_console_suspend=1 console=ttyDCC0 androidboot.hardware=qcom androidboot.emmc=true androidboot.serialno=d50ef161 androidboot.mtp=a0000027955778 androidboot.authorized_kernel=true androidboot.baseband=msm'

now serialno and mtp are device specific
androidboot.mtp is your esn hex under the battery
serial no i cant remember atm

Now I'm not really sure what's going on, because my /system is messed up so the kernel wasn't going to boot for me even if I did perfect the exploit. All I can get is adb (not because of this, i had done something earlier) and I see the Hydro by Kyocera bootsplash (been like this for two weeks but I'm not complaining as it's a bad esn/no service)

But basically since the phone didn't reboot on the sight of the kernel, I think it booted.

An easy way to get your boot cmd args is to look under dmesg and its in the 4th or 5th line



al
 
Question...

What file format did you create the kernel in?

You can get the kernel on the device?

What exactly happens? Does the phone automatically reboot or shutoff?
 
its a .img
i used dd to flash image
and the phone doesnt shut off, it hangs (which is a good sign because it means no rejection) but my /system is botched so even without this kernel flashed my device would hang
im controlling it through terminal via adb
 
I think the phone hangs because the system is not using enough ram to run the kernel. Its a property locked in the bootloader.

Did you add a line in the kernel specifying who has kernel rights?

Some kernels need the root user to be specified to run ram.

I believe for this device the line "root=/dev/block/ram0" needs to be added to your kernel if you have not done so already.

That line tells the system to all root access to ram0 which is the first ram command that runs, the quickest ram and the most amount of ram as well.

Hope this helps!
 
rbheromax said:
its a .img
i used dd to flash image
and the phone doesnt shut off, it hangs (which is a good sign because it means no rejection) but my /system is botched so even without this kernel flashed my device would hang
im controlling it through terminal via adb
Click to expand...

What kernel did you use? DTM?
 
I am also curios on what dev block did you use to copy it to?

Here is some food for thought...
The recovery block on the rise is mmcblk0p15.
The boot.img block is mmcblk0p8.
Now these blocks are located in the dev/block folder.

They are locked for editing by the bootloader.

Now how the system works is that it generally keeps a copy of vital system files in the cache. Since the cache is always changing it has no blocks on it and can be edited.

Since we can't flash directly to the device how about if we update the cache block?

According to other devices they flashed recovery to the cache block which is essentially a memory block. It has the ability to run extremly fast which should stop the phone from lose of power during boot.

The original stock file is about 4m but when lock info is added it becomes 8m. Now cwm is about 6m. When converted to recovery img with dd it turns to 8m.

With that in mind that means cwm fills up 2m of the recovery with its own info. Which pushes out 2m of original stock. This means about 2m of info is missing from recovery which triggers the reboot. Since the system recognizes the changed bits.

Now since cache is always changing, how about flashing it to the cache block? The problem is that if done wrong this will cause your phone to run slow because the cache r/w settings will be changed.

The cache will also allow the custom recovery to run at boot since it has a faster r/w setting than recovery.

Cache block is mmcblk0p13 in /dev/block on the rise.
 
it was stock kernel (3.0.8-perf), with command args set, and extra zeros at the end cut out.
u can flash to blocks while system is running, Ive been doing it since I got the phone. And cache isnt able to be bootable because there isn't an option for it in the bootloader.
also, i flashed the stock boot.img to recovery and my tests to boot partition so i could still boot normally if i hold recovery keys
 
Yes you can flash the system while its running. The kernel states it can be done. They allowed that feature in order for RnD.

In the kernel it references c5155 - c5170. Which leads me to believe those devices all have the same base kernel and harware.

I have also been flashing while the system is on. This feature is generally available with android devices for test and debugging once root is accomplished. This will allow you to return to stock if any problems occur.

Basically you just placed a file system on top of another one. It can be accomplished this way but the bootloader will still be locked.

I was able to set-up fastboot on linux. It runs with no problem when tested on another device. When tested on Rise it stays looking for the device until I close the window. This means there is a feature which is set-up in the phone to disable the fastboot keys.

To resolve the problem we would have to receive the fastboot files from kyocera or find the feature in the kernel. There are a lot of files to do reverse engineering.

I know the file system is set-up with 4 headers and 16 blocks. The first 3 headers verify informatiom and the 4 header is empty to hold information as it passes through it.

It looks like mmcblk0p2 has the bootflag enabled on it. Which makes me wonder what would happen if we disable the boot flag or change it to another block. The

MBR is mmcblk0. Which caused me to notice why we are able to flash on top of everything. The entire system is actually double the system. For example if you dig a little deeper you will see the sytem has enough space for 2 of everything. This means if we unlock the bootloader we could potentially double the power with the right development.

Not sure about you but the bootloader seems, like the first goal. Just some food for thought.
 
TechDad378 said:
Not sure about you but the bootloader seems, like the first goal. Just some food for thought.
Click to expand...

Totally agree. I'm a bit of a newb at this ( plenty of experience with linux tho ) and I'm just posting some notes, in case it helps people out. Warning some info may be outdated or plain wrong :P

***
Notes on the Kyocera Rise boot...

The bootloader is based on the LittleKernel (lk) bootloader, also known as aboot (short for android boot)

According to this:
Azimuth Security: Exploiting Samsung Galaxy S4 Secure Boot
There may potentially be an exploit to unlock the bootloader.

There are multiple lk projects on the web. I'm not sure which one is the most up-to-date one.

Here is a list of them:

https://github.com/beidl/lk_umia/tree/master/platform/msm7x30
https://www.codeaurora.org/cgit/quic/le//kernel/lk/
https://github.com/hiikezoe/android_device_kyocera_isw12k/blob/master/BoardConfig.mk

Here is the one I'm currently examining:

git clone https://android.googlesource.com/kernel/lk
git pull origin qcom-dima-7x30-fixes

Some interesting url's I found on the web...
https://android.googlesource.com/kernel/lk/+/qcom-dima-8x74-fixes/project/msm7630_surf.mk
https://android.googlesource.com/kernel/lk/+/qcom-dima-7x30-fixes/target/msm7630_surf/rules.mk
https://github.com/jcsullins/moboot/blob/master/target/msm7630_surf/include/target/display.h

These files could potentially aid in finding a project that closely resembles our own bootloader. Having the source code can really speed up the reverse engineering of the bootloader

To build the bootloader, make sure you have a baremetal ARM compiler:
make msm7630_surf

You can download a compiler from here: https://launchpad.net/gcc-arm-embedded

I managed to compile the msm7630_surf project, but I'm not sure what the output is exactly. Abootimg doesn't recognize any of the files that are created. All the files have an ELF header, maybe if I manually edit the header to ANDROID...

***

That's all, hopefully it helps. If it's not helping you guys lemme know and I'll keep my posts to a minimum
 
You made some valid points. I have read some of the articles you posted before you posted them. It seems were are heading in the same direction.

Here is what I have to add...

The msm7x30_surf project was the original firmware. The phones with android 4.0.3 had that firmware which would show up on the device in the about settings as 1.000vm. The OTA update changed it to 1.004vm, android v4.0.4. The msm is now msm8x55.

Now they claim its the same but the patches put in caused the bootloader to lock. The bootloader is locked by kyocera in order to reduce damage phones. They locked the device by disabling the bootloader keys during boot.

If we are able to find the file which disables those keys we would be on the right path.

Once we find that we need to find the file which references how the system locks the device.

From there would should be able to change a few things.

One thing I just found out is that kyocera uses the trust boot file from linux. This is suppose to encrypt the boot.

Aboot won't work because it is device specific.
I think if we could find out how trust boot and aboot work. We could compare the files.

The reason the changes are not taking is because the system is 16 bit with encryption the system put random code in the bit with their signature/key.

That's like giving a stranger the key to your car so he could do what ever he wants. Since no one would give their keys to their car away don't expect kyocera to do it.

Now here is a little bit of info I found interesting...
Since the encryption in at the front and back of the block in order to keep the link goining on the blocks, we now it is 16 bits... how about we put a file that's 10 bits? This way there is room for the automatic signature?
Just some of my thoughts
 
Hey I just got a notification that there is an update for the phone. My current software version is 1.000 so I'm guessing this is 1.004. Does anyone wanna examine the update? If so, your gonna have to tell me where it is cause I can't find it :P

Also, in no one is interested in examining it, could I get some help finding the downloaded update XD
 
It could be in your cache partition... If you are rooted you can use root browser from the play store to get to it... and yes the update package would be marvelous if you could post a link to it :)
 
The version is 1.00? That's pretty interesting. Before you update can you check the android version?
If i am not mistaking it may say android version 4.0.3.
If i read things correctly i think that is the version they had bootloader unlocked.
Reason i say this is before i applied the update i installed CWM. But since it was not the correct version the system crashed. I applied the update and CWM did not work. It would be great if you can extract boot.img and recovery.img before applying update. This can be accomplished if you phone is rooted, you have terminal explorer and enter the following...
For boot.img
"dd if=mmcblk0p8 of=sdcard/boot.img"

For recovery
"dd if=mmcblk0p15 of=sdcard/recovery.img"

If you get those 2 with no problems try this as well...

"dd if=mmcblk0p2 of=sdcard/tboot.img"
the one above may not work but wont hurt trying.
 
This thread started before the update. So I don't think it matters. I'm still on 1.00/4.0.3 if you still want the boot and rec images. It also gets the update message. Next time I'll download it and see if I can find it.

FYI its:
dd if=/dev/block/mmcblk0p15 of=/sdcard/recovery.img
dd if=/dev/block/mmcblk0p8 of=/sdcard/boot.img

Here they are, Enjoy:)

Boot http://db.tt/uTuf7qM2

Recovery http://db.tt/XXAcvEvp

Ota files I could find in /cache/delta
http://db.tt/Ph3dJHUK
 
I have done a bit of looking around with this phone. I found that the bootloader is on mmcblk0p5. mmcblk0p6 and P7 are empty ~4mb partitions. IDK what's up here.

As for getting around the locked bootloader, I don't know if any of you are good at exploits, but i'm more interested in workarounds. From what I have found, we can either set up some sort of 2nt init, where the phone basically goes back to the state before the kernel starts running the init scripts (basically this will be good enough to get CM9 on here, other ICS based roms and maybe CM10+) or figure out how to compile a kexec modules (kexec is a kernel function, but by default doesn't support being built as a module)

Either way the easiest way to manage different roms is to use some sort of imaging setup, where our init would mount a image from the /data partition as /system. That way users would have a hard time accidentally formatting their system partition and ending up with a brick. OR making sure every rom released has the 2nt init or kexec script (which is a risk). Also some way of booting into a recovery environment would be nice to do. this could basically be done the same way as a recovery image is just a kernel image with everything needed to run the recovery binary in the ramdrive
 
Just dump the partition and open with a hex editor...that's how we know
Blk0p5 is the bootloader aka aboot
This loads the boot partition which is located at p8. Aboot checks the sig on p8 before loading it for use
 
rbheromax said:
Just dump the partition and open with a hex editor...that's how we know
Blk0p5 is the bootloader aka aboot
This loads the boot partition which is located at p8. Aboot checks the sig on p8 before loading it for use
Click to expand...

That is what I got from it. I am still looking into making a Kexec module (which basically reloads a new kernel and removes the old one from memory) for the phone (most kexec-mods are very specific to omap devices, as that's the main use for them) If I cannot compile a kexec module, i'm going to resort to some sort of 2ntinit system.

Either way roms will not be too traditional. For kexec, if we could find out a way to trick a recovery environment into thinking the kernel partition is actually a image on the system partition, we'd be golden. It would appear to the user as a traditional setup. Then there would be nothing tricky when compiling roms.

2nt init isn't going to give us any ability to load custom kernels. It does let us load different roms. By basically puting the android system back to starting init.rc scripts that were origanally in the ramdisk, we can change the rootfs on every boot with a script then start a 2nt init system. It's restricted to roms that are compatible with the kernel, via modules (using insmod) or just works without any changes (CM9 will probably not have an issue with the stock kernel). As I said before, because recovery is just a fancy ramdrive, either method would allow us to make a recovery environment and we can give it fake mount points (for say images in /data) so they have no way of even removing the 2nt init/kexec script in recovery

Also, I made this device tree for building a recovery binary when it comes time. It seems to work although I did not try the binary I didn't end up with any compiling errors. (built TWRP with it using the CM9 source, also CWM on the builder site)

https://github.com/dtalley11/android_device_kyocera_C5155

and the mmcblk0p5 dump:
http://dev.dtalley11.com/dtalley11/mmcblk0p5.zip
 
Dtalley11: I spoke to interloper about this and he was saying that bootstrap would be the best route so u are we are all on the same page I see.
I tried making the kexec module from the source but apparently Kyocera gave us broken source. In config CONFIG_KEXEC needs to equal either y or m (can't remember atm) but I have been playing with it on my desktop and kexec is awesome. Purges old kernel from memory and loads new kernel and ramdisk (so we could also boot Roms from class 10 sdcards)
 
rbheromax said:
Dtalley11: I spoke to interloper about this and he was saying that bootstrap would be the best route so u are we are all on the same page I see.
I tried making the kexec module from the source but apparently Kyocera gave us broken source. In config CONFIG_KEXEC needs to equal either y or m (can't remember atm) but I have been playing with it on my desktop and kexec is awesome. Purges old kernel from memory and loads new kernel and ramdisk (so we could also boot Roms from class 10 sdcards)
Click to expand...

yeah, I have been poking at the source quite a bit. regardless of the wireless error i've been running into, I still end up with an warning that turns into an error when I try and compile kexec.

I get
[HIGH]arch/arm/kernel/machine_kexec.c: In function 'machine_kexec':
arch/arm/kernel/machine_kexec.c:124: warning: comparison between pointer and integer
error, forbidden warning: machine_kexec.c:124
make[1]: *** [arch/arm/kernel/machine_kexec.o] Error 1[/HIGH]
I got some people I know on IRC to take a look at it, and it stumped them as well.
The line is __virt_to_phys(cpu_reset)(reboot_code_buffer_phys);

If you don't mind, i'd love to work with you on this over IRC, as you obviously have had more experience with the phone than me. I'm on a lot of channels as dtalley11, but if you wanted to join #teamgelato, that is the channel I am most active on. Maybe we can get the ball rolling on this

Also, kexec=m doesn't work as the linux kernel doesn't know how to build it as a module (also, other than in the config, it can be found in the boot submenu of the menuconfig), by default it has to be built into the kernel. I have been doing some research on it, devs from the Droid 2 days were working on getting kexec to work as a module, but what they came up with was very specific to the omap devices (at least that's what I gathered from my brief workings with it) they called it kexec-mod. I wouldn't affiliate having a bad kernel source with never being able to compile a custom kernel for the device, there might always be a way to fix it.

But I am getting discouraged with this kexec, we might end up setting up something like bootstrap. Although it might be what we have to do, I dislike putting anything required to boot the phone on the sdcard, people don't often have class 10 sdcards and a I have lack of a lot of sdcards. Although, if I was to pick what goes on the sdcard, i'd make a image on it for the data partition. Or use Sd-EXT.
 
You guys through me for a loop with mmcblk0p5 being the bootloader.

The reason i say this is mmcblk0p2 is 512 mb. This 512mb is verified in the beginning and end of the blocks from what i found out about the rise.

I was under the impression mmcblk0p2 was the bootloader.

Which is why i was working on a solution similiar to the htc dumlock. The dumlock runs through the blocks and looks for a empty block.

If the bootloader is mmcblk0p5 that destroys my theory.
 
TechDad378 said:
You guys through me for a loop with mmcblk0p5 being the bootloader.

The reason i say this is mmcblk0p2 is 512 mb. This 512mb is verified in the beginning and end of the blocks from what i found out about the rise.

I was under the impression mmcblk0p2 was the bootloader.

Which is why i was working on a solution similiar to the htc dumlock. The dumlock runs through the blocks and looks for a empty block.

If the bootloader is mmcblk0p5 that destroys my theory.
Click to expand...

Block 2 is not 512mb, it is in KB. Partition 1 is the modem (you will find a AMSS.MBN in it). I have been working with Interloper (who recently got this kernel to compile for the device)

I have dumped every partition (other than system,data and cache) and put it all on a zip file: http://dev.dtalley11.com/dtalley11/images.zip for if anybody else wants to poke around the partitions a bit. info.txt is just an old thing I was trying to fill out what each partition did as I looked through it.

With a compiling kernel I may go back to poking around with kexec, but for now I have been working with 2nd-init, which just makes the phone hard hard reboot (not what I was looking for). This here is a script that basically does what 2nd-init does. I will try and find out which part actually kicks it into a reboot but if anybody wants to mess around with it, go right ahead. I really wanna make sure this is documented because it isn't the easiest thing to find, I had to talk to a few well known devs just to understand what is going on here with these work arounds.
 
I've been Rooted for almost 5 months now. Did alot of research and found out how:
Download:
"Poot Debug" from Google Play Store
also "Ministro 2"
,and "Superuser"
,and "busybox".

You can also get these from Filecrop.com (if you want to download to your pc) I sometimes connect my phone to the pc, and download DIRECTLY to my
sd card through my laptop.

Basically after you install the apps,
1st: you run Poot. (it will automatically tell you that it needs to download
the Qt libraries needed to continue. (the Qt libraries are the code written for your specific phone. This is what cracks the bootloader.

2nd: Ministro will begin downloading, so just WAIT.

3rd: back to Poot; click on poot command, then "Built in Rootcheck"
(to see if the Binary was written) Once it says "su binary is the first one
written; Anything else would be uncivilized", you can back out of
poot and go to Step 4.

Step 4: Open Superuser (You can download Superuser Elite from Filecrop)
and go into the PREFERENCES. Make sure the AUTOMATIC RESPONSE
is : "Allow".

Step 5: Open Busybox. It will want to know where you want it installed.
there are 2 small windows where you can browse for where to put
the installation.

Step 6: Press "Install" button (at the bottom of the screen).
Ads Pop-up and BLOCK the "Install" button, so you might need to
back out of the app, and open it, and Quickly press "Install".

It will tell you if you have "Superuser" access.

You are ROOTED on Kyocera Rise.



I also recommend you install FX file Explorer
and FX root update
(you can't get to your system files without the update; they are both FREE)
 
You must log in or register to reply here.
Back
Top Bottom