Hi,
I'm developing an application on SmartPhone SDK 2003.
I need to extract the cell ID from telephone.
How can I do?
If you have any suggetion, I'll be happy.
Thank you.
Bye
Andrea,
You might want to check out http://www.cell-profiler.de/
Maybe the developer would point you in the right direction
Regards
Keith Burke
I feel the XDA (I&II) badly need network monitoring software
Indeed
thanks, but the site is under costruction.
I don't have to buy but i've to deploy the software for my thesis.
I've downloaded from the site http://viewcvs.xda-developers.com/cgi-bin/viewcvs.cgi/xdautils/#dirlist the following class: debug.cpp, debug.h, ril.h, riltest.cpp, riltest.h, stringutils.h, stringutils.cpp, vectorutils.h, vectorutils.cpp.
I've create a new project and build it.
But RIL_GetCellTowerInfo response:
RIL_GetCellTowerInfo: 80004001
RES: 00000001 000000a6 10 00 00 00 03 00 00 00 02 00 00 00 02 00 00 00
RES: 00000001 000000a7 :shock:
I think that 80004001 (hexadecimal) mean that it don't work (not implemented)
I have no more idea how to do this. Could anyone to help me?
Thanks
Andrea,
Yes the site is under constuction, but their support email address is on that page.
He [dutty] also frequents this forum semi regularly. Maybe if you post a message for him, or even PM him. He's generally an approachable guy, he may help you.
Check topic
http://forum.xda-developers.com/viewtopic.php?t=8200&highlight=dutty
I haven't dabbled in the RIL myself, so can [EDIT : Should read "can't"] help you there, sorry. But you are developing for the XDA / XDA II, I take it. Not sure but I think the RIL applies to XDA and the like.
Thanks, but i'm developing on SmartPhone 2003 platform in eVC 4.0
It's possible that nobody know RIL for smartphone??? :?
for the xda2 you can get the cellid via a device specific API, 'RIL_DevSpecific, see RilClass.cpp
it is quite likely different for your smartphone.
to see if your device supports cell info notifications, you have to see if the string '+CREG=2' is somewhere in your rilgsm.dll.
you can extract rilgsm.dll from your rom using dumprom
Excuse me,
I don't understand how to use dumprom on smartphone!!!
Can you help me?
Thanks
I´m looking for a way to read cell ids for some weeks now and didn´t find anything valuable. Some working programs, but theyre all closed source...
I´m working with basic4ppc on win mobile 6. If there are any advances, PLEEAASE let me know ^^
Does at least, any program work?
Have you tried http://usuc.dyndns.org/tv/gsm/GSMCelluloz/ ?
Does it help ?
If you have problem, try the debug version and send me file files created in \Temp.
I may help if you have problem, but I don't do any basic4PPC...
Related
Hello everyone.
With the development of the New ROM, I decided to describe this and that.
-How to Prepare files and packages.
-How to create stable SYS and OEM.
-XIP Porting (Kernel) - if it succeeds.
-Build/Mod. BLDR/BOOT Section
-Change PagePool
-Etc
Small introduction:
Subject shows the structure of folding and unfolding ROM.
Everything described here are doing at your own risk.
I do not answer with any damage to the device.
Please read carefully and proceed with caution.
Topic applies only Toshiba devices Tsunagi: TG01
Execute Image System:
This step tutorial will be further developed.
Once, I'll add this feature in my kitchen.
Add OEM Apps:
OEM - This package is derived from the *. cab file.
It must include:
- The *. dsm guid the value of the name,
- The *. RGU with the same value in the name, it must be in Unicode encoding.
It must also be free, the last line in the content of the text.
- Application *. exe, *. dll, or library
- A shortcut to the program / library - if it is needed. It is not mandatory.
- Content may be more developed (in the files / programs)
Such a package can be easily added to the root of the OEM.
If, of course, is properly filed
Dependence of the Application, the memory devices.:
How can you distinguish the memory which will hit your application / library?
This differs from the rule:
- Module - that is, a file that looks like a directory goes to RAM.
- File - normal-looking, *. exe or *. dll file, going to Storage memory
Porting XIP (Kernel) and insert this file to Image System:
[TUT][UTIL]Remote Porting XIP
Working good in my kitchen for Toshiba TG01
XPR to LZX Compression:
Open the file os.nb.payload in HEX Editor. Find this Lines:
Code:
F8 AC 2C 9D E3 D4 2B 4D BD 30 91 6E D8 4F 31 DC ř¬,ťăÔ+M˝0‘nŘO1Ü
01 00 00 00 01 00 00 00 01 00 00 00 34 00 00 00 ............4...
08 00 00 00 00 02 00 00 00 10 00 00 58 50 52 00 ............XPR.
And change to:
Code:
F8 AC 2C 9D E3 D4 2B 4D BD 30 91 6E D8 4F 31 DC ř¬,ťăÔ+M˝0‘nŘO1Ü
01 00 00 00 01 00 00 00 01 00 00 00 34 00 00 00 ............4...
08 00 00 00 00 02 00 00 00 10 00 00 58 50 52 00 ............LZX.
Save this file. Get this library -> cecompr_nt.dll, then insert to TOOLS folder from your Kitchen ROM.
Download cecompr.dll and overwrite it in your XIP. Build XIP, build ROM, see results. Now Image System takes less memory.
Small Support
Changes PagePool:
Use PagePool Changer
Porting/build BLDR/BOOT and insert this file to Image System:
[UTIL][UPG] buildbldr
Build Image System:
This function, have a my Kitchen.
Ultra Kitchen Edition - ROM Builder for Toshiba TG01
Modyfications SYS Directory
Remove TimeBomb:
Open file *.rgu from location ->SYS/Shell/, and remove two keys from this registry:
Code:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\DeviceBeta]
"Today"="Beta"
"Expiry"="Expires: %02d/%02d/%04d"
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\DeviceBeta]
"About"="- BETA"
Now, Go to location -> SYS/Shell/, open file form module shell32.exe/S000 in HexEditor.
Search string 02 EB 7D 3E, and in both instances 7D change to BB.
from:
Code:
02 EB 7D 3E
to:
Code:
02 EB BB 3E
Remember, this sequence occurs twice
Thanks for Camelio
good idea, may be i'll try to understand something and build an italian version too, even if we are quit lucky with our tg01 'cause it's no brand at all.
Thanks for your great job with developement
Hey Nokser do you create wm6.1 rom for tg01?
Nokserze can you writa Polish version too?
here or in pdaclub forum, but I wont to understand anything, so it's more simple in our's language
Thanks for your job
Yes, of course
When you will to make this tourial? or you can write the tourial for stabil oem's now I want to make a rom but i can't create a stabil oem or a oem that's works... or you can tell me how i must put the oem.
Greats ALcAtRas
I give all my work in this, but first I must port WM6.5.5
Nokser, could we use the information you have gained about our device to port android?
Wm first, then we'll see Android
Nokser said:
Wm first, then we'll see Android
Click to expand...
Click to collapse
You think that is posible?There are a lot of people ho want that.
Everything is possible, but we shall see
Is this guide close to completion or has this been forgotten about?
I not forget.... I must gen. all options build structure ROM
Nokser said:
I not forget.... I must gen. all options build structure ROM
Click to expand...
Click to collapse
MAny of us are waiting for your light...
I know My friend
Small Update Thread
Nokser said:
Small Update Thread
Click to expand...
Click to collapse
Very good: I'm waiting for the next update impatiently. Do you know a good general tutorial, not device specific?
super_sonic said:
Very good: I'm waiting for the next update impatiently. Do you know a good general tutorial, not device specific?
Click to expand...
Click to collapse
You'll see ... if i end this tutorial
@Nokser:Can you help us to unlock t01a .It likes tg01 but it don't have code for unlocking .
Please...
Hello all,
I installed the CONROMv6 on my Verizon HTC Rezound. Everything went fine except that I was not able to receive SMS. Somewhere in google I found a solution: write some NV_stuff using cdmaware; didnt work. I also found in some HTC forum a kind of update that some HTC developer posted, I installed but didnt work either. Without finding a solution, I sitted my phone for a couple of days while taking care of my biz.
When I took my phone again, I realized that all the CDMA setting were gone. I tried to re-program the phone using QPST 2.7 366, but everytime I try to write to the phone, I receive an error saying "Roaming list file contains no data". I even tried to write some values at the time, but I keep receiving the same error or "NV_ACCOLC_I(0) NV_READONLY_S". I also tried to use CDMA Workshop to write the PRL file and even when it says it succeded, keep saying there is not PRL.
I cannot find the information about the solutions I tried for the SMS problem, and I am not sure about when the problem appeared, but I think I messed up with the NV stuff and i have not idea about how to fix it. Can anyone point me in the right direction? Does anyone have an NV backup that I can use for my phone?.
If you are S-OFF it is probably best to run the RUU for 4.3.605.2 and bring the phone back to stock, at least to get it working... Most of that stuff you were messing with is just bad news for 4G phones.
acejavelin said:
If you are S-OFF it is probably best to run the RUU for 4.3.605.2 and bring the phone back to stock, at least to get it working... Most of that stuff you were messing with is just bad news for 4G phones.
Click to expand...
Click to collapse
Thank you for your answer. I already flashed back to stock, but I guess that the NV_items are not modified by any ROM. Anyways, I am downloading the RUU you sugested to give it a try; will let you know.
acejavelin said:
If you are S-OFF it is probably best to run the RUU for 4.3.605.2 and bring the phone back to stock, at least to get it working... Most of that stuff you were messing with is just bad news for 4G phones.
Click to expand...
Click to collapse
Already tried with no avail. I flashed the latest RUU and did a factory reset after that, but still having the same problem. Any other ideas?
PortOS_76 said:
Already tried with no avail. I flashed the latest RUU and did a factory reset after that, but still having the same problem. Any other ideas?
Click to expand...
Click to collapse
switch the phone to cdma only. boot into recovery and wipe dalvik:
dial *22899
a popup should appear, then turn your 4g back on and test please.
synisterwolf said:
switch the phone to cdma only. boot into recovery and wipe dalvik:
dial *22899
a popup should appear, then turn your 4g back on and test please.
Click to expand...
Click to collapse
I followed your directions, but no popup appeared dialing *22899. Is there another way to turn the 4g back on?.
PortOS_76 said:
I followed your directions, but no popup appeared dialing *22899. Is there another way to turn the 4g back on?.
Click to expand...
Click to collapse
just turn it back on via the menu in mobile network
synisterwolf said:
just turn it back on via the menu in mobile network
Click to expand...
Click to collapse
I already did, but same problem, I cannot change the CDMA settings.
Found it! The file I wrote to my Rezound is the NV_Thunderbolt_Verizon.txt. Yes! I know this is a file for the Thunderbolt, but I dont know what I was thinking in that moment. The point is, can someone tell me if this is the source of the problem and what was the original values for this NV_Item?. The file content is the next:
[NV Items]
[Complete items - 1]
0855 (0x0357) - OK
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Also found the hotfix I used. Im afraid this is a hotfix for the Incredible, again the wrong device. Well, the hot fix is:
http://dl3.htc.com/misc/inc8049.apk
Any ideas?.
Well, let see.
You used CONROM on top of the latest ICS RUU leak? Con stopped supporting his ROM and it is not made for the latest ICS RUU leak.
You installed Thunderbolt and Incredible nvRam files on a Rezound phone?
You think installing things either not meant for your phone or not meant for your version of the operating system RUU were good ideas to try?
You installed something without researching first how to un-do it?
acejavelin: Yes, I used to think an RUU and factory reset will put everything back to normal. But, when I played with a T-Mobile SIM card (with 4.03.605.2) and ended up with a messed up Verizon APN, I discovered that the APN is stored in some unknown location where even an RUU and factory reset will not touch. I did manage to fix the Verizon APN problem. It is possible to really screw a phone up to the point that RUU will not fix it.
Anyway, I do hope someone has a solution to your phone's problems. I hope you realize now that installing things not meant for your phone or your version of the operating system is not a great idea. In the future, start with your phone on an RUU that the ROM is intended for, make a nandroid backup before installling the ROM, and if you don't like the ROM, then restore the nandroid backup to go back to stock.
Start with completely stock system - so everything matches and works together right.
Only install customized things that are meant for your phone and your version of the operating system RUU.
If you aren't sure, ask the author of whatever you are considering installing.
Think about: Do I really want and need what I am about to install? How risky is it? How will I be able to uninstall/undo it?
I don't intend this post to make you feel bad, it is more to make everyone else think a little.
P.S. You might try the LTE ON OFF app or HZUtils app to enter the hidden 4636 menu and select "CDMA+LTE/EvDo auto". But I wouldn't go experimenting as there are many options in hidden menus I do not understand. HZutils also has the ##778# hidden menu. You can also just dial ##778# to bring up the EPST menu with code 000000, but I wouldn't go changing things unless one understands it. Maybe you can compare your EPST values with those in someone's working Rezound phone. Then with a list of what the values are in a working phone, along with the list of what is stored in YOUR phone, you can cautiously change the EPST values in your phone?
The EPST hidden menu does have a submenu called PRL, so maybe this is something for you to investigate.
I know that I did something stupid by installing things that were not meant for my phone. Good news, I learned my lesson. About the solutions you proposed:
I cannot enter some of the hidden menus like ##4636#, however I was able to enter that menu using the tweaks app included in the ROM.
I also tried to enter to the ##778# menu, fortunatelly is working and i know how to modify every parameter in it. Unfortunatelly I cannot modify any of the options in the NAM Settings nor the PRL menus; they appear like in the View Mode.
Seems like all the NAM settings and PRL options are read only, how can this happened?.
I am out on a ledge, talking about PRL because I am not very knowledgeable about it.
I think PRL is updated by *228 for older phones and for the rezound it is via the SIM card.
http://www.verizonwireless.com/care/popups/prl.html
When the phone goes through a sim card activation, I think you get the PRL information into the phone.
Go to a Verizon store and talk them into giving you a replacement SIM card.
Maybe it dropped into the grass while changing your battery?
See if a new SIM card will set things right. Maybe also do a factory reset. If a new SIM card doesn't help, well it didn't cost you anything.
I already tried the *228 and nothing happens. As there is no PRL in the phone, it has no service, therefore, it cannot connect anywhere to update any data. About the Verizon simcard, the phone is not activated in Verizon, so I cannot ask for help from them.
I think the funny thing here is that all the NAM information is read only, while this must be writable in order to set the user information.
Have you tried writing the PRL with and without the SIM card installed? You could try using DFS to write some of your NV data too. I used workshop, Qpst, and DFS to program my Rezound on PagePlus.
I installed ConRom also and the stock RUU and only had to re-program the PRL, just so you know that the other settings shouldn't change after you get it going again. Cheers
Nam setting became write only
Looking for a solution to my problem I found this thread in which someone with a Droid has the same issues as me. I cannot use this solution as that folder is not present in my Rezound (this may be present only in Droids I guess). Any sugestions that may help me to write my NAM/PRL settings?
http://forum.xda-developers.com/showthread.php?t=651475
ckuke4 said:
Have you tried writing the PRL with and without the SIM card installed? You could try using DFS to write some of your NV data too. I used workshop, Qpst, and DFS to program my Rezound on PagePlus.
I installed ConRom also and the stock RUU and only had to re-program the PRL, just so you know that the other settings shouldn't change after you get it going again. Cheers
Click to expand...
Click to collapse
I already tried all of these programs, but, even when CDMA WS and DFS says that succeded to write the parameters, there is not cange on them.
PortOS_76 said:
Looking for a solution to my problem I found this thread in which someone with a Droid has the same issues as me. I cannot use this solution as that folder is not present in my Rezound (this may be present only in Droids I guess). Any sugestions that may help me to write my NAM/PRL settings?
http://forum.xda-developers.com/showthread.php?t=651475
Click to expand...
Click to collapse
The suggested solution was to remount the system partition as writable. ES File Explorer app can do that for you if you have root.
Also, that thread shows no feedback whether the proposed solution helped.
HowardZ said:
The suggested solution was to remount the system partition as writable. ES File Explorer app can do that for you if you have root.
Also, that thread shows no feedback whether the proposed solution helped.
Click to expand...
Click to collapse
That is why I would like to try to see if works, but I dont know how to remount the system partition in a Rezound (there is no mtdblock3 folder). Someone willing to give some help?
From terminal emulator app
su
mount -o remount,rw /dev/block/system /system
Be careful because until you remount it readonly or reboot your are capable of modifying or deleting important system files.
Hello, readers.
I am about to receive a MT6577-based phone. My religion prohibits me from using windows :silly: and I am using Linux since good old 1993,
I have done a lot of reading during the past months. I have installed the Android SDK, and thus I have adb up and running and I believe
I won't have problem in rooting the phone (which I must do as first thing). I have found a terminal application. I believe it will be
reasonably easy for me to find myself at home.
The only big gap I still have is on how to proceed about flashing updated/modified roms to the phone. There is a very informative thread
on china-iphone.ru about the specific phone I will get. It is in Russian, but thanks to Babelfish I was able to understand a lot. Most
important, I got hold of the latest official rom for the phone I will receive.
But then, how to proceed with flashing? all tutorials I found describe the windows way of transferring this file's
contents to the phone. Use is made of one of two tools that Mediatek apparently released. This is a no-no for me. I mean: Android is
Linux. I should not have to downgrade to windows to deal with my Linux phone! And then, I simply have no windows whatsoever here.
I see three possible ways for me to proceed:
Find an equivalent software that runs under Linux
Try to run one of Mediatek's softwares under Wine
Obtain from Mediatek, or elsewhere, the precise specs about the USB protocol being used, and implement my tool
Reverse-engineer the protocol
The first item is, I believe, a dead end. I think my search has been exhaustive enough.
The second one is a path I'd rather not tread.
The third one would be a nice project, but I perceive that Mediatek is a bit opaque when it comes to providing technical specifications.
The fourth one would very quickly come to a dead end, I believe, with a bricked device.
Any suggestion on the above, or on other possible ways?
Also: I have come across some very vague mentions about flashing this sort of devices from recovery mode.
From what I have gathered, you put the rom file on a SD card, and then enter recovery mode and let the phone do its own flashing.
This would be ideal for me, but I came across no mention about this mechanism on threads that are specific to this class of phone.
Do MT6577-based phones come with recovery mode? How is it used?
I would be thankful to anyone who could provide details on this aspect.
So far I have only flashed a custom recovery into my MTK6577 phone and I did it with dd.
The full ROM is exposed on /dev/block/mmcblk0.
Once you have rooted your phone you can use dd along with the info in the scater file (from windows tool) or from Memory/eMMC in the EngineerMode (at least in my phone).
Good Luck
P.S.: In my phone the recovery can be booted into from the phone info in Settings.
Or pressing volume up when turning on the phone and releasing volume up once it vibrates (if not it goes to factory mode that has a bunch of tests in it).
Or using adb reboot revovery
FrankVM said:
The full ROM is exposed on /dev/block/mmcblk0.
Once you have rooted your phone you can use dd along with the info in the scater file (from windows tool) or from Memory/eMMC in the EngineerMode (at least in my phone).
Click to expand...
Click to collapse
Thanks a lot.
Indeed, I had found out about using dd plus the info in the scatter file. At first I completed the task of loading a different recovery image, and that was sufficient at the moment. Later on, I spent another weekend on this: I started working on a Ruby script that, by interfacing with the phone via ADB, would dump and upload any partition, and possibly do the reverse, too. The upload part sort-of worked, and I was able to get hold of the current booting partition. What I wanted to do was to modify the boot script to let me run at boot a script resident on one of the sdcards.
I got to the point of unpacking the data in the gzipped/cpio-ed root fs archive, and certainly I would not have had problems modifying the script. But I was blocked when I tried to find the data about the format of ROOTFS. I mean: I could find the start of the compressed material, but I could not find exact reference about those few bytes that preceed it. Must those bytes change if the actual content changes?
I only have one phone, and I certainly do not want to brick it (or have to pour half-days of work into blind-man debugging mode...)
The block is 512 bytes long, filled with 0xff's except for (in my case)
00000000 88 16 88 58 │ 9F 94 08 00 │ 52 4F 4F 54 │ 46 53 00 00 │ 00 00 00 00 . X ..ROOTFS......
00000014 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 ....................
and it seems quite clear that the only data that may change are the first 8 bytes - presumably 4 shorts, which in my case would have the values:
5768
22664
38047
8
When I find out what these numbers are, and when I have another free weekend, I may go on in my exploring path.
I looked into modifying boot/recovery images a few weeks back but haven’t gotten around to fiddling with mine.
The initial data is the uboot header, if I remember correctly. It does need to change.
There is a tool out there in perl that does all the required to unpack and repack the boot images for MTK65xx phones.
Here is forum page with the tool info: http://forum.xda-developers.com/showthread.php?t=1587411
my way to do it on ubuntu
well I basically did it on ubuntu, but it was actually virtual box windows under ubuntu so...whatever
This thread is from 2012... 3 years later in 2015 and not a single mtk flash tool was developed for linux... i bet using a windows based phone it will be easyer to find that kinda tool
Now there is a flash tool for Linux available, (look for needrom.com -> sp-flash-tool-v5-1424-00),but I can't get it to work. I suppose there is a vcom driver missing. Unfortunately my phone (UMI Hammer) does not support adb flash, otherwise I would be very happy to do it that way.
I think it took so long that a linux flash tool became available because MediaTek didn't share their code with developers. They changed their policy about a year ago, though.
I wrote a tutorial for setting up the SP_Flash_Tool_Linux
It works
Scroll down for recent updates;
Has anyone ever heard more from h311sdr0id about his post (see here) to get more info about this "state" that allows you to flash MDK over ME7 in Odin? I'm curious to see if we can use that state, maybe in QDL mode to somehow either push an image to the phone or communicate with it using some methods/commands that E:V:A refers to on this page and a few pages after and before. It's also possible that we then might be able to use a modified unbrick.img (see here) to restore an MDK bootloader. So far those are the two ideas that I think have the best chance.
Also in this thread I started with the intention of compiling the entire stock firmware for the Dev edition (OYUAMDK), I mentioned at the bottom that when flashing the stock MDK restore Odin tar on an ME7 phone users usually get a "SW REV. CHECK FAIL: FUSED: 3, Binary: 1" message meaning that your current fuse counter in aboot is set to 3 but the binary your attempting to flash is set to 1 so the flashing attempt will fail and I'm willing to bet if you're on VRUDMI1 and you attempt to flash the MDK restore you will get a similar message but the FUSED: value will be set to 4, you can see the counter upped in this post from jeboo here. However, with flashing the dev OYUAMDK aboot file on S4's with a ME7 bootloader users will receive a "SECURE CHECK FAIL: aboot" message instead, I don't know if we might be able to use dev OYUAMDK aboot file and bypass the fused counter entirely, since the dev edition has an unlocked bootloader and the fuse is an efuse, so software enforced, not a hardware enforced qfuse. If anyone wants to go into more detail, or wants to expand on these ideas we I can expand on this info or we can collaborate ideas in the Dev discussion thread.
Other points to consider:
If you know how to use IDA pro, and can help with the base address of the binaries, that is probably our best bet to find a vulnerability in aboot, you can see jeboo and djrbliss discuss this a bit (here) and you can see Ralekdev show his findings here, also this gives the explanation of why you see the "custom unlock" boot screen that people constantly post about in the Q&A thread. Both of these threads along with djrbliss' blog discussing the S4 aboot vulnerability that lead to Loki (here), and exploiting the TrustZone (tz.mbn) on Moto's bootloaders (here) are good starting points in trying to find a new vulnerability.
If you know how to hexedit, then hexedit aboot.mbn from MDK, ME7, OYUAMDK, and MI1. You can see ME7 and MI1 are similar in both size and content, while MDK and OYUAMDK are more similar to each other in size and content. Obviously OYUAMDK differs from the others in the way it checks the recovery and boot partitions, (in djrbliss' blog on the S4 exploit he says "This bootloader differs between "locked" and "unlocked" variants of the Galaxy S4 in its enforcement of signature checks on the boot and recovery partitions.") but we are able to flash all bootloader partitions from the OYUAMDK firmware restore Odin file I made except aboot, so if you have any ideas on how we might be able to exploit any of that, please feel free to share.
If you do hexedit a dd'ed partition (if you copy mmcblk0p6 from your phone to your pc) you will see that its padded with zeroes at the end. You have to cut the padded zeros from the dd'ed image in order for the partition to be registered as a signed partition in Odin, etc. To do this, use Linux, open a terminal and type
Code:
sudo apt-get install hexedit
then enter your password and hit enter. Then go to the folder that contains the partitions you want to hexedit (for instance type cd /home/Your user name folder/Desktop/S4partitionbackups/" where "your user name folder" is whatever your username is and "S4partitionbackups" is a folder you create on your desktop containing a backup of your partitions) If you don't have a back up of your partitions you can create them using something like the command below, substituting mmcblk0p6 and aboot.mbn with the partition(s) you are interested in.
Code:
adb shell su -c 'dd if=/dev/block/mmcblk0p6 of=/sdcard/backup/aboot.mbn'
then
Code:
adb pull /sdcard/backup/aboot.mbn /home/Your user name folder/Desktop/S4partitionbackups/
then
Code:
cd /home/Your user name folder/Desktop/S4partitionbackups/
Code:
hexedit aboot.mbn
Quick guide on Hexedit controls/keys
shift+> will take you to the end of the hex file
shift+< will take you to the beginning
page up/page down it will take you up a page and down a page respectively
ctrl+c you will exit the hex file without saving any changes
esc+t you will truncate the file at the current location
ctrl+x you will save the file with all changes you have done.
This is an example of a padded aboot.mbn, before hexediting, and prior to truncating the file a at the first "0" in the string "00 01" found between the end of the actual file and the padded zero's and repeating F's
View attachment 2353922
This is an example of a properly signed aboot.mbn after hexediting
View attachment 2353923
How to find start addresses
First you have to open the selected bootloader with a hex file editor and look at the header, converting for little endian you can find the start addresses and offsets
Code:
[B]sbl1.mbn = 0x2a000000[/B]
00000000 D1 DC 4B 84 34 10 D7 73 15 00 00 00 FF FF FF FF ..K.4..s........
00000010 FF FF FF FF 50 00 00 00 [COLOR=Red]00 00 00 2A[/COLOR] 40 72 01 00 ....P......*@r..
00000020 40 41 01 00 40 41 01 2A 00 01 00 00 40 42 01 2A @[email protected]*[email protected]*
00000030 00 30 00 00 01 00 00 00 04 00 00 00 FF FF FF FF .0..............
[B] sbl2.mbn = 0x2e000000[/B]
00000000 16 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red]00 00 00 2E[/COLOR] ................
00000010 40 51 02 00 40 20 02 00 40 20 02 2E 00 01 00 00 @[email protected] [email protected] ......
00000020 40 21 02 2E 00 30 00 00 12 00 00 EA 5F 00 00 EA @!...0......_...
00000030 62 00 00 EA 65 00 00 EA 68 00 00 EA 6B 00 00 EA b...e...h...k...
[B] sbl3.mbn = 0x8ff00000[/B]
00000000 18 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red]00 00 F0 8F[/COLOR] ................
00000010 20 20 04 00 20 EF 03 00 20 EF F3 8F 00 01 00 00 .. ... .......
00000020 20 F0 F3 8F 00 30 00 00 D3 F0 21 E3 D3 F0 21 E3 ....0....!...!.
00000030 00 70 A0 E1 09 02 A0 E3 00 D0 A0 E1 DB F0 21 E3 .p............!.
[B] aboot.mbn = 0x88e00000 offset = 0x285[/B]
00000000 05 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red]00 00 E0 88 [/COLOR] ................
00000010 10 56 14 00 10 25 14 00 10 25 F4 88 00 01 00 00 .V...%...%......
00000020 10 26 F4 88 00 30 00 00 06 00 00 EA F0 38 00 EA .&...0.......8..
00000030 F6 38 00 EA FC 38 00 EA 02 39 00 EA 08 39 00 EA .8...8...9...9..
[B] tz.mbn = 0x2a000000[/B]
00000000 19 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red]00 00 00 2A[/COLOR] ...............*
00000010 C4 3A 03 00 C4 09 03 00 C4 09 03 2A 00 01 00 00 .:.........*....
00000020 C4 0A 03 2A 00 30 00 00 09 00 00 EA 90 F2 9F E5 ...*.0..........
00000030 90 F2 9F E5 90 F2 9F E5 90 F2 9F E5 84 F2 9F E5 ................
[B] rpm.mbn = 0x00020000[/B]
00000000 17 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red] 00 00 02 00[/COLOR] ................
00000010 38 57 02 00 38 26 02 00 38 26 04 00 00 01 00 00 8W..8&..8&......
00000020 38 27 04 00 00 30 00 00 06 00 00 EA 1E 00 00 EA 8'...0..........
00000030 2C 00 00 EA 39 00 00 EA 46 00 00 EA 53 00 00 EA ,...9...F...S...
EDIT: 2/01/2014 - Updated OP to include where we're at
2/01/2014
1. Figuring out what Hellsdroid's method was - Unfortunately this seems unlikely as of now (figuring out what he did that is) On the other hand, @TMcGrath50 and I discussed a method we thought to be similar to his starting around here and then I learned how to use ida better as time went on and recently disassembled that I9505 S4 USB repair tool. I have not done a thorough analysis of the pseudocode yet though. But even so, this method has never been done before (as far as I know) and
in addition to assuming the information in the pic below is true, and we can in fact reset the emmc on our devices with Secure Boot 3.0 (would this be a way of getting around having to reset the Secure Boot bit in the pbl to "0"?) I still think this idea needs to be refined a bit before its worth exploring because some questions remain in regards to if it would even work in the first place. For example, when a JTAG solution was tested previously, the VRUAMDK aboot.mbn didn't flash on a device with VRUAME7 after all the partitions were wrote over with VRUAMDK partitions via JTAG, why? @jeboo may be able to help answer that.
Also, it was previously questioned whether or not the flash programmer (8064 hex) would need to be signed or not. As I have two S4's one thats working and one in QDL QHSUSB dload mode, in doing some recent testing through usb (S4 to S4) I was able to get some info back about my bricked S4, namely that I had sent it the wrong hex file ( see the last line here) because the dmesg and last_kmsg logs say something to the effect of "the the cpu clocks cannot start because its configured for the wrong device" and the last line from the my pastebin post says "8660" among other things as well.
Status - Unknown - More Research Required
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
2. Using a Developer edition S4 to unlock a retail S4 - So here's what we know, the dev kernel (boot.img) is flashable and will work with retail S4's, but the recovery.img and aboot will not. Flashing the dev recovery.img will succeed in Odin/Heimdall, but if you try to boot into recovery it will inform you that your device is "tampered" and and will void your warranty by setting the Knox warranty bit to 0x1. Before I discuss why aboot.mbn wont flash consider this; neither the Developer edition of the GS4 nor the Developer edition of the Note 3 has every received an OTA or a factory Odin tar. This is not by random chance. Every Developer edition owner has a unique MD5 for their aboot. If you couple this with the fact that Dev edition devices have retail stickers under their dev stickers, you will probably come to the conclusion that Samsung/Verizon/AT&T haven't released updates to dev devices because they would have to do it on a 'per device' basis, that or risk handing us a method to convert retail devices into developer edition devices. If the method by which Samsung uses device specific info to sign developer edition aboot partitions were discovered this may work, or if their method to determine if a device is a developer edition or consumer retail edition is similar to what Dan R (djrbliss) took advantage of then this could be a possibility.
3,4,5,6, coming up....updating...this will be a long post...advance warning.
Status - Possibly - More Research Required
This really sucks. Looks like the dev that knows how to downgrade from ME7 to MDK is locked up for a while.
h311sdr0id is currently indisposed and will probably not be getting out anytime soon. He has court next month. If anyone is interested in writing him, please send a message to his account and I will give you his info.
- Mrs. h311sdr0id
Travisdroidx2 said:
This really sucks. Looks like the dev that knows how to downgrade from ME7 to MDK is locked up for a while.
h311sdr0id is currently indisposed and will probably not be getting out anytime soon. He has court next month. If anyone is interested in writing him, please send a message to his account and I will give you his info.
- Mrs. h311sdr0id
Click to expand...
Click to collapse
Man... Samsung's really cracking down...
Sent from my SCH-I545 using XDA Premium 4 mobile app
Is it confirmed this is Samsung's doing?
Sent from my SCH-I535 using XDA Premium 4 mobile app
Travisdroidx2 said:
This really sucks. Looks like the dev that knows how to downgrade from ME7 to MDK is locked up for a while.
h311sdr0id is currently indisposed and will probably not be getting out anytime soon. He has court next month. If anyone is interested in writing him, please send a message to his account and I will give you his info.
- Mrs. h311sdr0id
Click to expand...
Click to collapse
WOW, this is news to me! It explains why I haven't seen him update his VS3 rom in awhile.
@Nicgraner
Sarcastic joke, or are you serious?
I noticed in the note 3 part of the forum a member started a petition to unlock the boot loader. Can someone start one or combine with the note 3 page?
Petitions just turn into complaint threads. I wanted to give this a last shot, so I posted alot of info and plenty of references with the intent that even less experienced s4 users could learn and eventually contribute to helping unlock this bootloader. I also offered some ideas as a starting point. Ive never joined irc's or google talk sessions with others in trying to solve things, I mostly read and learned on my own and im by no means a dev. But I don't think we can unlock this unless we stop complaining and one-uping each other and start working together. I wish that people would stop asking if devs are still trying to unlock this, or being pessimistic about it and start being part of the solution by reading a little and then helping contribute to a solution. All suggestions are welcome. But if you don't know what comprises the "bootloader", learning the flashing order of the partitions at least uptil tz.mbn would benefit you greatly.
P.S.
Just because your not a dev doesn't mean you cant help, most devs are knowledgeable about their devices, but some don't know much beyond how to use android kitchen.
Sent from my XT912 using xda app-developers app
Surge1223 said:
Petitions just turn into complaint threads. I wanted to give this a last shot, so I posted alot of info and plenty of references with the intent that even less experienced s4 users could learn and eventually contribute to helping unlock this bootloader. I also offered some ideas as a starting point. Ive never joined irc's or google talk sessions with others in trying to solve things, I mostly read and learned on my own and im by no means a dev. But I don't think we can unlock this unless we stop complaining and one-uping each other and start working together. I wish that people would stop asking if devs are still trying to unlock this, or being pessimistic about it and start being part of the solution by reading a little and then helping contribute to a solution. All suggestions are welcome. But if you don't know what comprises the "bootloader", learning the flashing order of the partitions at least uptil tz.mbn would benefit you greatly.
P.S.
Just because your not a dev doesn't mean you cant help, most devs are knowledgeable about their devices, but some don't know much beyond how to use android kitchen.
Sent from my XT912 using xda app-developers app
Click to expand...
Click to collapse
On that note, I thank you for developing the OYUAMDK FW. I have not tried it yet just waiting for another guinea pig or at least have a backup device to swap SIMs so that I can have something to use.
Samsung has their first Dev Conference today in San Francisco and hopefully there will be Devs there to get better insight on Samsungs position on ROMs and bootloaders etc...
Awesome analysis Surge, that hellsdroid thread piqued the interest of several devs, including myself. Unfortunately I believe his thread was a bit misleading, which may explain why he closed it. There has been no demonstrated method to boot vulnerable BLs (ie, loki-fiable aboot) once the qfuse has been incremented.
Some of us are looking at the binaries, but no exploit has popped out yet. I did find it interesting they updated SBL1 in the latest OTA, that may be a hint towards something..
jeboo said:
Awesome analysis Surge, that hellsdroid thread piqued the interest of several devs, including myself. Unfortunately I believe his thread was a bit misleading, which may explain why he closed it. There has been no demonstrated method to boot vulnerable BLs (ie, loki-fiable aboot) once the qfuse has been incremented.
Some of us are looking at the binaries, but no exploit has popped out yet. I did find it interesting they updated SBL1 in the latest OTA, that may be a hint towards something..
Click to expand...
Click to collapse
So I just started analyzing my emmc back up (took the entire 16gb mmcblk0 to make sure I didnt miss anything) have you looked through the emmc? I think the modem and apnhlos are more involved in the security checks than we previously thought. Plus these tima, tzapps, and apps.mbn etc files may have contributed to the failure of flashing the mdk aboot on the me7 device you guys were attempting, is there a reason you guys didnt include the mdk modem and apnhlos in your attempt to restore the mdk bootchain? I flashed the dev bootloader with the exception of the dev aboot, boot and recovery using 3 heimdall packages. The first contained the modem, apnhlos and sbl1-3. The second contained rpm and tz, and the third contained boot and recovery (as expected this package failed) the result was my device was now on the dev bootchain with the exception of aboot, boot and recovery and confirmed these results via hexedit. So I think we can rule out sbl3 being the main culprit in checking the fuses when trying to flash a new aboot, also I dont get the "fused 3 binary 1 aboot" failure message when I attempt to flash aboot anymore, just the "secure check fail aboot" message. I definitely think its worth looking into using the dev tz.mbn to find an exploit because I no longer ever see the "samsung custom unlock" boot screen and my device believes its unmodified, and reports its official. My device is so far from unmodified its ridiculous. That means the dev tz.mbn partition I flashed is behaving as if my s4 is a dev edition (see ralekdev's post I linked to in the OP)
Sent from my TouchPad using xda app-developers app
Surge1223 said:
So I just started analyzing my emmc back up (took the entire 16gb mmcblk0 to make sure I didnt miss anything) have you looked through the emmc? I think the modem and apnhlos are more involved in the security checks than we previously thought. Plus these tima, tzapps, and apps.mbn etc files may have contributed to the failure of flashing the mdk aboot on the me7 device you guys were attempting, is there a reason you guys didnt include the mdk modem and apnhlos in your attempt to restore the mdk bootchain? I flashed the dev bootloader with the exception of the dev aboot, boot and recovery using 3 heimdall packages. The first contained the modem, apnhlos and sbl1-3. The second contained rpm and tz, and the third contained boot and recovery (as expected this package failed) the result was my device was now on the dev bootchain with the exception of aboot, boot and recovery and confirmed these results via hexedit. So I think we can rule out sbl3 being the main culprit in checking the fuses when trying to flash a new aboot, also I dont get the "fused 3 binary 1 aboot" failure message when I attempt to flash aboot anymore, just the "secure check fail aboot" message. I definitely think its worth looking into using the dev tz.mbn to find an exploit because I no longer ever see the "samsung custom unlock" boot screen and my device believes its unmodified, and reports its official. My device is so far from unmodified its ridiculous. That means the dev tz.mbn partition I flashed is behaving as if my s4 is a dev edition (see ralekdev's post I linked to in the OP)
Sent from my TouchPad using xda app-developers app
Click to expand...
Click to collapse
So does this mean if I flash your OUYAMDK ODIN image my Dev Ed phone will think its OOB without custom unlock?
Theres a post in that thread where a dev owner achieved those results as well he only flashed a couple partitions, you can get more details there
Sent from my XT912 using xda app-developers app
thread cleaned of selling and or trading and the ensuing discussion.
Use Swappa.com for that.
neh4pres said:
Is it confirmed this is Samsung's doing?
Sent from my SCH-I535 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I've always known Samsung to be like Google when it comes to consumer development. Google supports and encourages the freedom to modify Android, it being open source in the first place. Samsung doesnt mind, themselves; it's carrier security teams that require companies like Samsung to create their own methods of locking down the device for the average user. I'm quite impressed with the Knox bootloader and secure VM app. It may not be done anytime soon, but it can always be cracked. But, the fact that this code is so hard to modify, thanks to carriers, is actually a good thing.
Hey guys I am totally supporting this thread. Unfortunately i have no experience in this kinda stuff or else i would help. Good luck!
Much like most of us. Still out there Surge?
Sent from my SCH-I545 using xda app-developers app
Still here I use tw based roms so my motivation for wanting to unlock this isnt for AOSP or custom kernels. Its just the challenge, that and out of hate for Verizon lol. The Droid X sitting on my desk is a painful reminder of defeat. Cant let them win twice..
Sent from my SCH-I535 using xda app-developers app
Surge1223 said:
Still here I use tw based roms so my motivation for wanting to unlock this isnt for AOSP or custom kernels. Its just the challenge, that and out of hate for Verizon lol. The Droid X sitting on my desk is a painful reminder of defeat. Cant let them win twice..
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
No doubt... can't believe i left my G-Nex for this locked down thing... unfortunately i had to craigslist an upgrade and couldn't snag one of these when they first came out.
i am also in full support of this thread! running stock MJ7 never rooted my phone once, i have taken all the OTAs i'm really crossing my fingers that someone can break this thing so i can finally root and install a stock google rom, i hate TW so much! with all the headache with safestrap and junk on the MI1 i was not wanting to root my device just to have a half assed recovery.
Does it mean anything that my S4 is still showing unlocked and custom? Should it still show that even if it is in fact locked?
I have problem when i try to unpack boot.img from CM10.1.3 Stable version for I9100G.
I tried many time but It say can't find kernel or ramdisk.
Any body help me please?
Anybody help me please???????????????????????
Very few people post here these days, not even the mods seem to be around. If you want help with this, you're either going to have to be really patient (understatement, don't be surprised if you still don't have an answer in a week), or go ask in the CM discussion thread. Your question isn't exactly a 'Hlap mai fone borked ! Odin don't werk !' type query. There aren't many people who post to S2 forums anymore who can answer this type of question.
So you can either sit in this thread & not get the answers you're looking for, or you can be proactive & seek them out.
I tried to worked out with few boot images before. I dont know what is yours
can you upload it please.
If you have windows it will be easy for you to explore that image in hex editor
That what i know so far is. Open your image in hex editor and look for "error" phrase
and you will find several of that 'error' kernel error header error compression error
im my case it is last one before compressed file. You need to recognize magic of
compressed file it is just after 'error'
Ex.
for gzip is: 1F 8B 0B
for LZMA is: 5D 00 00 00 04 FF FF
you can look for that instead 'error' And then you need to cut of everything before
magic number. Make your file start of that magic number. If you do that you will be able to
decompress it. gunzip file.gz or unlzma file.lzma
or you can use your android to find archive in your boot.img
hexdump -C boot.img | grep '1f 0b 08'
and result is
000046b0 72 6f 72 00 1f 8b 08 00 00 00 00 00 02 03 ac bd |ror.............|
ant then you have hex address 46b0 witch is pointing on first byte of that line. Its 72
hex is not easy to count in your memory so we need to convert it to dec value
echo $((16#46b0))
result is
18096 but remember this addres is pointing on 72. We need address of next 4 byte 1f
so we need to count in a memory then. Addres of 1f is 18100
Its easy now. We need to extract archive from boot.img
dd if=boot.img of=archive.gz bs=18100 skip=1
And then decompress it. Thats not all it is just a clue i hope it will work out for you