Free SIM Unlock for SGS2 by Odia. (ONLY for HW Version MP 1.200)
1. Root your phone.
2. Extract your nv_data.bin
3. Look at the file with an hex-editor and goto offset 0x181460 (Ultra Edit, HxD, Hex-Workshop etc)
4. Take the hashes from 0x18146e (20 bytes), 0x18148e, 0x1814ae, 0x1814ce, 0x1814ee
5. If the hash is 7D 3E 17 CF CD 81 6C AC D4 E0 25 FA A6 50 04 FD D1 7D 51 F8 ignore it since that is 00000000
6. Put the hash into the BF exe for example:-
ighashgpu.exe /h:EF63BF26E2382917D96850CCF9632458EE6E6C77 /t:sha1 /c:d /max:8 /min:8 /salt:0000000000000000
and wait for it to finish, do that for each hash which is not zeros, the Found password: [50681318] is the code.
7. Put unaccepted simcard in the phone and when it asks for the unlock code enter them in order
8. Job done, phone is now unlocked for free.
If you cannot find a block which looks like hashes @ 0x181460, then search for SSNV and add 5216, but from the files which I have seen the block appears to be fixed @ 0x181460.
If it will not accept the code which you believe to be correct, it means the attempts have been used up, so you need to use the MCK code to unfreeze your phone, note it will not request unfreeze code, just say network lock unsucessful even your code is valid. (MCK HASH is @ offset 0x180049)
Added an example for what you need to look for.
Mastercode
Dynamic located PERSO section, holds the mastercode (MCK / unfreeze), search for PERSO and look for a hash, can be multiple old sections, added screendump with an example.
MCK HASH is also in the SSNV section @ offset 0x180049
Direct Offsets
GT-I9100
NET 0x18146e -
SUB 0x18148e -
SP 0x1814ae -
CP 0x1814ce -
MCK 0x180049 -
GT-I9000
NET 0x18154b -
SUB 0x18155f -
SP 0x181573 -
CP 0x181587 -
MCK 0x1815af -
If this saved you a few quid, maybe you would like to buy me a beer
View attachment 602403
View attachment 602464
I could not have made this solution and proved my theory without the special help from pulser_g2 and Fall Guy.
I have been advised by pulser_g2 that Chainfire will make a software solution next week using this information.
(APK is here http://forum.xda-developers.com/showthread.php?t=1092451)
Im happy to test for you. Mine is locked, tried tmobile earlier today, and it required a code, im rooted so i can provide anything.
nintendolinky said:
Im happy to test for you. Mine is locked, tried tmobile earlier today, and it required a code, im rooted so i can provide anything.
Click to expand...
Click to collapse
Grab that file from the device and pop me a PM. I presume you know how to get ADB up and running?
OK. Sorta bad news. I can't see a way to retrieve the code itself from the file...
On another note, I DO notice that at address 0x181468, we see the semi-familiar pattern of FF 01 00 00 00 00 ...
On an unlocked phone, that was FF 00 00 00 00 00 (I checked earlier)
This fits in with the information at http://forum.xda-developers.com/showthread.php?t=761045, namely "Change any 0x01 to 0x00 (or 0x00 to 0x01 to lock for warranty)"
That suggests there is a possibility a free unlock could be gained by editing this file. But there would likely be consequences. As such I'm not going to recommend that, nor give instructions for it... If anyone chooses to, they do it 100% at their own risk, and should bear in mind that they NEED a backup of that and the corresponding md5sum first.
But I can't see an unlock code in plaintext
Anyway, that should be food for thought for someone who has a desire to mess about with their device. I won't be trying it for now, and I recommend you don't unless you know what to do to fix this, and are aware you are messing with stuff I don't know much about...
P
pulser_g2 said:
OK. Sorta bad news. I can't see a way to retrieve the code itself from the file...
On another note, I DO notice that at address 0x181468, we see the semi-familiar pattern of FF 01 00 00 00 00 ...
On an unlocked phone, that was FF 00 00 00 00 00 (I checked earlier)
This fits in with the information at http://forum.xda-developers.com/showthread.php?t=761045, namely "Change any 0x01 to 0x00 (or 0x00 to 0x01 to lock for warranty)"
That suggests there is a possibility a free unlock could be gained by editing this file. But there would likely be consequences. As such I'm not going to recommend that, nor give instructions for it... If anyone chooses to, they do it 100% at their own risk, and should bear in mind that they NEED a backup of that and the corresponding md5sum first.
But I can't see an unlock code in plaintext
Anyway, that should be food for thought for someone who has a desire to mess about with their device. I won't be trying it for now, and I recommend you don't unless you know what to do to fix this, and are aware you are messing with stuff I don't know much about...
P
Click to expand...
Click to collapse
Scared are we?
Pretty understandable tbh, I was kinda hoping it was as easy to unlock as the SGS but maybe there is still a way...let's hope so.
Just want to say, hex editing doesnt work. Doesn't detect sim and you get no signal, just put old file back and all works. Looks like we're gonna need another fix.
Quick question, can anyone who has an unlocked device please send me there nv_data.bin.
I want to see if there are any other differences that could be keeping it locked.
dh2311 said:
Just want to say, hex editing doesnt work. Doesn't detect sim and you get no signal, just put old file back and all works. Looks like we're gonna need another fix.
Quick question, can anyone who has an unlocked device please send me there nv_data.bin.
I want to see if there are any other differences that could be keeping it locked.
Click to expand...
Click to collapse
I diffed an unlocked and locked one, and there's a lot of differences at binary level
I would need to ask the guy whose unlocked nv_data I borrowed if he was OK with that, or see if someone else has one...
Also, I did think. Perhaps it "rejects" the file if the MD5 thing doesn't match. If it's a salted MD5, then it could check the md5 of the bin file salted against a "secret" string, and then compare to the contents of the md5sum file...
When I tried putting the old file back i used all the same commands, and it said there was no md5 sum. Which would be expected to be honest. But maybe it requires one. Ill try again this time leave the md5. Doubt it'll work, but its worth ago
EDIT: Faliure again!
Also as a note, cannot be anything to do with the md5 sum, just removed and it still works, so it cannot be checking values against it.
dh2311 said:
Also as a note, cannot be anything to do with the md5 sum, just removed and it still works, so it cannot be checking values against it.
Click to expand...
Click to collapse
OK. So it seems to be checking this file is "valid" somehow then...
pulser_g2 said:
OK. So it seems to be checking this file is "valid" somehow then...
Click to expand...
Click to collapse
is the file size identical? That's a usual standard check for validation.
risq said:
is the file size identical? That's a usual standard check for validation.
Click to expand...
Click to collapse
Should be. We are switching a bit from 0 to 1 - not adding anything
You can have my nv_data.bin if you want... my handset used to be locked to O2 but has been unlocked.
(and I've manually changed the ProductCode by editing nv_data.bin as well, not that that should make a difference)
Let me know, and I'll PM it to you
stuclark said:
You can have my nv_data.bin if you want... my handset used to be locked to O2 but has been unlocked.
(and I've manually changed the ProductCode by editing nv_data.bin as well, not that that should make a difference)
Let me know, and I'll PM it to you
Click to expand...
Click to collapse
Yeah it's worth a shot. Do you have your original file as well? This suggests you managed to edit it fine, and it still worked...
We have tried switching the flag for locked to 0x00, from 0x01, but it didn't work. Would be interesting to see the file though after using a code, to see if the flag is now at 0x00
Really what we might need is a BEFORE and AFTER from an unlock.
ie. anyone getting a code, could you get a dump of this file BEFORE the unlock, then enter the code, and then RE-dump to another file. Call them before and after perhaps? Then we can see what actually happened after the unlock - perhaps a checksum gets re-calculated, or a second "backup" bit was flipped that we missed?
My email, for anyone wanting to send their file (it's only 2 MB so goes fine as an attachment) is (the lines stop OCR gathering it for spam =D)
{
"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"
}
Email on its way
Something tells me it wont be as easy as on the previous Galaxy S. Remember, the Exynos sports an in die crypto engine.
stuclark said:
Email on its way
Click to expand...
Click to collapse
Will look at yours shortly
mathieulh said:
Something tells me it wont be as easy as on the previous Galaxy S. Remember, the Exynos sports an in die crypto engine.
Click to expand...
Click to collapse
Per http://forum.xda-developers.com/showpost.php?p=13526163&postcount=13 it is evidently possible to edit nv_data.bin and have the phone still work...
stuclark said:
Email on its way
Click to expand...
Click to collapse
any chance of emailing me the nv_data aswell?
mathieulh said:
Something tells me it wont be as easy as on the previous Galaxy S. Remember, the Exynos sports an in die crypto engine.
Click to expand...
Click to collapse
Hey Math,
there are I9103-devices with tegra2-chipsets out there. Not sure how different the firmware would be for those but I guess samsung had to find a way to make the one mechanism work for both sgs2-devices...
Related
I'm new to this. Now what? I was trying to remove the TMDNL.Customizations.sa.CAB file like Akira did, but the thing won't let me cut or delete it. Neither will it allow me to edit config.txt, it just says make sure that the program isn't in use or write-protected - WTF?! It wasn't saying that before the update. Any suggestions? I'm using scarybears extended_ROM viewer btw. Is there any program that allows me to edit the registry? Thanks in advace.
get a reg editor like regedit.Mrln_ARM.cab
If you delete the value "MountFlags" (dword:00000001 == 'hidden filesystem') from the key [HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\TRUEFFS_DOC], this 16MByte disk gets mounted as '\Extended_ROM'.
then when connected to active sync
you can delete the files
you can edit the config.txt and just remove the line in case you want the cab file not to be deleted
Exactly where do I get that editor?
I've done that, deleted mount flags and all, and it STILL won't let me edit!
where is this protected rom area?
delete the files from your pc
not through you pda
link to active sync
and cut the files
and past them in a folder on your pc
It's useless for me~
I think the extended rom lock is being applied like the sim lock.
Upgrade OS rom or extended rom will do nothing on the lock.
I only can mount the ms_.nbf in linux, modify the file, and flash it back to the xda2
akira said:
delete the files from your pc
not through you pda
link to active sync
and cut the files
and past them in a folder on your pc
Click to expand...
Click to collapse
Tried that too. Won't work as well mate.
killercheung said:
It's useless for me~
I think the extended rom lock is being applied like the sim lock.
Upgrade OS rom or extended rom will nothing on the lock.
For this case , we only can mount the ms_.nbf in linux, edit the file, and flash it back to the xda2 to modify it
Click to expand...
Click to collapse
How do you do this exactly? I read what you and the other guy talked about in the other thread, but it wasn't too clear for me (I'm not a programmer y'know)
Care to explain it to me more thoroughly? Such as what software do I need? and what steps to take? I'm new to this stuff. It seems like only you and I have this problem y'know...and it sucks.
King said:
Exactly where do I get that editor?
Click to expand...
Click to collapse
Hello
you can download it from this site http://www.phm.lu/Products/PocketPC/RegEdit/
{
"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"
}
regards.
Othman
my guess is that this is how it is protected:
( from http://www.m-sys.com/ )
3.3 FL_IOCTL_WRITE_PROTECT ( == 3002 )
This function enables key-controlled write protection (software protection) for
DiskOnChip. Once DiskOnChip is protected by the key, it remains in read-only
mode. Removing a key can be done by an authorized user who knows the current
key.
The key consists of 8 bytes (64 bits), each of which may be any 8-bit code
character (264 combinations). The key is stored on the flash disk in a manner
that is both scrambled and hidden. That is, the key is encrypted, and it is not
possible to read the flash disk to see the encrypted key. If the key is lost or
forgotten by the authorized user, the flash disk can be restored to read/write
mode by downloading all data from it, reformatting it, and uploading the saved
data. A new key can then be enforced.
The same procedure can also be performed by unauthorized users. In this case
however, the authorized user is able to determine that the key was removed or
changed.
A key-protected DiskOnChip is available to an unauthorized user in read-only
mode. All data may be read, but not written or modified. An authorized user can
write to the flash disk by temporarily disabling the write-protection (unlock)
or permanently removing it (unprotect), depending on the parameters involved.
If the protection is temporarily removed, dismounting DiskOnChip and/or
performing a system reset cause DiskOnChip to revert to read-only mode.
DiskOnChip units are not key-protected by default when shipped by M-Systems.
Note: This protection is not as reliable as the hardware protection supported
by DiskOnChip Millennium Plus and Mobile DiskOnChip.
Input Record
typedef struct {
unsigned char type; /* Type of operation: FL_PROTECT / FL_UNPROTECT / FL_UNLOCK */
long password[2]; /* 8 bytes Key */
} flWriteProtectInput
#define FL_PROTECT 0 - Make the DiskOnChip write-protected.
#define FL_UNPROTECT 1 - Permanently remove the write-protection.
#define FL_UNLOCK 2 - Temporarily remove the write-protection.
Output Record
typedef struct {
FLStatus status;
} flOutputStatusRecord;
hmm, my 1.60 is not write protected.
can anyone with a writeprotected rom_extended dump the first 96k of
the extended rom, and mail with attachment to the forum?
instructions:
*download tool: xda2dmp
* then boot the xda-ii in bootloader mode ( hold power + navigator button while resetting ) , you should see 'serial' on the display.
WARNING: you will lose all data on your device
* then put back the device in the cradle ( now you see 'usb' on the display )
* disable USB connections in the connection settings of activesync
* then run
Code:
xda2dmp -u 0x70000000 0x18000 xtdrom.bin
* if you zip the xtdrom.bin it will be really small no problem to attach it to a posting to this forum
XDA developer Itsme said:
hmm, my 1.60 is not write protected.
can anyone with a writeprotected rom_extended dump the first 96k of
the extended rom, and mail with attachment to the forum?
instructions:
*download tool: xda2dmp
* then boot the xda-ii in bootloader mode ( hold power + navigator button while resetting ) , you should see 'serial' on the display.
WARNING: you will lose all data on your device
* then put back the device in the cradle ( now you see 'usb' on the display )
* disable USB connections in the connection settings of activesync
* then run
Code:
xda2dmp -u 0x70000000 0x18000 xtdrom.bin
* if you zip the xtdrom.bin it will be really small no problem to attach it to a posting to this forum
Click to expand...
Click to collapse
Errr...what's this supposed to do?
figure out where the protection is stored in the extended rom.
I suspect it to be somewhere in the memory range 0x70000000-0x70018000
Damn...is that the only way? Can't I edit the upgraded ROM's executable file then upload it to my PDA again? I can't put it on bootloader mode without removing it from the cradle you see - I don't have the USB connection cable (without the cradle) thing. I'll still have to purchase one in order to put it on bootloader mode if that's the case.
it does not matter if you remove it from the cradle in order to put it in bootloader mode, just put it back afterwards.
the xda2dmp tool can read roms through either usb, or serial port, but I only wrote the usb instructions since I expect more people to have a usb cradle, than a serial cable.
this is the only way I know of to read the hidden part of the chip that the extended rom is on.
Alright. BTW, many thanks for taking the time to help out a newbie
Oh,and there are two dmp files I can download...the cpp one, and the compiled version...which one should I use?
King
u need a compiled version of the file. cpp is source code which u will need to compile before running.
to answer ur other question. u can create a file on ur linux box and flash it to the phone. what xda developers are trying to do is to crack the key to be able to write to the card and skip the flashing step.
alex
XDA developer Itsme said:
hmm, my 1.60 is not write protected.
can anyone with a writeprotected rom_extended dump the first 96k of
the extended rom, and mail with attachment to the forum?
instructions:
*download tool: xda2dmp
* then boot the xda-ii in bootloader mode ( hold power + navigator button while resetting ) , you should see 'serial' on the display.
WARNING: you will lose all data on your device
* then put back the device in the cradle ( now you see 'usb' on the display )
* disable USB connections in the connection settings of activesync
* then run
Code:
xda2dmp -u 0x70000000 0x18000 xtdrom.bin
* if you zip the xtdrom.bin it will be really small no problem to attach it to a posting to this forum
Click to expand...
Click to collapse
thanks.
hmmm, that looks almost like it is in my rom.
and on my xda the extended rom is not write protected.
are you sure your rom is write protected?
if you unhide the extended rom, can you modify /add/remove files from
the folder \Extended_ROM ?
----------------------
my rom:
00008000 "17A3339203052"
00008020 "OK"
00008400 "HT339D326916"
00008420 " Himalayas DIAG V1.01s "
00008440 "OK "
00008460 c2 70 00 00
000084a0 80 70 00 00
your rom:
00008000 "17A4345100264"
00008020 "OK"
00008400 "HT345D312949"
00008420 " Himalayas DIAG V1.03sb3"
00008440 "OK "
00008460 70 38 00 00
000084a0 40 38 00 00
---------------------
I expect to find the hash of the password somewhere, none of these values look like one.
I found out many info after reading other threads about pagepool editing.
Jiggs open my ideas to read and have an info about pagepool editing.
With this site, he discussed it in a simple way:
http://buzzdev.net/read.php?71,31876
How To: Adjust PagePool for the XDA Atom
byJiggs
Tools:
1. Image file of the atom diskimage_Ver.nb0
2. Hex Editor
Instructions:
1. locate the first occurrence of the following hex values:
FF FF FF FF FF FF FF FF 9B 4F FF FF 64 B0 00 00
2. You will see something like this:
{
"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"
}
4MB = 00 00 40 00
6MB = 00 00 60 00
8MB = 00 00 80 00
Our Atom comes with 8MB pagepool, after experimenting though, 4MB is okay, 2MB still works though... It's your choice.
3. Of course, you need to flash back the new ROM to your device.
Very simple instructions and straight forward.
Because of this I thought pagepool editing can be done only by editing NBO FILE and we really need to flash back our atom. Like discussed also in other forum device.
xda-developers > Elf > Elf upgrading etc.
PagePool Smart Changer
http://forum.xda-developers.com/showthread.php?t=326006
xda-developers > Hermes > Hermes upgrading etc.
PagePool Changer
http://forum.xda-developers.com/showthread.php?t=323269.
Now I Found out something, They tried to change pagepool on their device without flashing their ROM & they are succesfull.
xda-developers > Elf > Elf upgrading etc.
Change pagepool size! The EASY way!
http://forum.xda-developers.com/showthread.php?t=324594
vippie said:
Fist of all! All credits go to paradis_pal because he came with this solution for the prophet. I've just edited the offset to make it work for the touch (should work for the wing too as they share the offset)!
Also thanks to Paul from Modaco for his guide to do it manually!
It's now possible to change the pagepool size of a rom (4, 6, 8 and 12 mb) with this tool and just a soft reset afterwards!
I strongly recommend flashing USPL before doing this. It isn't necessary, but if you're device fails to start you want to be able to flash a rom from bootloader!
Steps to take:
- Download and Unpack "Change pagepool size TOUCH.zip"
- Connect your device with activesync!
- Copy EnableRapi.cab to your device and run it
- Make a safety backup using "backup.bat" (takes only a few seconds) and check if there's a file called "backup.nb" afterwards!
- run the bat (takes only a few seconds) with the pagepool size of your choice! (ex: 4mb = 4mb pool.bat)
- Soft reset and enjoy your new pagepool size!
If anything goes wrong you can flash back the old value with restore.bat!
Use at your own risk!
Click to expand...
Click to collapse
xda-developers > Prophet > Prophet mobile 6 >
Change PagePool for WM6 ROM 4.0.0.0 using ActiveSync
http://forum.xda-developers.com/showthread.php?p=1442907#post1442907
paradis_pal said:
if you want to test it then please backup first using backup.bat and restore by restore.bat if you have errors, then softreset
no need to hard reset or install new Rom, just soft rest
please use this at your own risk, don't do it unless you know what it is
first install EnableRapi.cab I'll attach it
in shortcut, this will change the memory for youlike this:
4mb pool.bat will make the total memory 52mb
6mb pool.bat will make the total memory 50mb
8mb pool.bat will make the total memory 48mb
12mb pool.bat will make the total memory 44mb the official.
it will take only few seconds, 1 or 2 seconds
only now softreset no need to hardrest or format
you may backup the old byte by backup.bat and restore by restore.bat
please don't blame me if you do anything wrong
and just wish me best of luck if this works for you as I
copyright to me
Click to expand...
Click to collapse
Im trying now to figure out if we can do this easy way to our ATOM. Im already trying to communicate to the thread and see their opinion.
Jiggs, can we do this in our atom? Just asking bro...thanks a lot
...if we manage to pull this off, COOL! It would save tons of time on testing and reflashing. I hope it can be done.
Also, if there was a way to simply flash a small part of the ROM without forcing a hard reset, I think we'd all love that too. The one thing I miss from the O2 Mini is that I could easily throw in a bootload screen without junking my entire install base.
generalriden said:
I found out many info after reading other threads about pagepool editing.
Jiggs open my ideas to read and have an info about pagepool editing.
With this site, he discussed it in a simple way:
http://buzzdev.net/read.php?71,31876
How To: Adjust PagePool for the XDA Atom
byJiggs
Tools:
1. Image file of the atom diskimage_Ver.nb0
2. Hex Editor
Hi Generalriden,
Did you get my pm re Resco Explorer 2007?
I've read all these, that's why I was asking about the procedure of changing the page pool without re flashing the rom, hoping that we can use it in our atom..It would be taxing to reflash..
Best Regards,
Click to expand...
Click to collapse
I have requested already the developer of the Smart Pagepool Changer. SharkinDark. Unfortunately, it doesn't work on our device yet. Although he said that the device info is already included in his program and should work.
When I use his program, it simply says its CID Locked. I'm not sure how to go about it. CID is new to me. All the while I thought we were CID unlocked because we can flash any ROM anytime.
You can follow the thread I requested from him since September 11, 2007.
http://forum.xda-developers.com/showthread.php?t=326006
I always update using SD Card (256mb) method. So, updating for me only takes 10min max especially when I do a lot of testing. BUT THIS REQUIRES THE EXACT FORMAT FOR SD CARD FLASHING. Renaming diskimage_ver.nb0 to diskimg.nbo IS NOT ENOUGH!
jiggs said:
I have requested already the developer of the Smart Pagepool Changer. SharkinDark. Unfortunately, it doesn't work on our device yet. Although he said that the device info is already included in his program and should work.
When I use his program, it simply says its CID Locked. I'm not sure how to go about it. CID is new to me. All the while I thought we were CID unlocked because we can flash any ROM anytime.
You can follow the thread I requested from him since September 11, 2007.
http://forum.xda-developers.com/showthread.php?t=326006
I always update using SD Card (256mb) method. So, updating for me only takes 10min max especially when I do a lot of testing. BUT THIS REQUIRES THE EXACT FORMAT FOR SD CARD FLASHING. Renaming diskimage_ver.nb0 to diskimg.nbo IS NOT ENOUGH!
Click to expand...
Click to collapse
thanks jiggs...
Hi,
Used hex editor and changed the pagepool frm 4mb to 8mb and flashed . No problem .Though program memory is increased In Setting---> system info shows 4mb pagepool , Can this be changed though it does not matter?
hope sharkindark in the forum mentioned by jiggs help us so we can do the easy way...
chaksu said:
Hi,
Used hex editor and changed the pagepool frm 4mb to 8mb and flashed . No problem .Though program memory is increased In Setting---> system info shows 4mb pagepool , Can this be changed though it does not matter?
Click to expand...
Click to collapse
info found in version.txt. you need to dump it and rebuild rom using mamaich tools.
jiggs said:
I have requested already the developer of the Smart Pagepool Changer. SharkinDark. Unfortunately, it doesn't work on our device yet. Although he said that the device info is already included in his program and should work.
When I use his program, it simply says its CID Locked. I'm not sure how to go about it. CID is new to me. All the while I thought we were CID unlocked because we can flash any ROM anytime.
You can follow the thread I requested from him since September 11, 2007.
http://forum.xda-developers.com/showthread.php?t=326006
I always update using SD Card (256mb) method. So, updating for me only takes 10min max especially when I do a lot of testing. BUT THIS REQUIRES THE EXACT FORMAT FOR SD CARD FLASHING. Renaming diskimage_ver.nb0 to diskimg.nbo IS NOT ENOUGH!
Click to expand...
Click to collapse
i f we can only find out how to unlocked, we can do this...even sharkindark cannot say something regarding this :-(
I cant do it with my exec, hic hic (
OMG i didn't understand anything
scounter said:
I cant do it with my exec, hic hic (
Click to expand...
Click to collapse
you really cant, even us in our atom
We are proud to announce that the Evo 3D is now UNbrickable. Users with the QHSUSB_DLOAD issue can now fully recover their phones and get them fully functional.
{
"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"
}
Note: This will fix only devices which were bricked by turning S ON. And bricks caused by a damaged hboot via interrupted OTA update/RUU flash on a S-ON device. Any devices bricked with other ways are currently *not* supported. We are working on it
The "core" of the unbricking project dev team:
MOVZX
RussianBear
Fuses
Dexter93
Testing stuff and irc support:
globatron
Deceptivechaos
dburgd84
Snake_skw
Other stuff:
dmcb123
xIndirect
Hawke84
Thanks to trevE, xHausx and the rest of the evo3d team that gave us the basic info to work on and made us curious to see if we could get something out of it. Also thanks to ief and his team @revolutionary for helping us understand the bootloaders better. We should also not forget to thank cxb01 of malshenzu.com and xda members arthurire and untrueparadox who helped in translation.
Prerequisites
a linux box/live cd with automount disabled and without unity
the appropriate package for the device
the latest RUU for your device
a device bricked by writing security flag 3 with an unsigned hboot, or caused by a damaged hboot via interrupted OTA update/RUU flash on a S-ON device
a usb cable
some basic linux experience
patience
DISCLAIMER: We do NOT guarantee that this method will work for you, or that it is flawless. We are also not responsible if your phone is completely dead after the procedure, or your house burns down because your phone exploded. You are doing this in YOUR OWN RISK.
Instructions
NEW: Detailed video on the process. Its displaying the process on a Sensation, but its pretty much the same thing. Watch out for partition differences. Thanks to kgs1992
Boot the linux box and download the appropriate package for the device.
WARNING: IT IS DEVICE SPECIFIC. DO NOT USE THE CDMA VERSION ON A GSM EVO AND VICE VERSA. SAME GOES FOR THE INSTRUCTIONS
Extract the package in the home directory
Open up a terminal
Remove SIM, microSD card and battery and connect the device using the USB cable. This procedure must be done without battery
Detect the device using the script provided. Type this in the terminal
Code:
./brickdetect.sh
You should get something like sdX. We are interested on that "X"
Unplug the usb cable from the device
Backup the hboot currently in the phone by using this command. Plug the device in ONLY when asked to
Code:
sudo ./emmc_recover --backup b_hboot.img --device /dev/sdX13
Replace the "X" with the letter the script gave you
Follow the on-screen instructions from emmc_recover
Hexdump the b_hboot to check the hboot version
Code:
hexdump -C b_hboot.img |less
The output should be like this:
Code:
00000000 05 00 00 00 03 00 00 00 00 00 00 00 00 00 10 40 |[email protected]|
00000010 d8 fc 0f 00 d8 fb 0f 00 d8 fb 1f 40 00 01 00 00 |[email protected]|
00000020 d8 fc 1f 40 00 00 00 00 1a 00 00 ea 31 2e 34 30 |[email protected]|
00000030 2e 30 30 30 30 00 00 00 38 32 36 30 20 53 50 4c |.1100...8260 SPL|
00000040 00 00 00 00 00 f0 20 e3 53 48 49 50 00 00 00 00 |...... .SHIP....|
00000050 00 f0 20 e3 00 f0 20 e3 48 42 4f 4f 54 2d 38 32 |.. ... .HBOOT-82|
00000060 36 30 00 00 00 f0 20 e3 62 62 35 35 33 39 32 62 |60.... .bb55392b|
This is the typical hex of a hboot. We are interested to check if that is the hboot partition and if it is, to get to know the version. In this case it is 1.40
If in the above step you failed to identify the hboot, unplug all devices connected to that pc, reboot and try again
Unplug the device
Check again it is the right version, because if you do a mistake here, you won't be able to go back
You can only flash the same version as the one in the device.
!!!!!DO NOT ATTEMPT TO FLASH ANOTHER VERSION OR DOWNGRADE!!!IT HAS BEEN PROVEN FATAL!!!!
Flash the hboot on the device. Replace "V.VV" with hboot version (eg. 1.30, 1.40, 1.50) and "X" with the one you got from the detect script. Plug the device in ONLY when asked to
Code:
sudo ./emmc_recover --flash shooterV.VV.nb0 --device /dev/sdX13 --backupafter hboot_f.nb0
Follow the on-screen instructions from emmc_recover. A successful flash should have this output:
Code:
511+1 records in
511+1 records out
1047808 bytes(1.0 MB) copied
Unplug the device, put microSD card and battery in and power on
Congratulations, the device is unbricked.
FLASH THE RUU IMMEDIATELY AFTER RECOVERING!! The device will be unstable after the recovery if you don't flash it.
Notes on the procedure:
If the device doesn't power on, get a copy of the hboot_f.nb0 and b_hboot.img (should be located in the home directory) and contact us
The connection between the device and the pc will be unstable, and will time out. You have to be quick when doing the above, specially while flashing. If the connection times out don't panic, just unplug and replug the device
Unity and automount are known to cause issues in ubuntu 11.04 and 11.10. We recommend getting rid of both, or use a 12.04, or 10.04/.10 liveCD
USB3 ports do not work properly. Please plug the device in a USB2 port
How to disable automount on ubuntu
Code:
gsettings set org.gnome.desktop.media-handling automount false
Downloads
For EVO 3D CDMA( Shooter):
32bit version MD5: 5f49aff0347b7b839f666f590bfb3f76
64bit version MD5: e9087359552b622cf07cb5d67adb991b
Don't have a linux distro installed on your pc? We highly recommend this livecd
!Luke
Sent from my Galaxy Nexus using Tapatalk 2
nice!
Looking forward to this!
What is this for?
If you follow their instructions you can make your 3d unbrickable. Meaning you can flash whatever including a gsm rom in your cdma and be able to recover from it. Definitely excited dexter thanks
Sent from my SPH-D710 using Tapatalk 2
This sounds awesome... Will make it safer to follow the downgrade guide for hboot 1.5 users, meaning if they true brick, they can recover...
sent from my downgraded hboot 1.50 3vo running ZR3D injected with anthrax... s-off HTC, thanks to the real developers, I now have control of my device again
I <3 anticipation threads..
myn said:
I <3 anticipation threads..
Click to expand...
Click to collapse
/me starts myn ICS anticipation thread..
to this post:
:O whaaaaaaat that's awesome
Sent from my PG86100 using xda premium
Unbrickable? Shut the front door!
Works great!
Astronomical dev work. Hats off truly to all involved. I'll be picking up another 3d as well and this just gives me more incentive.
#Root-Hack_Mod*Always\
Amazing work with all parties involved. Thanks again for all the hard work and dedication.
Sent from my PG86100 using xda premium
luis4ever said:
What is this for?
Click to expand...
Click to collapse
ru joking??? lolz
Funny how they have disclaimers. The phones already bircked is it possiable to have an ultra bricked device?
Sent from my PG86100 using Tapatalk
Where was this a few months ago?! Hehe.
Great work to all those involved!
Sent from my PG86100 using Tapatalk 2
dexter93 said:
We are proud to announce that the Evo 3D is now UNbrickable. Users with the QHSUSB_DLOAD issue can now fully recover their phones and get them fully functional.
Note: This will fix only devices which were bricked by turning S ON. And bricks caused by a damaged hboot via interrupted OTA update/RUU flash on a S-ON device. Any devices bricked with other ways are currently *not* supported. We are working on it
The "core" of the unbricking project dev team:
MOVZX
RussianBear
Fuses
Dexter93
Testing stuff and irc support:
globatron
Deceptivechaos
dburgd84
Snake_skw
Other stuff:
dmcb123
xIndirect
Hawke84
Thanks to trevE, xHausx and the rest of the evo3d team that gave us the basic info to work on and made us curious to see if we could get something out of it. Also thanks to ief and his team @revolutionary for helping us understand the bootloaders better. We should also not forget to thank cxb01 of malshenzu.com and xda members arthurire and untrueparadox who helped in translation.
Click to expand...
Click to collapse
Nice to Finally see the goings ons of unbricking, however any chance of this at some point becoming an unbrickable mod
sweeeeeeeet thanks guys will bookmark this. Though I am a very paranoid tester so I doubt I will ever brick my device
ok, I've had some pms about this. Maybe I didnt stress it enough in my sig, but I cannot give support by pm. I simply can't respond to all of them. Please post here so that if someone faces the same issue , will have the answer
Thanks guys
Hi devs,
hoping on help of people who better know about this materia than me, I hope to create a workaround for OTA repair on faulty Iconia B1-A71 from Acer.
In this case we need devs who has knowledge about stock JB and also testers, who has a B1 with problems on installing OTA Updates with "Invalid partition settings" on FAT.
Status:
More and more user of B1 report the problem of updating their device by OTA. It appears to be a mass problem, which Acer has no solution for.
After checking on rooting issues we already know, that there is a difference in dumchar_info between "normal" and "faulty" B1´s:
Android Partition:
http://forum.xda-developers.com/showpost.php?p=40987372&postcount=197
Normal - android 0x0000000026500000 0x00000000020e8000 2 /dev/block/mmcblk0p3
Faulty - android 0x0000000015e00000 0x00000000020e8000 2 /dev/block/mmcblk0p3
Furthermore there is a difference (and this I assume is the problem for OTA routines) on FAT partition:
Normal - fat 0x0000000148638000 0x00000000882e8000 2 /dev/block/mmcblk0p6
Faulty - fat 0x00000001b0a38000 0x00000000232e8000 2 /dev/block/mmcblk0p6
Those who was in charge of rooting the B1 knows, that we have dumped the android partition by dd using the offset shown in dumchar_info.
In this logic it would be impossible to dump a faulty B1 system.img by using the normal offests - you would not "meet the partition/bits", if you use wrong data.
BUT - as we found out it was possible to dump the system.img from a faulty B1 using the offset of a normal B1! User agentdeep confirms a successful root from scratch on Linux base using the normal offsets: http://forum.xda-developers.com/showpost.php?p=40988791&postcount=202
Now my idea:
- According entonjackson pawitp already assume, that the dumchar_info may be wrong, since otherwise agentdeep would have a bricked device. IF we can proof that OTA checks this value - would it make sense to push a corrected dumchar_info through the ENGMODE backdoor? Anyone out there, who is able to save and extract the OTA, to see the routine?
- If it dont work, does it make sense to try a root from scratch on Linux - and fix the dumchar_info afterwards? Is it possible?
- How can I check a report of existing partitions on Android? Do I have to run busybox from terminal, to start fdisk? I would like to validate the partition information inside the dumchar_info...
This subject may be not as hot as a rooting thread - but more and more user report their problem with update errors, and we may help lots of them ... and show Acer, how this work has to be done...
Thank you in advance!
Sub.
I would like to try that procedure enton asked me by replacing 15e to 265 in dumchar_info. But knowing there is no way I can restore my nandroid backup if something bad happens, I will hold for now
Nice to meet you here, agentdeep I was hoping you will join this thread, since you are the one who made me thinking about this solution...
From my point of view the risk of bricking the tab after changing the dumchar_info is ... pretty low. As long as we have a working system you still can switch back to your origin value. But at that point I would also like to get some more background from the Linux masters in here. Currently I have a problem to understand about the dumchar_info - what is it? How it is created? Do I understand right, that it is an output from Linux kernel?
When this file is accessed? On boot? Which result we will have, if we change it? Is it a properties file, used to set up partitions - or just an info? IF it is only an information we can change it without any fear...
https://github.com/ameer1234567890/...To-Gather-Information-About-Partition-Layouts
This page gives us the information, that "fat" is not just the format - it is the internal memory on MTK based devices. Which finally gives me more inscentive to believe that we have an issue with 8gb and 16gb versions. On that I have seen a thread in a different forum, where a user reported to have opened the B1 and found out that there were 16gb internal memory instead of 8gb as shown in the device properties.
Probably we have "masked" 16gb-versions declared as 8gb???
alba81 said:
Nice to meet you here, agentdeep I was hoping you will join this thread, since you are the one who made me thinking about this solution...
From my point of view the risk of bricking the tab after changing the dumchar_info is ... pretty low. As long as we have a working system you still can switch back to your origin value. But at that point I would also like to get some more background from the Linux masters in here. Currently I have a problem to understand about the dumchar_info - what is it? How it is created? Do I understand right, that it is an output from Linux kernel?
When this file is accessed? On boot? Which result we will have, if we change it? Is it a properties file, used to set up partitions - or just an info? IF it is only an information we can change it without any fear...
Click to expand...
Click to collapse
1st, thanks for the thread! It's really been time to create one for this issue.
I will put a link on the 1st post of my thread to this one, for people experiencing this issue.
Regarding agentdeep, I also think changing the dumchar_info won't brick the device. But we should first make sure it won't brick.
Although I'm using Linux for like 10 years now, I cannot help a lot at this moment.
But if there will be a solution, I will put it immediatly into my toolkit
So, I made a small calculation for the offsets, and this seems to confirm a wrong information in the dumchar_info:
Normal B1 Offset Android size:
Hex: 26500 Dez: 156928 Multiplied with 4096=642777088 Divided by 1024 = 627.712kB
Faulty B1 Offset Android size:
Hex: 15e00 Dez: 89600 Multiplied with 4096=367001600 Divided by 1024 = 358.400kB
If you take into consideration, that the system.img.gz takes (in packed form!) about 350 MB, unpacked even 627,712kB (size of the parition, see above) - then it appears that the information MUST be wrong - if I am right with my calculation...
Following this we have these values for internal memory on both versions:
Normal B1 Offset FAT size:
Hex: 148638 Dez: 1345080 Multiplied with 4096=5509447680 Divided by 1024 = 5.380.320kB
Faulty B1 Offset FAT size:
Hex: 1b0a38 Dez: 1772088 Multiplied with 4096=7258472448 Divided by 1024 = 7.088.352kB
Anyone with 15e can check available space on internal memory? In fact it should be about 5GB as I remember (have the B1 not with me now).
Maybe I am writing complete bull**** here? Anyone can confirm my calculation..??
Thanks in advance!
alba81 said:
So, I made a small calculation for the offsets, and this seems to confirm a wrong information in the dumchar_info:
Normal B1 Offset Android size:
Hex: 26500 Dez: 156928 Multiplied with 4096=642777088 Divided by 1024 = 627.712kB
Faulty B1 Offset Android size:
Hex: 15e00 Dez: 89600 Multiplied with 4096=367001600 Divided by 1024 = 358.400kB
If you take into consideration, that the system.img.gz takes (in packed form!) about 350 MB, unpacked even 627,712kB (size of the parition, see above) - then it appears that the information MUST be wrong - if I am right with my calculation...
Following this we have these values for internal memory on both versions:
Normal B1 Offset FAT size:
Hex: 148638 Dez: 1345080 Multiplied with 4096=5509447680 Divided by 1024 = 5.380.320kB
Faulty B1 Offset FAT size:
Hex: 1b0a38 Dez: 1772088 Multiplied with 4096=7258472448 Divided by 1024 = 7.088.352kB
Anyone with 15e can check available space on internal memory? In fact it should be about 5GB as I remember (have the B1 not with me now).
Maybe I am writing complete bull**** here? Anyone can confirm my calculation..??
Thanks in advance!
Click to expand...
Click to collapse
Yeah internal space is 5.12 GB like posted here in bullbrands post:
{
"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"
}
Note: this is after swapping internald and external sd...
The calculation looks good, but i don't know why the f... you multiply with 4096 and divide by 1024... I'm working as a developer and now I really feel stupid, because I really just don't know.
entonjackson said:
The calculation looks good, but i don't know why the f... you multiply with 4096 and divide by 1024... I'm working as a developer and now I really feel stupid, because I really just don't know.
Click to expand...
Click to collapse
Dont worry I could explain as follows: 4096 is the qty of bits you write at once on dd, and 1024 - logically to convert bits to KB.
Well, so we see that nothing is right in the dumchar_info, at least on Android and FAT partition, on faulty B1´s. Now we know there is a mistake - and need to validate the right offsets. Anyone has experience with fdisk on Android? Do I have to run it from busybox from terminal emulator?
And can anyone experienced tell us the specifications of dumchar_info? I found out it is a MTK-own chart, which is not existing on other CPU based devices .... which means for me - it can not be that critical in regards to format table, right?
On a rooted device - can we use a log to see when the dumchar_info is triggered?
alba81 said:
Dont worry I could explain as follows: 4096 is the qty of bits you write at once on dd, and 1024 - logically to convert bits to KB.
Well, so we see that nothing is right in the dumchar_info, at least on Android and FAT partition, on faulty B1´s. Now we know there is a mistake - and need to validate the right offsets. Anyone has experience with fdisk on Android? Do I have to run it from busybox from terminal emulator?
And can anyone experienced tell us the specifications of dumchar_info? I found out it is a MTK-own chart, which is not existing on other CPU based devices .... which means for me - it can not be that critical in regards to format table, right?
On a rooted device - can we use a log to see when the dumchar_info is triggered?
Click to expand...
Click to collapse
Ah I see. very easy. so bs=4096 is blocksize and well ok 1024 I already guessed could be convertion from bits to bytes. alright.
Then I would say, yes. the calculation makes sense indeed.
Now we only need someone that tries to write the right parition info into dumchar_info.
volunteers hands up! :victory:
entonjackson said:
Now we only need someone that tries to write the right parition info into dumchar_info.
volunteers hands up! :victory:
Click to expand...
Click to collapse
The biggest problem on that point is - you need to have either root, or do it by obtaining "temporary backdoor root" through ENGMODE. And the qty of user having root on faulty B1 is still pretty low...
alba81 said:
The biggest problem on that point is - you need to have either root, or do it by obtaining "temporary backdoor root" through ENGMODE. And the qty of user having root on faulty B1 is still pretty low...
Click to expand...
Click to collapse
i know busybox has fdisk binary.
adb doesn't know fdisk?
Where can I call it thru ADB?
Starting busybox from internal memory thru Terminal Emulator also makes me problems ... permission denied.
alba81 said:
Where can I call it thru ADB?
Starting busybox from internal memory thru Terminal Emulator also makes me problems ... permission denied.
Click to expand...
Click to collapse
There is none. I thought fdisk comes with adb, but... no.
But maybe we need no fdisk. If i understood it right, wie only must edit the dumchar_info so the system "believes" it has the right partitions again.
Yes, obviosly the update process checks this value. As you already checked the /proc/emmc shows different values, and /proc/mtd is empty. /proc/partitions contain different information type.
Before changing an important value I think we need to validate that any change in dumchar_info remains after reboot, since the update failure notification appears in recovery mode during update - right?
Edit:
I do not get access to dumchar_info. Going through ES File Manager I set the properties, and even it shows after changing its saved - its not. How can I get the rights? And how I can take the rights for system away to not be able to access it any more? Each time I open the properties of it I see a different date ... is it in permanent access?? Or do I need a different file Explorer?
Edit2:
Wikipedia is my friend. Ok, now I know - dumchar_info is a procfs, generated by the kernel during boot and not saved. So I am affraid ... we are stuck on a faulty kernel issue?
Where does the kernel gain this Information from during boot? Anybody an idea?
I hope this helps
agentdeep said:
I hope this helps
Click to expand...
Click to collapse
Thank you - I will validate later on, once I am at home ... have now only my n8000 with me.
Ok, checked - my version is the same, except:
[email protected] (after Linux version 3.4.0)
which I think can not be that important, since all other release data is similar. So it is not the kernel we have to fight with - at least...
Ok, so following on this subject we need to see what comes up in the future:
http://forum.xda-developers.com/showpost.php?p=41168837&postcount=295
At least the reason seems to be confirmed from Acer site - a faulty format which is reported.
IMHO it can not be only the update with the problem, the device itself reports a different format in dumchar_info, not the update.
Well - we´ll stay tuned...
hi there,
i have a faulty B1 with root....also i tried the Factory Reset Workaround several times, it does not work for me....everytime about 10-15% i got the message "partition error...bla".
So if you want me to to test things...go on
I'm new here, however I successfully rooted my device using the "toolkit" even though I have
Code:
Faulty - android 0x0000000015e00000 0x00000000020e8000 2 /dev/block/mmcblk0p3
Thanks to Enton.
My internal storage is reported to be just 5.17GB (not 8GB as expected) confirming the figures in a previous post.
I complained to acer support about the size of the internal storage being nearly 3GB short of what it should be and that I thought it was down to a "memory allocation error".
There response was " As you have mentioned in the previous e-mail internal storage shows as a 5.17GB, I would like to inform you that the other space of the unit is occupied by Android Operating System, customer will not be able to use the complete 8GB from the unit, as Operating system needs a space. "
Is this complete and utter BS? I understand 4.1.2 Jelly Bean is just over 200MB.
Can someone please confirm.
BTW if any dumps are required from my "faulty" device (I do not have the partition error though) I'm happy to try.
BTW2 I've installed the new PMTUpdate patch "FixG1PMT" and that did nothing for my problem.
Please note that this has only been testing on MTCB Head units.
As with all mods, do so at your own risk. I take no responsibility if you brick your unit.
The instructions set out below work for me and I have done been successfully using this method for over a year now.
The unit I testing it on was an Xtrons TD696a RK3188 800x480.
I have determined that this process works on Malaysk 4.4.4 roms up to about March, the same with booroondook roms. As far as I can make out it works with all 5.1 custom roms
I haven't testing much on stock firmwares but I see no reason why it won't work with all of them.
If you follow the steps correctly the worst that can happen is that it will load with your custom boot logo once then revert back to the original without causing any harm to your unit.
Tool required
gimp - https://www.gimp.org/
HxD - https://mh-nexus.de/en/programs.php
RK3xxx firmware tools by SergioPoverony - http://vondroid.com/threads/rk3xxx-firmware-tools-by-sergiopoverony.14718/#post-44489
Terminal Emulator - http://www.apkmirror.com/apk/jack-palevich/terminal-emulator/terminal-emulator-1-0-70-release/terminal-emulator-1-0-70-android-apk-download/
The guide is split into 4 sections.
1. Modifying kernel to determine image size
2. Making the image
3. Importing image to kernel
4. Installing kernel to system
5. Modifying kernel.img inside backup.img
I think I have covered everything but no doubt as time goes on things will be changed or added.
I stress again As with all mods, do so at your own risk. I take no responsibility if you brick your unit.
Modifying Kernel to determine image size.
1. Using RK3xxx decompile the update.img you are using or going to use. Click "Select Img" then browse for your update.img.
{
"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"
}
1a. Then Click Extract.
2. Click on "Logo tools" then "Run logo Changer" (A new window will open).
3. Click on "File" then "Select kernel.ing" and browse for the kernel (it will be in temp/Android/Image).
4. If the kernel boot logo loads you should see an image in the right hand box
And in the box below you should see something like:
Code:
KernelPass:rkdroid
Kernel image size: 800 * 480
Supported Image Size: 800 * 480
If you see an image you are sooooooo lucky and can skip to Making the image section.
If the kernel boot logo doesn't load you will see no image and also in the box below something like this:
Code:
KernelPass:rkdroid
ÃÜÂë´íÎó!
ÔØÈëkernelʧ°Ü
5. Open Hxd and open kernel.img (click "File" then "Open" and browse for the kernel.img).
5a. Click "Search" then "Find" and search for "rk logo password" (don't include the quotation marks "") and make sure Datatype is set to "Text-string".
5b. In the last column (furthest right) highlight between the 1st character
after "password" and before the 1st character of "rk29_backlight" (you will see that the middle section has now been highlighted as well, a total of 44 pairs of characters).
Here's where it gets a bit complicated.
5c. In the middle section take a note of the 1st set of characters and last set. In the above picture they are 93 and C0.
Left click somewhere above to clear all the highlighted code.
5d. Now in the middle section highlight everything from the 1st pair and last pair. (the 2 pairs you took a note of above). You should have 44 pairs of characters highlighted now.
5e. Right mouse click and copy then left click somewhere above again to clear any highlighted characters.
5f. Click on "Search" then "Replace", change Datatype to "Hex-values" and in the 1st box (search for) right mouse click and paste. It should have pasted the 44 pairs of characters.
5g. Copy the below set of codes and paste into the 2nd box (Replace with).
Code:
31 57 8D EB 18 4B A9 41 D9 47 EA 2F 7E 60 B1 67 6C 6F 67 6F 2E 6E 6F 6C 6F 67 6F 00 00 00 00 00 FC F3 AC C0 60 BD AB C0 C8 42 AD C0
Then click "OK".
If the changes were successful the values in the centre and right hand columns will have changed to red.
Double check that the values in the centre column match:
Code:
31 57 8D EB 18 4B A9 41 D9 47 EA 2F 7E 60 B1 67 6C 6F 67 6F 2E 6E 6F 6C 6F 67 6F 00 00 00 00 00 FC F3 AC C0 60 BD AB C0 C8 42 AD C0
5h. Save and exit HxD. (A backup of the original kernel.img has been made if you balls it up at any point).
6. Open RK3xxx again. Click on "Logo tools" then "Run Logo Changer" (a new window will open).
7. Select "File" then "Select kernel.img". Locate the kernel you have just modified.
If you did everything correct in HxD your image should load in the right hand box.
You should also see:
Code:
KernelPass:rkdroid
Kernel image size: 800 * 480
Supported Image Size: 800 * 480
or
Code:
KernelPass:rkdroid
Kernel image size: 1024 * 600
Supported Image Size: 1024 * 600
Image size is very important before you can continue. I have found that some kernels although from a 1024x600 unit have a 800x480 boot logo and visa versa.
If after doing the steps above you find that is the case. You MUST use the image size stated (Supported Image Size even though it doesn't match your unit resolution.
You have been warned.
That is pretty much the hardest section. You can now go to Making the image.
Making the image
1. Now that you have established the image size make sure the image you intend to use for a boot logo is the exact same resolution.
2. Open Gimp and open the image you want to use as a boot logo.
2b. Click on "Image", "Mode", "Indexed".
2c. Set Maximum number of colours to 224 (very important). Then click "Convert".
If you find that the quality of the image isn't as good play around with the colour dithering settings
but never change the Maximum number of colours from 224.
2d. Click on "File" then "Export as".
2e. Click on "Select File Type (By Extension).
2f. Scroll down and select "PPM Image" then "Export"
2g. Data formatting select "ASCII" (Very Important), then "Export"
Getting easier, isn't it . Off to Importing image to kernel.
Importing image to kernel
1. Using RK3xxx click on "Logo tools", then "Run Logo Changer"
2. Click "File" then "Select kernel.img" and load the kernel.img you modified earlier.
3. Click on "File" then select "PNM logo image" and load the PPM image you created in Gimp.
4. If both loaded ok
Simply click on "Replace" and the image in the right side box should change to your custom logo. Click "Exit"
Forgot to take a screenshot of it but it will move the image in the left box over to the right.
And that my pedigree chums is your kernel.img ready to be installed on your unit.
Last but not least . Installing kernel to system.
Installing kernel to system
There is a difference between kitkat and lollipop so please make sure you follow the correct instructions.
1. Copy kernel.img to external_sd.
2. Open terminal emulator.
3a. If you are using Kitkat Android 4.4.4.
Type the following. Make sure to press enter between each line:
Code:
su
cd /mnt/external_sd
dd if=kernel.img of=/dev/block/mtd/by-name/kernel
3b. If you are using Lollipop Android 5.1.
Type the following. Making sure to hit enter between each line:
Code:
su
cd /mnt/external_sd
dd if=kernel.img of=/dev/block/platform/emmc/by-name/kernel
Regardless of which one you use, you should get a few lines of confirmation. Forgot to take another screenshot but it should look something like this:
Code:
12345+1 records in
12345+1 records out
12345 bytes transferred in 0.198 secs
If it failed then it will look something like this:
Code:
12345+0 records in
12345+0 records out
12345 bytes transferred in 0.198 secs
Fingers crossed that you have the 1st output result.
You can simply type "Reboot" in terminal emulator and it will reboot the system and again, fingers crossed you will see your nice new boot logo.
I have taken a lot of time and effort to put this guide together. I know it's not perfect but I hope it helps :good:
GREAT
Example Boot Logos for Head Units
New Boot Logos on Request! Be sure, that you use the correct resolution! All files are optimized to PPM format. So you can skip Step 2 "making the image"! All downloads are direct downloads from my server!
TOYOTA
DOWNLOAD 1024x600
VAUXHALL
DOWNLOAD 1024x600
VAUXHALL ASTRA
DOWNLOAD 1024x600
Will this work with "Update_4_4_4_FUSE_800X480_RK3066_40_MAL_12_06_2016_FIX_RADIO_MTCB" - Last modified 26-Jun-2016?
Thanks
cat2115 said:
Will this work with "Update_4_4_4_FUSE_800X480_RK3066_40_MAL_12_06_2016_FIX_RADIO_MTCB" - Last modified 26-Jun-2016?
Thanks
Click to expand...
Click to collapse
Read the OP
I have determined that this process works on Malaysk 4.4.4 roms up to about March, the same with booroondook roms. As far as I can make out it works with all 5.1 custom roms
I haven't testing much on stock firmwares but I see no reason why it won't work with all of them.
Click to expand...
Click to collapse
MTCD not MTCB work ?
Hello and thank you for your work.
I can use them on bootlogo MTCD not MTCB?
If so how to do it please? The basic procedure does not.
Thanks a lot.
Goodbye
zoxenrbg said:
Hello and thank you for your work.
I can use them on bootlogo MTCD not MTCB?
If so how to do it please? The basic procedure does not.
Thanks a lot.
Goodbye
Click to expand...
Click to collapse
I think I did say in the OP that it was only tested on MTCB units. I don't know what the differences are between the 2 so I really can't comment or give you advice on MTCD units.
I use an 5.1.1 RK3188 China directly.
MCU GS 1.6...
MTCD. I help you ?
Tell me what I have to tell you please do and how to put the logo annimé (I can not find procedure).
Thanks for your help !
Jaihoidundso said:
Example Boot Logos for Head Units
New Boot Logos on Request! Be sure, that you use the correct resolution! All files are optimized to PPM format. So you can skip Step 2 "making the image"! All downloads are direct downloads from my server!
VAUXHALL
DOWNLOAD 1024x600
VAUXHALL ASTRA
DOWNLOAD 1024x600
Click to expand...
Click to collapse
Hey man! I would really appreciate it if you could make a Toyota boot logo for me please? Thank you so mcuh!
jacobreed222 said:
Hey man! I would really appreciate it if you could make a Toyota boot logo for me please? Thank you so mcuh!
Click to expand...
Click to collapse
I believe this was meant so anyone could change the 1st boot logo. It is very simple as I have finished mine a couple hours ago. This post is not a request for logo but for a user make his/her own. Follow the OP procedures and you will not have any issues. This is my first time to extract anything from a ROM and change something and make it work.
bsavoir22 said:
I believe this was meant so anyone could change the 1st boot logo. It is very simple as I have finished mine a couple hours ago. This post is not a request for logo but for a user make his/her own. Follow the OP procedures and you will not have any issues. This is my first time to extract anything from a ROM and change something and make it work.
Click to expand...
Click to collapse
It's the 1st time I've written a guide so how did it go for you following the procedure?
Goose247 said:
It's the 1st time I've written a guide so how did it go for you following the procedure?
Click to expand...
Click to collapse
It was pretty straight forward. The steps were easy to follow and I had no issues with the guide. The only issue i had was with GIMP and resizing my image, for some reason i only got it to 800x500, but after playing around with it i found that I had already created and save a 800x480 resolution copy.
jacobreed222 said:
Hey man! I would really appreciate it if you could make a Toyota boot logo for me please? Thank you so mcuh!
Click to expand...
Click to collapse
Which resolution do you have?
Jaihoidundso said:
Which resolution do you have?
Click to expand...
Click to collapse
I have the JOYING 1024x600
jacobreed222 said:
I have the JOYING 1024x600
Click to expand...
Click to collapse
You can find your image here: http://forum.xda-developers.com/showpost.php?p=68535050&postcount=7 #7
Jaihoidundso said:
You can find your image here: http://forum.xda-developers.com/showpost.php?p=68535050&postcount=7 #7
Click to expand...
Click to collapse
Thank you so much man!