Alright, I'm not posting this in development as I feel it isn't really much other than ideas/tests/information.
Alright so lets begin with what I learned tonight from toying with my dads photon:
cat /proc/mtd shows absolutely nothing
cat /proc/* shows: http://dl.dropbox.com/u/15069134/cat_proc.txt *stops at /proc/mtd for some reason.
Perhaps we can work from here.
Is anyone able to do adb shell ls /dev/ and let me look through it and then go from there?
note:
Code:
I am doing this so I can backup Wimax from within the actual system so I can see how 4G is being broken when the bootloader is being unlocked. I just need to see if a backup and restore would fix it.
Let us know!
sent from Cybertron, mopho!
Dump of ls -aletr /dev attached
P Daddy said:
Dump of ls -aletr /dev attached
Click to expand...
Click to collapse
Alright, now I need you to cd to dev/block/
then do cat mmcblk*** <--- fill in with the last part of all mmcblk's so basically do this
echo MMCBlock1p3 > /sdcard/RSAlog.txt;cat mmcblk1p3 | grep RSA >> /sdcard/RSAlog.txt
echo mmcblock1p2 >> /sdcard/RSAlog.txt;cat mmcblk1p2 | grep RSA >> /sdcard/RSAlog.txt
echo mmcblock1p1 >> /sdcard/RSAlog.txt;cat mmcblk1p1 | grep RSA >> /sdcard/RSAlog.txt
echo mmcblock0p18 >> /sdcard/RSAlog.txt;cat mmcblk0p18 | grep RSA >> /sdcard/RSAlog.txt
those partitions dont exists, needs to be mmcblk0p*
secondly anyone willing to give their private RSA keys that will allow you to connetc to wimax to this gentleman, please do so via pm or other form of private communication. posting them publicly means a whole bunch of htc people that had their rsa keys corrupted can now get on 4g thanks to you
Im not wanting to have their rsa keys, im just wanting to be able to check which partion has begin RSA private key and so on. Its really all i need lol. So long as i can find it, i can finish this up so you all can backup wimax. Btw, hey shabby.
Sent by breaking the sound barrier
Indirect said:
Im not wanting to have their rsa keys, im just wanting to be able to check which partion has begin RSA private key and so on. Its really all i need lol. So long as i can find it, i can finish this up so you all can backup wimax. Btw, hey shabby.
Sent by breaking the sound barrier
Click to expand...
Click to collapse
That would make this phone a beast! I miss 4G! :sad:
Sent from my MB855 using xda premium
Indirect said:
Im not wanting to have their rsa keys, im just wanting to be able to check which partion has begin RSA private key and so on. Its really all i need lol. So long as i can find it, i can finish this up so you all can backup wimax. Btw, hey shabby.
Sent by breaking the sound barrier
Click to expand...
Click to collapse
you misunderstand. all im saying is dont post it publicly. to send it if they are willing to you, do it via a private method.
id hate to see someone who is trying to help out in any way they can with dev work lose access to 4g because a simple oversight on it all, ya know?
shabbypenguin said:
you misunderstand. all im saying is dont post it publicly. to send it if they are willing to you, do it via a private method.
id hate to see someone who is trying to help out in any way they can with dev work lose access to 4g because a simple oversight on it all, ya know?
Click to expand...
Click to collapse
Ah, my apologies I did misunderstand. Sorry about that Shabby.
Related
Okay I posted this also in the Themes forum for Nexus but I wanted to see if anyone could assist. Someone in the theme forum asked about the bootanimation.zip that shows us the cool animation during boot, while reading this it reminded me of the behold 2. See below
What are the permissions for bootanimation.zip if they were left open to non root then this may-b a way to get root with unlocking the bootloader. This would be the same approach that was used to root the behold 2 where the "try3" file was renamed to play_logo . play_logo then was used to root and after root was opened it would make play_logo_real play which was the boot animation. I may be wrong but couldnt this be a possibility. Thanks, any help is appreciated. Im wondering if Zinx could chime in...
How are you going to write to the bootanimation.zip without root? Further, do you intend to replace the recovery or update custom roms? I am just trying to figure out the purpose of root and flashing other customized images.
seraph1024 said:
How are you going to write to the bootanimation.zip without root? Further, do you intend to replace the recovery or update custom roms? I am just trying to figure out the purpose of root and flashing other customized images.
Click to expand...
Click to collapse
You can always write if I am not mistaken using the low-level write dd if/of command. We would use the bootanimation.zip to run the root command. An example is in the Samsung Behold 2 it was done as follows:
Example
echo "#!/system/bin/sh
/data/local/try3 /system/bin/sh
mount -o rw,remount /dev/st9 /system
cat /system/bin/sh > /system/bin/su
chmod 04755 /system/bin/su
/system/bin/playlogo_real" > /system/bin/playlogo
Click to expand...
Click to collapse
This is how it was done. I am wondering if the same can be done on the nexus using bootanimation.zip as it executed at startup. We would basically modify the bootanimation.zip to the above and add a line for it to execute the boot image. By gaining root this way we would still be able to put on a custom recovery and roms without unlocking the bootloader in theroy. The try3 file was created by Zinx and used by Maxisma to bring root to the behold 2. I am pretty sure this may work on the Nexus 1. I hope this helps.
Ok. I don't have a locked phone that I can play with at the moment. I'll make up a package for you tomorrow. Can you test it for me?
seraph1024 said:
Ok. I don't have a locked phone that I can play with at the moment. I'll make up a package for you tomorrow. Can you test it for me?
Click to expand...
Click to collapse
Okay XDA is back up. Yes I can test. Oh man if this works there will be absolutely no need to unlock the boot loader... Thanks
seraph1024 said:
Ok. I don't have a locked phone that I can play with at the moment. I'll make up a package for you tomorrow. Can you test it for me?
Click to expand...
Click to collapse
Hey Seraph1024 take a look at this. Its too big for XDA so I put it up on pastebin. http://pastebin.com/f62780d32 Its what is contained in the try3 file. Zinx used it in flashrec
No joy.
Code:
$ getprop | grep product.model
[ro.product.model]: [Nexus One]
$ pwd
/data/local
$ ls -al try3
-rwxrwxrwx 1 0 0 74512 Jan 25 13:26 try3
$ id
uid=2000(shell) gid=2000(shell)
$ ./try3 /system/bin/sh
[1] Killed ./try3 /system/bin/sh
$ id
uid=2000(shell) gid=2000(shell)
Exploit does not work.
I was that close to rooting today until i saw this now its made me double think again lol I've been waitin for a custom rom by cyanogen until i rooted, and since its pretty much almost here i was going to root. bah guess i'll wait until CM gets released!
flak0 said:
You can always write if I am not mistaken using the low-level write dd if/of command.
Click to expand...
Click to collapse
You can't on this phone. There are two ARM cores - one running the low-level stuff (bootloader, radio) and the other running Linux.
Without the engineering bootloader (or some exploit) we don't have access to the baseband ARM core, and therefore don't have access to its MMU, which is programmed to deny read/write access to protected areas of the flash - such as the bootloader and splash screens. Even with root, Linux can't access that stuff.
It's going to be really hard to find a kernel exploit for the N1 to get root. Most exploits involve mapping memory to the zero page and then triggering a null pointer de-reference bug in the kernel. But the N1's kernel won't allow such mappings.... I believe the minimum address for mmap on the N1 is around 64k. (It's in the kernel config.)
This is a tough nut to crack.
The behold root was done that way because there's no way to flash the partitons on it.
You still need root in the first place to write to that file. The droid guys have been looking a while for a new root exploit but didnt find one. The problem is that all known exploits have been closed in 2.1.
We need to wait for someone to find a new one that works. Then this would be a real posibility, and there' no need to hijack playlogo.
for what its worth, if you need a lab rat i do not have my phone rooted yet and i am willing to test some things if anyone needs...
i dont plan on rooting it until the ball really gets rolling with everything and until I am 100% satisified with the phones performance
kam187 said:
You still need root in the first place to write to that file.
Click to expand...
Click to collapse
That's what I though. And like it was posted earlier, I don't think there is a exploit since this phone is done differently. I am busy for the next couple of days but if anyone want to "try", I'll make up something but I really doubt any of the old stuff will work on this phone.
I read in the bootloader development thread that it'd reached a level where it could almost boot into a custom system image stored on the SD card. Some questions about that:
1. The creation of that image, is it similar to how it's done for use with the XDAndroid project? (The porting of Android to HTC WinMo devices)
2. Is there a way to avoid having to reflash the device after every attempt? It looks like the boot-scripts take control pretty early in the process so having a choice if you want to proceed would be awesome, especially since I can't figure out how to get hold of a bootlog.
Thanks
ddewbofh said:
1. The creation of that image, is it similar to how it's done for use with the XDAndroid project? (The porting of Android to HTC WinMo devices)
Click to expand...
Click to collapse
I have no clue how they do it for XDAndroid, but here's how I created mine:
dd if=/dev/zero of=rootfs.ext2 bs=1M count=512 (for 512Mb fixed size)
mkfs.ext2 rootfs.ext2 (press y to accept)
mount somewhere
copy your stuff into
umount
ddewbofh said:
2. Is there a way to avoid having to reflash the device after every attempt? It looks like the boot-scripts take control pretty early in the process so having a choice if you want to proceed would be awesome, especially since I can't figure out how to get hold of a bootlog.
Click to expand...
Click to collapse
You don't need to re/flash at all. Pressing any key during the bootup will cancel the script and get you back into old good SE's 1.6
zdzihu said:
You don't need to re/flash at all. Pressing any key during the bootup will cancel the script and get you back into old good SE's 1.6
Click to expand...
Click to collapse
I've tried hammering all the keys without any success, since it works for you maybe I'm doing it at the wrong time. Where in the boot process do you do it?
And thanks for the tip about the image, didn't want to risk messing something up since I had to reflash after every try.
ddewbofh said:
I've tried hammering all the keys without any success, since it works for you maybe I'm doing it at the wrong time. Where in the boot process do you do it?
Click to expand...
Click to collapse
Bash them for a while as soon as you see SE logo appearing
ddewbofh said:
And thanks for the tip about the image, didn't want to risk messing something up since I had to reflash after every try.
Click to expand...
Click to collapse
Make sure you either name your image rootfs.img (not .ext2) or edit the init in the ramdisk accordingly.
Cheers
Thanks, that should make things much, much easier.
zdzihu said:
I have no clue how they do it for XDAndroid, but here's how I created mine:
dd if=/dev/zero of=rootfs.ext2 bs=1M count=512 (for 512Mb fixed size)
mkfs.ext2 rootfs.ext2 (press y to accept)
mount somewhere
copy your stuff into
umount
You don't need to re/flash at all. Pressing any key during the bootup will cancel the script and get you back into old good SE's 1.6
Click to expand...
Click to collapse
is there different form flash?
I've figured out why my phone refuses to go back to normal after testing the chroot. It needs grep and the standard sh doesn't provide it nor is there a grep symlink/binary in /system/bin so I'll add those manually.
Anyways, if anyone has a script or something to do all this it would be very helpful. I'm not looking forward to going over tons of symlinks manually.
ddewbofh said:
I've figured out why my phone refuses to go back to normal after testing the chroot. It needs grep and the standard sh doesn't provide it nor is there a grep symlink/binary in /system/bin so I'll add those manually.
Anyways, if anyone has a script or something to do all this it would be very helpful. I'm not looking forward to going over tons of symlinks manually.
Click to expand...
Click to collapse
How about busybox --install -s /your_destination_dir ?
zdzihu said:
How about busybox --install -s /your_destination_dir ?
Click to expand...
Click to collapse
Awesome, thanks. My knowledge about busybox is limited at best so when I saw install listed as a busybox function I assumed it was the "normal" install command.
In the quest for finding a way to use custom kernels I'm playing around with the splboot module but I need to find a way to get hold of dmesg or kmsg from failed attempts. Is there a reliable way to get any of these logs?
I've tried adding a line in the mount_iso script which cats kmsg to a file right before executing the splboot but I'm seeing nothing that would indicate that I'm running anything but the stock kernel.
Any ideas?
Hi,
I just realised that I'm going to post this, hopefully to get some help getting the frame buffer issue working. I'm not giving up on it, but it just doesnt seem fair to sit on this any longer since it works, besides the GUI glitches.
As i said before, the S7 kernel does not support framebuffering, which makes the GUI in the recovery a bitt messy. When you move up / down in the menu, it switches between selecting an item on top and an item on the bottom (you'll see 4 menus in total, but the ones on each horizontal line is a mirror).
This means that it starts by using the lower one, and it uses the top one next, then it goes back to the lower one. Boot it up and you'll probably see what I mean. This shouldnt cause any problems with the recoverys operation anyhow.
If you want to enter adb in linux you will have to get a copy of usb_modeswitch and run the following line in order to get adb to recognize the device:
sudo usb_modeswitch -W -v 12d1 -p 1031 -V 12d1 -P 1035 -M "5553424370ab71890600000080010a1106000000000000000 0000000000000" -s 20
This will switch the huawei s7 usb device into adb mode.
Also i take no responsibilites of bricks or other problems caused by using this recovery. Its truly for learning usage only.
My credit list would be to long if I where to include all forums that I've visited to get more information about this device, but if you feel like you deserve credit, let me know and i'll add you, otherwise, thanks to all people posting information about android devices, i could never have done it without you.
Ofcourse i have to thank the creators of clockwork mod, and also the people who wrote the repack-image.pl and unpack-image.pl scripts
Thanks to my wife who put up with me sitting and messing around with this for almost a week, giving her not the attention that she deserved, and thanks to all users of the S7 tablet out there.
h***://rapidshare.com/files/438781673/recovery.img.zip (not allowed to post links yet)
The shortcut key for entering recovery is menu + send, if anyone wonders.
Hope you'll enjoy it as much as I did.
Works great. Ill research a bit to see if i can help
Sent from my Ideos S7 using XDA App
Sorry for qwestion, but... How can i put it into device? Via fastboot on cmd, or somehow other?
Sent from my Ideos S7 using XDA App
I hope we can get a 2.2 rom
sorry, but it working not fully...
its have errors to open nandroid-mobile.sh
and its cant format SDcart to partitions ext2 and ext3...
or maybe i doing something wrong
GvoZdik said:
sorry, but it working not fully...
its have errors to open nandroid-mobile.sh
and its cant format SDcart to partitions ext2 and ext3...
or maybe i doing something wrong
Click to expand...
Click to collapse
You're right, I noticed now that I the wrong ramdisk in the image that was released. I have several of them for which I use to debug the framebuffer stuff, and I forgot to use my own build.
I'll upload the correct one sometime this weekend.
Sorry.
Sent from my HTC Desire using Android Tablet Forum App
thanx, thats a great work anyway...
Sent from my S7 using XDA App
thanks perivarlura for your support!
perivarlura said:
You're right, I noticed now that I the wrong ramdisk in the image that was released. I have several of them for which I use to debug the framebuffer stuff, and I forgot to use my own build.
I'll upload the correct one sometime this weekend.
Sorry.
Sent from my HTC Desire using Android Tablet Forum App
Click to expand...
Click to collapse
The ui glitches even more now that the misc partition handled and the nandroid script is running. I guess i need to get this fixed before i release it, or it will just be a mess.
Someone, please, with a rooted device, execute the following...
Code:
adb shell su -c "mkdir /sdcard/output; dd if=/dev/block/platform/dw_mmc/by-name/BOOT of=/sdcard/output/boot.bin ; dd if=/dev/block/platform/dw_mmc/by-name/HIDDEN of=/sdcard/output/hidden.img ; dd if=/dev/block/platform/dw_mmc/by-name/PARAM of=/sdcard/output/param.bin ; dd if=/dev/block/platform/dw_mmc/by-name/RADIO of=/sdcard/output/modem.bin ; dd if=/dev/block/platform/dw_mmc/by-name/RECOVERY of=/sdcard/output/recovery.img ; dd if=/dev/block/platform/dw_mmc/by-name/SYSTEM of=/sdcard/output/system.img ; dd if=/dev/block/platform/dw_mmc/by-name/TOMBSTONES of=/sdcard/output/tombstones.img"
then do an adb pull /sdcard/output in a good folder. zip the files up and upload to hotfile.com or something.
I'm having big problems with even getting the device to boot because we don't have this. I'm mis-matching files from several different people/builds. I really need this set of files from a single working device.
IRC channel
I'm doing it now and im in the irc channel
Left you a PM in the IRC channel with a link to where to download it
Additional source left. That should help in the quest.
For those of us who don't know anything about development fill us in a bit Assuming this is bootloader work being done.
bose301s said:
For those of us who don't know anything about development fill us in a bit Assuming this is bootloader work being done.
Click to expand...
Click to collapse
Im pretty sure that he is just trying to make a working stock odin file
Sent from my SCH-I605 using Tapatalk 2
Hey guys... using IRC is great, but it impedes the flow of information. When you use the Forums or Google+, it's searchable by google and colaborative effort is possible.
here are the links I got on IRC.
http://dl.dropbox.com/u/88471315/Outler.rar
http://daxterfellowesservers.com/adamoutler/
Also, there is another one coming soon which is official, but this should be enough to get me up and running.
jellydroid13 said:
Im pretty sure that he is just trying to make a working stock odin file
Sent from my SCH-I605 using Tapatalk 2
Click to expand...
Click to collapse
That's exactly the goal. I need a stock firmware because my device is beyond booting and all currently available firmwares are improper for the device. So, my idea is to get some firmwares then create an Odin and a Heimdall package.
Hey Adam, what part of LA are you from?
UPDATE: You can enable CP Debug by just typing *#66336# and turn the option on.
If you don't know what this is, it might be a good idea to pass on this, as it won't really provide you any benefit.
Verizon disables CP debugging in the radio/service menu. I found a unique little proof-of-concept hack that I tested and was successful. So basically there's a file called cmdline in /proc which shows you the arguments ran at boot time. This file is from the kernel/ramdisk, and cannot be modified, as it's merely a symlink to the arguments in the kernel, and not a file itself. /proc is very dangerous for the uninformed/uneducated user, so continue at your own risk. I am not responsible for anything any of you do, ever.
Before you continue, understand this is a VERY dangerous process, and messing up can permanently destroy your device. I am not responsible for anything that happens to your device. It is your choice to utilize this information. Please follow my directions VERY carefully.
Step 1: Make a copy of your /proc/cmdline
It should look similar to this (note: do not use this example, it has been heavily modified to protect my private information and applies to my kernel/device specifically):
Code:
console=ttyS0,115200 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x3F cont_splash=1 ********************
[email protected] [email protected] sec_debug.reset_reason=0x1a2b3c00 lcd_attached=1 lcd_id=0x404024 androidboot.debug_level=0x4948 sec_debug.enable=1 sec_debug.enable_user=1 slub_debug=o msm_rtb.enable=1
[B]androidboot.cp_debug_level=0x55FF sec_debug.enable_cp_debug=0[/B] cordon=REMOVED connie=SM-N900V_VZW_USA_REMOVED
loglevel=8 samsung.hardware=SM-N900V samsung.board_rev=8 androidboot.emmc_checksum=3 androidboot.warranty_bit=0
androidboot.bootloader=N900VVRUBMJE androidboot.nvdata_backup=0 androidboot.boot_recovery=0 androidboot.batt_check_recovery=0
sec_debug.pm8941_rev=3 sec_debug.pm8841_rev=2 vmalloc=450m level=0x47494844 sec_pvs=0 batt_id_value=0
androidboot.check_recovery_condition=0x0 androidboot.emmc=true androidboot.serialno=REMOVED androidboot.baseband=msm
Step 2: Take a look at the bolded line in the previous step. If we want to enable CP debugging, we'll need to change those values. Change androidboot.cp_debug_level=0x5500 instead of 0x55FF and obviously change sec_debug.enable_cp_debug=1 instead of 0. Save this copy to /sdcard or wherever you will remember it. Remember to save it without an extension so it's not a text document.
Step 3. Since cmdline is read at boot, how would changing this work? Well it appears that it reads some of these debugging values during runtime, instead of just at boot. We can't edit or modify /proc/cmdline, but we can bind it to another file so it reads our custom cmdline instead of the one from our kernel. Find your modified cmdline copy (i.e, /sdcard/cmdline) and take note of its location. Next, open adb shell or terminal emulator and type the following:
Code:
mount -r -o bind /sdcard/cmdline /proc/cmdline
Now check your logcat I use a nifty free app called aLogcat which can be found in the Play Store. You will need to run this command every time you boot/reboot, or you can write a script to do so at startup. You can also verify success by using the following command: cat /proc/cmdline and that should result in your modified cmdline appearing.
Keep in mind this log can contain sensitive information such as incoming text messages or google messages, which may leave you vulnerable. Surge1223 was also successful using this method on the Verizon S4 also. Again, PLEASE do not change any other values in CMDLINE as it will either not work since it takes those values at boot time, or it can render your device inoperable/bricked/unbootable.
I'm also currently exploring the possibility of enabling bands 26 and 41 (Sprint bands) on Verizon devices. Again, it won't really bring any benefit to most, but is more of a proof-of-concept type hack.
Thanks to surge1223 and bftb0 as always
This is very useful. Note this also enables you to grab the detailed logs from the sec_log location indicated in the cmdline, though this log is prob only useful to devs or enthusiasts.
Surge1223 said:
This is very useful. Note this also enables you to grab the detailed logs from the sec_log location indicated in the cmdline, though this log is prob only useful to devs or enthusiasts.
Click to expand...
Click to collapse
How would do you do that? viewmem?
Also, what's the difference between:
sec_log= and sec_dbg=
Have you tried it? Can you post an example output?
E:V:A said:
How would do you do that? viewmem?
Also, what's the difference between:
sec_log= and sec_dbg=
Have you tried it? Can you post an example output?
Click to expand...
Click to collapse
Second to last post here I posted a lot of a sec_log http://forum.xda-developers.com/showthread.php?t=2691420 (I didn't post all of it because sec_log is a minimum of 1 MB) and yep I used viewmem to extract it As for sec_dbg, it isn't human readable per se.
Sent from my SCH-I545 using XDA Premium 4 mobile app
Surge1223 said:
S As for sec_dbg, it isn't human readable per se.
Click to expand...
Click to collapse
Perfect! Probably the sec_dbg contain raw RF data or whatever is in the SHM buffer. Probably QXDM can read this, or try loading it in Wireshark...Um, no it probably need to be "translated/extracted" first.
Figured I'd update this post too, since I found the correct way to enable CP Debug Mode. Make sure HiddenMenu is enabled in /efs then dial *#66336# and turn CP Ramdump On (or MDM Ramdump if you're on an S4.)
ryanbg said:
...I'm also currently exploring the possibility of enabling bands 26 and 41 (Sprint bands) on Verizon devices.
Click to expand...
Click to collapse
Are you using a Sprint SIM?
If not, you'd probably need to look deeper, and perhaps reprogram part of SIM, enable correct PRL's and check for phone band support etc.
... Make sure HiddenMenu is enabled in /efs
Click to expand...
Click to collapse
What menu is that and how is that done?
I obviously don't have your device, but perhaps this is not Verizon specific...
E:V:A said:
Are you using a Sprint SIM?
If not, you'd probably need to look deeper, and perhaps reprogram part of SIM, enable correct PRL's and check for phone band support etc.
What menu is that and how is that done?
I obviously don't have your device, but perhaps this is not Verizon specific...
Click to expand...
Click to collapse
I believe the bands may be controlled by Qfuses, and some other parameters within the CP.
/efs/factoryapp/HiddenMenu -> ON
ryanbg said:
I believe the bands may be controlled by Qfuses, and some other parameters within the CP.
/efs/factoryapp/HiddenMenu -> ON
Click to expand...
Click to collapse
bands are not controlled by Qfuses. I've never heard of such a thing. Bands are controlled in NV items and/or in SIM card. If Qfuses are involved there must be a proxy app doing the fuse --> NV items translation. Or did you see something in the Qfuse register dump?
Deleted.
ryanbg said:
Deleted.
Click to expand...
Click to collapse
I be damned! Nice to be wrong sometimes. That's when you learn new stuff.
We'll then I just don't know how it works. I guess Verizon is such a big customer, they can do what they want. So the questions are, where is the physical location of those fuses? Where are they read and where is that information going?
E:V:A said:
I be damned! Nice to be wrong sometimes. That's when you learn new stuff.
We'll then I just don't know how it works. I guess Verizon is such a big customer, they can do what they want. So the questions are, where is the physical location of those fuses? Where are they read and where is that information going?
Click to expand...
Click to collapse
Their SoC package with integrated Baseband/CP is REALLY interesting. I think the CP = Hexagon, and the Hexagon DSP does all sorts of low-level non-radio business. The more I discover the more I'm intrigued.