Is there an unlock for the SGS3 yet?
Does the Galaxy_S or the sgs2 unlock code finer work anyone know?
Well.. carriers haven't gotten the device yet so not sure. All the SGS3's that peeps have now come unlocked from Europe.
sent from my Galaxy S III
Coreym said:
Well.. carriers haven't gotten the device yet so not sure. All the SGS3's that peeps have now come unlocked from Europe.
sent from my Galaxy S III
Click to expand...
Click to collapse
+1
Mine was carrier unlocked when I received it (UK on contract with Three via Carphone Warehouse) doesn't even have a CPW CSC.
hmm...yeh...*#7465625# shows all locks off, although I was told when I bought it that it was locked...didn't have another microsim to check. Looks like my handset is like the others mentioned. Happy days...
Hi guys, well my sgs3 is locked and galaxy s unlock and sgs2 unlock respectively from helroz and chainfire dont work.
Im thinking about buying a code... unless someone have some kind of solution ?
Odia was able to unlock my SGS3 succesfully last week. He is still researching stuff using a friends phone this time so he will be releasing a guide on how to do it.
For the moment it has been reported from several users that flashing a custom kernel removes the lock.
Well I don't understand how can this be possible but you are free to try installing omega rom from the dev forum and see if that helps.
m33ts4k0z said:
Odia was able to unlock my SGS3 succesfully last week. He is still researching stuff using a friends phone this time so he will be releasing a guide on how to do it.
For the moment it has been reported from several users that flashing a custom kernel removes the lock.
Well I don't understand how can this be possible but you are free to try installing omega rom from the dev forum and see if that helps.
Click to expand...
Click to collapse
Thanks for the tip but, i've already installed the omega rom and network lock is still ON, and i think Odia did it by editing nv_data.bin.
The thing is, and i think that is why galaxy unlock of helroz doesnt work, is that the offset in the file that determine the network status are not in the same place.
And this is a problem since the app does the unlock by editing that file too.
That is just what i think , and i also dont see why flashing a kernel should remove the lock.
Coreym said:
Well.. carriers haven't gotten the device yet so not sure. All the SGS3's that peeps have now come unlocked from Europe.
sent from my Galaxy S III
Click to expand...
Click to collapse
woo.. galaxy s3 spreading fast.. and i am still with my S2.. hope Xda wont forgot to pull out S2 update..
dw4 said:
Im thinking about buying a code... unless someone have some kind of solution ?
Click to expand...
Click to collapse
For what is worth, I seem to have managed to unlock the phone, but it was not a matter of click & run an application (encrypted hashes)
http://forum.xda-developers.com/showpost.php?p=26917982&postcount=37
I haven't checked with another SIM, just checked network lock [ON] -> [OFF]. At some point while I was playing aroung and trying things I was asked to enter a code, but I didn't know about 0000000, which seems to have worked for some.
the method involved rooting the phone, installing an unbranded firmware and editing /efs/nv_data.bin. In my case, the (encrypted) hashes were stored exactly at the same offset, I don't understand why some people say they are not :?.
* backed up efs
* copied /efs/nv_data.bin to sdcard
* hex edited /efs/nv_data.bin - changed flag 0x01 for network lock to 0x00, copied the 32 byte long encrypted hash from the "off" locks (which were all the same) to the network lock hash, just in case.
* I also reset the MCC/MNC to FFFFFF
* Copied back the /sdcard/nv_data.bin to /efs
* removed the md5 hash (for some reason, the existing md5 did not match the existing file either), but it seems in my case was ok to remove it has been regenerated. Removed the old files
* chmodded /efs/nv_data.bin
* chown radio.radio the file
* rebooted-
It is much better documented elsewhere though - Proceed at your own risk!
---------- Post added at 09:48 AM ---------- Previous post was at 09:41 AM ----------
dw4 said:
And this is a problem since the app does the unlock by editing that file too.
Click to expand...
Click to collapse
As stated above, I managed to, but I did everything manually. At some point I got an unexpected "enter code" dialog that I dismissed (a issue that I solved by installing an unbranded firmware first).
- I found the encrypted hashes at the same location (NET 0x18146e).
- I did *NOT* find PERSO, but I also resetted the MCC/MNC
i also dont see why flashing a kernel should remove the lock.
Click to expand...
Click to collapse
agreed, I fail to see the relationship, but there are so many things I don't know...
Thanks iphdrunk, i'll try this.
Dont know if its a good idea tho since i've got no knowledge whatsoever of hex editing...
Thanks iphdrunk for the explanation! Do you by any chance have the time and mood to write a detailed guide on how to do this progress?
It would be ideal to start a new thread about unlocking and post the guide there. Then Odia may jump in too and help with anything.
Its 100% safe to mess with nv_data.bin because even if you screw up you can always restore a back up of that file and it will start working again.
m33ts4k0z said:
Thanks iphdrunk for the explanation! Do you by any chance have the time and mood to write a detailed guide on how to do this progress?
Click to expand...
Click to collapse
I appreciate the offer and consideration, but I would feel uncomfortable writing such a guide for several reasons: first, it would not be based on my research and findings (I just applied a quite well known method), it is heavily documented elsewhere and, finally, I may not be able to provide the deserved level of support
In any case, the skeleton of the method is here. Read those posts to get a clear overview of the process and then any other comment or disclaimer. Credits given to their respective authors
http://forum.xda-developers.com/showthread.php?t=1064978
http://forum.xda-developers.com/showthread.php?t=761045
What one needs to know is:
- you need a rooted device. Root can be otained either with the unsecure kernel method (cfr. intratech posts) or using recovery. The second one seems to be the most straighforward.
- It is nice to have busybox installed. It allows you to use cp, tar and other unix commands.
- it is mandatory to have a backup of the the /efs folder, which is the mount point of the /dev/block/mmcblk0p3, in ext4. In some guides it is advised to backup the partition at block level, using dd if=/dev/block/mmcblk0p3 of=/sdcard/mmcblk0p3.raw or something. Personally, I found that I could work with regular files. You can use adb shell or a "terminal application" typing su
- You need a backup, specially since this process can mess your IMEI and the nv_data.bin file (!). You may want to read about "Recovering IMEI" which is also related to the /efs folder.
- in that directory there is the famous nv_data.bin file, it is binary, and contains the hashes that are checked to validate unlock codes. There is a bin.md5 file (as a checksum to validate the file integrity) which, for proactical purposes, it will be recreated if missing and, finally, two (hidden) old backup copies. Unlocking is then reduced to either reverse engineering the hashes to find the code (a method which was doable when they where sha1 hashes of a 8 digit password salted with zeros) or, ignoring the hashes simply flip a bit that represents locked to unlocked.
- In recent samsung devices as well as in SGS3, the plain 20-byte long sha1 hashes are now padded and encrypted (I am not sure with which block cypher, aes?), giving you a raw 32 - byte stream that is also stored in the same place. Being able to locate the key to decrypt the encrypted hashes seems to involve patching modem.bin and / or ARM debugging, as per Odia posts.
- This means that, unlike in previous tutorials, reverse engineering the 20-byte hash using CUDA and similar approaches (ighash etc.) will not work: the program will iterate all 8-digit passwords and find that no hash matches the stored one.
- It has also been reported that a branded firmware may interfere with the unlocking process. In my case it did have some effect, although I solved it by installing an unbranded firmware.
- I concluded that, without accessing the key, the way to proceed was to reset the bit that signals that the phone is locked,
- This requires editing the file with an hex editor, looking for the pattern "Ox01, 0x00 etc" as explained above.
- I also copied the encrypted hashes of the "OFF" codes as the encrypted hash of the network lock hash. The reason for this is that the 3 were equal and could be the result of encrypting a very simple password (e.g. 0000000) with the same key.
- At offset 00180069-0018006e, there is a 5-byte stream and a "#" sign, with the carriers MCC / MNC For example 208 01 Orange France. Replace those with 0xFFFFFFFFFF
I am sorry I did not write a full guide, let me restate that the whole process is well documented and you should be able to apply the method if you understand it.
HTH
Well i made some progress, but still it seems that i cant push the edited nv_data file in place.
dw4 said:
Well i made some progress, but still it seems that i cant push the edited nv_data file in place.
Click to expand...
Click to collapse
You dont need to push it. Just copy it to place using root explorer or file explorer.
Sent from my GT-I9300 using XDA
iphdrunk said:
I appreciate the offer and consideration, but I would feel uncomfortable writing such a guide for several reasons: first, it would not be based on my research and findings (I just applied a quite well known method), it is heavily documented elsewhere and, finally, I may not be able to provide the deserved level of support
In any case, the skeleton of the method is here. Read those posts to get a clear overview of the process and then any other comment or disclaimer. Credits given to their respective authors
http://forum.xda-developers.com/showthread.php?t=1064978
http://forum.xda-developers.com/showthread.php?t=761045
What one needs to know is:
- you need a rooted device. Root can be otained either with the unsecure kernel method (cfr. intratech posts) or using recovery. The second one seems to be the most straighforward.
- It is nice to have busybox installed. It allows you to use cp, tar and other unix commands.
- it is mandatory to have a backup of the the /efs folder, which is the mount point of the /dev/block/mmcblk0p3, in ext4. In some guides it is advised to backup the partition at block level, using dd if=/dev/block/mmcblk0p3 of=/sdcard/mmcblk0p3.raw or something. Personally, I found that I could work with regular files. You can use adb shell or a "terminal application" typing su
- You need a backup, specially since this process can mess your IMEI and the nv_data.bin file (!). You may want to read about "Recovering IMEI" which is also related to the /efs folder.
- in that directory there is the famous nv_data.bin file, it is binary, and contains the hashes that are checked to validate unlock codes. There is a bin.md5 file (as a checksum to validate the file integrity) which, for proactical purposes, it will be recreated if missing and, finally, two (hidden) old backup copies. Unlocking is then reduced to either reverse engineering the hashes to find the code (a method which was doable when they where sha1 hashes of a 8 digit password salted with zeros) or, ignoring the hashes simply flip a bit that represents locked to unlocked.
- In recent samsung devices as well as in SGS3, the plain 20-byte long sha1 hashes are now padded and encrypted (I am not sure with which block cypher, aes?), giving you a raw 32 - byte stream that is also stored in the same place. Being able to locate the key to decrypt the encrypted hashes seems to involve patching modem.bin and / or ARM debugging, as per Odia posts.
- This means that, unlike in previous tutorials, reverse engineering the 20-byte hash using CUDA and similar approaches (ighash etc.) will not work: the program will iterate all 8-digit passwords and find that no hash matches the stored one.
- It has also been reported that a branded firmware may interfere with the unlocking process. In my case it did have some effect, although I solved it by installing an unbranded firmware.
- I concluded that, without accessing the key, the way to proceed was to reset the bit that signals that the phone is locked,
- This requires editing the file with an hex editor, looking for the pattern "Ox01, 0x00 etc" as explained above.
- I also copied the encrypted hashes of the "OFF" codes as the encrypted hash of the network lock hash. The reason for this is that the 3 were equal and could be the result of encrypting a very simple password (e.g. 0000000) with the same key.
- At offset 00180069-0018006e, there is a 5-byte stream and a "#" sign, with the carriers MCC / MNC For example 208 01 Orange France. Replace those with 0xFFFFFFFFFF
I am sorry I did not write a full guide, let me restate that the whole process is well documented and you should be able to apply the method if you understand it.
HTH
Click to expand...
Click to collapse
Thanks for the long post anyway . That explains how Odia was so fast
Sent from my GT-I9300 using XDA
I tried the above method, but it seems that the phone alters the nv_data.bin upon reboot.
When i push my edited nv_data.bin to the phone (having removed all backups and the md5 file), reboot the phone, and then pull it back to my computer, here is what I notice:
The network lock byte is back to 0x01, and the MCC/MNC code gets restored somehow. The file also gets altered in a bunch of places (7471 changes if I'm not mistaken).
Code:
cmp -l nv_data.PUSHED nv_data.PULLED | wc -l
7471
Is anyone willing to speculate on what's going on here ?
PS: I haven't flashed a new firmware, but it looks like it's unbranded: (XXLE8/ IMM76D.I9300XXALE8)
Guillaume2x said:
I tried the above method, but it seems that the phone alters the nv_data.bin upon reboot.
Click to expand...
Click to collapse
Just for completeness, set the permissions on the file and chown to radio.radio
Guillaume2x said:
I tried the above method, but it seems that the phone alters the nv_data.bin upon reboot.
When i push my edited nv_data.bin to the phone (having removed all backups and the md5 file), reboot the phone, and then pull it back to my computer, here is what I notice:
The network lock byte is back to 0x01, and the MCC/MNC code gets restored somehow. The file also gets altered in a bunch of places (7471 changes if I'm not mistaken).
Code:
cmp -l nv_data.PUSHED nv_data.PULLED | wc -l
7471
Is anyone willing to speculate on what's going on here ?
PS: I haven't flashed a new firmware, but it looks like it's unbranded: (XXLE8/ IMM76D.I9300XXALE8)
Click to expand...
Click to collapse
I have exactly same problem ... I have omege V4 ROM....
iphdrunk said:
Just for completeness, set the permissions on the file and chown to radio.radio
Click to expand...
Click to collapse
Thanks for your reply. I did, I chowned and chmoded the files right after uploading them, before rebooting the phone. I'm just going to try to flash my phone with another unbranded ROM, just in case my original ROM seems unbranded but actually isn't.
Guillaume2x said:
Thanks for your reply. I did, I chowned and chmoded the files right after uploading them, before rebooting the phone. I'm just going to try to flash my phone with another unbranded ROM, just in case my original ROM seems unbranded but actually isn't.
Click to expand...
Click to collapse
After several checks and discussions, it seems that most users have a problem in the sense that:
- If the md5 file is missing, the nv_data (locked) is restored, deleting the patched one.
- If old backups are deleted, same thing (plus the risk that one may end with the nv_data.bin file with a wrong imei)
- MD5 does not seem to be a simple md5 hash (e.g as in Linux) since the existing md5 bytes one and the result of running the md5 command do not match
- No one has tried the chattr +i nv_data.bin, just to check that the restoration fails.
In my case, I managed to unlock the phone, but I did several things that I cannot easily reproduce. In short, it seems that in my case, the md5 file was somehow regenerated after copying the patched file. In previous posts, I also mentioned that, during one of the tests (without touching the sim card) I was prompted to type the unlock code (and I clicked dismiss). This was also after installing an unbranded phone.
A user via PM suggested checking the nv.log. This is interesting
Code:
Sun Jan 1 00:01:03 2012: MD5 is turned on.
Sun Jan 1 00:01:03 2012: nv_data.bin does not exist.
Sun Jan 1 00:01:03 2012: default NV restored.
Sun Jan 1 00:01:11 2012: Network lock unlock input.
Sun Jan 1 00:01:11 2012: NV data back-up begin.
Sun Jan 1 00:01:11 2012: secondary NV built
Code:
Sun Jan 1 00:05:59 2012: MD5 is turned off on 0
Sun Jan 1 00:00:39 2012: MD5 is turned off on 2
Sun Jan 1 00:09:40 2012: enabling MD5 automatically because it was off temporarily.
Sun Jan 1 00:09:40 2012: NV data back-up begin.
Sun Jan 1 00:09:40 2012: secondary NV built
As suggested there seems to be a way by which md5 check is on or off.
A curious thing is that there seems to be a "date" backward
Code:
Thu May 24 04:12:38 2012: NV data back-uped.
Sun Jan 1 00:00:06 2012: NV data back-up begin.
May to January? -- clock reset?
And finally followed by
Code:
Sun Jan 1 00:02:57 2012: NV data back-uped.
Sun Jun 3 11:46:05 2012: MD5 is turned on
June 3... For some reason, in my case the check was off?
- Can we turn on and off md5 checking?
- If md5 check is off, the nv_data is backed up and the md5 is recreated?
- if md5 check is on, the nv_data md5 is checked and if fail, restored?
Any pointers welcome.... Check your /efs/nv.log file ?
Related
I had a look at
SPDREM_U_01.6.5.1-73_SPU-11-PASS-10_SIGNEuropeAustraliaEMEA_USASPDRRTGB_HWp2b_Service1FF_fastboot.xml
and being a Android noob I have a couple of question.
1.) Why is there a Windows executable, MotoCast-installer (~72MB) included, in the cdrom_signed file?
2.) Would it not be possible to add mods and root-kit into this firmware, e.g. system_signed, webtop_signed or any of the other xxxx_signed files, create a new MD5 checksum for the changed file to be added to SPDREM_U_01.6.5.1-73_SPU-11-PASS-10_SIGNEuropeAustraliaEMEA_USASPDRRTGB_HWp2b_Service1FF_fastboot.xml?
I have seen that those xxxxx_signed files have a signature and assume that the bootloader will check these.
As I said I am a Android noob, but have a little bit of experience with previous Motorola's phones, especially the Linux based Motomagx OS used on a few models. They worked roughly this way.
I am trying to get my head around how Android phones and OS are working.
Rasputin007 said:
2.) Would it not be possible to add mods and root-kit into this firmware, e.g. system_signed, webtop_signed or any of the other xxxx_signed files, create a new MD5 checksum for the changed file to be added to SPDREM_U_01.6.5.1-73_SPU-11-PASS-10_SIGNEuropeAustraliaEMEA_USASPDRRTGB_HWp2b_Service1FF_fastboot.xml?
Click to expand...
Click to collapse
As far as I know, those checksums are just to verify the integrity of the downloaded files, so that a bad connection or storage device can't brick your phone. I think the signatures themselves are stored in the individual partition images and verified the the bootloader at flashing-time.
The bootloader of the Motomagx phones had a RSA protection, which meant that signed codegroups could not be modified. Bizarre really as Linux based Motomagx was OpenSource and Motorola pointed the finger at the providers for that.
So I assume that a locked bootloader behaves the same way.
Once the RSA protection was cracked, we were able to modify the codegroups/firmware, even though we could leave out the signature, we still had to keep to the same byte size of most codegroups and had to keep one "security code", e.g. "00 01".
I guess this still applies now.
Sent from a mobile phone using Tapatalk
I live in Japan and after more than 6 months I have successfully and permanently rooted both my Sharp 003 SH Galapagos and the 005SH Galapagos (Softbank not Docomo). My next concern is how to SIM unlock. I have been reading the posts about hacking the nv_bin file. I have searched through all of the the files (Root FTP thank you!) but there was no such file. I am happy to send along any screenshots or data files if that helps.
Thanks in advance.
Search Sharp 003SH Root Success and Sharp 005SH Root success on Youtube for more info
Can't really help you. Don't know anything about it. But I would like to know how you ended up rooting this phone of ours.
Its not a file on the filesystem. The sim locking in these phones is in the radio image; which can be accessed when you use the custom build kernel thats in the latest rootkit (I assume thats what you are using).
See the 2ch root/ROM thread for more details, but basically it is done through ADB, manually backing up the "_modem" partition; stripping the spare/ECC bytes and then extracting the radio OS using QualcommDumpAnalyser
I have managed to extract this image, but no idea where to go from there. None of the other device info seems to apply to this (HTC, Samsung, LG, any other Android that has had its sim-lock discovered in the radio)
Advice i got from the guys on 2ch: "Qualcomm's NAND code is neither difficult, nor unique, so if you know what you are looking for its not hard"
003SH 005SH Sim unlock
Thanks very much for giving me a new direction. I'll get started on it right away and let you know how it progresses.
It just sucks that the guys who know how to unlock it are staying quiet, saying its "taboo"
FYI, stripping the Spare/ECC bytes can be done manually (i wrote a C program to do it), but there is an option in the RevSkills app to do it all for you - i recommend doing that.
Of course we face another issue once we find the actual unlock - recalculating the ECC bytes after making the change; the only way to access the radio is with raw data access.
P.S. hope you have warranty on your phones - this is very likely to brick at least one phone until we get it right
---------- Post added at 12:30 PM ---------- Previous post was at 12:24 PM ----------
In the spirit of open cooperation, here are the instructions i was given, translated and simplified
In ADB Shell, type su to get the # prompt, then:
cat /proc/mtd <Enter>
Confirm that you have the "_modem" partition available. If not, you need to reflash with the custom build kernel
Dump the image to file with the following command:
dump_image -r -D -F _modem /sdcard/backupimages/modem.img
Access this with anything as "raw dump" and all blocks will get read as ECC error, so definitely dont do this
ECC positioning is different to Linux, so take care
The following maps out how 512bytes of data and 10 bytes of ECC info are stored in a 528 byte block:
0000 - 01CF (0-463): Data
01D0 - 01D1 (464-465): Unused (0xff)
01D2 - 0201 (466-513): Data
0202 - 020B (514-523): ECC
020C - 020F (524-527): Unused (0xff)
Use RevSkills application to extract the data portions:
Menu⇒Calculators/Generators⇒Android MTD Nand remove Spare and ECC
Extract all of the Data only portions out of the raw dump, and then use QualcommDumpAnalyser to read it and split up the various parts. I did notice that i wasnt able to get the AMSS block out with QualcommDumpAnalyser - i copied that out manually by calculating the byte positions shown in QDA.
003SH bootloader key sequence?
Eternalardor,
I'd be happy to swap information. Perhaps you could shed some light on the question of the bootloader for the Sharp 003SH and 005SH? There seems to be no discernible key sequence (Power+home+Volume up etc.) to access the bootloader. I feel like I've tried them all. Can you tell me this critical piece of information?
Is a form of the USB Jig necessary to access it?
Looking forward to your response.
003SH SIM unlock
Dominik,
Here are the results of the original /proc/mtd (before rooting)
boot
cache
misc
recovery
ipl
system
persist
log
battlog
calllog
ldb
userdata
I don't see the _modem partition. Should I?
I have also included a screenshot of the results showing size. I have most of them backed up as .img files too.
FYI: .img backed up sizes. Perhaps this will help you to ponder where the _modem partition may have gone. Maybe it's been renamed?
boot 11,264KB
cache 3,072KB
misc 1,024KB
recovery 11,264KB
ipl 15,360KB
system 419,840KB
persist 30,720KB
ldb 45,056KB
userdata 405,120KB
There is no bootloader menu AFAIK. If you install the custom kernel, you will have the option of a quasi-recovery mode, by pressing the home button between 7-12 seconds after the Galapagos logo is seen (or was that the Softbank logo)
Anyway, looking at the screenshots, it seems you do not have the custom kernel.
How did you achieve root on your phone?
To do this, you need to use the "003sh_005sh_dm009sh-rootkit" from at least 5/27 (recommend _0614); which is available on the 2ch forums. This includes 2 possible ways of achieving root:
1. A modified standard kernel (boot image), which, when flashed gives you regular root access
2. A custom compiled kernel, which has full root, a bunch of power profiles, and heaps more features (inc that quasi recovery), as well as access to the "_modem" image.
Judging from your youtube videos, you speak some Japanese, so the Japanese menus in the rootkit shouldnt be much trouble.
http://www1.axfc.net/uploader/Si/so/142435
This is what i used.
Go here for help/instructions http://anago.2ch.net/test/read.cgi/android/1337845757/
And dont even think about typing in English on there, or you will be ignored and/or told to go away
This all looks familiar. I have been using the root kit (5/27) to get where I am now - step by blessed step. It was pretty straight forward BUT I have never seen the option to write to the system partition. It is in all the instructions but the only option I have with respect to the system partition is to back it up. I'm confused as to why it doesn't seem to show up for me. I am using a Japanese machine so all the characters are displayed and I can read the instructions but I can't find help anywhere as to why I don't have that particular (and critical) option. I can see a lot of new and cool options in the 6/14 release. I'm excited and would like to get it installed.
I'll let you know how it goes. Thanks for your help .... keep it coming!
And another thing
Could you explain a little more about "having" the custom kernel? Using the root kit, I wrote to the Recovery partition then the Boot partition then rebooted from the Recovery partition and all seemed well. As I said above, I have never been able to write to the System partition despite it appearing in all the instructions. I suspect that is what is holding me back from the latest and greatest custom kernel. Still, I am enjoying all the same functionality that everyone else seems to be enjoying in root. What am I missing?
Eep, you wrote to the boot partition before trying the recovery? Brave!
The steps should be:
Write image to recovery partition;
Then reboot to recovery partition (from the menu) and confirm it all works without errors.
Then write image to boot partition
And then turn off the phone, and reboot (the last part is only my instructions - you could just select "reboot to boot partition" from the menu)
You are doing this on your 005SH right? It should be the same for the 003SH, but i only have the 005SH. In the rootkit there is 2 options when you say "burn custom image":
1 カスタムビルドrootedカーネル（リカバリーキット機能付き）
2 S4080 標準rootedカーネル（簡易リカバリー機能付き）
Q 中止してメインメニューへ戻る
You must do the first one, the CUSTOM rooted kernel, to get any of the really cool features. The second option is only if you just want root access for a particular app or something. AFAIK the second option doesnt even disable MIYABI LSM, which prevents you from mounting the system dir as R/W
But either way, writing to the System dir is not important for what we are doing. You need the Custom kernel, which gives you access to the "_modem"
Edit, i just noticed in your screenshots above, you didnt even get root in ADB shell?
Type
ADB Shell<Enter>
Then type
su<enter>
The cursor should change to a #, this means root. You may get a prompt on the phone from Superuser asking you to give root access to "shell". Once you have this try the cat /proc/mtd again
jcroot003sh,
can you tell me how to root 003sh?
Use the link i provided in my previous post
http://forum.xda-developers.com/showpost.php?p=27989085&postcount=8
You can use a translator if you dont understand Japanese, but the general instructions are in the post above yours
I translated it for a friend, but that is at work, so wont be able to put it up until monday.
DominikB said:
Use the link i provided in my previous post
http://forum.xda-developers.com/showpost.php?p=27989085&postcount=8
You can use a translator if you dont understand Japanese, but the general instructions are in the post above yours
I translated it for a friend, but that is at work, so wont be able to put it up until monday.
Click to expand...
Click to collapse
Thank you for your replying. I will wait for your translated version. You are really a good person.
Progress
I have successfully found and dumped the "_modem" image. Exactly as you stated - forgot the "su" command in ADB. Thanks. The next problem is editing out the code. I am way above my head here so I will do some research before bugging you for a step-by-step for that.
Also, the bootloader worked. I didn't realize how to do it until I read the notes in the 6/14 release. I successfully put a previously dead phone back on it's feet EXACTLY to the point of my current phone simply by backing up and then restoring partitions through the bootloader. Very slick and easy.
Will get to work. I'll be in contact soon with my progress on the SIM unlock.
I have spent a bit of time looking at it, it certainly isnt easy (Certainly isnt a "lock=yes" section). I assume the actual locking portion is encrypted/compressed/or just compiled, because it would be too easy otherwise (be happy to be proven wrong). For starters, i cannot even find my IMEI number in the dump file... I think that this dump only includes the radio code, not the NV RAM which contains the IMEI and SIM Lock status. If that is the case then the solution should be to change the portion of the radio code that queries the NV RAM, so that it doesnt care if the SIM lock is supposed to be applied.
Extracting the spare/ECC bits out should be done with the RevSkills app; extracting the relevant portions, that is a bit of a cludge; QualcommDumpAnalyser can show the start/end positions, but doesnt extract the AMSS part (AFAIK thats where the code will be). You need to use a hex editor to cut that part out manually... And i am still not 100% sure what the block size is on this NAND.
Good luck!
And if there *are* any experienced hackers out there willing to help out, i can offer some monetary help (as will a few of my fellow Japanese smartphone owning friends) as this will be valuable for not just these 2 phones (there is an army of 007SH owners waiting on this unlock)
Shall we give the 007/009 a shot?
I can see mountains of the 007SH on the auction (mostly pink). Perhaps I should pick one up and take it for a spin. I am happy to try to do something to help out for all the help I am receiving.
Or perhaps the 009SH?
How hard would it be to crack the 007? The 009SH looks like it is supported in the latest release kit.
Thoughts?
Currently, the 003/005SH are going to be the easiest, because they have the custom kernel which allows access to the "_modem" image. To do it on the 007SH we need to build a custom kernel (compiled from the sources available on the ktai-dev site), and add the modem access code (this is in the src directory of the rootkit). Not impossible, but i dont have a Linux machine to compile the sources.
However i think that the code will be fairly universal. Once we find it on the 005SH we will know what we are looking for on the 007SH as well. That will make many people happy
Anyway, my 005SH is under warranty/anshin plan so i dont mind if it gets bricked (especially now that we can take nand backups).
First things first though - examining the 005SH modem image. Does anyone know whether the NAND is a 16kb or 128kb block size? Or is it something completely different?
P.S. The DM009SH is just the Disney Mobile version of the 003SH
Linux machine no problem
I have a Linux server running 24/7 so compiling the kernel is easy. Don't let that be the holdup. I'll keep working on the 003SH _modem image.
DominikB,
I can't open this site [anago.2ch.net/test/read.cgi/smartphone/1319287551/] on channel2 for free. This site had been moved to the past-log storehouse. So.... I even can't look at Japanese version for rooting 003sh. It is very helpful if you can show me the steps for rooting 003sh.
Hello,
I am starting this thread in the hopes of spurring some investigation into how to unlock the Samsung Galaxy Ace 2(X) without paying for an unlock code or for a service box such as Octoplus etc. All other methods for unlocking Samsung devices (dialer code, nv_data etc) do not work on this device.
I have made a little bit of progress on my own device, the GT-S7560m or Galaxy Ace 2X, outlined here. Unfortunately, I cannot provide a method to unlock as of yet, as the method I currently have found will replace the target device IMEI with the IMEI of the 'donor' device. I have not found a way to change the IMEI back (yet).
First, what I did was simple: Root the phone and backup all partitions other than /system, /data, /cache (/dev/block/mmcblk0pX) I did this a couple of times in between reboots and factory resets to have multiple backups as well as to see if any partitions change after reboots or resets.
It turns out that there are five partitions which change (slightly or drastically) after reboots/resets. These are:
mmcblk0p9
mmcblk0p10
mmcblk0p11
mmcblk0p13
mmcblk0p19 (/efs, found via mount command)
Since the S7560M does not have a GPT partition table, I can't find the labels for what these partitions actually are. 11,13 and 19 are mostly blank, while 9 and 10 are chock full.
Next, I bought an unlock service on eBay. Once unlocked, I took another image of all the partitions, and compared which ones were changed (locked vs unlocked). Unsurprisingly, the same five partitions were different.
To narrow it down, I the flashed back the locked versions of these partitions until my simlock returned.
mmcblk0p9 is the partition that holds the simlock data
I tested flashing only p9 and, indeed, simlock disappeared and reappeared according to the version being flashed. I have multiple devices to test with at the moment, so I took the unlocked p9 from Phone A and flashed it to Phone B, and sure enough, Phone B could then accept foreign SIM cards.
Unfortunately, this also changed Phone B's IMEI to that of Phone A
I tried various tools to attempt to zero out the IMEI (so that the partition image can be shared between devices and the end-user can then restore their proper IMEI) to no avail. It seems the NV items on this device are locked or read-only for some reason.
CDMA Workshop, NV Items Reader-Writer, QPST, QXDM, all these tools are able to read NV items fine, but when trying to write back NV item 550 ue_imei it inevitably fails. In QPST an unknown error (0x80004005) is thrown when writing, whereas in QXDM the program states "No DIAG response received" when attempting to write the NV item. I tried multiple phones, PCs and versions of Windows with the same error.
You'll recall that on other devices such as the GS3, QPST/QXDM/etc works perfectly fine to restore the IMEI through NV editing.
I believe mmcblk0p9 is the 'real' EFS partition, holding the NV items for the device. It also seems to be encrypted, since I cannot find the IMEI in hex nor decimal format inside it, yet the IMEI is changed when the partition is cross-flashed. Across phones and even simply rebooting, the partition almost completely changes, save for a header and a couple of other bytes.
In order to unlock the device freely, I believe the next step is to either decrypt mmcblk0p9, or find a way to get QPST/QXDM to write to the phone
If you have any thoughts/experience, feel free to post below! I am sort of stuck here.
This is a REALLY interesting thread. We need more of these! I know that to unlock my good old Galaxy Gio, you had to pull the bml5 partition and look at it with a hex editor to find 8 digits surrounded by nonsense symbols. Unlocking this device is gonna be MUCH harder, but maybe we just need to look at one of the 5 partitions you mentioned with a hex editor? I have no need of unlocking my device, nor have I ever actually tried it, but I'd like to get involved in this. Tell me, what happens when you insert a foreign sim card into your Ace II X (then you power it on or reboot it)? Does a dialog pop up asking for a code?
Dont bother with tools from market, they are made for units with samsung and qualcomm cpus. Ace2/S3 mini/S Advance/Xperia Sola/Xperia U and few others use NovaThor cpu from ST-Ericsson. So you should look in that direction. I have posted partition info here http://forum.xda-developers.com/showpost.php?p=42096782&postcount=22
You should also look those threads about partitions and some other info:
http://forum.xda-developers.com/showthread.php?t=2145464
http://forum.xda-developers.com/showthread.php?t=2352064
http://forum.xda-developers.com/showthread.php?t=2389395
http://forum.xda-developers.com/showthread.php?t=2132670
IIRC imei is most likely in cspsa partition, but encrypted. Search also for binaries in /system/lib/tee.
Some things i think may help further:
- gap betwwen partitions
- serial number is not encrypted, you can find it by searching the dump
If you want you can buy development board for NovaThor pretty cheap at http://shop.strato.com/epages/61428605.sf/en_GB/?ViewObjectID=11538 as this platform seems dead since ST-Ericsson split and so is with price of the board.
For i8160/p/l (and for all phones with novathor soc) the imei, serial and simlock data is on cspsa_fs that's 100%, but it's encrypted and I think there is a hash check or something similar because if you edit something (no matter what) in cspsa partition dump after reflashing the modem completely stops working - no signal, no imei.
Szaby59 said:
For i8160/p/l (and for all phones with novathor soc) the imei, serial and simlock data is on cspsa_fs that's 100%, but it's encrypted and I think there is a hash check or something similar because if you edit something (no matter what) in cspsa partition dump after reflashing the modem completely stops working - no signal, no imei.
Click to expand...
Click to collapse
angrybb said:
Dont bother with tools from market, they are made for units with samsung and qualcomm cpus. Ace2/S3 mini/S Advance/Xperia Sola/Xperia U and few others use NovaThor cpu from ST-Ericsson. So you should look in that direction. I have posted partition info here http://forum.xda-developers.com/showpost.php?p=42096782&postcount=22
You should also look those threads about partitions and some other info:
http://forum.xda-developers.com/showthread.php?t=2145464
http://forum.xda-developers.com/showthread.php?t=2352064
http://forum.xda-developers.com/showthread.php?t=2389395
http://forum.xda-developers.com/showthread.php?t=2132670
IIRC imei is most likely in cspsa partition, but encrypted. Search also for binaries in /system/lib/tee.
Some things i think may help further:
- gap betwwen partitions
- serial number is not encrypted, you can find it by searching the dump
If you want you can buy development board for NovaThor pretty cheap at http://shop.strato.com/epages/61428605.sf/en_GB/?ViewObjectID=11538 as this platform seems dead since ST-Ericsson split and so is with price of the board.
Click to expand...
Click to collapse
You guys are mistaken. The device being discussed is not the Ace II, but instead the Ace II X (same as S7560 Galaxy Trend or S7562 S Duos but with single sim). It does have a Snapdragon S1 clocked to 1 GHz (MSM7227A) with an Adreno 200 GPU. @op maybe you should modify the thread name to Ace II X instead of Ace 2 (X). It makes it less misleading.
angrybb said:
Dont bother with tools from market, they are made for units with samsung and qualcomm cpus. Ace2/S3 mini/S Advance/Xperia Sola/Xperia U and few others use NovaThor cpu from ST-Ericsson. So you should look in that direction. I have posted partition info here http://forum.xda-developers.com/showpost.php?p=42096782&postcount=22
You should also look those threads about partitions and some other info:
http://forum.xda-developers.com/showthread.php?t=2145464
http://forum.xda-developers.com/showthread.php?t=2352064
http://forum.xda-developers.com/showthread.php?t=2389395
http://forum.xda-developers.com/showthread.php?t=2132670
IIRC imei is most likely in cspsa partition, but encrypted. Search also for binaries in /system/lib/tee.
Some things i think may help further:
- gap betwwen partitions
- serial number is not encrypted, you can find it by searching the dump
If you want you can buy development board for NovaThor pretty cheap at http://shop.strato.com/epages/61428605.sf/en_GB/?ViewObjectID=11538 as this platform seems dead since ST-Ericsson split and so is with price of the board.
Click to expand...
Click to collapse
wrong thread dude..
---------- Post added at 08:59 PM ---------- Previous post was at 08:59 PM ----------
Codename13 said:
You guys are mistaken. The device being discussed is not the Ace II, but instead the Ace II X (same as S7560 Galaxy Trend or S7562 S Duos but with single sim). It does have a Snapdragon S1 clocked to 1 GHz (MSM7227A) with an Adreno 200 GPU. @op maybe you should modify the thread name to Ace II X instead of Ace 2 (X). It makes it less misleading.
Click to expand...
Click to collapse
they should read the entire thread first right?(first post) see how observent they are
Is this thread dead?
Codename13 said:
Is this thread dead?
Click to expand...
Click to collapse
I think so
---------- Post added at 09:21 PM ---------- Previous post was at 08:35 PM ----------
krazykipa said:
Hello,
I am starting this thread in the hopes of spurring some investigation into how to unlock the Samsung Galaxy Ace 2(X) without paying for an unlock code or for a service box such as Octoplus etc. All other methods for unlocking Samsung devices (dialer code, nv_data etc) do not work on this device.
I have made a little bit of progress on my own device, the GT-S7560m or Galaxy Ace 2X, outlined here. Unfortunately, I cannot provide a method to unlock as of yet, as the method I currently have found will replace the target device IMEI with the IMEI of the 'donor' device. I have not found a way to change the IMEI back (yet).
First, what I did was simple: Root the phone and backup all partitions other than /system, /data, /cache (/dev/block/mmcblk0pX) I did this a couple of times in between reboots and factory resets to have multiple backups as well as to see if any partitions change after reboots or resets.
It turns out that there are five partitions which change (slightly or drastically) after reboots/resets. These are:
mmcblk0p9
mmcblk0p10
mmcblk0p11
mmcblk0p13
mmcblk0p19 (/efs, found via mount command)
Since the S7560M does not have a GPT partition table, I can't find the labels for what these partitions actually are. 11,13 and 19 are mostly blank, while 9 and 10 are chock full.
Next, I bought an unlock service on eBay. Once unlocked, I took another image of all the partitions, and compared which ones were changed (locked vs unlocked). Unsurprisingly, the same five partitions were different.
To narrow it down, I the flashed back the locked versions of these partitions until my simlock returned.
mmcblk0p9 is the partition that holds the simlock data
I tested flashing only p9 and, indeed, simlock disappeared and reappeared according to the version being flashed. I have multiple devices to test with at the moment, so I took the unlocked p9 from Phone A and flashed it to Phone B, and sure enough, Phone B could then accept foreign SIM cards.
Unfortunately, this also changed Phone B's IMEI to that of Phone A
I tried various tools to attempt to zero out the IMEI (so that the partition image can be shared between devices and the end-user can then restore their proper IMEI) to no avail. It seems the NV items on this device are locked or read-only for some reason.
CDMA Workshop, NV Items Reader-Writer, QPST, QXDM, all these tools are able to read NV items fine, but when trying to write back NV item 550 ue_imei it inevitably fails. In QPST an unknown error (0x80004005) is thrown when writing, whereas in QXDM the program states "No DIAG response received" when attempting to write the NV item. I tried multiple phones, PCs and versions of Windows with the same error.
You'll recall that on other devices such as the GS3, QPST/QXDM/etc works perfectly fine to restore the IMEI through NV editing.
I believe mmcblk0p9 is the 'real' EFS partition, holding the NV items for the device. It also seems to be encrypted, since I cannot find the IMEI in hex nor decimal format inside it, yet the IMEI is changed when the partition is cross-flashed. Across phones and even simply rebooting, the partition almost completely changes, save for a header and a couple of other bytes.
In order to unlock the device freely, I believe the next step is to either decrypt mmcblk0p9, or find a way to get QPST/QXDM to write to the phone
If you have any thoughts/experience, feel free to post below! I am sort of stuck here.
Click to expand...
Click to collapse
Can you post a zip file op your efs folder?
Thanks in advance.
Hello all,
Unfortunately at this point I have sold all the Ace 2X units I had previously. I wasn't really getting anywhere anyway and ended up buying a Z3X box. Thread can be closed, or feel free to continue in my absence. Good luck!
I'd like if we, as developers working together, could get this done. Just a question: Is there an issue if we share the same IMEI? Why can't one of us pay to unlock our device, then share our mmcblk0p9 with others? Would it cause problems if others flashed our efs partition to their device?
Codename13 said:
I'd like if we, as developers working together, could get this done. Just a question: Is there an issue if we share the same IMEI? Why can't one of us pay to unlock our device, then share our mmcblk0p9 with others? Would it cause problems if others flashed our efs partition to their device?
Click to expand...
Click to collapse
1- multiple phones with the same IMEI on the same network cause problems for all other (the only reason this can normally happen is your phone losing signal or crashing then reconnecting, so it's reasonable for the phone company to drop all other active links when it connects again)
2- on the U8500 Sonys, the role of CSPSA, EFS and some other firmware partitions is done by the "TA" partition. We know parts of it are signed (with different keys, some specific to the individual hardware) and changing them results in hard bricks... not terribly related to this phone, but the moral is that without knowledge about this undocumented binary sequence that is partition 9 (probably requiring a JTAG backup and trial and error) we common mortals can't afford to experiment blindly
Hello,
An S7560M came through my hands again, and I've taken the time to capture the data that is sent to the proprietary Z3X server for generating the unlock codes. The tool bypasses the MSL, reads some data from the modem, sends it to the server for analysis, and sends back your unlock code(s). If anybody is good at cryptography or data analysis, feel free to analyze the Wireshark dump that contains all the data. Somehow, the unlock code shown in the screenshot is attainable with only that data.
I myself have no idea how to get from there to an unlock code on my own. The only modification I've made is removing the serial number of my Z3X equipment in the dump for security. The IMEI and SN do not appear to be transmitted in the dump, but I've removed them from the screenshot.
Hope this helps, good luck.
krazykipa said:
Hello,
An S7560M came through my hands again, and I've taken the time to capture the data that is sent to the proprietary Z3X server for generating the unlock codes. The tool bypasses the MSL, reads some data from the modem, sends it to the server for analysis, and sends back your unlock code(s). If anybody is good at cryptography or data analysis, feel free to analyze the Wireshark dump that contains all the data. Somehow, the unlock code shown in the screenshot is attainable with only that data.
I myself have no idea how to get from there to an unlock code on my own. The only modification I've made is removing the serial number of my Z3X equipment in the dump for security. The IMEI and SN do not appear to be transmitted in the dump, but I've removed them from the screenshot.
Hope this helps, good luck.
Click to expand...
Click to collapse
Not sure how to help, but this is some serious looking stuff! I downloaded your attachment, extracted S7560M.pcapng and I converted it to S7560M.pcap using this guide. I then tried opening it and Ubuntu searched for a program that could open it. I got Wireshark and was able to open it. I'm guessing that's no such sort of hacking, right? Anyways, I'd like to help out. In the image you uploaded in that 7z archive, what is the unlock code? I want to scour the data in the Wireshark dump and see if I can find any correlations between the data in the image and the data in the dump. All I have to guess at this time is that all the code is hex, and it probably translates to decimal.
In the screenshot the unlock code is the NET lock code. The other numbers and * # are dialer codes (for unlocking direct from dialer without inserting a foreign SIM) but the actual code is 30385735.
If i understand it right the sim-partition is 9?
Why whe can't just share that partition from someone who payed for unlocking his device and changing imei (there are some tuts on xda)?
imei
the unlock code is based on the imei..
somebody unlocked his phone based just on his imei and the name of his carrier over the internet..
Anas Karbila said:
If i understand it right the sim-partition is 9?
Why whe can't just share that partition from someone who payed for unlocking his device and changing imei (there are some tuts on xda)?
Click to expand...
Click to collapse
I'll say this again, Partition 9 is unique to each phone. Another way of seeing it is: two people own the same car, when one person is driving the car, the other person can't drive the car, vice versa. You can't duplicate that car, because each numberplate is specific to one car.
Likewise, you can't copy partition 9 to another phone, because it would be the same as using the same numberplate on two different cars. The partition 9 includes the IMEI, if you will, the "numberplate" of the phone.
Mod Edit
Changing imei numbers is illegal.
Any such discussion is not allowed on XDA
Thread closed
malybru
Forum Moderator
I'm looking for some help verifying a few bits of information before I take a leap and risk bricking my phone. I need to change my bluetooth address. With any luck back to my original hardware address. I do have the original address, as "btnvtool -p" outputs a different address than is reported in 'about phone' -> 'status'. I problem is that both my wife and I have the same phone with the same ROM history, and now we both have the same improper mac address.
By way of links provided by another helpful users I have partial information in Russian. http://4pda.ru/forum/index.php?showtopic=420801&st=6840#entry28414922 post 6853. I think I understand what to do via google translate and my partial understanding of how this works. The post points me to the /misc partition but I can't find any useful information about the partition for this phone that would backup the claims. Also the specific location that the post references, offset 4000, contains a string "ANDROID-BOOT!". While "ANDROI" is hex of 414E44524F49 which matches my incorrect mac address, the fact that it says "BOOT" makes me worry about changing it.
I'm hoping someone can help me any verify that this string isn't part of the boot process, or that the /misc partition isn't required to boot recovery. I feel fairly confident that I could create a flashable zip to restore a backup of this partition if needed. Below is my cleaned translation of the Russian post. If anyone with an e970 and a proper BT address could complete the first half, dd the partition to a file and check out the contents in a hex editor, I would feel much better about doing the rest.
Code:
Hello, using this method you can restore your original Bluetooth addresses. The active mac address is in raw MISC partition at hex offset 4000, it is not spelled out or anything.
perform the following (root is required)
ADB shell
su
dd if=/dev/block/platform/msm_sdcc.1/by-name/misc of=/sdcard/misc.img
and get at the file on the SD card and in a HEX editor zero the MAC address starting at hex offset 4000, save the file. Save the changed file to your phone:
su
dd if=/sdcard/misc.img of=/dev/block/platform/msm_sdcc.1/by-name/misc
reboot
After rebooting the details in the “About Phone” should show the real MAC BT.
----------
So I found a little corroborating evidence to this post. I found this post about the LS970(Sprint LGOG) stating that "All rooted LGOG Bluetooth MAC addresses are 41:4E:44:52:4F:49". Reading the thread a bit, I found a link to a "BT MAC FIX" script found with this kernel.
Looking at what the file does, it uses btnvtool to get the real mac and writes it to byte 16384 ( hex 4000 ) of the misc partition. Seeing as this file has people confirming it works, I took the leap. It worked. Problem solved.
Sound like to me this is a problem as old as unlocking with freegee. Could be wrong but that seems like the common denominator to me from the posts I was reading. And yes for the record, now the dump of the misc partition now reads "******D-BOOT!" *s to hide my real mac.
***Warning, 2015-01-12, This Fix as is doesn't work and causes problems with CM12 on the E970. Will post in thread with details.
I have the exact same issue with mine and my wife's phone. I tried this, and it seems like it should work, but after I reboot my phone, the contents of misc revert to the original (ANDROID...). Any thoughts?
mindstormsguy said:
I have the exact same issue with mine and my wife's phone. I tried this, and it seems like it should work, but after I reboot my phone, the contents of misc revert to the original (ANDROID...). Any thoughts?
Click to expand...
Click to collapse
I believe everyone that used freegee to root/unlock have the corrupted BTmac address. I also believe that it is only an issue when two of these devices try to use BT in close proximity, but you never know what device the person beside you will have.
I had not done anything about my BT until just now. The .zip just puts a script in the userinit.d folder. The script is run every boot. I do not recall what my BTmac address was, but the script does change it from the default.
I deleted the script and rebooted. My BTmac address reverted back to the default. I restored the script and my BTmac address changed back. This shows that the change is not permanent, and the script needs to be run every boot.
Did you flash the .zip, or just extract and run the script?
I've recently upgraded my E970 to CM12 nightly. Just like previous roms the BT Mac address is corrupted and results in my pairing being invalid. My mac address currently reports in "About Phone" as 00:00:00:00:5A:AD. Clearly this is incorrect.
When I tried to install this fix. The init.d script was placed properly, but did not repair the mac address as it did previously. This might be a one off case, but after the script was installed, my phone started acting funny, over heated, and completely drained the battery. The charger I regularly use, an iPad 2.1 amp failed to charge the phone. All it would do was turn on the red notification light solid. I was still able to use the computer usb ports to enter download mode, and start entering the off-charge mode. This port didn't give enough power to fully enter the off-charging mode. The phone made it to the first icon and then shut off, no progress was made.
I needed to switch to a lower output charger before I could gain charge to 5% and boot. As the OS booted it reported 0% charge. I was able to enter airplane mode and reboot. After the reboot the phone functioned well enough to use Solid Explorer to delete the script file from /data/local/userinit.d . After deleting the file my phone was back to functional with the bad mac address.
As I find info I will post it here.
2015-01-13 Update -----
Running the steps of the script file manually, results in a error "dd: stdout: Illegal seek" . Trying to read (if) instead of write (of), I get the same Illegal seek. Might this be part of a new protection with lollipop? I tried editing a dump of the partition as I suggested originally and writing the whole 16mb back. This completes without error, but when I read the partition again the modification was not saved.
Either way my BT Mac address with CM12 doesn't match the expected 41:4E:44:52:4F:49 to match the ANDROID from the file dump, so where is the OS picking up the new address?
Still works for CM11
I noticed my phone and my wifes also had the same bluetooth address. This was messing up my car link. I ran the script and now it shows that I have a different address. I will keep an eye out and make sure nothing else gets messed up. Thanks. I was looking for a fix for some time....
Hello! I’ve come, because in my quest to root my recent Galaxy S Devices, I’ve hit a big fork in the road and I don’t have the knowledge base to answer the last few questions I have. I feel like I should know the answers here, but for some reason I am lost to what to do next. I don’t quite understand how the newer root methods work these days, since working with the system & recovery images isn’t as easy with the newer Samsungs.
I got together with a developer, @droidvoider, where together we came up with this idea to get a root shell capable of at least remounting the filesystem R/W before reboot. He coded it on 6.0.1, and I talked a whole lot while I tested it on 5.1.1.
The Greyhat Root Console post#63
droidvoider said:
Major update!
1. I have debugged the tool heavily and it appears to me that I can replace any file on the system. Testing files you can't normally read is done via code so it's slow going, let me know if you find any blocks now.
2. If you have any file that gives an error but then replaces, that's because it tried other contexts.. PUT THIS ACTION AS THE LAST ENTRY, it might not be changing back to install_recovery from some contexts
3) the su install thing is designed to give an error I didn't even try to get root with this, literally focused on getting the tool done only.
4) next is a console of sorts, with exec dcow patching.. muahahaha
https://github.com/droidvoider/CVE-2016-5195_GreyhatRootProject_Root_Console
Click to expand...
Click to collapse
droidvoider said:
post#41you start an apk with am or monkey ... Let me know if I missed any other questions I'm excited about my find
I have awesome news.. As soon as I started playing with ls -la / using both contexts with root I seen that inside /cache/recovery/ is some log files. I am pressed for time hard, however
Code:
ls -la /cache/recovery/
Attached you can see the full output acquired from ls under both contexts
Click to expand...
Click to collapse
I'll start with the fact that I do not have Cellular Service. I no longer own a Note 5 N920A. But I do still own an S5 G900V, S6 Edge G925V, and a S7 Edge G935V. They serve as Wi-Fi Only Devices, and they are owned by myself. So slightly selfishly, I concern myself only with modifications that allow the device to boot, working network services are not a primary concern of mine. As they can more than likely be configured after boot by someone smarter than me.
I know that normally DM-Verity, KNOX, Encryption, U/G IDs, and SELinux, play a big role in allowing a user to execute processes as the root user. I am running 5.1.1 Android on my S6e & 7.0 on my S7e. I have an Engineering Kernel and boots normally with ADB Root Shell access. I have an Engineering Sboot, and allows me a non Root ADB Shell while booted normally in Stock Recovery. Right now the Eng Kernel I have, sets SELinux to Enforcing Mode. If I use the stock factory binary kernel, I lose root adb shell access but gain Permissive SELinux Mode. How do I inject root from here in a stable fashion?
akiraO1 said:
post#112
But I did want to post my findings so far on my selinux adventures thus far with my note 7....
So I was able to change the root context permanently from ubject_r:rootfs:s0 to u:r:shell:s0.
This by itself isn't all that helpful except that I actually changed it, and it stuck when I rebooted the device.
I achieved this through dirtycow-ing the file_contexts file with my customs file_contexts file and the commmands restorecon -RFv / and chcon -Rhv u:r:shell:s0 / restorecon makes selinux reload the file_contexts file immediately, so it loads all or most of my custom contexts. then I do a chcon command to make sure it writes?
well thats all I have for now but im working vigorously and will keep posting my findings as I find them =)
Click to expand...
Click to collapse
Using "DD" on Android 6.0.1 post#18
droidvoider said:
Tool is working!!!
Android 64 bit universal dirtycow dd image write works for both push/pull.. I am tired so please see github readme, the Makefile and push_files.txt, pull_files.txt examples. I am going to get root, this is the first step.
https://github.com/droidvoider/Android_6.01__DD_Dcow
Click to expand...
Click to collapse
Page 4 for File and GHR Console
Page 5 further discussion of Console
Page 6 GHR Console
I'm going to go into some detail here about the Firmware I've been flashing just so everyone knows without having to ask. I'm almost really hoping maybe we could all muster one more attempt at rooting this Note 5 variant.
I really feel like I really might have something here, especially with the updated binaries of "Farm Root", "CVE 2016-5195 (dirtycow)", and bootimgtools (mkbootimg & unpackbootimg). All compiled for arm64-v8a. Thanks to @droidvoider for helping to compile those. I'm not a linux Expert by any means, but I'm on a mission, and I do know a few things. With all of the Security Bulletins that have come out since November, there should be plenty of Attack Vectors for using the LL Eng Kernel or DirtyCow to gain enough Kernel Privileges to maybe even unlock the dang bootloader. Or maybe bypass the signature check for one boot. LL-based UCU1AOGG Recovery Mode does not use DM-Verity when exiting, and the Combination Firmware doesn't seem to use it at all So....
Q1.) Can someone please help me get at least a systemless root installed? WITHOUT using a custom recovery? It might need to actually be a system root though looking at the Galaxy S8.
This should be possible using the LL Engineering Kernel & Engineering Sboot for the Factory Binary. Especially since the August builds are fully exploitable by DirtyCow, and with an eng Kernel that is half the battle we were using dirtycow for in the first place. Now we should be able to use DirtyCow to finish the root injection. Because the Factory Binary does not utilize DM-Verity that is obvious. So using the Factory Combination Firmware, there may actually be a way to legit boot a custom recovery I feel, even if only for one boot, that is plenty enough if prepared when that oneshot boot happens. Once installed with the full Combination Bootloader (ODIN BL file) I can then flash any N920A LL ODIN AP File. All the way back to N920AUCU1AOGG. Warranty Bit Intact, Official Status, Normal Rebooting. In fact, after everything I've done thus far, I have still yet to trip my KNOX Warranty (Still 0x00).
**************
** MM 6.0.1 **
**************
Here are the contents of the tar.md5's:
Code:
tar -tvf AP_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 28746016 2016-08-10 00:31 boot.img
-rw-rw-r-- dpi/dpi 29413664 2016-08-10 00:32 recovery.img
-rw-rw-r-- dpi/dpi 4125403456 2016-08-10 00:33 system.img
-rw-r--r-- dpi/dpi 549536816 2016-08-10 00:33 userdata.img
tar -tvf BL_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 1634576 2016-08-10 00:31 sboot.bin
-rw-rw-r-- dpi/dpi 1095680 2016-08-10 00:28 param.bin
-rw-rw-r-- dpi/dpi 2113808 2016-08-10 00:28 cm.bin
tar -tvf CP_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 37269840 2016-08-10 00:28 modem.bin
tar -tvf CSC_ATT_N920AATT3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 3072 2016-08-10 00:32 NOBLELTE_USA_ATT.pit
-rw-r--r-- dpi/dpi 89608656 2016-08-10 00:34 cache.img
For this MM Stock Firmware, I've also come across this Modem for a Z3X Flash Box, that is used when direct unlocking this device. I do know, that when I have this CP installed, I do have access to the APN Editor, to Add/Modify/Delete APN's:
Code:
tar -tvf N920A_UCS3BPH4_CP_FOR_UNLOCK.tar
-rw-r--r-- 0/0 37269840 2016-08-10 00:28 modem.bin
******
**************
** LL 5.1.1 **
**************
I’ve happened upon the full ODIN flash-able SW Rev 3 Factory Binary for the AT&T Galaxy Note 5. It allowed me to do a full firmware downgrade from MM 6.0.1 to LL 5.1.1 without worrying about trying to downgrade my binary counter in download mode. It’s the only 5.1.1 build I’ve seen that isn’t a binary 2-(SW REV 2) & It contains these files:
Filename: COMBINATION_FA51_N920AUCU3APH1_CL6053901_QB10608083_REV00_user_mid_noship.tar.md5
Code:
tar -tvf COMBINATION_FA51_N920AUCU3APH1_CL6053901_QB10608083_REV00_user_mid_noship.tar.md5
-rw-rw-r-- dpi/dpi 1634576 2016-08-10 06:44 sboot.bin
-rw-rw-r-- dpi/dpi 1095680 2016-08-10 06:43 param.bin
-rw-rw-r-- dpi/dpi 2113808 2016-08-10 06:43 cm.bin
-rw-rw-r-- dpi/dpi 24660256 2016-08-10 06:44 boot.img
-rw-rw-r-- dpi/dpi 24754464 2016-08-10 06:44 recovery.img
-rw-r--r-- dpi/dpi 1537858544 2016-08-10 06:44 system.img
-rw-r--r-- dpi/dpi 4292768 2016-08-10 06:44 persdata.img
-rw-rw-r-- dpi/dpi 36163408 2016-08-10 06:43 modem.bin
-rw-rw-r-- dpi/dpi 3072 2016-08-10 06:44 NOBLELTE_USA_ATT.pit
Using ODIN v3.12.5, I flashed this firmware using the AP slot overtop of the Full 3BPH4, and after flashing the Factory Binary these are the build details that boot up with zero errors. Mind you, I have tried this with, and without, a sim card inserted. It is not lost on me either, that UCS3BPH4 (Stock) and UCU3APH1 (Factory) have the same build dates listed on them.
***
* Device := SM-N920A
* Android Version := 5.1.1
* Baseband Version := N920AUCU3APH1
* Kernel Version := 3.10.61 August 10th 2016
* Build Number := LMY47X.FA51_N920AUCU3APH1
* SELinux Status := Permissive
***
From @TechNyne66 I got the LL Eng Kernel from the 2APB2 build. I have yet to see any other UCE branded files.
Code:
tar -tvf N920AUCE2APB2.tar
-rwxr-xr-x 0/0 27326752 2016-02-11 01:42 boot.img
But flashing this kernel into the Factory Binary sets SELinux to Enforcing, which makes things a bit more difficult. And I don't know how to edit the Kernel in a way I can repack it for flashing. My attempts thus far have failed when trying to flash a repacked boot.img. Probably because I did not make the necessary build.prop tweaks, and because I didn't use the correct compression levels to repack. What I mentioned earlier about not understanding the filesystem all that well anymore, stems from not having a broad understanding of build/default.prop & the various .rc/init files.
This is also possibly due to Samsung using a customized header for the Kernel's Binary.
Q2.) Is there a way to update the UID/GID from 'dpi/dpi' to '0/0' without modifying the signature embedded into the tar.md5?
Q3.) Is there a way to extract the extra data from the end of the file?
Q4.) Can I examine the persdata.img directly, to see it's contents before flashing? I don't know how to view the img format and how to extract it.
My post is too long, so I'm moving to post #2
Since these are too long to fit in post 1, I was forced to double post. Here is the last bit about partition tables. The reports are long. Please, any solid advice would be helpful.
***************************
** PIT File Examinations **
***************************
Moving on, I have used "PIT Magic 1.3 Release", found here on XDA, to look at the partition tables of the .pit files included with the N920AUCS3BPH4 & N920AUCU3APH1 ODIN firmware packages. I have also included the PIT File examination from the unlocked European Firmware. Given that PIT Magic 1.3 is a few years old, the latest version I have is labeled 2012. I read about how difficult it was to get the format correctly back then, and I have no way of knowing if the PIT File format has changed since then. But it does still seem to give usable output. I just don't know how to use this output meaningfully yet.
If you could hack one of the apps that are included in the sepolicy and set the Androidmanifest.xml to include android:dubuggable="true" we can make a two stage app. read and replace as root with the cow and then reload your inits.
toolbox.c root trick:
I am working on a very very powerful tool now. I am taking farm-root toolbox.c and changing it to grab root + context but then fork a process into a loop and just keep those privs. Hopefully I can even control that loop from the command line still! Currently I can get root and system_server, install_recovery.. But today after work we find out if I can hold on to it in a loop.
recovery-from-boot.p
I researched this today because we can read/patch this file with dirtycow. This file replaces the stock recovery every time you boot if they are different. I don't know if it also uses the hardware signature verification process, if so that's a key that's hidden in the partition image (hopeless for us i bet)
So if we replace recovery we have to crush this file with dirtycow.c
This sounds very interesting, i have a damaged g935f with dm-verty faied and frp lock so there is no way to use this device unless i flash with no-verity firmware but cant as frp stops me flashing root, hopefully you can use this exploit with the factory combination firmware to replace the boot loader with twrp or other custom bootloader to fix this issue, there is lots of people with same the problem im sure
verg0 said:
This sounds very interesting, i have a damaged g935f with dm-verty faied and frp lock so there is no way to use this device unless i flash with no-verity firmware but cant as frp stops me flashing root, hopefully you can use this exploit with the factory combination firmware to replace the boot loader with twrp or other custom bootloader to fix this issue, there is lots of people with same the problem im sure
Click to expand...
Click to collapse
Can you get booted at all? If you can' t get booted I won't be gaining access to that phone until someone smart works out the encryption, no one has on the note 3 yet not even hashcode (that he ever released). While the bootloader is locked.... The sboot.bin = signed by hardware key. If that key is not present there is an undisclosed backup key embedded in the partition, one must be present and neither are known. Minus the presence of those keys, chain of trust fails.
S7 is worth saving if it can be saved tho
droidvoider said:
Can you get booted at all? If you can' t get booted I won't be gaining access to that phone until someone smart works out the encryption, no one has on the note 3 yet not even hashcode (that he ever released). While the bootloader is locked.... The sboot.bin = signed by hardware key. If that key is not present there is an undisclosed backup key embedded in the partition, one must be present and neither are known. Minus the presence of those keys, chain of trust fails.
S7 is worth saving if it can be saved tho
Click to expand...
Click to collapse
No bud, the phone wont boot a normal firmware as the certificate is screwed and imei 0000000000, but it will boot with combination firmware, all i need to do is gain root and disable 'frp lock' via z3x box or another method and car repair the phone... Im not fussed about the warranty being void to be honest... I have ADB but not root fix phone
My tool will likely be helpful to you because that sounds good enough as long as you can get to a prompt that is CVE-2016-5195 / SVE-2016-7504 vulnerable. Anyone who isn't patched beyond Sept 2016 on any Android in the last 10 years will be able to use the tool I'm building to do amazing things. I am designing it precisely for people like you and Delgoth who have large investments in phones that could simply be repaired with enough access.
I am thinking now to fork off a child process anytime I can capture root + "any_new_context"... This will be forked into a child process then kept in a loop. If there is a new root + context that happens along through toolbox, we will grab that also.. (but I won't grab two of the same for example root + system_server I just need once)
I am hoping I can control this loop from the command line but since I am not the caller of the process for which I am capturing I am not sure that would work. This is new code to me, not sure of any examples of something like this. If I have to control it through values I set in files it adds a little more time. The great news is I am not having binary size problems so I can add quite a bit of code while still keeping toolbox much less than the currently installed version on my Note 5. File size must match exactly otherwise patching causes seg fault and seg fault ruins the fun (reboot to cure but irritating)
anyway just needed to come up for air I have a ton done, need to get toolbox fired up to test angle.. any c programmers that want to help or anyone with awesome ideas please feel welcome I could use help
Ah cool the combination firmware i have is:
COMBINATION_FA60_G935FXXU1APB5_STEP1_OLDFW\COMBINATION_FA60_G935FXXU1APB5_CL7345605_QB8752841_REV00_user_mid_noship.tar
The kernel is 3.18.14-7345605 Thu 25th Feb 2016 so it should be exploitable I'd love to get my S7 Edge working again
droidvoider said:
My tool will likely be helpful to you because that sounds good enough as long as you can get to a prompt that is CVE-2016-5195 / SVE-2016-7504 vulnerable. Anyone who isn't patched beyond Sept 2016 on any Android in the last 10 years will be able to use the tool I'm building to do amazing things. I am designing it precisely for people like you and Delgoth who have large investments in phones that could simply be repaired with enough access.
I am thinking now to fork off a child process anytime I can capture root + "any_new_context"... This will be forked into a child process then kept in a loop. If there is a new root + context that happens along through toolbox, we will grab that also.. (but I won't grab two of the same for example root + system_server I just need once)
I am hoping I can control this loop from the command line but since I am not the caller of the process for which I am capturing I am not sure that would work. This is new code to me, not sure of any examples of something like this. If I have to control it through values I set in files it adds a little more time. The great news is I am not having binary size problems so I can add quite a bit of code while still keeping toolbox much less than the currently installed version on my Note 5. File size must match exactly otherwise patching causes seg fault and seg fault ruins the fun (reboot to cure but irritating)
anyway just needed to come up for air I have a ton done, need to get toolbox fired up to test angle.. any c programmers that want to help or anyone with awesome ideas please feel welcome I could use help
Click to expand...
Click to collapse
Do you have your toolbox on github? And is it commented decently? If so, I can look into helping with your code. I ask about comments because Ive not really looked into the whole. But if we figure out what parts samsung and at&t stripped down the AOSP toolbox, there could be a vector for completely patching the toolbox binary installed on our device.
Most root methods I see around, use busybox and su.
But our note 5 actually uses toolbox instead. Meaning, adapting a root method to use toolbox instead of busybox, eliminates that extra disk space taken up by the busybox binary, that needs to be patched in memory.
I needed to finish another piece of code before I started on toolbox, and that code is finished and on github. I need to be able to replace a list of files and know they are exact byte for byte, that's the code that I made available, which is in itself cool. Now I'm testing how to control the toolbox loop but so far if I get input from the command line the child executes one task then dies. I don't really want to fork fork fork fork things.. I need better control logic. soon i will solve it then upload a great starting point
edit: I realized there is places I can post snippets of code.. Here's the code I'm playing with but please realize some things may not work, not belong or I may have started making variables I never used.. (this is the pile of code I am using for testing).
I test code in Ubuntu first otherwise there wouldn't be enough time in a day:
gcc -o fork_u fork_u.c
./fork_u
http://pastebin.com/7nFxGcnY
Update: It's not exiting after executing a command at all. I messed up that if statement that checks for x. I am not a C programmer by trade I took it in college 20 years ago. Now I'm relearning it, so be warned on that
====>] We have changed directions back to replacing the bootloader see the next post [<====
I am exuberantly confident we can take the bootloader after the testing I've done today. This is the basics of the bootloader
https://www.xda-developers.com/galaxy-s7-bootloader-lock-explained-you-might-not-get-aosp-after-all/
===>] I need someone to copy their bootloader in both locked/unlocked status so I can find what to change. [<===
I am starting to suspect I can't simply copy an unlocked bootloader from another device. I am fairly certain that I need to pull the sboot from the device, patch it and then push it back. I need to actually look at the source code and perform any steps it does as well, such as deleting stuff.
I need someone who is vulnerable to dirtycow with an unlocked version of the Note 5 to pull their sboot in locked/unlocked status. This means they would run the hack I'm using on their device, overwrite toolbox, dumpstate and app_process temporarily to pull the partition.
====>] Plan B is downgrading then attacking an earlier version of the phone [<====
I believe I can write the original sboot.bin and system.img to the Note 5 now to do a forced downgrade. If that is true we could be dealing with trying to root an Android 5.0 device instead of Android 6.0 .. This opens the door on a million exploits!!
Plan B is all I have for now let me know if anyone can help with Plan A
**** Warning **** This is the most dangerous developer tool I've seen in a very long time. You can easily smoke your device with this without even trying.
====>] farm-root updated for Note 5 [<====
Ok guys it works for recovery or boot. It will pull an image or push an image.
https://github.com/droidvoider/Note5-Root-Farmer
toolbox directory compressed for recovery and boot, matches above code
boot push / pull --- aosp toolbox directory
recovery push / pull --- aosp toolbox directory
-DFARM_BOOT changes from recovery to boot in the shared.c
-DFARM_PULL is for pulling in toolbox,c / bridge.c, no define means compile to push.
-DDEBUG is for logcat messages, recompile minus this option to reduce binary size a lot
===>] What was wrong? [<===
When I got this working at first a couple weeks ago I thought I checked the path but I didn't. That and the updates to dirtycow are the only differences between mine and freddies version. (except that I also added push boot.img)
partitions:
/dev/block/platform/15570000.ufs/by-name/RECOVERY
/dev/block/platform/15570000.ufs/by-name/BOOT
directory containing sym links: (shell is allowed to ls -la inside this directory and view partition links!)
/dev/block/platform/15570000.ufs/by-name/
===>] So why can't we do this to the bootloader? [<===
I am now focusing just on this idea!!
Notes: I have a suspicion that if we used the bootloader from another device the numbers won't match, such as mac, and that will be permanent hard brick. I need someone to copy their bootloader partition both locked and unlocked using a tool I create for that purpose. (anyone got a friend who will help out?) Obviously this will not be an AT&T version.
===>] Basic instructions [<===
Download and unzip to a Ubuntu directory (android sdk + ndk needed)
Plug in your device and make sure you can adb shell
Add a screen lock pin to your device first
In terminal change to the directory first then make log
Open another terminal then you compile the sources for pushing or pulling as follows
make pull_boot, make pull_recovery, make_push_boot, make_push_recovery
You will be hung on "waiting for process to complete"
On your phone enter your pin, then go to settings, remove the screen lock pin..
close settings
On your phone again now go add back a lock screen pin.. close settings.
repeat the lockscreen thing it will go...
===<> Breaking my rule and playing with it now <>===
I tried boot.img altered with Assayed kitchen modified heavily but no changes, I think it was written back on reboot I bet recovery-from-boot.p really replaces this.
So I tried with recovery.img from Assayed kitchen modified heavily, I got a big blue error telling me to take my phone to AT&T
(if you get an error use heimdall to flash the specific file(s) or use odin to flash your AP file from the firmware.)
Continue Notes: I have confirmed I am replacing the boot.img and recovery.img completely freddie knocked it out of the park fellas. I have only tried heavily modified versions, I have not tried modifying the pulled version yet. If I flash anything not factory the phone has an error screen telling me to take it to at&t. pwr+vol. down I have to release and retry but eventually I get it to reboot, then download mode. Then simply flashing back what I replaced with farm-root gets me back up again.
If I flash recovery.img from t-mobile note 5 twrp it won't give me the error message until I attempt to enter recovery! After that it will always give the error. I tried putting twrp as the boot.img but that fails too, it does look like it almost loads something then I get the chain of trust error.
continuation of notes: I've still only tried heavily modified versions but I have unpacked the boot.img and recovery.img I've pulled, they are complete. If I flash recovery.img first then reboot without entering recovery it doesn't error. (until you enter recovery then it won't allow boot)... So instead I flashed boot.img also. Now boot.img isn't replaced on startup, I get the blue error message and this time I have to flash both recovery.img and boot.img to get the phone working again. (what does that mean?, mostly it confirms we wrote to both partitions which I have also confirmed through pulling / testing after writes) one thing is for sure this is a lot more fun then having nothing.
edit: nevermind on this idea I want to stay focused on unlocking the bootloader or downgrading it to Android 5.01
Update on status:
I can hard code toolbox to replace a list of files that you create right now, I am confident this includes bootloader, system, and a ton more.. So if anyone wants to do the leg work and find out which partitions are which, gather up a file list to replace and deliver that to me (the text version not the real files) .. I will hard code that out for you.. (i think that's freedom for you, see later bye)... Everyone else please realize I am having fun.. I tried to write toolbox to read what to change from /data/local/tmp/ but as suspected it can't read from there.. Today I will try to use dumpstate to copy a file list to /data/cache so that I can read it as install_recovery.
--- When I read what to change from a file we just need one toolbox for everything.. (no more separate toolboxes)
--- When I can communicate with toolbox in this manner I can move on to the next tool which is controlling the loop
Update:
toolbox is very limited on what it can open for reading if anyone is working on another project following along here for ideas you need to use the farm-root bridge idea. and by that I do mean even patching arbitrary file tests have failed now also, so there will be no eliminating bridge/dumpstate process
Updated again: Haven't had a tremendous amount of time to play lately but I sat down and tested my way through my final idea for farm-root. Bridge reads what to pull/push from a text file and then also pushes a text file to cache/recovery for toolbox to read. The file will have the dd if/of statements. Instead of performing 1 operation bridge will loop it will either wait..pull...wait or push...wait..push.. toolbox dd pulls or dd writes, waits for bridge and they loop between one another doing the work.
(still uncertain about dealing with 4gb file size but I realized that I don't need a sig verification. So I can unpack system, make it quite small then repack. This should smash down the version problem then we will need to do a follow flash of OJ1 AP, CP, CSC files...)
....thanks for your help with things lately @Delgoth you've hurtled this project ahead and are likely the reason it's here at all. I'm not forgetting the other things you mentioned I'm just at a wait and see pattern on what we need to force this downgrade, then get root
droidvoider said:
Update on status:
I can hard code toolbox to replace a list of files that you create right now, I am confident this includes bootloader, system, and a ton more.. So if anyone wants to do the leg work and find out which partitions are which, gather up a file list to replace and deliver that to me (the text version not the real files) .. I will hard code that out for you.. (i think that's freedom for you, see later bye)... Everyone else please realize I am having fun.. I tried to write toolbox to read what to change from /data/local/tmp/ but as suspected it can't read from there.. Today I will try to use dumpstate to copy a file list to /data/cache so that I can read it as install_recovery.
--- When I read what to change from a file we just need one toolbox for everything.. (no more separate toolboxes)
--- When I can communicate with toolbox in this manner I can move on to the next tool which is controlling the loop
Update:
toolbox is very limited on what it can open for reading if anyone is working on another project following along here for ideas you need to use the farm-root bridge idea. and by that I do mean even patching arbitrary file tests have failed now also, so there will be no eliminating bridge/dumpstate process
Updated again: Haven't had a tremendous amount of time to play lately but I sat down and tested my way through my final idea for farm-root. Bridge reads what to pull/push from a text file and then also pushes a text file to cache/recovery for toolbox to read. The file will have the dd if/of statements. Instead of performing 1 operation bridge will loop it will either wait..pull...wait or push...wait..push.. toolbox dd pulls or dd writes, waits for bridge and they loop between one another doing the work.
(still uncertain about dealing with 4gb file size but I realized that I don't need a sig verification. So I can unpack system, make it quite small then repack. This should smash down the version problem then we will need to do a follow flash of OJ1 AP, CP, CSC files...)
....thanks for your help with things lately @Delgoth you've hurtled this project ahead and are likely the reason it's here at all. I'm not forgetting the other things you mentioned I'm just at a wait and see pattern on what we need to force this downgrade, then get root
Click to expand...
Click to collapse
If toolbox is becoming limited, Toybox is also a partner binary that is used on the system beside toolbox.
Also if you can shrink the system partition and keep it persistent. You can shrink it from 4gb to 3.5 safely and then possibly reclaim that 500mb for your own private partition. My installed stock system uses 3.4gb of 4. That hidden partition should then remain even after a factory reset. As long as the device was not repartioned by odin or otherwise. Or as long as a new PIT isn't flashed.
This is where you can store your hacks, and have access to on device when first booting to recovery from a fresh flash.
toybox, good idea
I forgot about toybox when I get this code working I will rerun some of the test code on it to see how powerful it is.
New logic for root-farmer
root-farm will now only have 1 bridge and maybe 2 toolboxes (depending on final binary size for toolbox)
Now the files to PUSH/PULL are in a text file. Bridge copies it to cache and then toolbox can read it also.
PULL example: <= everything before the '|' is one execv command used by toolbox. => | <=== following this character is bridge copy leftvalue => | right value
of=/cache/recovery/bota0_pull.img if=/dev/block/platform/15570000.ufs/by-name/BOTA0 bs=10m|cache/recovery/bota0_pull.img|/data/local/tmp/bota0_pull.img
So push will only push a files.txt, pull_files.txt/push_files.txt is copied to /data/local/tmp/ then bridge decides if this is a push or pull depending on the text file format. After that it's pretty much business as usually toolbox uses the dd command as root+install_recovery to over write or copy anything
This code snippets are not complete. They are meant to show you what I did to test my theories.
toolbox_working example
bridge will copy files.txt to /cache, toolbox will pick it up and then spit the contents out into logcat -- success
unfinished_test_code
that's the parsing, it echos the commands it doesn't actually dd anything.. but you can see it echo what it should be copying, or dd'ing.
updated (adding sources per a users request):
brdg.c.tar.gz == linux proof of concept for bridge, i make copies, test stuff from blocks of code like this then port to android
This morning something dawned on me. If I can write to the first partitions known to the computer worlds as MBR1 512kb limit MBR2 extended mbr.. Then I already own this device. Now I need twrp with the correct addresses for my device, I simple write twrp on the device and wipe the rest.
While I think that is true 100% I have different passions then simply winning. If anyone is willing to try it I will port farm-root over to point at those partitions instead, and also to replace them in one go.
Those waiting for the finished tool I get to play today a little since I had to work Sunday! we should have a template at minimum this evening. I'm adding to sources one is the partitial conversion it will be called Android_Dirtycow_root_farmer from now on.. (because it isn't specific to any device any more it will work with any 64bit dirtycow vulnerable device)
the test zip?, man I forgot what I tested with that just type make test and watch logcat.. tests are always safe, reboot afterwards though.
Tool is working!!!
Android 64 bit universal dirtycow dd image write works for both push/pull.. I am tired so please see github readme, the Makefile and push_files.txt, pull_files.txt examples. I am going to get root, this is the first step.
https://github.com/droidvoider/Android_6.01__DD_Dcow
More info on it
I updated this thread with some info first/last posts only
https://forum.xda-developers.com/no...g-dirtycow-t3559637/post71102343#post71102343
What about root right now?
If I can get system_server + root, then switch to install_recovery + root I can fork both these processes away and send commands to them through a text file just like I sent the options for push/pull. This code wasn't only to eliminate the need for multiple toolbox / bridge binaries.. It was to create a command shell that I can issue any command. Remember my examples above?
.....Work study: take the examples I created and create a loop that doesn't close but instead waits for changes to a text file. Then execv those changes returning to wait again for more changes.
I have to be away for 1 to 4 weeks I just found out.. I might be able to check messages, I dunno. not away but same as.. have fun
Im going to go over all this, this weekend. Hopefully I can work out what data to write.
If we can patch /sbin/sverifysignature then we maybe able to disable the sig check. Right now my device is without a DT_Hash, I have busybox installed and linked to /system/xbin
I also have the su binary in xbin but its not linked so apps dont know it's there. But they both persist through reboots no problem. I am currently half way rooted, with zero hiccups so far.
Im close but im running 5.1.1 with an eng kernel and eng sboot. I dont currently have a CSC installed.
The problems im running into are that most apps have always done root the same way, the way that doesnt work on this device. Root is possible, but the age old standard root injection doesnt fly here, we have to do it manually this time because the standard root install scripts expect privs we dont have in certain places. That doesnt mean we can't root, it just means we have to edit the scripts and run them from some place other than TWRP. Which is still possible.
So here is what I have:
Dm Verity verification failed... Message when entering recovery. No effect on operation.
ADB root on boot, and when charging offline.
Busybox 1.22 fully linked from /system/xbin
Chainfire supersu 2.76 su binary placed in /system/xbin unlinked, I dont know how to link it like I did with busy box.
Even though dm verity fails, I can mount the entire filesystem read/write, and all my changes are still in place after normal reboot. I can modify my system and dm verity does NOT undo my changes. I can even pull my boot img from /dev/block/sda5
What do I have in my hands right now?