Related
Hallo,
I want to tune up my german mda2's extended rom also.
But i can't . It's read only!
Can't delete,write,rename.
I only can make it visible thats it.
Please help!
Edit:
It seems that the disk on chip (doc) can be write protect by software.
Look here:
http://www.spezial.ru/products/producer/msystems/pdf/App_Note_011.pdf
There is an entry in the windows registry called TrueFFS.
(True Flash File System).You have too search the registry for trueffs.dll
I would be interested for some dwords values from other people whos rom is not protected.
For instance the key "Ioctl" has an value of 4 in my mda2.
This is my TRUEFFS Registry Area:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\TrueFFS]
"Profile"="TRUEFFS_DOC"
"Index"=dword:00000001
"Dll"="TrueFFS.dll"
"Prefix"="DSK"
"Order"=dword:00000000
"Ioctl"=dword:00000004
"WindowBase"=dword:04000000
"DeviceArrayIndex"=dword:00000000
"IClass" =hex(7):7B,00,41,00,34,00,45,00,37,00,45,00,44,00,
44,00,41,00,2D,00,45,00,35,\
00,37,00,35,00,2D,00,34,00,32,00,35,00,32,00,2D,00
,39,00,44,00,36,00,42,00,\
2D,00,34,00,31,00,39,00,35,00,44,00,34,00,38,00,42
,00,42,00,38,00,36,00,35,\
00,7D,00,00,00,00,00
Deckard
I have the same problem, after I used the Extended ROM unlocking tools I can unhide and see the contain of the Extended ROM, when I tried to unlock, it showed me a debug popup window and the content is 'ERROR: FL_IOCTL_BDTL_HW_PROTECTION' , the ROM cannot be unlocked for adding or deleting ?? !!
Anyone can help ??
Hello,
Anyone interested in porting linux to HTC Hermes? The Samsung processor is currently supported by vanilla 2.6 kernel
I tried running GNU HaRET 2006070419 version, here's the output of some commands:
Code:
# telnet 192.168.1.23 9999
Trying 192.168.1.23...
Connected to 192.168.1.23.
Escape character is '^]'.
Welcome, this is GNU/HaRET running on WindowsCE v5.1
PocketPC
HERM200
Minimal virtual address: 00010000, maximal virtual address: 7fffffff
CPU is ARM ARM arch 4T stepping 0 running in system mode
Enter 'HELP' for a short command summary.
-----------------
FB1: form=1 bpp=16 fbaddr=4E800000/10800000 x=240/2 y=320/480
FB0: form=160 bpp=16 fbaddr=4E800000/10800000 x=240/480 y=320/480
HaRET(1)# dump wince
Wince information
curr_perm: 00010001, memdiv: rdisk= 64 ram= 12493 pagesize= 4096
memdiv1: rdisk= 64 of 14612 ram= 12493 of 12493
memdiv2: 3 rdisk= 64 of 14612 ram= 12493 of 12493
OEMINFO: ncha=9
OEMINFO: HERM200
OEMINFO: HERM200
PLATFORMTYPE: PocketPC
PLATFORMTYPE: PocketPC
machine_id:0
audio_innum=1, audio_outnum=1
32snapshot failed
I don't think the Samsung SC32442A-400MHz processor is supported by this version of HaRET, but I found a page in russian where there is a version of HaRET for s3c2442 processors available!!
Here is some interesting output of this haret version:
Code:
# telnet 192.168.1.23 9999
Trying 192.168.1.23...
Connected to 192.168.1.23.
Escape character is '^]'.
Welcome, this is HaRET running on WindowsCE v5.1
Minimal virtual address: 00010000, maximal virtual address: 7fffffff
CPU is ARM ARM arch 4T stepping 0 running in system mode
Enter 'HELP' for a short command summary.
HaRET(1)# cpudetect
Warning: Detected CPU family: S3C24XX
HaRET(2)# cpuwgpio 1
Warning: Ready to watch s3c24xx GPIO
f0004 - GPA: 1
f0014 - GPB: 4e
f0024 - GPC: 3621
f0034 - GPD: 0
f0044 - GPE: f7e8
f0054 - GPF: d3
f0064 - GPG: 24be
f0074 - GPH: 7f
f00d4 - GPJ: 14b0
GPE changed to 0000f7e8
GPE changed to 0000f7c8
GPE changed to 0000f7e8
[...]
HaRET(3)# dump mmu mmu.txt
The MMU dump hungs the device
Samsung has also published manuals and datasheet of the processor, available here:
http://www.samsung.com/products/sem...ationProcessor/ARM9Series/SC32442/SC32442.htm
More information and kernel patches for Samsung SC32442A procesor can be found here:
http://www.fluff.org/ben/linux/
So, we have a lot of work to do... any developers able to help?
Wiki page
I've created a page on the wiki for the Hermes Linux port here:
http://wiki.xda-developers.com/index.php?pagename=Hermes_Linux
Forgive me for asking, but why would you want to put Linux on this device?
We've got enough issues getting support for the WM5 ROMs, don't you think?
If there's a good reason, I'd love to know what it is!
goestoeleven said:
Forgive me for asking, but why would you want to put Linux on this device?
We've got enough issues getting support for the WM5 ROMs, don't you think?
If there's a good reason, I'd love to know what it is!
Click to expand...
Click to collapse
If there's a mountain to be climbed... :wink:
That's what I figured... Good luck!
Well, may be climbing that mountain is the main reason. But here you have another, in my opinion, interesting reason:
http://www.linuxdevices.com/articles/AT7937511405.html
Re: Linux on HTC TyTN / Hermes
pof said:
The MMU dump hungs the device
Click to expand...
Click to collapse
What about running the "DUMP MMU" with gnuharet ? You can also try other commands
(POWERMON 10; NLED*)
They are ported from itsutils and should not depend on the CPU.
Hey cr2! Sorry for the late reply but I didn't see your post before
With gnuharet, powermon 10 works, shows this:
Code:
HaRET(4)# powermon 10
2146258 1 70 % 3792 359 0 410 0 0 -1 -1 0 255 255 0 -1 -1 0 0 0 4
2147264 1 70 % 3792 359 0 410 0 0 -1 -1 0 255 255 0 -1 -1 0 0 0 4
[...]
Also nled* commands work, I can make the device vibrate with "nled on 1" and stop it with "nledoff 1", etc..
The MMU DUMP was ok with gnuharet, see attached file!
I also updated the wiki page with some info about the Hermes hardware, as there are now pictures of the chipsets available, see this post:
http://forum.xda-developers.com/showthread.php?t=279151
yep.
got one. busy with htc sable. start when i'm done or bored.
Glad to see that lkcl and cr2 got an Hermes too
This sure means we'll see a linux kernel booting soon!
pof said:
Glad to see that lkcl and cr2 got an Hermes too
This sure means we'll see a linux kernel booting soon!
Click to expand...
Click to collapse
It sure would be damned sweet to get rid of M$'s OS on this device! By the way, how is Qtopia and other Linux PDA "stuff" doing these days? The last time I tried it was back on my IPAQ in... 2001 I think.
You have GPE and Opie as the main graphic environment used in handheld devices those days.
It seems that soon a new environment called OpenMoko will be released under a free license too, this one is more phone-focused than the others.
pof
thanks for the post , im glad i came across it,
somethings been on my mind for the last few days, a mate at work is always on about Linux so it got me thinking, id like to give it a try on my TyTN
Iv got 2 questions for you,
first is there a newbie guid to running Linux on PDA's il have a look on wiki next im sure il find something. is there any that you guys can recommand which you have found helpfull.
2nd Now this is the question thats bugging me,,,,,
Can we run 2 OS on a PDA????
is this poss? to have a dual boot option when the PDA starts so we can select either Linux or WM05, both on there own will run on the device, how about installing both at the same time, and then being able to boot with one,
just some thoughts>?
I might start another thread on this just incase this thread isnt getting anymore traffic
well time to get back to work and start doing the job im actually getting paid to do
N2h said:
first is there a newbie guid to running Linux on PDA's il have a look on wiki next im sure il find something. is there any that you guys can recommand which you have found helpfull.
Click to expand...
Click to collapse
Depends very much on which device you want to run linux, on the Hermes is not possible yet. But for the Universal or BlueAngel you have some guides here:
http://www.handhelds.org/moin/moin.cgi/Universal
http://www.handhelds.org/moin/moin.cgi/UniversalHowtoInstallLinux
http://www.handhelds.org/moin/moin.cgi/BlueAngel
N2h said:
Can we run 2 OS on a PDA????
is this poss? to have a dual boot option when the PDA starts so we can select either Linux or WM05, both on there own will run on the device, how about installing both at the same time, and then being able to boot with one,
Click to expand...
Click to collapse
You have WM5 on your flash, and Linux on the SD card. You start your pda with WinCE and then browse to storage card and run gnuharet.exe which will "destroy" WinCE and boot the Linux kernel and initrd found on FAT32 partition of SD card. Then from initrd, you mount the root filesystem on another partiton of the SD card...
pof thanks for the quick reply
il b ereading up on the guide links you have given,
also just to clarfy point 2
-----------------------
You have WM5 on your flash, and Linux on the SD card. You start your pda with WinCE and then browse to storage card and run gnuharet.exe which will "destroy" WinCE and boot the Linux kernel and initrd found on FAT32 partition of SD card. Then from initrd, you mount the root filesystem on another partiton of the SD card...
Today 02:05 PM
------------------------
by this means can we boot with WM and then run Linux from SD card once this is run would WM be completey wiped from device memory? so any data we had on the device for WM will be lost,
just so im explaing myself propley, i was wondering if you can keep both OS on the device and SD card boot from WM when you need that and when you want to use Linux boot with Linux but without losing you WM5 data etc.
same as some of the apple macs that can boot with windows and apple oc from the same machine and switch between the differnt OS's
thanks for the quick reply,
Iv got a collegue with universal I wonder if he will let me borrow his Universal??? lol
You can boot linux from SD card and you don't loose any data on WM5 when you shutdown linux and go back to WM5.
pof thanks mate,
il be hopefully running Linux on my Tytn,
you never know,,,,,,,,,,, by the time i learn and update myself on linux it may running on our devices
all the best to anyone else also trying!!!
I would love to try and help you guys, but i haven't got much experience in these kind of stuff. Where should i start looking for more info on the project?
The status of hermes linux port is always updated at this wiki page:
http://wiki.xda-developers.com/index.php?pagename=Hermes_Linux
All development happens at #htc-linux in freenode irc server, but unfortunately as of now there's not a booting kernel yet for the Hermes, so you need some knowledge of low level programming to help at this stage.
i actually have studied low level programming with assembly and c, but i'm not that familiar with kernels :-/.
Needed tools:
PuTTY ver.6 or above
Plink
Active Sync 4.5
any Hex editor
MTTY1.exe ver 1.11a
Windows PC
SPL 2.30 Olipro
SPL 1.01 MFG pack
SPL 1.10 Oli w/custom RUU
SPL 1.04 w/custom RUU
DUTTY'S Good .NB Tool
Win Rar
Hermes with working wlan
There are steps for the user with the device with the working wlan eeprom, and steps for the user with the device with the corrupted or missing wlan eeprom. Basically what you will be doing is cloning the MAC of a device with a working wlan, editing it, and flashing it to your device with the non-working wlan.
Steps for Working Wlan Device:
You need to get SPL Oli 2.30 (found on the XDA DEV FTP Site in the HERMES/HardSPL folder) on the working device. You can do this by following the downgrading bootloader page at:
http://www.mrvanx.org/cms/index.php?option=com_content&task=view&id=59&Itemid=27
Assuming you have HardSPL v7 on your device (as most of you have been doing upgrades and downgrades), follow the steps to downgrade to Oli 1.10 then to SPL 1.04, (read and execute carefully)
then use DUTTY'S Good .NB Tool...
http://forum.xda-developers.com/showthread.php?t=296311
...to convert the SPL Oli 2.30 .nb file contained in the .rar you downloaded (use WinRar to extact) to an .nbh file (RUU_signed) THEN flash SPL 2.30 (you can use the same custom RRUwrapper you used to flash to 1.04 by putting it in the same folder, but move the RUU_signed.nbh of 1.04 to another folder first, then put it back when your finished)
Download PuTTY and Plink and copy them into your C:\Windows\Temp folder
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Put your device in bootloader mode and disable USB connections in Active Sync
Connect to the PC and open PuTTY
Click SERIAL, and make the speed 115200, and type \\.\WCEUSBSH001 (all CAPS) in the space for SERIAL LINE (overwrite what is there) or connect with MTTY first...
http://forum.xda-developers.com/download.php?id=9864
... and copy and paste the address into PuTTY then close MTTY. Type HERMES into the space named SAVED SESSIONS and hit SAVE. Hit OPEN. Press ENTER to get a CMD prompt...you will see a green cursor. Type Task 32 and it will return Level=0. Ok, close PuTTY as you have verified that it's working.
Sometimes your device will be seen as \\.\WCEUSBSH002 or \\.\WCEUSBSH003, just use which ever it connects to.
Now the next bit is tricky because you you will do it "blind" as in this mode, Plink does not have local echo so you won't see what you're typing.
Go to START/RUN/CMD
This opens a DOS window. Change directories to C:\Temp and type the following:
plink HERMES > herm1.nb (hit ENTER TWICE) (you will see the new file herm1.nb written in your Temp folder) (notice the spaces before and after the > sign)
Now type the following and hit ENTER (once) after each command:
task 32
password 0000000000000000 (that's 16 zeros)
set 1e 1
rbmc me.txt 500a0000 40000
that will copy the wlan section of the eeprom nand to the file called herm1.nb. You can right click on the file, select properties, and see that it grows to 256k-257k.
When it's done creating the file (to 256k or 257k, you'll see it doesn't get any bigger), press CTRL C in DOS to close plink and it saves the file at 257k size.
Open the file in a Hex Editor, and remove all the non usable Hex Data (basically the commands you typed) between offsets 00000000-00000140 up thru the Hex equivalent of the word HTCS. Delete the data so that you actually delete the word HTCS. Then at the end of the file, offset (00040000), delete from the very end of the file (right to left) thru the word HTCE. You delete the Hex equivalent of the word HTCE. You can leave the D+ ] there as we're only going to write 40000 bytes. Now the now MAC address is at ROW 0001F850 with two bytes at row 0001F860. The MAC reads backwards. Save it as herm1.nb (but not in the same folder as the original).
Now, since you've basically cloned another's MAC address (already allocated to another device), it's necessary that you change your MAC address ASAP. Instructions on how to do that below:
In the edited herm1.nb file, go to the MAC Address at offset 0001F850 and change the 2nd, 3rd and 4th bytes from the right... (it's your MAC address in reverse), to ANY numbers you like, keeping the same format. This 6 byte sequence is your NEW MAC ADDRESS. The last 3 numbers of the MAC (which appear in opposite order) can be "invented".
You now have the eeprom flash file to be transfered to the non working device...
Steps for Non-working Wlan Device:
Using the methods on MrVanx's downgrading SPL page...
http://www.mrvanx.org/cms/index.php?option=com_content&task=view&id=59&Itemid=27
...downgrade again to SPL 1.04, then flash SPL 1.01 MFG. When flashing and using SPL 1.01 MFG, some users suggest you only use the version of MTTY that comes with the MFG Pack.
http://wiki.xda-developers.com/index.php?pagename=Hermes_BootloaderMFG
Read the full instructions before flashing.
Ok, now that you have verified that you have SPL 1.01 MFG on the device, put in bootloader mode, disable USB connections in Active Sync. Connect the device and open MTTY. Make sure you have copied your herm1.nb file into the same folder as MTTY.
Connect to the device (\\.\WCEUSBSH001)
and hit ENTER to get a CMD prompt
Now type the following:
task 32
password 0000000000000000
set 1e 1
lnb herm1.nb 500a0000 40000
Hitting ENTER after each command.
When it's done, close MTTY and reboot your device and verify that your Wlan is now working...
Then I recommend flashing HardSPL v7 or SPL 2.30 to your device right away (because you know you won't leave your device alone and we don't want you bricking your Hermes, do we?)
BTW, if you want to do a full backup of you FULL eeprom nand at any time, connect as before and type these commands:
plink HERMES > full.nb (hit ENTER twice)
task 32 (hit ENTER once and only once from now on after every command)
password 0000000000000000
set 1e 1
rbmc me.txt 50000000 7fff800
watch your file grow to 128 MB.
If you ever need to flash the entire eeprom nand, just edit it as above so you take out the commands you typed (HTCS-HTCE) and you're good to go...
Thanks go out to Pof and Olipro for doing the initial research on this issue. And also to members Laikos and Panzer who helped tremendously.
Tested on Cingular 8525 Wm6 VP3G modified AT&T rom, and Orange m3100 WM6 cooked rom based on Dopod 3.54.707.3 rom.
*NOTE* Olipro just posted later in this thread
"just to point out guys;
to flash 2.30.Olipro, just convert it into an NBH then run SSPL on your phone and go ahead with the flash, same goes for loading any other SPL, just load SSPL first (or use Custom RUU with the NBH and select force SSPL) the downgrading is unnecessary"
another member (dan1967) suggested that one only have to use SPL 2.60 Oli Hard SPL v9 Developer Edition to do this procedure and one can avoid the upgrading and downgrading of bootloaders...
Member alakentu has translated this method into Spanish. The thread is here:
http://forum.xda-developers.com/showthread.php?t=364751
***DISCLAIMER.....TRY AT YOUR OWN RISK, WE ARE NOT RESPONSIBLE FOR ANY MALFUNCTIONS OR OTHER ISSUES THAT MAY OCCUR.***
For those of you who used my guide to fixing your dead Wlan on Hermes, please feel free to make a donation via paypal if you feel I've helped you in some way. Any amount will be very much appreciated, and I could really use the cash, hee hee, thanks in advance. Just click the PayPal Logo below to donate.
cool !! I try this if i found a phone with no dead wlan
nice.........
It's possible to just hand code the WLAN EEPROM Value to your dead WLAN EEPROM too. Download your dead EEPROM and Edit the location mentioned by drummer.
Warning: It took about 30 mins to hand code the WLAN EEPROM DATA.
Would it be possible for someone to extract the eeprom file from a working wlan device, "zero-out" the MAC address portion, or replace with 'FF' or some other 'dummy' value, and post this here, so those of us without access to a working device can use to flash our damaged devices?
By "blanking-out" the MAC address in the attached file, you dont risk having your MAC address used by everybody, so there is no "legal" risk, and help us without a working device to fix ours...
Thanks for the solution guys and hopefully you can post the file here for us to use.
Good work !!
Thank you very much for this solution !!!! Great job!
But as said chrisvor, could you post an extract of a working Eeprom for thoose who don't have one please...
Thank you !
drummer,
first of all is to say thanks to you all who put in their time and effort in resolving this problem
so my question is... can you post the file of working wlan bit for us, without that i can't solve this problem... =(
Thanks!!!
Thank you so much for this!!!!
I will try to reviving my X01HT WiFi later!
Great Job!!!!
Someone has repaired his hermes ??
nicoebra said:
Someone has repaired his hermes ??
Click to expand...
Click to collapse
I did. And so did Laikos. Actually, he fixed his about 20 minutes before I did, he is a better editor than I am. Why do you think we did the research? We both had devices with non-working wlans, and now they're working again.
...and no, we're not posting, or sending anyone the file. You have to find a friend that will help you, as your trust in each other will safeguard against any possible mis-use of this technique.
laikos said:
It's possible to just hand code the WLAN EEPROM Value to your dead WLAN EEPROM too. Download your dead EEPROM and Edit the location mentioned by drummer.
Warning: It took about 30 mins to hand code the WLAN EEPROM DATA.
Click to expand...
Click to collapse
I don't believe that this is a good idea, as you don't know what else (from EEPROMcode) is corrupted!!
The MAC address is the only visible part to us...
pop20032004 said:
I don't believe that this is a good idea, as you don't know what else (from EEPROMcode) is corrupted!!
The MAC address is the only visible part to us...
Click to expand...
Click to collapse
How did you come to that conclusion?
All Laikos was suggesting, is you could type in the data, rather than replace the data by "cloning" it from another's device. Once you know the offsets, which you do if you read this technique, it's quite easy, although time consuming. So far, each file we have examined have had the identical wlan signatures, and identical first three numbers of the MAC address. That suggests that HTC was assigned a set of MAC addresses by OUI for their use.
BTW, using SPL 2.30 oli, you can change your backup CID, and model number (Hermes 100, 200, 300, or whatever you want to change it to like "Hermes 911").
Help
I believe that would be better than someone give the instructions detailed for those that they do not have other device to the hand to extract the EEPROM, extract your corrupt EEPROM and edit it.
In my case, live in Mexico city and these devices are extremely rare of seeing by here.
As soon as if someone can help me to obtain the file of a EEPROM will be I thanked what is.
Open the file in a Hex Editor, and remove all the non usable Hex Data (basically the commands you typed) between offsets 00000000-00000140 up thru the Hex equivalent of the word HTCS. Delete the data so that you actually delete the word HTCS. Then at the end of the file, offset (00040000), delete from the very end of the file (right to left) thru the word HTCE. You delete the Hex equivalent of the word HTCE. You can leave the D+ ] there as we're only going to write 40000 bytes. Now the now MAC address is at ROW 0001F850 with two bytes at row 0001F860. The MAC reads backwards. Save it as herm1.nb (but not in the same folder as the original).
i can't edit file " herm1.nb"
you can guide again or help me to edit my file.
Hello,
Is it normal that my file herm1.nb is rained large that 30Mo at the time of that creation, thank you.
-------------
Edit:I excuse myself I have to make an error the first handling, I succeeded in having the file herm1.nb has 256 Ko (262 ' 439 bytes).
If I do not modify the mac address that you it will occur on the other apparatus, thank you
drummer10630 said:
...and no, we're not posting, or sending anyone the file. You have to find a friend that will help you, as your trust in each other will safeguard against any possible mis-use of this technique.
Click to expand...
Click to collapse
@drummer10630: I do appreciate all your and Laikos efforts to solve this problem and to let the whole community know the method so everybody can fix their devices... however, the reason I asked if anybody could post the file was not a sign of "laziness", rather it is due to the lack of friends who have a TyTN or who want to void their warranty by flashing a non-official bootloader in order to "do me the favor" of extracting their eeprom data.
If any of you guys have extracted the eeprom and you have edited it to include your MAC address, could you please edit a COPY of this file, put "FF" in all the bytes of the MAC address (which is the only thing that "ties" this file to your purchased device and hence yourself), and post it here for us "tytn-friend-less" people to use?
Many thanks for EVERYBODY's efforts in solving this
Thanks and kudos go to Pof and Oli ofcourse, due to whom none of this would be ever possible !!
Chris
I have tried to get the code from a working Vario II using Des' SSPL, to avoid all the flashing of a working device, but got
Code:
USB>task 32
Level = 0
USB>password 0000000000000000
HTCSPass1.
CMËHTCEUSB>set 1e 1
USB>rbmc me.txt 500a0000 40000
GetExtRomData+(): *pszPathName=me.txt, dwStartAddress=500A0000, dwLength=40000
USB>c=40000
... and no dump.
Is there a workaround?
jrp said:
I have tried to get the code from a working Vario II using Des' SSPL, to avoid all the flashing of a working device, but got
Code:
USB>task 32
Level = 0
USB>password 0000000000000000
HTCSPass1.
CMËHTCEUSB>set 1e 1
USB>rbmc me.txt 500a0000 40000
GetExtRomData+(): *pszPathName=me.txt, dwStartAddress=500A0000, dwLength=40000
USB>c=40000
... and no dump.
Is there a workaround?
Click to expand...
Click to collapse
According to the #1 post, you HAVE TO follow the instructions, i.e. downgrading to SPL 1.04, 1.01 MFG, Olipro 2.30, in order to save the eprom from the working device.... no shortcut I'm afraid
I removed the lines 00000000-00000140
But I do not have information with the line 0001F850 and 0001F860 is this normal? , thank you.
{
"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"
}
Quick question.... Could I dump the WLAN eeprom from a Wizard? Dont think so, but I thought I'd ask since I have a wizard lying around too....
I would ask all active members to upload or share their collection of roms for Hurricane. I bricked my hurr 2 years from now and yesterday i got one so i would like to try as many roms as possible, and it will be great for all to share roms!!! I found several on this forum (lazaj's, saleng's, shadow's) but i think that there is more!!! So share your collection!!!
Here i found some on forum:
hurricane unlock, patch and upgrade wm 6.1(selang09) ***
Link: http://www.megaupload.com/?d=JLO5H1L7
Thread: http://forum.xda-developers.com/showthread.php?t=475286
Opinion: Good one, but chinese language everywhere! After u change main lang. still some apps name stay in chinese and options too!
wm6.1 for hurricane (with Bluetooth and INFRARED RAY problems solved)0415update!!!
Link: http://rapidshare.com/files/100934508/5x6_wm6.1_0319.rar
Thread: http://forum.xda-developers.com/showthread.php?t=378607
Opinion: Didn't tried!
WM 6 Graphite rom, how to get WMPlayer in English (now in Polish)
Link: http://rapidshare.com/files/108676266/wm6_2_2.zip
Thread: http://forum.xda-developers.com/archive/index.php/t-384972.html
Opinion: Using this one right now! Seems ok, works nice, nice look, except incoming calls didn't show up!!! Very bad bug!
Wm 6.1 Pl/eng
Link: http://rapidshare.com/files/131860280/wm_6_1_by_Lazaj007.zip
Thread: http://forum.xda-developers.com/showthread.php?t=410739
Opinion: Tried before Graphite eng edition, works great, looks great... Main lang polski, after lang change WMP stay in polski! But still ok!
WM6 for SPV C550
Link: http://rapidshare.com/files/56833250/566.zip
Thread: http://forum.xda-developers.com/showthread.php?t=330709
Opinion: Never tried!
And one pack with SPL 1.00.84 & soft spl (nb, nbf), IPL 1.00.15, GSM DATA (hex and dec), bootloader commands, splsplit... etc!
Link: http://rapidshare.com/files/427352270/data_hurricane.rar
Info: This last files can help u to unbrick your hurricane (BUT AVOID TO BRICK IT), i found it on pda2u.ru , and thanks them for that! Special thanks to member SAXON!
I found many links for ROMs but those which is here have alive links! Someone with good upload speed can reup them again in one pack and post a link here!
ENJOY!
I would like to have a non T-Mobile German version (can be a shipped ROM). Have not found any yet, only those that are available at www.shipped-roms.com Have to live with de-branding this as it seems.
Possibly someone with any of the following devices can do a "r2sd all" backup of the ROM?
imate SP4M
Orange C550
Qtek 8200 (the Russian/English is available as RUU)
Thanks for this link tobbbie !
Btw, in selang's rom SMS Send don't work! So, it is useless!!! :S
I have tested all ROM´s below for SDA II, but for me lazaj007 is the best of all
Thanks to lazaj007
Did anyone care to pick up some ROM cooking for that device? I did not succeed in getting the .BIN files manipulated correctly - and I think I have a collection of nearly all ROM tools now :-(
howto convert .bin to .nb0 and back
Foreword:
.BIN files are not all the same by their nature (of course not by content). There are
.bin that are used to identify the bare binary content of the various partitions (you mostly see those)
.bin that are used to flash a ROM to the device. This looks somehow historic though, the format is already described by itsme at: http://www.xs4all.nl/~itsme/projects/xda/wince-flashfile-formats.html. It seems to me that some non HTC devices are still using this format.
The osnbtool.exe (from Weisun at PDACLAN.COM) does not work for any purpose regarding .bin files
at least not for Hurricane.
- The -sp option cuts only the B000F\0a header but does not reconstruct the blocks of the .bin file.
Mind that small .bin files (smaller than 0x1c00000) are treated correctly as there is only one block.
- The -2bin option creates an incorrect .bin header (sets a weird total length) and sets totally confused
block-load addresses for the created blocks of 64k (0x10000) size. Check it with viewbin.exe if you like.
Reference for the filestructure by itsme:
http://www.xs4all.nl/~itsme/projects/xda/wince-flashfile-formats.html
The splitrom.pl (itsme romtools) seems not be able to read the content of any .bin file I have fed to it.
Neither for .BIN files created for Hurricane nor those for Typhoon, I always get:
cmd> splitrom.pl <binfile>
B000FF image: 82040000-84c40000, entrypoint: 00000000
!!! your rom is not known to me: md5: a520f0d1093b36f0a3cfd9323ea99155
this bootloader seems to be No bootloader present
no xipchain found
no bootloader found
no operator rom found
no bitmap found
I am rather sure it should handle everything correctly but I am too stupid to debug .pl :-(
So the only thing that works and will re-create a flash-able .BIN file from a .nb0 is listed below:
convert .bin to .nb0:
enter: viewbin -r <binfile>, you get something like:
Image Start = 0x82040000, length = 0x02C00000
Record [ 0] : Start = 0x82040000, Length = 0x01C00000, Chksum = 0x00000000
Record [ 1] : Start = 0x83C40000, Length = 0x01000000, Chksum = 0x00000000
Record [ 2] : Start = 0x00000000, Length = 0x00000000, Chksum = 0x00000000
Start address = 0x00000000
The above has two blocks of data and a termination block.
The checksum = 0 effectively disables upload checking (so potentially dangerous).
The size just fits the Hurricane's SPL "l" (load) command buffer, as you get when loading a ROM:
"clean up the image temp buffer at 0x8C080000 Length 0x01C40000 "
The blocks can be smaller than 0x1c40000 but not bigger obviously.
then convert to nb0, enter: cvrtbin.exe -r -a <imgstart> -l <length> -w 32 <binfile>
for above viewbin output: cvrtbin.exe -r -a 82040000 -l 2c00000 -w 32 <binfile>
mind to omit the 0x for the start and address, replace <binfile> with your filename, then you get a resulting file from <original-name.bin> to <original-name.nb0> which can further be decomposed and edited with standard ROM tools
convert .nb0 to .bin:
enter: xipbin.exe <input.nb0> <start-in-nb0> <output.bin> <loadaddress>
to get back something flashable like above: xipbin.exe <input.nb0> 0 <output.bin> 82040000
mind to omit the 0x for the loadaddress, replace <"file"> with your filenames
to recheck if the created BIN file is usable, startup the viewbin again
enter: viewbin -r <binfile> you now get something like:
Image Start = 0x82040000, length = 0x02C00000
Record [ 0] : Start = 0x82040000, Length = 0x00040000, Chksum = 0x0208CC79
...many entries deleted...
Record [175] : Start = 0x84C00000, Length = 0x00040000, Chksum = 0x0177FB3C
Record [176] : Start = 0x00000000, Length = 0x00000000, Chksum = 0x00000000
Start address = 0x00000000
Done.
Looks quite different - but this is ok! The loading process in MTTY indocates the loading of each above block with a sequence of |*, so with these many blocks the upload to the device is giving feedback and thus is not tempting people to interrupt it.
I have done my tests with the 566.zip linked in the first post of this thread, but this should work with any .BIN file from the other ROMs as well. So I will continue to see if I can recycle any of the WM6 Roms for inserting my imgfs created for Tornado. As before the imgfs still the XIP is loaded and I know too little about this yet (especially in connection to the imgfs and how close these two are linked) - I am prepared to see non booting device states quite a lot. Luckily there is nothing done to the early boot chain (IPL and SPL) so I can always get back to the bootloader and start over again.
I hope to get a first indication that imgfs is mounted correctly in the "old" XIP before I have to replace the OEMdriver parts in my Tornado ROM.
I just checked if I can still use this flash-method for the Tornado - and it works as well. So the created "os-new.nb" in the OUT directory can be converted to .BIN and then flashed inside MTTY with the "l" command. Not that I like this method - but it works as well.
Tobbbie, you have here a very good research! To bad this device is out of use!
Current version: !IMEIme 2.2.0.4
Bug Fix
Fixed bug in use previous patch that could result in variable used before declared error.
Changed processing order when custom patches were to be used
The program will now process custom patches prior to editing framework.jar and build.prop edits. With new kernel patches requiring a new build.prop users would lose build.prop edits if the kernel was included in custom patches, the program will now patch any user modifications, then process IMEI generation and build.prop edits.
Updated to work with ROMs that do not include GSMPhone.smali
Recently, many ROMs are not including GSM phone utilities in framework.jar. I have added testing for missing GSMPhone.smali and patching via TelephonyManager.smali if necessary.
UPDATED FILES UPLOADED
MANY of the support files have been updated to the newer versions (smali, baksmali, adb and components).
I encourage you to delete all files in your existing IMEI Generator folder and use the new !IMEIMe.exe to generate the files necessary.
The devices.dat file if you've used the previous version has several issues that prevents the device model from being correctly patched on many of the devices. This has been fixed here and in the device list thread.
There is a known issue with the GUI when your screen settings are set at 125% in Control Panel - Appearance and Personalization - Display... I will work on fixing that in the next release.
Bug reporting thread for !IMEIme
Device list thread
New features:
Will patch GSMPhone.smali if present in framework... patches TelephonyManager.smali otherwise.
I chose this method since more ROMs are coming out for wifi tablets that do not have GSM phone information included in framework.jar. I was playing with CM10.1 and discovered GSMPhone.smali is not present, thus I was getting unable to patch GSMPhone.smali error, and there was no patching for an IMEI. In all honesty... this should be irrelevent, since IMEI is only utilized in cellular communications on GSM phones... however... some applications MAY (xda free does) require an IMEI to work, even on wifi only devices.
ODEX files still in the works
odex file support... I think this solution will work on odex file systems as long as the patching is done on the ROM prior to flashing to device (anyone using odexed system please let us know) and I am working on in place patching on odexed systems... however, I am not completely comfortable since there is a lot of work done by the device itself during odexing of the modified files... I am very hesitant since any mistake could render a bricked device and I don't have a system to test with prior to release.
Previous Important Changes
The new version of the IMEI Generator will no longer overwrite your existing devices.dat file with the current. To use new devices.dat file, delete the old one prior to running the program, or download the new one and unzip it in the IMEI Generator directory.
Device Communications not necessary in certain situations
If you select to Update ROM, using Serial Number based IMEI and do not select Encrypt IMEI, the program will no longer need to communicate with the device when performing its tasks. The framework.jar patch will not hard patch the IMEI in this situation as before. This is useful for patching a ROM for distribution to multiple people, since they will all maintain unique IMEI's. This is accomplished with the following change in the framework.jar
Code:
/com/android/internal/telephony/gsm/GSMPhone.smali
.method public getDeviceId()Ljava/lang/String;
[b]changed[/b] iget-object v0, p0, Lcom/android/internal/telephony/gsm/GSMPhone;->mImei:Ljava/lang/String;
[b]to[/b] sget-object v1, Landroid/os/Build;->SERIAL:Ljava/lang/String;
prior to patching in code to prepend "0"
.method public getDeviceSvn()Ljava/lang/String;
[b]changed[/b] iget-object v0, p0, Lcom/android/internal/telephony/gsm/GSMPhone;->mImeiSv:Ljava/lang/String;
[b]to[/b] sget-object v1, Landroid/os/Build;->SERIAL:Ljava/lang/String;
prior to patching in code to prepend "0"
To try to explain the above a little...
The above is always changed, no matter what IMEI generation method you select...
If you select Serial Number and New Type IMEI and not Encrypt: no other patching is done for the IMEI... this can be implemented on many devices, since each will have a unique serial number.
If you select Serial Number and do not select New Type: additional code is added to format the IMEI to the old standard ("00-" and "-"s)... this can be implemented on many devices for same reason.
If you select MAC Address or Encrypt (or both): additional code is added that results in the IMEI being hard coded, this makes it very much device specific.
If you select MAC Address or Encrypt (or both) and do not select New Type: additional code is added that results in the IMEI being hard coded as well as code to format the IMEI, this makes it very much device specific.
Use Custom Patch NOTE: This is only used when patching a ROM
This is going to take some major explanation, since I ran into so many possible scenarios...
One thing of note... the only additional lines added to updater-script will be for files in the base directory
The order of processing is:
1. Original ROM updater-script and files
2. Custom Patch zip file
3. Custom Patch folder
The program will utilize folders (from Patch zip file or Patch folder itself) named modboot, modsys, or system (not case sensitive in windows) as well as files in the base folder
Any files in modboot will be moved to the root of the **ROM**-IMEI.zip file and lines added to updater-script as needed
Any files in modsys will be moved to the system directory of the **ROM**-IMEI.zip file
If Custom Patch is checked...
/META-INF/com/google/android/updater-script is extracted from the ROM
the program will ask you to select the Custom Patch Folder
If there is a zip file present in the folder the program will ask if you want to use it
You have 3 options, "Yes", "No" or "Cancel"
Yes = Use the zip file
No = Don't use it, select another
Cancel = Don't use a zip file
If you use a zip file, it will extract the zip file and process the updater-script in it for any additional lines needed
After the above, any non-zip files and modboot, modsys and system directories in the Patch Folder will be processed
I chose this order so you can have a "go to" patch zip file, and test other additions by using the file, folder options prior to including them in the zip.
Example here:
I have my custom patches in folder /CM7/UserMods with these contents:
/META-INF
/modboot
/modsys
patch.zip
The program processes patch.zip first, then overwrites any files with the files in modboot and modsys
It also processes /META-INF/com/google/android/updater-script for any lines extracting files to /boot and adds them to the original ROM updater-script if not already there.
It then adds lines for any files originally in /modboot to updater-script to extract them to /boot
"New IMEI Type" of IMEI which no longer has the "-"s in it, but maintain backward compatibility for those who already have IMEI's generated or prefer the old style. When the new type is selected in the GUI:
NOTE: Per the IMEI standards... Using a single 0 prepended to the IMEI indicates a TEST IMEI for a country with 3 digit international code... while it should have no implications to us since we are not on a cell... it may provide potential country validity issues... I will monitor this and resort to 00 prefix in the new type of IMEI if necessary.
ADDITIONAL NOTE: Per the IMEI standards... For devices without an IMEI, they are to provide a unique serial number to be used... This program modifies framework.jar to allow this.
I am now patching framework.jar in the /com/android/internal/telephony/gsm/GSMPhone.smali file instead of /android/telephony/TelephonyManager.smali (this change is what allows the information to display in the about tablet information)
I am renaming and patching 2 functions... getDeviceID() and getDeviceSvn()
By patching the two functions in this file... the IMEI now shows in Settings... About Tablet... Status... no longer have to use external program or dial *#06# to verify the device is patched.
getDeviceID() shows it in IMEI
getDeviceSvn() shows it in IMEI SVN
You can rename or copy !IMEIme.ini to IMEIme.ini and the program will work.... useful for *nix users and probably mac users... since they have issues with special char actors (!)... While I like to use it in windows to keep the executable and ini file at the top of the file list in windows explorer... anyway...
The program looks for IMEIme.ini first and uses it if present... if it is not... it then looks for !IMEIme.ini (which will be there... because the program installs the generic !IMEIme.ini if it isn't ) This also provides a good way to keep your ini.. and see the new settings in the compiled in ini.
GUI selection and related ini setting
GUI: New IMEI Type
INI Setting:
New_Type =
; If 0 then the old type of "00-XXXXXX-YYYYYY-ZZZ" will be used
; If 1 then the new type of "00XXXXXXYYYYYYZZZ" will be used
BUG FIX
No known or reported bugs to work out.
!IMEIme.ini file default settings and explanation:
Code:
;The setting options are 1 (use the option) or 0 (don't use the option)
;WiFi IP Address can be set to your Nook's IP address here to a default to use
;IMEI can be set to a default here... you can also set the seed you use for generation
;Setting Device_Manufacturer to anything will result in an edit to build.prop setting the entered manufacturer
;IF Device_Manufacturer is NOT blank then:
;Setting Manufacturer_Device to anything will result in an edit to build.prop setting the entered device
;
;NOTE: ONLY Device_Manufacturer is necessary for this edit... there have been no software that appears to
; require a device edit
;
;Setting LCD_Density will result in build.prop edit for this setting regardless of Device_Manufacturer setting
;
;Set all options in [Settings] section at the bottom
[Settings_Explained]
Use_In_Place = 1
; If 0 Disable In Place patching... useful for those who always update AOSP ROM files and never patches on device framework.jar
; If 1 Enables In Place patching if ADB is working
Use_Previous_Patch = 0
; If 0 Ignore IMEI.fix
; If 1 AND IMEI.fix exists... use it for patching
Use_Serial_Number = 1
; If 0 then do not base IMEI off of Device Serial Number
; If 1 then base IMEI off of Device Serial Number
; NOTE: This takes priority over Use_MAC_Address
Use_MAC_Address = 0
; If 0 then do not base IMEI off of Device MAC Address
; If 1 then base IMEI off of of DeOvice MAC Address (last 5 hex words) (2 bytes = 1 hex word)
; 0A is converted to 010, FF is converted to 255 etc.
; NOTE: Use_Serial_Number takes priority
Use_Manual_Input = 1
; If 0 then Manual Input disabled
; If 1 then Manual Input enabled
Encrypt_IMEI = 1
; If 0 then uses actual data for IMEI... i.e. Serial Number (last 15 digits) or MAC Address (last 5 hex words) is actual IMEI
; If 1 then program encrypts data for IMEI generation... hiding actual Device data
New_Type = 1
; If 0 then the old type of "00-XXXXXX-YYYYYY-ZZZ" will be used
; If 1 then the new type of "00XXXXXXYYYYYYZZZ" will be used
Use_ADB = 1
; If 0 then ADB is disabled... this will prevent In-Place updating from working all together
; If 1 then ADB is enabled... In-Place will work... IF adb is working on your device
; NOTE: This takes priority over Use_ADB(usb) and Use_ADB(WiFi)
Use_ADB(usb) = 1
; If 0 then ADB via USB connection is disabled... I use this since some ROM's have Debug Mode issues
; If 1 then ADB via USB is enabled and attempted first
; NOTE: Use_ADB takes priority over Use_ADB(usb) and Use_ADB(WiFi)
Use_ADB(WiFi) = 1
; If 0 then ADB via WiFi connection is disabled
; If 1 then ADB via WiFi is enabled... I use this since some ROM's have Debug Mode issues
; NOTE: Use_ADB takes priority over Use_ADB(usb) and Use_ADB(WiFi)
Clean_Up = 1
; If 0 then the program will leave all support files when cleaning up and exiting
; If 1 then the program will delete all support files when cleaning up and exiting if none of them
; existed at program start
Include_Patch = 0
; If 0 then custom patches is disabled
; If 1 then the program will prompt for custom patches to include
Device_Manufacturer =
; If blank then the program will not edit build.prop
; If anything other than blank the program will edit build.prop to include manufacturer
Manufacturer_Device =
; If blank then the program will not include device in build.prop edit
; IF anything other than blank the program will include device in build.prop edit
; NOTE: No build.prop edit will occur if Device_Manufacturer is blank
Device_Model =
; If blank then the program will not include model in build.prop edit
; IF anything other than blank the program will include model in build.prop edit
; NOTE: No build.prop edit will occur if Device_Manufacturer is blank
Build_Fingerprint =
; If blank then the program will not include Build Fingerprint in build.prop edit
; IF anything other than blank the program will include Build Fingerprint in build.prop edit
; NOTE: This edit will occur even if Device_Manufacturer is blank
LCD_Density =
; If blank then the program will not include LCD Density in build.prop edit
; IF anything other than blank the program will include LCD Density in build.prop edit
; NOTE: This edit will occur even if Device_Manufacturer is blank
WiFi_IP_Address =
; You can enter the default Device IP address here... especially useful if you are only using this on one device...
; or if you keep seperate folders for each device you use (!IMEIme.exe and !IMEIme.ini must be in each folder)...
; i.e. folder for "sister" containing the program and ini file at minimum.
; If blank the program will prompt you for the IP address of the device to establish ADB WiFi connection
IMEI =
; Enter a base 10 (integer) and it will be used as the IMEI (duplicated until 15 digits is reached)
; Enter your "seed" and the program will generate an IMEI based off of it
; NOTE: If you try to generate the old GENERIC IMEI the program will not do it
[Settings]
Use_In_Place = 0
Use_Previous_Patch = 0
Use_Serial_Number = 1
Use_MAC_Address = 0
Use_Manual_Input = 1
Encrypt_IMEI = 0
New_Type = 1
Use_IMEI(15) = 0
Use_ADB = 1
Use_ADB(usb) = 1
Use_ADB(WiFi) = 1
Clean_Up = 1
Include_Patch = 1
Device_Manufacturer =
Manufacturer_Device =
Device_Model =
Build_Fingerprint =
LCD_Density =
WiFi_IP_Address =
IMEI =
Credits:
mthe0ry: Credit for the original IMEI patches released for us Nookers(TM). His original thread is here...
martian21: Took mthe0ry's work and maintained it for releases of CM7, upeating it for each nightly that needed a new one. Martian21's thread.
HacDan on irc.freenodes.net #nookcolor for helping me figure out patching GSMphone.smali instead of TelephonyManager.smali
Thank you's:
paleh0rse: I believe was the first to download and test this program... I think the first bug report too... helped many users with suggestions regarding their apps.
mr_fosi: Continues testing and reporting despite no need to. Tested a few private beta builds to help iron out a significant issue. Also providing information regarding Phone App *#06# IMEI test.
martian21: Set the wheels turning. Provides invaluable feedback and suggestions. He is an invaluable tester and Q&A guy. Thanks for dangling that bait
mellopete: Provided the very first bug report... prompted me to include necessary files in the program itself.
TheMainCat, 12paq and frankusb: Provided bug reports leading me to look at why some Windows versions didn't run the program initially.
Nayla1977: Bug report regarding a mistyped EndIf in my source.
jdexheimer: Bug report that lead me to find a problem with folders with spaces in them.
LinuxParadigm: Bug report regarding missmatching If - EndIf's.
BitingChaos: first public post to get me back on target.
dillweed, garrisj and many others: for PM's indicating the importance of this solution.
lemdaddy for reporting the bug that we tracked down to the java version and reporting back that it was the java version causing issues.
adusumilli for reporting the bug where IMEI was generated as "00-cat: c-an't o-pen"
topcaser for being persistent enough with the bug causing In-Place to fail in certain situations.
HacDan on IRC for leading me in the right direction to impliment the patching of GSMphone.smali.
We are all adults, if we break our toys... we only have ourselves to blame and we may have to buy new ones... (this will NOT break your Nook... I PROMISE you that! but it may break some of your apps... more on that later in post)
BUG REPORTING:
This program was initially ineteded to generate a unique IMEI based on your device S/N and update Dev's install zip files... it has become so much more, and as such there are many functions involved in this process.
Due to the complexity the program has taken on... far beyond what I initially intended... to report bugs please try to use the following as a template:
Function attempting: i.e. Updating ROM... In Place Upgrade... Update framwork saved on computer... etc.
Error Messages: any error message you receive... or the last message you saw prior to the issue.
End result: i.e. GSMphone.smali updated, ROM not... GSMphone.smali updated framework.jar not... etc....
Environment: ROM in same folder as IMEIme.exe... ROM on same drive as IMEIme.exe... ROM on different drive... etc. (same for framework if updating framework instead)
!IMEIme.ini settings: you can put your entire ini file if you'd like.
If you could take notes of EXACTLY what which selection in the GUI you have selected and any buttons you click on which prompt it would be EXTREMELY helpful...
As I said, this program has taken on functions I initially had not imagined including... the more features added, the more complex testing and tracking bugs becomes... I don't want to include a bunch of messages just for the sake of letting you know where in the code you are... would not be beneficial to you... more buttons to click for no reason, etc.
The more detailed you can be, the quicker I can see what is happening... otherwise I have to try to duplicate what I think you are doing when you get the error.
mr_fosi and martian21 have been very tedious in reporting bugs... I greatly appreciate their testing despite not needing to, and the manner in which they document what is going on....
Everyone should click "Thanks" on their bug report posts... they have been instrumental in getting the program where it is so far.
Background:
Some developers require a unique number that is supposed to be provided by hardware manufacturers that is unique to every device. This unique number (IMEI) is extremely important in devices utilizing cellular communications.
Since B&N has not registered IMEI numbers for the Nooks, the AOS's we are using do not acquire it as they do in other Android devices.
The developers that require a unique IMEI have been less than receptive of our devices and past methods to provide functionality to utilize their apps.
I decided to provide what I believe to be a viable solution to this problem.
What this program is:
It is a method to provide a unique IMEI (with reasonable certainty) for our Nooks.
It IS intended to be a supplement until IMEI is addressed in dev's ROM's.
It IS viable for Froyo... CM7... CM9... CM10...Honeycomb... MIUI.... AOKP... and others.
I can't think of any reason it will not work with ANY ROM you choose to utilize... if you run across one... just let me know and I'll see if I can't fix that.
What this program is not and does not do:
This is not a perfect solution to our Nook specific issues. Let me make it PERFECTLY CLEAR there is NO PERFECT SOLUTION We are generating an IMEI from something else... I use TEST IMEI patterns based off of our device serial number, to ensure apk devs wouldn't come down on us.
It is not targeting any specific AOS.
It is not guaranteed to be accepted by any other developers.
It is not intended to be the end all, beat all solution.
It is not intended to dissuade other developers from providing what they feel is a better method.
It will not cause any programs to show in the market. That has to be dealt with via APK developers and/or build.prop Manufacturer strings.
Potential issues:
There is NO legitimate solution to the IMEI issue we Nookers (TM) face... unless a group desires to register a block of them for our use... thus I am generating TEST IMEI's... ideal... no, but the only method available to us.
While I feel, with significant certainty, there will be no negative consequences from apk devs in general, I cannot speak for them, or their logic. This can easily be disabled by them again. That is on them, not me or us. By the same token, they can decide to stop providing their service for cause, I still have no control over that.
Above, I emphasize “with reasonable certainty” due to the fact that, in theory, you can wind up with an IMEI that 9 other Nooks that use this software has. That can only happen if the other 9 owners use this program and have a serial number within the same 10 as yours. This is even less likely with the New IMEI Type since it is using the right most 16 digits of a device serial number (and we know they all start with 2)
If everyone who has the same beginning 15 digits utilizes this program to generate an IMEI, you will all wind up with the same IMEI. Given the number of Nooks out there compared to the number of user's hacking them.... I find it extremely difficult to believe, with a reasonable certainty, that any 2 (much less 10) devices would ever wind up with the same IMEI generated by this program. This is prevented when using the New IMEI Type
What this program does/is capable of:
It allows you to extract framework.jar from a developers update zip file.
It will allow you to pull framework.jar from your Nook or use an existing framework.jar already stored on your computer.
It will generate an IMEI based on your Nook's serial number (or MAC Address) if adb is working on your system. If you have issues running adb via USB (ADB(USB)), it provides the opportunity to utilize adb via WiFi (ADB(WiFi)) for any computer-device communications.
It will provide you a method to manually input your serial number if you cannot connect to the device via adb. You can also input a “seed” (easy to remember word or phrase) and generate an IMEI based on the ASCII codes of the text you enter.
It will edit /com/android/internal/telephony/gsm/GSMPhone.smali to rename any existing getDeviceId() and getDeviceSvn() function to getDeviceId2() getDeviceSvn2() and append the patch to end of that file. NOTE: When the program "smali's" the resulting GSMphone.smali... it relocates the appended function to be before the renamed function.
It will save the patch as IMEI.fix, thus allowing you to utilize it for subsequent runs of the program. A caveat to this is... if you run it from the same folder on a friend's Nook... it will overwrite your original one if it is in the same folder or they will have the same IMEI as you do if you use Previous Run.
It will offer to push the patched framework.jar to your Nook... IF you opted to pull framework.jar from your Nook AND adb successfully worked to do that. This facilates in place upgrading.
It will backup the existing developers zip file appending “-IMEI” to it, distinguishing it is one this program has been used on. It will update this file, not the original developers file.
If there are issues with file names that become duplicate in a case insensitive OS such that windows is, it will warn you of this case and not remove the updated framework.jar to facilitate manual updating of the zip file.
Caveats:
This program is known to work on Java version 1.6.0_23 and known NOT to work on version 1.6.0_17 or earlier. If your system seems to work fine... but the nook does not give you an IMEI number... check your java version by typing this in a DOS window (start-run and type in cmd):
java -version
this will tell you the version of java you are running.
Java must be on your system. It must be in your system's path statement, or this program must be in the java/bin folder. It is possible that you must have java 32 bit version, this is being researched.
It will very likely break your swype, or any other app that utilizes IMEI for validation and you have used previous methods to circumvent their validation process.
It will likely break the same software if/when developers include a fix to the Nook IMEI situation in their AOS. Unless you opt to use this method again on their AOS to ensure you maintain the IMEI you used my program to generate.
Since I have opted to utilize test formed IMEI's to prevent duplicating someone's “real device” IMEI, software developers can easily shut us down again. That is their option. I am trying to provide a solution that is acceptable to both sides of the fence.
Closing statement:
As I desire to make this program as beneficial as possible... PLEASE provide any feedback and/or bug reports... just don't continue to push your ideals once it has been discussed... beating dead horses gets tiresome and just wastes precious time.
112 downloads of 2.2.0.3 with bug when pervious fix was selected
1686 downloads of 2.2.0.2 with no bugs reported
141 downloads of 2.2.0.1 with CM10 in place bug that would cause BBSOB and never boot
197 downloads of 2.2.0.0 (that actually appeared to be 2.1.0.4 in the zip) with a few minor bugs... mostly in custom patching
648 downloads of 2.1.0.3 with known GT for GameLoft issues
1123 downloads of 2.1 with no known bugs
182 downloads of 2.0a with a Generic IMEI bug
1919 downloads of 1.9 with no bug reports
3131 downloads of 1.8 with all bug reports being for non-nook devices
80 downloads of 1.7 with no bug reports
600 downloads of 1.6 with a couple of reports of In-Place update bug
880 downloads of 1.5a with 0 bug reports
148 downloads of 1.5 with a bug that could result in IMEI being generated without being properly formed.
36 downloads of 1.4 with a bug that could result in IMEI of "cat: can't open".
258 downloads of 1.3 with 0 bug reports... time to move on with next feature.
1618 downloads of 1.1 and the only bug noted has been tracked to the user's Java version.
12,758 downloads prior to the current version.
Bug reporting thread for !IMEIme
Device list thread
Looks like I have something new to mess with tomorrow night... thanks for working this, we owe ya!
Been looking forward to this! Thanks for your hard work DizzyDen.
Tested it out however it isn't finding 7zip. I've tried both the 64-bit and the 32-bit version (on 64-bit Windows 7). I'm probably doing something wrong if so please feel free to enlighten me
Martian21
martian21 said:
Been looking forward to this! Thanks for your hard work DizzyDen.
Tested it out however it isn't finding 7zip. I've tried both the 64-bit and the 32-bit version (on 64-bit Windows 7). I'm probably doing something wrong if so please feel free to enlighten me
Martian21
Click to expand...
Click to collapse
It wasn't you... there's something weird with the API to the fileopendialog that changes the working directory... a TEMPORARY work around is to copy the zip file to the folder you are running the program from.
Updating to beta 2 to auto extract support files on run.
Beta 2 is up... OP updated... note the bold text... for now the zip file must be in the same folder as IMEIme.exe
That will be fixed shortly.
Updated to beta 3. OP updated.
Fixed file browse for update file.
Improved cleanup behind itself before exiting...
removes helper files
removes framework.jar
removes classes.dex
removes out folder
removes system folder (the one used to add framework.jar to the zip file)
Still debating ability to allow manual input of the IMEI or a serial number... but those that want to do it will probably figure out how to do it manually... its REALLY not that hard.
Will add random IMEI generation as an option. The only purpose I see for this is for those who don't want to use the generic IMEI and cannot get adb working... even with the included adb in this program.
Feedback and bug reports are welcome and will help improve the program.
Thank you for this
I had to copy my AdbWinApi.dll for it to work. It did not put the new framework.jar in the zip though. It made the files, but didn't update the zip. I moved it to the root of my drive and ran it as administrator, but it still didn't update the zip. I am using Windows 7 x64. I used the IMEI.fix file and updated the zip myself. Thanks again for this nice tool.
mellopete said:
I had to copy my AdbWinApi.dll for it to work. It did not put the new framework.jar in the zip though. It made the files, but didn't update the zip. I moved it to the root of my drive and ran it as administrator, but it still didn't update the zip. I am using Windows 7 x64. I used the IMEI.fix file and updated the zip myself. Thanks again for this nice tool.
Click to expand...
Click to collapse
Did you use something prior to b3 ?
There was an issue I discovered that was preventing appending IMEI.fix to TelephoneProvider.smali that was fixed in b3.
I did my development on windows64 so that shouldn't be an issue.
As for the dll... I hadn't experience issues with that... but I can certainly add it to the program.
Both adb dll's will be included in all releases after b3.
Good job!
Can you explain more about how rom is being affected?and what to check?
Sent from my phiremod for Nook using Tapatalk
DizzyDen said:
Did you use something prior to b3 ?
There was an issue I discovered that was preventing appending IMEI.fix to TelephoneProvider.smali that was fixed in b3.
I did my development on windows64 so that shouldn't be an issue.
As for the dll... I hadn't experience issues with that... but I can certainly add it to the program.
Both adb dll's will be included in all releases after b3.
Click to expand...
Click to collapse
b3 is the first one I tried. I didn't look at the classes.dex before it was deleted. I will check.
RASTAVIPER said:
Good job!
Can you explain more about how rom is being affected?and what to check?
Sent from my phiremod for Nook using Tapatalk
Click to expand...
Click to collapse
Read here http://forum.xda-developers.com/showthread.php?t=1004102
TelephonyManager.smali did not change.
mellopete said:
TelephonyManager.smali did not change.
Click to expand...
Click to collapse
Please make sure b3 is the one you are using. When you originally posted... the thread was showing 0 downloads of that file.... or just wait a few minutes... beta 4 is on its way shortly.
To ensure TelephonyManager.smali is not changed you need to look in two places.... the easiest way is to search for getDeviceID
If it worked correctly you should find 2 instances... the first is the original function and my program renames it to getDeviceID2()... the second should be the one !IMEMe adds to the end of TelephonyManager.smali
Additionally... could you check and see if your run is actually overwriting update zip file.... see if there is a update ".zip.tmp" file left over... if it is there... the zipping is running into an issue overwriting the original file... I thought I had that issue worked out... but may need to add a check for that within my program.
I d/l b4, dropped it in a directory with just the .zip for n87 and ran it (win7 pro 64-bit). It errored out and here's the play-by-play of each of the windows which popped up one immediately after the other:
- I was warned about you being an unverified software publisher, which I OKed.
- "Windows cannot find 'java'. Make sure you typed the name correctly, and then try again." I OKed this one as well.
- window titled "DizzyDen's IMEI Generator" containing: "Return Code is:0 and Error Code is: 1"
- window titled "DizzyDen's IMEI Generator" containing: "Java is required on your system. You can download the current version from http://java.com"
I have JRE6 on my machine, though it is not in the system PATH.
Oh, and there were files for 7za, adb, .dll's and .jar files left behind.
mr_fosi said:
I d/l b4, dropped it in a directory with just the .zip for n87 and ran it (win7 pro 64-bit). It errored out and here's the play-by-play of each of the windows which popped up one immediately after the other:
- I was warned about you being an unverified software publisher, which I OKed.
- "Windows cannot find 'java'. Make sure you typed the name correctly, and then try again." I OKed this one as well.
- window titled "DizzyDen's IMEI Generator" containing: "Return Code is:0 and Error Code is: 1"
- window titled "DizzyDen's IMEI Generator" containing: "Java is required on your system. You can download the current version from http://java.com"
I have JRE6 on my machine, though it is not in the system PATH.
Oh, and there were files for 7za, adb, .dll's and .jar files left behind.
Click to expand...
Click to collapse
java will need to be in your path... I have no way of including all possible locations of where it could be installed... and it is way too big to include with my program.
The left over files is due to the program exiting when it did... I will fix that in next beta... should have waited until java was tested to extract them... or have it perform cleanup before exiting on any errors... sorry bout that.... you can leave them... when you have successful run (or run beta 5 or later) it will clean them up.
For now you may have to run as administrator.... I will try to add code to avoid this in the short future.
BTW. Nowhere does getDeviceID does it say that it must be a well formed IMEI.
nemith said:
BTW. Nowhere does getDeviceID does it say that it must be a well formed IMEI.
Click to expand...
Click to collapse
As much as I admire your work... I am honored that you are even checking this out.
I do understand that as of now it is not required... but I figure if I utilize standards (as much as there are anyway) we may avoid future issues if dev's start checking for well formed IMEI's.
I figure if I'm going to make this... I might as well make it right.
As far as I can determine... if a sw dev implemented IMEI checks, the only thing that could cause them to shut down someone using this would be to check that it is a "TEST" IMEI... but I don't see that happening, because hardware manufacturers do use these in testing.
DizzyDen said:
java will need to be in your path... I have no way of including all possible locations of where it could be installed... and it is way too big to include with my program.
Click to expand...
Click to collapse
Roger that. Should the instructions then note either the required change to PATH or that the file must be run in the user's jre#\bin directory?
DizzyDen said:
The left over files is due to the program exiting when it did... I will fix that in next beta...
Click to expand...
Click to collapse
I figured as much, but thought you should know.
DizzyDen said:
For now you may have to run as administrator...
Click to expand...
Click to collapse
I ran it this way and got the same behavior.
I'll keep a lookout for further versions, test them and report.
Beta 5 is up... OP updated to include Java requirements... thank you mr_fosi for pointing this out.
RASTAVIPER said:
Good job!
Can you explain more about how rom is being affected?and what to check?
Sent from my phiremod for Nook using Tapatalk
Click to expand...
Click to collapse
Did you find the information in the thread linked in response to your questions?
TY mellopete for that.
- Plugged NC into USB port.
- Copied new B5 exe and n87 zip to java\jre6\bin directory.
- Ran exe as admin.
- Prompted for .zip check ("is this correct") and it was, so I OKed it. Not OKing it gave me the option to browse for the file, which I cancelled, resulting in a termination of the prog with a few more dialogs. Any extracted files were cleaned up an prog close, except for adb.exe (which I deal with below).
- Re-ran, exe, chose the detected n87 .zip.
- Displayed correct serial.
- Displayed correct generated 17-digit IMEI.
- Dialog contents "Modifying" gave error "Unable to open file", which I OKed.
- Several more dialogs flew by in rapid succession without error, ending with "Updating ROM" overlaid by "Updated ROM file has been saved as: cm_encore_full-87-IMEI.zip".
- Not all ancillary files were cleaned up. Two files remained: 1) IMEI.fix, a plain txt file containing the correct code to insert the generated IMEI and 2)adb.exe which could not be removed because it was still running the devices server. Running "adb kill-server" in the java\jre6\bin directory allowed me to remove adb.exe.
- A check of the modified smali showed only one instance of "getDeviceId" indicating that the smali had not been modified to add the code to spoof the IMEI.
I would also not have been able to eject my NC, had I tried, until I killed the adb server. Looks like one more line of code to add before cleanup.