>>>> In a post further down, I have released a updated zip file which contains the 2ndihkvc program as well as its source as well as few support scripts to allow experimentation with this mechanism of multiple user spaces <<<<
Hi All
I have been following the below thread, as well as working on my own on some of the concepts. You can get the details till now from my posts in the below thread.
http://forum.xda-developers.com/showthread.php?t=1378886
I was not able to get the SETREGS to succeed in setting PC required for the current/existing 2nd-init logic, nor wait was waiting to lock the process, SO I tried a new and simpler alternate method for triggering/execve the init process a 2nd time using only POKE and it seems to have succeeded. I am guessing this based on my nooktablet having got messed up and it keeps rebooting again and again when it reaches my logic potentially. I have to restore back to factory settings and try afresh in the morning (Well it is almost morning ;-) now here) with few more debug messages to pin point it fully.
The code I am injecting directly into init process is in the attached txt file which is actually a .s (assembly file). (NOTE: Currently I am not handling environment variables, not sure if that is causing my boot to keep looping).
In turn the logic to hijack the init process and inject the code is as simple as
Step1) PTRACE_ATTACH
Step2) PTRACE_GETREGS
Step3) PTRACE_POKETEXT (Regs.ARM_pc, code to inject)
Step4) PTRACE_CONT
Step5) PTRACE_DETACH
I will upload the code in a day or two - however the jist of the logic is above, if anyone wants to experiment on their own.
NOTE: The code is very simple and experimental and expects the pc address to be known before hand to massage the .s file appropriately.
NOTE: The above algo with the corresponding .s file is still EXPERIMENTAL and also requires additional shell scripts to get access to the boot flow to trigger the hijack. And the current code will break the nooktab booting, so don't experiment this logic and the .s file unless you know what you are doing.
NOTE: I am not that much into Custom Roms etc, so don't expect anything much shortly wrt Custom Roms etc, this is just a experimentation for myself and to feel happy inspite of BN removing some useful features like sideloading as well as forcing a signed bootloader on everyone.
can you make a 2-init zip like on the milestone
http://forum.xda-developers.com/showthread.php?t=998425
because then the devs can go on and make a recovery
Bit more exploration with init hijacking - 2ndihkvc src package for EXPERIMENTATION
Hi,
NOTE: Source code package is attached with this message. However this is WIP and provided for anyone wanting to EXPERIMENT on their own parallel to me. Because I think the basic logic is done now. It is more of cleaning up the init rc files and or killing some additional tasks before restarting init or some such things HOPEFULLY (NO harm in hoping and being positive . HOWEVER NOTE that the current version will loop your boot and fail. I have put a timed triggering logic to try and reduce the risk, check out the documents in the package, but it can factory reset or worst case wipe your partitions and render the nooktab dead.
After yesterdays initial init hijacking, I have cleaned up the .s file so that it passes the Args properly as well as added the environment variables set by Android by default. Also the ptrace code I have updated to do relocation (using a simple custom table) of injected code. Also rather than a minimal ptrace code, I have put a bit more full fledged one with my logic as well as skrilax's logic as well as reg dumping and few other stuff to help experimenters.
In turn I have cross verified, that init is actually getting restarted and it is running thro the scripts and setting up the properties as specified by my modified default.prop as well as in the process rerunning all the commands/services/prgs.
However some where beyond rild/vold sequence it seems to be blocking and looping the boot. Also I had modified the init a bit, have to check that also once later.
Enjoy and experiment
NOTE: Not sure how to avoid having to put the same message in two threads. I created this thread only becasue the original thread was in the wrong category (i.e non development), when it should have been in development also.
This is interesting. I have minimal experience with assembly, none of it ARM. I would like to help, if possible. I appreciate the work you have put into this. I'm really hoping to be able to have CM7 on this tablet eventually.
Sent from my BNTV250 using xda premium
Potentially working Alternate Userspace in uSD using 2ndihkvc
Hi All,
I have updated my 2ndihkvc package a bit more and now you can boot into a ALTERNATE Android user space in uSD (NOTE: Userspace only and not kernel - locked bootloader doesn't allow alternate kernel).
For this you require to copy your required android /system and /data partitions into a MicroSD card in its 2nd and 3rd partitions which should be ext4 (specified in the init.omap4430.rc file in 2ndihkvc directory).
NOTE: Best way of getting a working /system and /data partitions is to ==> After rooting your Nook and removing all unwanted Apps/Junk, make a copy of the /system partition from eMMC to uSD. Same for /data/partition. Then you can copy what ever additional applications you want in this uSD based Android /system/app or /data/app partition. Thus you can have different sets of Android user space in different uSD cards.
Follow the instructions in INSTALL file for experimenting this on your rooted NookTab. BUT REMEMBER IT IS STILL EXPERIMENTAL. ALSO as a SAFETY FEATURE, as of now it will boot into this ALTERNATE MODE (in uSD) only when the current HOUR is specified in the start2ndihkvc.sh file appropriately. Otherwise it tries to boot into the your normal Andorid system in eMMC. This should hopefull CATCH any mistake, BUT THIS IS NOT GUARENTEED AND THIS IS A DANGEROUS THING TO EXPERIMENT, UNLESS YOU KNOW WHAT YOU ARE DOING.
NOTE: One time it did reboot from my alternate android system, I haven't debugged this yet, as it has not occured after it (Well I have tried only once more) so cann't say one way or the other yet. But definitely, there are some corner cases.
NOTE: If something gets messed up or if something is different or even if there is some corner case in my code, which I haven't handled yet, it may MESS UP your NOOK TAB so EXPERIMENT WITH THIS only if you know how to recover on your own, provided the NOOKTAB is recoverable (90% should be, but NO GAURENTEE).
Now the BRAVE HEARTS can experiment and Enjoy a alternate Andorid system in uSD card.
NOTE: With this one should be able to boot into any Custom ROM after suitable updation of the scripts in my zip file, as well as by copying their /system and /data/ partitions into uSD 2nd and 3rd partitions. AS long AS that Custome ROM doesn't have any specific kernel requirements.
BYPASS Kernel and Ramdisk check for People with UART ACCESS
Hi,
NOTE: THis is based on a initial look at the source code and then the objdump of u-boot.bin. I haven't cross checked this yet, because for now I haven't opened up the nooktab for uart access yet. Also this assumes by default booti command is used for booting in BN uboot. If some one wants to use bootm, then a different location requires to be patched wrt the image loading security check.
If you are a lucky ;-) person working with opened up NookTab with UART access, then basically replacing the memory contents of these two offsets with NOP will 90% BYPASS the security check successfully and allow you to boot a MODIFIED KERNEL or RAMDISK as required.
All offsets specified Assuming u-boot is loaded at 0 (adjust for the actual address where u-boot.bin is loaded, haven't looked into that yet).
Check for Security check of Kernel image is at
[ORIG] 0x48c0 => bne 0x48d8 (0x1a00.0004)
Make this a NOP by overwriting using uboot memory write command to
[MODI] 0x48c0 => mov r0, r0 (0xe1a0.0000)
Check for Security check of RAMDisk image is at
[ORIG] 0x4928 => bne 0x4958 (1a00.000a)
Make this a NOP by overwriting with
[MODI] 0x4928 => mov r0, r0 (0xe1a0.0000)
Someone (Hi Adamoutler, maybe you) with opened up NookTab can try this and tell me if it worked or not.
NOTE: you have to add up the actual u-boot load address to the offsets specified.
UPDATE1: It appears the load address is either
Possibility 1) 0x80e8.0000 OR
Possibility 2) 0x80e8.0000-0x120 (More likely).
Have to dig thro bit more, but one of these two will potentially work.
So that means to NOP RAMDisk security check the offset is
Possibility 1 ==> 0x80e8.0000+0x4928
Possibility 2 ==> 0x80e8.0000-0x120+0x4928 (More likely)
Best is to cross check if the resultant address contains the BNE instruction bytes specified above.
Same concept applies for the Kernel security check Nopping offset.
NOTE: It appears there is a 0x120 size header before the actual u-boot.bin code starts and in turn, when I did the objdump, it included the 0x120 bytes of header also assumed as code. And inturn the full (including the header) u-boot.bin or for that matter the u-boot from emmc seems to load into 0x80e8.0000-0x120.
UPDATE 2:
Code around the locations to be noped to help identify the same in memory, in case my offset calculations are wrong
48b4: eb0030f1 bl 0x10c80
48b8: e59d3010 ldr r3, [sp, #16]
48bc: e3530000 cmp r3, #0
48c0: 1a000004 bne 0x48d8
48c4: e59f0104 ldr r0, [pc, #260] ; 0x49d0
48c8: e594100c ldr r1, [r4, #12]
48cc: e5942008 ldr r2, [r4, #8]
48d0: eb0015db bl 0xa044
............
491c: eb0030d7 bl 0x10c80
4920: e59d3010 ldr r3, [sp, #16]
4924: e3530000 cmp r3, #0
4928: 1a00000a bne 0x4958
492c: e59f00a4 ldr r0, [pc, #164] ; 0x49d8
4930: e5941014 ldr r1, [r4, #20]
4934: e5942010 ldr r2, [r4, #16]
4938: eb0015c1 bl 0xa044
UPDATE 3: ... for a rainy day in future ;-)
UPDATE 4: For maximum success, first try a changed RAMDisk rather than Changed Kernel. If Changed Ramdisk works then try Changed Kernel (THere is one more thing in Code, which I am not sure if it will impact a modified kernel or not yet, only way is to experiment).
How can I run 2ndihkvc just to load a new default.prop using the existing userspace? What I did so far was to remount / in rw, updated default.prop, pushed 2ndihkvc to /data/local/, changed permissions to 755 and executed. Here is the output
Code:
# ./2ndihkvc -p 1 -w 0 -c 0 -m 2
INFO:2ndihkvc:v30Dec_2020:
INFO:2ndihkvc: Tracing process with pid = 1
INFO:2ndihkvc: NewPrg = /init
WARN: RESPECT_WAIT disabled
WARN: Mode = MODE_INJECT_HKVC2
INFO: ContType = CONTINUE
INFO:2ndihkvc:PTRACE: Attached to (1)
INFO:2ndihkvc: Giving 2 secs to the likely traced process
ERROR:2ndihkvc:WAIT:Failed (No child processes)
INFO:2ndihkvc:hkvc2: InjectAddr (Regs->ARM_pc) = 0xffff0520
INFO:2ndihkvc:hkvc2: /init found at offset 0x100
INFO:2ndihkvc:hkvc2:ProgramToExecute: /init replaced with /init
INFO:2ndihkvc:hkvc2: At offset 0x208 relocating from 0x100 to 0xffff0620
INFO:2ndihkvc:hkvc2: At offset 0x200 relocating from 0x208 to 0xffff0728
INFO:2ndihkvc:hkvc2: At offset 0x280 relocating from 0x288 to 0xffff07a8
INFO:2ndihkvc:hkvc2: At offset 0x288 relocating from 0x300 to 0xffff0820
INFO:2ndihkvc:hkvc2: At offset 0x28c relocating from 0x307 to 0xffff0827
INFO:2ndihkvc:hkvc2: At offset 0x290 relocating from 0x312 to 0xffff0832
ERROR:PTRACE:POKE failed at location ffff0520
INFO:2ndihkvc:PTRACE: Continue/SingleStep ...
INFO:2ndihkvc: Detaching...
ERROR:2ndihkvc:PTRACE: Failed DETACH (No such process)
#
Do I need to push your init to /system/2ndihkvc/init? I am just trying to play around with it and Adam's BHT just to see what I can do them. Thanks.
Hi Brianf21,
As specified in the INSTALL file with in my zip
Copy my 2ndihkvc.zip file to /data/local/tmp
Then mount /system in rw mode.
Next unzip 2ndihkvc.zip into /system. It should create 2ndihkvc folder.
Next run ./install.sh from with in 2ndihkvc folder.
This will setup the boot process to start into 2ndihkvc. And it inturn will restart init with new set of init.*.rc as well as default.prop files.
Have a look at the 2ndihkvc folder, it already contains a default.prop file. If you want to change anything in default.prop then do the changes in this default.prop in /system/2ndihkvc folder.
Also remember to change the time check in start2ndihkvc.sh file in /system/2ndihkvc folder to the current hour, when you will be experimenting. Otherwise, it will not run 2ndihkvc, but continue with the normal Android init flow.
Cross check my INSTALL file once again for the details/steps to setup 2ndihkvc.
Once you have done the above. When you restart your system, it will trigger 2ndihkvc as required and the default.prop will be the new one which you would have edited/updated in /system/2ndihkvc/ folder.
NOTE: Looking at the address, it seems like you had tried 2ndihkvc once before in the same session. Try following the install step specified above/In the 2ndihkvc zip file and see. There is a minimally modified version of init.omap4430.rc and default.prop already in the 2ndihkvc folder, modify those if you want to modify them. This is because start2ndihkvc.sh will copy these files from /system/2ndihkvc/ folder when it is run to restart init.
I will have to read more, to avoid setting up system and data up on an sdcard. Once the setup is done, will it always hijack init for every following boot until it is removed or only one reboot? i am just to get a clearer picture of what's going on, I wanted to just see the hijack of init work independently of the other processes.. I kind of like to break things down into parts so I can get a better understanding of the entire process. Thanks for the work you've out in so far.
hkvc said:
Hi Brian21,
As specified in the INSTALL file with in my zip
Copy my 2ndihkvc.zip file to /data/local/tmp
Then mount /system in rw mode.
Next unzip 2ndihkvc.zip into /system. It should create 2ndihkvc folder.
Next run ./install.sh from with in 2ndihkvc folder.
This will setup the boot process to start into 2ndihkvc. And it inturn will restart init with new set of init.*.rc as well as default.prop files.
Have a look at the 2ndihkvc folder, it already contains a default.prop file. If you want to change anything in default.prop then do the changes in this default.prop in /system/2ndihkvc folder.
Also remember to change the time check in start2ndihkvc.sh file in /system/2ndihkvc folder to the current hour, when you will be experimenting. Otherwise, it will not run 2ndihkvc, but continue with the normal Android init flow.
Cross check my INSTALL file once again for the details/steps to setup 2ndihkvc.
Once you have done the above. When you restart your system, it will trigger 2ndihkvc as required and the default.prop will be the new one which you would have edited/updated in /system/2ndihkvc/ folder.
NOTE: Looking at the address, it seems like you had tried 2ndihkvc once before in the same session. Try following the install step specified above/In the 2ndihkvc zip file and see. There is a minimally modified version of init.omap4430.rc and default.prop already in the 2ndihkvc folder, modify those if you want to modify them. This is because start2ndihkvc.sh will copy these files from /system/2ndihkvc/ folder when it is run to restart init.
Click to expand...
Click to collapse
brianf21 said:
I will have to read more, to avoid setting up system and data up on an sdcard. Once the setup is done, will it always hijack init for every following boot until it is removed or only one reboot? i am just to get a clearer picture of what's going on, I wanted to just see the hijack of init work independently of the other processes.. I kind of like to break things down into parts so I can get a better understanding of the entire process. Thanks for the work you've out in so far.
Click to expand...
Click to collapse
If all you are interested is run 2ndihkvc with a modified default.prop but no other modification (i.e no uSD /system and /data partitions), then
a) overwrite the init.omap4430.rc in /system/2ndihkvc with the one in / . However if you have already booted into a system with 2ndihkvc then in /data/local/tmp.
Or if required you can directly edit the init.omap4430.rc in /system/2ndihkvc and update the mount commands in there to mount from emmc instead of uSD.
b) Remove the 2 lines in restart-userspace.sh corresponding to mount -o move ....
This will allow you to boot into a system with a modified default.prop but no other change from a runtime perspective (unless I have forgotten something).
Also 2ndihkvc will be applied each time boot into NookTab provided the current hour matches the hour set in start2ndihkvc.sh. Once the current hour no longer matches the hour set in the sh file, it will boot into the normal BN Nooktab environment.
NOTE: I purposefully modified the init.omap4430.rc file to replace the /system and /data from emmc to uSD, so that if someone is experimenting something, he doesn't corrupt the emmc easily as long as he doesn't become root user. HOWEVER with root access emmc can still get corrupted if one is not careful, because eMMC is still available and mounted.
tried but rebooted few times until factory reset kicked in
Hi,
ok. maybe a bit too optimistic, but I compiled ICS for pandaboard and put the system to sd card (partition 1 ext4 empty, partion 2 ext4 system with panda stuff, partion 3 data, partition 4 empty).
I hit adb reboot and the device booted a few times until it restored factory. Uff.
Is there a way without serial console to see what happens?
There's also small glitch in install.sh. It doesn't find init.rc in /system/2ndihkvc.
Rgds,
Chris
chrmhoffmann said:
Hi,
The device booted a few times until it restored factory. Uff.
Click to expand...
Click to collapse
If it's counting boots like the Nook Color you can stop it by running this (if the rom partition is mounted at /rom-- it's p2 on nc and I guess p5 on nt).
chrmhoffmann said:
Hi,
ok. maybe a bit too optimistic, but I compiled ICS for pandaboard and put the system to sd card (partition 1 ext4 empty, partion 2 ext4 system with panda stuff, partion 3 data, partition 4 empty).
I hit adb reboot and the device booted a few times until it restored factory. Uff.
Is there a way without serial console to see what happens?
There's also small glitch in install.sh. It doesn't find init.rc in /system/2ndihkvc.
Rgds,
Chris
Click to expand...
Click to collapse
Hi,
The missing init.rc is not a glitch, I purposefully left it out while packaging, so that one doesn't modify it drastically and botch up the boot. init.4430.rc is the only thing required to change the mount partitions.
Also if you are using my default start2ndihkvc.sh script, then it has a time check, so while xperimenting if you have goofed up. Just let the time you have set in this script pass by (i.e don't power on), then it will automatically go back to the stock NT boot, thus avoiding the factory reset.
Related
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.
Zen's Backtrack 5 For HD2 (and other) Android Smartphones
V0.3
----------------------------------------------------------
New app for loading this (and other) Linux Systems! - https://play.google.com/store/apps/details?id=com.linux.autoloader
Image and app support can be found here --> http://www.zenfulapps.com/
Packed - 640mb
Unpacked - 2.6gig (fits on 3.3 img now.)
--GRAB THE UPDATED SCRIPTS ATTACHED TO THIS POST, THEY ARE NOT PACKAGED INTO THE ZIP--
--Scripts are set to load from EXT4 partition, when i modify them for the .img's ill add them to the script pack--
--if you have .img mounting scripts from previous versions, they will work, as long as file names and directories match--
V0.3 Download
http://www.zenfulapps.com/Android/backtrack5-0.3.7z
(MD5 is still the same
MD5sum (of .7z file) - 9a4796f0ed96e03579c2b4a684d026f5
--------------------
Script pack contains
--------------------
btgo - mounts BT5, and askes how you would like to start, CLI or VNC
bts - stops BT5, and unmounts everything for it.
btl - used to login to bt5 after it has been mounted, to avoid all those "resource busy" messages
mkcore - directory installation and swap file creation
-------------
What you need
-------------
Rooted Android Smartphone
Linux on PC
Busybox installed on your device
SDcard adapter or reader, if neccesary
----------
Lets begin
----------
There are 3 different ways you can do this:
1. Fresh install on EXT4 Sdcard partition ( I HIGHLY recommend this method if possible, much better, a bit faster (no double loops to write to)
2. Create Fresh .img
3. Replace old BT5 system .img
=========================================
1. Fresh install on EXT4 Sdcard Partition
=========================================
This portion of the guide is to install BT5 on a FRESH EXT4 partition on your SDcard. Throughout this porcess, you will:
Backup your current sdcard (EVERY PARTITION, this is why we use PC-linux and not windows)
Fully erase and repartition your SDcard
Replace Android system and user data
Install BT5 on third partition
prepare system for chroot and VNC connection
----------------------------------------
Boot into your Linux operating system. **I DO NOT recommend using virtualbox or vmware, as drivers for usb and SDcard connections arent direct, things can go wrong.**
Shutdown your phone, and remove your SDcard. Do not use adb, or any other tools to do this.
insert your SDcard into your computer (adapter or reader yada yada) and mount every partition.
Make careful note of what is on which partition. safest way to back everything up is through the command line with the command
Code:
sudo cp -Rfvp /media/your-sdcard-partition/* /where/your/backup/folder/is
Do this for each partition, whether you have 1, 2, 3, or more.
In my case, my backup directory looks like this:
Code:
[[email protected] sdcard-backup]$ ls -l
total 12
drwxrwxr-x. 2 hookup-cellular hookup-cellular 4096 Sep 13 18:48 ext2
drwxrwxr-x. 2 hookup-cellular hookup-cellular 4096 Sep 13 18:48 ext4
drwxrwxr-x. 2 hookup-cellular hookup-cellular 4096 Sep 13 18:48 fat32
(ignore the empty directory sizes, my TRUE backup folder is MUCH more vulgar and i wont display it publicly, people may tear thier eyes out )
After everything is backed up, open your partition manager (in Gnome it is gparted, cant remember the name in others)
Navigate to your SDcard, and DELETE every partition. every one.
afterwards, recreate them using this strategy:
partition 1 - FAT32 size = total sdcard size minus ext2 and ext4 partition sizes
partition 2 - EXT2 size = 256mb, 512mb, 1gb, depending on how you like your apps2sd
partition 3 - EXT4 size = size you want for linux, minimum should be 4gb (mines at 10gb, i like my linux and got 3 different ones on it at the same time.)
When you are done, copy back your fat32 and ext2 stuff using the SAME COMMAND AS ABOVE (sudo cp -Rfvp from/here to/here)
Now, unzip/tar the .tar.gz package. I recommend extracting it to your pc before trying to put it on your sdcard.
Using the copy command above, put the extracted files onto your sdcard's EXT4 partition.
Double check the partition (navigate to it in nautilus or whatever filemanager your using) and ensure that it has the system copied over properly. You should see /boot /etc /root /sys so on and so forth, NOT just one folder with all of those inside of it.
Insert your SDcard, power on your phone, go to terminal emulator, and enter this:
Code:
su
cd /sdcard/scripts
sh mkcore
Swap file is damn near neccessary if your planning on using any GUI tools (armitage, zenmap)
Your directory structure is now in place, swap file created, and you start BT5 by typing (from /sdcard/scripts OR /data/linux):
Code:
sh btgo
=================================
2. Fresh Image Creation
=================================
for this, we use the dd command and mkfs.ext4 command.
Code:
dd if=/dev/zero of=/path/to/where/you/want/the/img bs=1M count=3300
Change this command as needed, running it as is wont do anything good. Change the of= to where you want your img to be located.
next is mkfs.ext4
Code:
mkfs.ext4 /path/to/where/you/want/your/img
select yes when it cautions about "not a block device"
When this is finished, mount it using these commands:
Code:
su
-your password-
mkdir -p /mnt/bt5img
mount -t ext4 /path/to/your/img /mnt/bt5img
now, extract the BT5 package to a place on your Computer. When finished, run this command:
Code:
sudo cp -Rfvp /path/to/bt5/core/* /mnt/bt5img/
changing parameters accordingly.
After this, copy the .img to /sdcard/bt5 and run the start scripts from your terminal emulator.
================================
3. Replace Existing Image
================================
Mount your bt5 image, erase what is inside of it, and copy in the new system:
Code:
su
-your password-
mkdir -p /mnt/bt5img
mount -t (your ext type) -o loop /path/to/your/bt5/img /mnt/bt5img
rm -Rfv /mnt/bt5img/*
cp -Rfvp path/to/bt5/core/* /mnt/bt5img/
unmount your .img, place it on your sdcard, and your all set.
==============================
Changes in v0.3
==============================
- Trimmed alot of fat, fits inside of 3.3 image now, though space is SEVERLY limited (removed CUPS and sound stuff, who needs to print from within thier phone anyways?)
- various small changes for performace improvements.
- a few new tools installed, but not tested
- restored my personal version that i nuked. It works now.
NEW STUFF TO COME, STAY TUNED!!!
First off, My apologies for starting a second thread on this, I've made ALOT of changes and i feel the first thread is dead and useless. (Reprimand me if needed
-pics coming once I find my camera could be a small while-
---------------------------------------
Backtrack5 for HD2 - v0.2
Customized by z3n
My goal: the perfect stealth
tool in your pocket
just one tap away
---------------------------------------
========================
Codename
Squeaky Wheel
========================
Updated, check second post for changelog
========================
DOWNLOAD
========================
Please use the scripts attached at the bottom of this post instead of the packaged ones, and i havent had a change to update the full image zip with it (uploads take a while )
V 0.2
Part 1 - http://www.megaupload.com/?d=D0MQVAS4
Part 2 - http://www.megaupload.com/?d=M2MRYLAH
MD5 - 06225e18cdbfee6f88daf7e9ee3a1163
SHA1 - eeba19e53565a1643703cf8938be2f8cfc12db9a
V 0.1
Part 1 - http://www.megaupload.com/?d=83B22Y00
Part 2 - http://www.megaupload.com/?d=SB98AA19
mirror - (NOT interchangeable)
Part 1 - http://www.megaupload.com/?d=HU320Z81
Part 2 - http://www.megaupload.com/?d=QN9C560Z
Checksums of bt5.img
MD5 = 863e6db99e5207a81ad0df7d13998235
SHA1 = c84d8f27df8b9b51059e5a6b09e65853f11de970
7zip required to extract.
Just over 1gb packed, unpacked is 4.9gb.
========================
INFO
========================
This is my first release of a customized, working, mostly stable BT5.
Many things have been added, taken out, and configured to be used within the Android system. For a full list, please see the bottom of this post.
Mounting is different than most other linux .img installations, allowing for a full (and expandable) image.
V 0.2 Now has a swap file created when you run the mkdirectory script. This swap file is necessary, as with all my tests, When you run VNC with most of the major tools, there's a high chance of the phone running out of memory (im running no extra apps, completely stock Hyperdroid)
(if you have a swapfile already, you can say no to creating another, just make sure that the file is located at /data/bt and named btswap.)
**This image is in ext4, make sure your kernel supports it!**
**Everything tested on Hyperdroid-CM7 by pongster**
==============
INSTALLATION
==============
You need:
-Full Nandroid Backup in case something goes batty
-16gb HD2
-ext4 support on your ROM/kernel (lost my ext2 image due to my own stupidity, will create another matching one later)
-Linux on PC (to create the ext4 partition)
-Busybox (from market)
-VNC Viewer (from market) (optional)
FAT32/EXT4 Split card
---------------------
1.
Back up your HD2 and SDCard to safe places (off of the phone and sdcard)
2.
Boot your linux installation and open partition manager. erase all the partitions on yor SDcard. Then create them in this order.
1. FAT32 - size of this is total sdcard size minus 6.5g (for bt image) minus 100mb for aps2sd
2. ext2 - 100mb
3. ext4 - 6.5 gb
3.
Copy the bt5.img to the root of your third partition.
copy the bts folder to the root of your FAT32 partition.
4.
if this is your first time using this script/image, run the mkdirectory script first with
Code:
su
sh /pathtoscripts/mkdirectory
Load up your android terminal and type
Code:
su
cd /path/to/scripts
sh go
5.
Now it asks you if you want to log in to the console or start vnc automatically. (check log for port, usually 5901 or 5902)
DEFAULT VNC PASSWORD IS: toortoor
DEDICATED SDCARD
----------------
Same as everything above, minus the FAT32 partition.
"sh ded"
starts for dedicated SDcard instead of
"sh go"
Proper Shutdown Procedure
=====================
Stop script has been modified to shutdown backtrack and all of the (usual) programs that stop things from unmounting properly.
Exit any VNC connection you currently have.
1. Run sh stop (from your scripts location)
2. Reboot phone as a precaution.
One thing i did personally to make this easier was load the scripts onto /data/bt, so switching SDcards or locations doesnt matter.
(I also changed the terminal start directory to my scripts folder easy quick access)
=======================
Main Features I've gotten to work
=========================
-Clean mount/umount, as long as VNC and MySQL are killed BEFORE exiting the chroot - stop script kills these now
-Apps no longer disappear for good with sdcard removed, only disappear until SDcard is reinserted (apps2SD/loop device problem, any ideas?)
-MySQL for metasploit
-Metasploit working
-Armitage working, missing some "Attack" options (looking into it)
-Zenmap installed
-OpenVPN installed
-Traffic analysis possible with tcpdump (local only)
-Enables possibility for FakeAP attacks
-macchanger works (kinda, phone needs a reboot for original MAC to return)
-Armitage Launcher placed on Desktop (takes a while to load, be patient)
-Terminal Launchers in various places (updating may randomly remove your terminal, synaptic placed on desktop as standby to redownload terminals
-guake installed (drop down Terminal, makes commands easier to see while working) (not configured to a key yet)
This probably works with other Android phones too. If you change the scripts, and as long as it has a external SDcard you can partition.
if your using a different phone, this is untested unless specified otherwise.
-boot and shutdown scripts run clean as long as VNC and MySQL are shut off(in almost all cases)
@ XDA
http://forum.xda-developers.com/show....php?t=1152994
PASSWORDS
------------
MySQL - user: root pass: toor
VNC - User: root pass:toortoor
sys pass - user:root pass:toor
(I know, standard ones, but this should answer a few questions)
===============================
Thanks
===============================
anantshri - for the original scripts and BT5 img for android
BT dev team - (of course )
and all of you
===============================
Information, bugs, and oddities
===============================
One important thing, While performing heavy operations, its normal for your screen to not turn on for a while if it turns off. Dont panic, just give it some time to finish whatever you were running and your phone will be back to normal again. DO NOT PULL THE BATTERY UNLESS ABSOLUTELY NECESSARY.
To avoid this, get wakelock (known to cause problems) or set your screen timeout to some large number.
Swap file will help with alot of this.
These are the features I've tested out so far.
No major changes to anything, (except new packages) just configuring everything i see.
If you find anything you want added in or that is acting odd, please let me know. Same goes for if you fix something!!
Overall
-------
-Repo's activated, most things work (upstart processes fail, for now)
-startvnc and stopvnc no longer give that pesky USER error
-startvnc starts mysql database for metasploit
-stopvnc stops mysql (mostly, invoke ps -A and look for mysqld. Kill it with fire(-9) if need be)
-network traffic is capture-able with tcpdump, with wifi hotspot activated
-working on adding in a swap partition on sdcard (if possible)
-openoffice installed
-openVPN installed (the quieter you become...)
-Removed Zoho Web services
MySQL
-----
default user - root
default pass - toor
-Starts automatically with startvnc
-stops automatically with stopvnc
-start manually by invoking "mysqld"
-Only runs as root (for now)
-Console hangs when it is manually loaded or shutdown, service continues running though. killall --signal 9 mysqld if needed.
Metasploit
----------
-Loads up alright (45-90 seconds)
-MySQL already set as default DB
-Must manually connect to MySQL DB each instance of metasploit by invoking (from msf) db_connect root:[email protected]
-working on a possible way to limit cpu consumption to prevent system hangs(cpulimit does some nasty things)
-So far, this is the only connection string ive been able to get to work: root:[email protected]
Armitage
--------
-Takes forever to load (30 seconds for connect screen, 4 minutes or so for main client)
-Causes system hangs frequently (to minimize this, leave the vnc server on your screen, and set the display timeout to 10 minutes-switch it back when done to conserve battery life)
-So far, this is the only connection string ive been able to get to work: root:[email protected]
-Can Crash phone if running too big of an operation (Max Phone memory problem, fixed in v.2 with swapfile added)
Zenmap
------
-Slows phone down (incredibly bad with more complex scans, of course)
-Some Complex scanning options can crash phone (Nothing damaging has happened)
-will attempt to throttle cpu usage in the future
-Can Crash phone if running too big of an operation (Max Phone memory problem, fixed in v.2 with swapfile added)
Aircrack-ng suite
-----------------
-Aircrack-ng works
-Airodump-ng doesnt work (needs monitor)
-Airdecap-ng untested
-Airdecloak-ng untested
-Airbase-ng doesnt work (needs monitor)
-Airmon-ng doesnt work (needs monitor)
-Aireplay-ng doesnt work (needs monitor)
-Airdriver-ng doesnt work (yet)
-Airolib-ng works (doesnt do anything yet)
-Airserv-ng doesnt work (needs monitor)
-Airtun-ng doesnt work(needs monitor)
Plus lots of stuff for the future, stay tuned!!
http://forum.xda-developers.com/show....php?t=1152994
In the future
=========
-nessus
-Booting via HD2 Toolbox by d4n14l (sp?)
-Custom kernel (WAYYYY down the road, but working on it)
and more
--Copyrighted by z3n, 2011
(just kidding, but it looks good )
Looks good will give it a go.
Thanks for sahring
I we could get our wifi card into monitor mode --> awesome!!!!
Thanks to z3nful & everyone made this possible!
Enjoy everyone
The next release is going to be faster, stabler, and more useful
I'm also working on a round-about way for packet injection and monitor mode
Stay tuned
Sent from my Hyperdroid Pocket Laptop
cool.. good job man..
Are you trying to patch the wifi drivers ? =D
Holy crap.....this is a dream in the making Bring on monitor mode and packet injection
I've done some researches.. and found out that many devs have tried making the driver to work on the Monitor mode.. but they failed to do that.
It looks to me that Backtrack on HD2 is kinda useless.
Not useless, just last night I ganked my roommates computer with my phone
As far as monitor mode and injection go, sadly, they may be right that its not possible, but I got some ideas that may make it work, I just need to hammer out some kinks in BT first
And who needs monitor when you can fakeAP?
"Make them hand you the keys and you don't have to break their Window(s)™"
Sent from my Hyperdroid Pocket Laptop
A m a z i n g
Next release is going to be even better this 5gig image is almost full, so I'm going to expand it to 6gig, along with instructions on how to expand your own image if that's to large or want even more space.
Btw, Wine should be good to go in the next one
stay tuned!!
Sent from my HD2 "Pocket Laptop"
I would love to see some Sceenshots (or better: a video) here!
Lol will do, gotta go find my 10 year old Polaroid I've been using this phone or all my pics and videos, so this could be tricky
Sent from my HD2 "Pocket Laptop"
good to see development beyond just starting up the image... I would be taking some pointers from here for my device too....
hope you don't mind that....
Not at all, I've been trying to track down your name again so it can add you to the credits part, as the basis of the scripts was yours lol, I just changed the loops and mounting structures around a bit, and added some stability checks.
The scripts for this image are slightly out of date but I got new ones going up once I have time they should fix a few of the small eerrors people get while mounting
My next version is a little ways out (works gotten crazy busy lately) but it'll be out eventually
Sent from my HD2 Pocket Laptop
Not Booting!
Hi Thank you for sharings this up!!! this is like a dream for alot of people.
i have followed all your steps but i have a problem when i run the scripts, the folders dont get created because when i run go i get a bounch of folder not found.
my SD card had some differences is a 16GB
with
Fat32
Ext-sd/ EXT2 -->1GB
EXT3 --> 100MB
EXT4 --> 6.5GB
could this setup causing the script to look on the wrong partitions? i have alot of time with out playing with Shell scripting but i would like to know if that is the place i should start looking for a fix
-edit- just double checked (forgot scripts were on my phone... its been a long week lol) and you should just need to change the mount -t ext4 /dev/block/vold/179:3 to /dev/block/vold/179:4
Also, did you run the new mkdirectory script? If you have the one packaged with the image its out of date. The attachment on the fist post has the updated ones
Ignore all mmcblk's
For another "buffer" partition, you need t point the sdcard parts (mmcblk0p* and vold/179:*) to what yours are in /dev/block. In your case I think you just need to change any vold/179:3 to 179:4. If you go to /dev/block/vold it will have folders from each partition (they are numbered 0 and up, but 1 would be your fat32, 2 is ext2 so on and so forth)
When I'm near my computer ill figure out the full ones for you
Sent from my HD2 Pocket Laptop
can I get it for Htc desire..??
It should work, as long as you have a big enough sdcard, your phomes kernel suppers ext4, and you might have to change a few small variables
Sent from my HD2 Pocket Laptop
I merged the latest B&N 1.4.2 code into my 2nduboot git repository on github: https://github.com/bauwks/Nook-Tablet
It still compiles and works on my 16GB NT and others have have successfully booted the 8GB NT model.
The instructions for building are the same as before:
cd distro/u-boot
PATH=/usr/local/arm-2010q1/bin:$PATH
make nt2ndboot_sd_config
make
./tools/build_nt_2ndboot_img.py -o test.img u-boot.bin
cp test.img /media/boot/flashing_boot.img
For those of you that wish to try it without messy compilers, this zip file (http://dl.dropbox.com/u/40331061/bauwks-boot-1.4.2.zip) contains:
MLO from 1.4.2
u-boot.bin from 1.4.2
flashing_boot.img <- the 2nd uboot
Unzip it to the root directory on an SD card, drop in a boot.img you want to test and go. If you see the box then it's booting off the SD card and should then load your boot.img.
Great job bauwks!
Someone with an 8 gig model please test this. If it works, I can begin working on a resurrection solution for the NT 8gig.
FWIW "Cyanoboot" (w/menu and all that) has been tested and works w/512 model as well.. stay tuned.
Incidentally, my tester did seem to indicate that sd card boots need to be tethered. FWIW
so going off of what i have read heres what ive gotten so far.
format the sd card to fat32 and make sure the flags for boot and lba are on.
transfer the files to the root directory of the card (im assuming this doesnt mean try to write any of the image files to the card).
put the card in the nook.
press the power button and it should boot from the sd card.
this is everything that i have done and the device wont power on while the card is in the slot but i can take it out and it works fine.
am i doing something wrong?
anyone else have this issue?
EDIT: booted after i changed the partition size to 50 mb, but it didnt change or add anything.
just for clarification. Even if this allows boot and root from SD card, people should still not be using this new found access to flash roms designed for the 16gb on the 8gb? I say this because, last I read the acclaim update bricked the 8gb tablet.
that could be mine, but the tech at b&n says it's hardware problem so I'm not too sure. the flash was going well half way and when I stepped away for a couple minutes and came back to find it bricked.
albertwertz said:
just for clarification. Even if this allows boot and root from SD card, people should still not be using this new found access to flash roms designed for the 16gb on the 8gb? I say this because, last I read the acclaim update bricked the 8gb tablet.
Click to expand...
Click to collapse
Actually, I believe if the kernel is 1.4.2, there should be no problems and CM for the nook tab should have 1.4.2, we would need gonce to come in and verify though.
albertwertz said:
just for clarification. Even if this allows boot and root from SD card, people should still not be using this new found access to flash roms designed for the 16gb on the 8gb? I say this because, last I read the acclaim update bricked the 8gb tablet.
Click to expand...
Click to collapse
As long as the bootloader and kernel are based on the latest kernels and such there shouldn't be a reason that both devices can't run the same roms. The issue with the acclaim update is that it flashes the bootloader/kernel stuff from 1.4.0 which doesn't take into account the variances between both devices. Since the 1.4.0 bootloader doesn't know how to take into account the 512 memory you get a bricked device. If it were possible to create an acclaim update with the newest 1.4.2 bootloader/kernel and a 1.4.0 file system except for a couple of possible driver related changes the 1.4.0 file system would work fine on the device.
However, as long as we stick to the same guidelines that BN will, any rom we release should work just as effectively on both devices. This is because BN has designed the latest BNOS to run on both devices so that they only have to release one update file in the future as opposed to support for two devices with so few differences between them. As long as we take into consideration both devices by using the latest bootloader/kernel sources, it should work on both devices without a hitch.
I am sorry to sound so dumb but I came to the party late. (Just bought the 8gb NT yesterday.)
I did create the 50meg partition and loaded the files to it. It boots to the box but I am uncertain of where to go from here. I have tried to find related threads but I have not been successful.
Please be kind.. ;-)
So far this is the only thing that has been release for the 8gig. I haven't seen any CWM or 1.4.2 ROMs yet. I know that they are currently working on CM7 for 8gig and an Ubuntu recovery.
raywaldo said:
I am sorry to sound so dumb but I came to the party late. (Just bought the 8gb NT yesterday.)
I did create the 50meg partition and loaded the files to it. It boots to the box but I am uncertain of where to go from here. I have tried to find related threads but I have not been successful.
Please be kind.. ;-)
Click to expand...
Click to collapse
@bauwks: The boot.img you provide does not boot completely on the 8GB tablet; it reboots abruptly after /system is mounted. Upon further investigation the culprit appears to be the files /manifest00 and /manifest01 in the ramdisk in boot.img, which contain (what I would assume to be) checksums or signatures of a large number of files under /system. The /init binary seems to include a B&N-specific "feature": it crashes if any of the files listed in /manifest00 and /manifest01 has a different checksum on disk than the checksum specified in /manifest00 or /manifest01. There're a number of differences between the /manifest00 and /manifest01 included in the boot partition of the 8GB version and those in your boot.img (meaning that the system files themselves are different on the 8GB than on the 16GB), which is what causes /init to crash on the 8GB NT, resulting in a reboot.
The simple solution is to delete everything in /manifest00 and /manifest01, because /init only verifies the checksums of files listed in /manifest00 and /manifest01, and will happily ignore everything else. I zeroed out the two files in your ramdisk, rebuilt boot.img and can boot perfectly into the stock software.
This mechanism is really evil on the part of B&N. To modify an Android system file (I discovered this when trying to replace /system/framework/framework.jar), for instance to apply a skin or enable copy & paste, you would need to modify /manifest00 or /manifest01. To modify /manifest00 or /manifest01, you would then need to flash a new boot partition. But to flash a new boot partition, you would need to circumvent the locked bootloader (which you have done - hats off to that). This is the most locked-down Android device I've ever played with.
jichuan89 said:
@bauwks: The boot.img you provide does not boot completely on the 8GB tablet; it reboots abruptly after /system is mounted. Upon further investigation the culprit appears to be the files /manifest00 and /manifest01 in the ramdisk in boot.img, which contain (what I would assume to be) checksums or signatures of a large number of files under /system. The /init binary seems to include a B&N-specific "feature": it crashes if any of the files listed in /manifest00 and /manifest01 has a different checksum on disk than the checksum specified in /manifest00 or /manifest01. There're a number of differences between the /manifest00 and /manifest01 included in the boot partition of the 8GB version and those in your boot.img (meaning that the system files themselves are different on the 8GB than on the 16GB), which is what causes /init to crash on the 8GB NT, resulting in a reboot.
The simple solution is to delete everything in /manifest00 and /manifest01, because /init only verifies the checksums of files listed in /manifest00 and /manifest01, and will happily ignore everything else. I zeroed out the two files in your ramdisk, rebuilt boot.img and can boot perfectly into the stock software.
This mechanism is really evil on the part of B&N. To modify an Android system file (I discovered this when trying to replace /system/framework/framework.jar), for instance to apply a skin or enable copy & paste, you would need to modify /manifest00 or /manifest01. To modify /manifest00 or /manifest01, you would then need to flash a new boot partition. But to flash a new boot partition, you would need to circumvent the locked bootloader (which you have done - hats off to that). This is the most locked-down Android device I've ever played with.
Click to expand...
Click to collapse
Thanks a lot for your detailed analysis jichuan89. I'm kind of surprised the checksums don't match because I took the original boot.img straight out of B&N's 1.4.2 release zip file. Well, at least I know that the bootloader is working on the 8GB model.
odd... I just booted this on my NT 16G...
Code:
Texas Instruments X-Loader 1.41 (Nov 11 2011 - 17:05:18)
Start not on PWRON, skipping power button check.
mmc read: Invalid size
Starting OS Bootloader from MMC/SD1 ...
U-Boot 1.1.4-elation1.4.3_1.4.3.3001^{} (Feb 15 2012 - 18:31:19)
get_sdram_size: 1073741824
Load address: 0x80e80000
DRAM: 1024 MB
Using default environment
In: serial
Out: serial
Err: serial
hw_status 0x23 vbus_status 0x80
MAX17042+UBOOT: battery type=LG
MAX17042+UBOOT: gas gauge detected (0x0000)
MAX17042_STATUS (00h) is 0x0000
MAX17042+UBOOT: BATTERY Detected!
MAX17042+UBOOT:WARM BOOT
No valid max17042 init data found, assume no battery history
uboot verify: 1d CONFIG is 2210 ; should be 2210 & 0xFDFB
uboot verify: 2a RELAXCFG is 083b ; should be 083b
uboot verify: 29 FILTERCFG is 87a4 ; should be 87a4
uboot verify: 28 LEARNCFG is 2456 ; should be 2406 & 0xFF0F
uboot verify: 18 DesignCap is 205c ; should be 205c
uboot verify: 12 Vempty is 7d5a ; should be 7d5a
uboot verify: 25 TEMPLIM is 2305 ; should be 2305
uboot verify: 2b MiscCFG is 0810 ; should be 0810 & cc1f
uboot verify: 2c TGAIN is e3e1 ; should be e3e1
uboot verify: 2d TOFF is 290e ; should be 290e
uboot verify: 2e CGAIN is 4000 ; should be 4000
uboot verify: 2f COFF is 0000 ; should be 0000
uboot verify: 37 FCTC is 05e0 ; should be 05e0
MAX17042+UBOOT: warm config is okay
hw_status 0x23 vbus_status 0x80
Identified DVT or newer, using its charging GPIOs
Disable charging
Powering off!
hrm... nevermind... my device won't power up on even stock right now... it could be low on battery, but oddly it is showing green on the charger.
bauwks said:
I'm kind of surprised the checksums don't match because I took the original boot.img straight out of B&N's 1.4.2 release zip file.
Click to expand...
Click to collapse
I totally agree. A diff between your /manifest00 and the 8GB's /manifest00 shows that the userspace on the 16GB and the 8GB versions are completely different; core Android system libraries like /system/framework/framework.jar, /system/framework/core.jar, /system/framework/ext.jar, /system/framework/core.jar and so on are all different in the two ROMs:
Code:
$ diff nook_16gb_boot/ramdisk/manifest00 nook_8gb_boot/ramdisk/manifest00
160,187c160,187
< /system/framework/ime.jar:0208a82881c097c787c49c40fdb4679487b4b2e9
< /system/framework/framework.jar:540d575dd8b88dceaff9931f5169508f73f53ce8
< /system/framework/input.jar:a52eb0ba70b8f6a0a5e4035ccc49c2a98ed95dd6
< /system/framework/monkey.jar:08e7508dfaa10f8c0eb80fa6abff6e69fb283c80
< /system/framework/javax.obex.jar:5c5685865ac196e0b7e487b145a6e112e695a257
< /system/framework/android.test.runner.jar:6c795691eb3990362e3cd08bf0babe2403bdac73
< /system/framework/am.jar:4d015820c353ad5e92942cc5bce25e431942b94d
< /system/framework/com.bn.cloud.jar:35992cbd24e29ce5366d90128733cae01c2314ce
< /system/framework/com.bn.app.displayinfo.jar:56a0d6a43c55a930d6141444140a10f44dc775f0
< /system/framework/services.jar:4f50684204b449ab45566e86a5a7573d9bedc8d3
< /system/framework/pm.jar:ab289af9add3be4907c2c51fc19bc64021a00836
< /system/framework/com.bn.app.deviceinfo.jar:6eb25c7ec0afa72f123983be3767abd90aef8823
< /system/framework/sqlite-jdbc.jar:c2f75237682f87add7c0ff07c0b844666941c17d
< /system/framework/core.jar:0f8b49f7b38625dc9354235464edd49070f5883a
< /system/framework/svc.jar:b3db35986ceee4e035963648fb66ae8072708e25
< /system/framework/com.bn.authentication.jar:612168ccd4e724e7aa08d2b10d7522b52e1ab4e6
< /system/framework/bncloudapi.jar:46ee63bcd922d52dde46a61377633d76c1cd3ea9
< /system/framework/ext.jar:b9f34ae936d1d2cc1a2d37d8a645e59d393d71d3
< /system/framework/com.bn.app.crypto.jar:f30292d95d4834ddd74d2076ff4352f70893fd02
< /system/framework/com.bn.gpb.jar:6a6c0ba81cf0edb2eb23d5cadcd78dace38bc98e
< /system/framework/core-junit.jar:ef8c3aa523400df6ed0c74a03a1565765fe2acc1
< /system/framework/com.android.location.provider.jar:8d5c848effb81aeb001dfc18b061414b48fd46ef
< /system/framework/com.bn.provider.utils.jar:0cc256eff7b6e0f268a130ddf6bf744e468505e0
< /system/framework/bouncycastle.jar:eaf8716aecb7b5c5404cdd0dc945a0ac5546f76e
< /system/framework/bmgr.jar:cc90fb658bd9373841b23d4a68bb04602be278bd
< /system/framework/com.bn.service.devicemanager.jar:833fca513552ce073f6a28d22fc7f185538b80c4
< /system/framework/com.bn.policymanager.jar:95d54490b9e148385670e836651b0685058cb433
< /system/framework/android.policy.jar:98af166741dd0a8ab1964584e37cbc4c7e825fcb
---
> /system/framework/ime.jar:27146e528c683df58b76492eaab8cf02f5310f1b
> /system/framework/framework.jar:636c3015a7f6e5975e84cc523b578aaeffa45454
> /system/framework/input.jar:21833f73ecd9ccd868cbec6733607fda36bffe22
> /system/framework/monkey.jar:de98f6b9f43dfc30029e240765d56f8284498d39
> /system/framework/javax.obex.jar:616ed1d68673333a9b05b69dc13171d971006ed2
> /system/framework/android.test.runner.jar:edbc28be81077514e6cdedd5018a9cd741622da8
> /system/framework/am.jar:3aed3895f63fb27309dba486ae645f6b3eb447f6
> /system/framework/com.bn.cloud.jar:8182d5d308a46b277a03775c473bf86c3e33b73b
> /system/framework/com.bn.app.displayinfo.jar:858074aa9ec095d8ed4a6e7e880ab376a52ce271
> /system/framework/services.jar:fa3808bcbce9b64fa3cdc1adc322ff783729ef63
> /system/framework/pm.jar:47c08c0de507bd2a5ea71a43004d6ad5f220c986
> /system/framework/com.bn.app.deviceinfo.jar:c3b261f713cd1cd78095d21a53ea5df54cf874dc
> /system/framework/sqlite-jdbc.jar:90a05ffc8aa06c937e0107340af211b9166b204e
> /system/framework/core.jar:4d34e393d8ab0b8f544405ec833af355a5670192
> /system/framework/svc.jar:98aef5fabe53a0771010e83c7e8cb6e1d69aeeb8
> /system/framework/com.bn.authentication.jar:95be7d84b4fddbbcef417e5c1ab3410d9c1cba41
> /system/framework/bncloudapi.jar:9207bdd53e52ee1d721244c4d8eaad7aba828429
> /system/framework/ext.jar:2d582e4793457a35e19e429d5bbac746fc72b2ef
> /system/framework/com.bn.app.crypto.jar:26d118312120b661612ee7335673923064567d63
> /system/framework/com.bn.gpb.jar:739e7ce38c94615130ce3780085496553e6656c3
> /system/framework/core-junit.jar:80a4040d76cd04d85a8fe16e7910365f5994d378
> /system/framework/com.android.location.provider.jar:08628ff32fe0d9ea23e2ae362803cad3e26b6425
> /system/framework/com.bn.provider.utils.jar:5897fdec7612a796824475454414d39dd0e5a6f6
> /system/framework/bouncycastle.jar:8d2cee2830d46e557c52eeea7de21b6abfba1529
> /system/framework/bmgr.jar:89cc7d926e9bdb36e7fe1adeccf0d140fe5d4b90
> /system/framework/com.bn.service.devicemanager.jar:066da8a087d199239e2dc96fd2aa4ab3c364f5c1
> /system/framework/com.bn.policymanager.jar:a7e953e9e550a5ffce357007a97b82c753063b99
> /system/framework/android.policy.jar:48dd1337c5e45830e5d2dc009173cb7622226aad
211c211
< /system/bin/debuggerd:6dea49eb6a8cf831efb459fd73800d319f21050a
---
> /system/bin/debuggerd:9e90dd40168eef36fee2a9cf273146180e4c9135
You're right in saying this is very surprising; I would have thought that the only difference between the ROMs should be the kernel command line in the boot partition.
bauwks said:
Well, at least I know that the bootloader is working on the 8GB model.
Click to expand...
Click to collapse
Well since I based my root method for the 8GB NT on your images (just in case you didn't know), I want to use this opportunity to say a HUGE THANK YOU for everything you've done - esp 2nduboot (just ingenious...wow) and posting these files for the 8GB. You're a god.
I've looked deeper into the /manifest00 + /manifest01 stuff and came across something really strange. I grabbed the official 1.4.2 update archive from and observed that the /system/framework/framework.jar in the update archive, which I assume to be the same as on the 16GB tablet, is indeed different from the same file on the NT 8GB. However, when I extract both files with unzip, I discovered that they have the same content; in addition, the two files also have the exact same length. I would be very curious to know if this is intentional on the part of B&N, and why.
It is not clear to me if this has been verified to work on the NT 8GB model.
Has this been verified?
Thank you!
I have a brand new Nook Tablet 8GB with factory 1.4.2 firmware and the image did absolutely nothing on it. What are the stept again? I copied the three files to the SD card and nothing happens when I turn on the Nook with the SD inserted.
haloway13 said:
It is not clear to me if this has been verified to work on the NT 8GB model.
Has this been verified?
Thank you!
Click to expand...
Click to collapse
I believe it has, as has CyanoBoot.
i have some curious results here... I have a device which does not boot from SD Properly.
Code:
Texas Instruments X-Loader 1.41 (Oct 21 2011 - 14:00:05)
Checking power button state... PRESSED. OK
mmc read: InvaliD size
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
Could not read bootloader!
X-Loader hangs
The SDCard works in my device, but it does not work in this bricked device...
Any ideas. My mind seems to keep revolving around a modification to e-Fuses??
AdamOutler said:
i have some curious results here... I have a device which does not boot from SD Properly.
Code:
Texas Instruments X-Loader 1.41 (Oct 21 2011 - 14:00:05)
Checking power button state... PRESSED. OK
mmc read: InvaliD size
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
Could not read bootloader!
X-Loader hangs
The SDCard works in my device, but it does not work in this bricked device...
Any ideas. My mind seems to keep revolving around a modification to e-Fuses??
Click to expand...
Click to collapse
I'm not sure which x-loader (mlo) you're running, but looking at source from 1.41 source as well as 1.42, that line seems to be from cpu/omap4/mmc.c , though I don't see the capital "D" in "InvaliD" the way you've shown me in any source we've been given, which makes me think the mlo has changed (unless you retyped it).
It should be reported like this:
function omap_mmc_read_sect:
printf("mmc read: Invalid size\n");
I'm also not sure if you just copied the flashing_boot.img to that sd card, but you may want to copy mlo over from 1.42 as well, just to be sure.
What is Kexec?
"Kexec", which is short for 'Kernel Execution' is derived from the Linux Kernel call "exec". It allows the "live" booting of a new kernel "over" the currently booted kernel without taking the device down for a reboot. This is extremely useful on locked bootloader devices, as a user with root authentication can boot a custom kernel without rebooting, and undergoing the security checks enforced by the bootloader. On unlocked devices, it can be used to "multi-boot" kernels on a device without requiring the kernels to be installed to the /boot partition.
Whilst Kexec is extremely useful, it also can be extremely hard to implement, as it needs to take all devices down, and bring them back up along with the new kernel, this can lead to some serious bugs, like devices not working after soft-boot, kernel corruption, device hangs, etc. This make it very device specific, and hard to get fully working, as it requires retrieving kernel crash logs, (often) UART serial output, and a ton of debugging.
What about this whole "Hardboot" thing?
The solution to this was written (initially) by Mike Kassick, who had the idea to "Hardboot" a kernel. Which is when a kernel is loaded into memory, a flag is set, the device is taken down for a full reboot, then the flag is read out by the primary kernel very early in the boot sequence, at which point, the "primary" kernel directly loads the new "secondary" kernel/ramdisk/passes arguements/etc.
This is much easier to implement than the normal Kexec SysCall, as it jumps to the new kernel before most devices are initiated, and in doing this, we allow the secondary kernel to initialize all the devices on its own, and not have to worry about taking them down.
Many people unknowingly make use of Kexec in the form of MultiROM, so, today, I thought I would do a write up on how to use it in practice.
Necessary Components:
* Boot.img (alternatively, the zImage-dtb/ramdisk you want to use)
* Unmkbootimg
* Kexec Binary (can be found in your specific devices MultiROM zip)
* Kexec Hardboot enabled Kernel installed (most custom kernels have it)
* Root Access
Downloads:
All the Binaries I've cross compiled/found can be downloaded here: https://www.dropbox.com/sh/7g5jcofv8j2gwg9/AAA-2b-wLiHq2z0nCMIHSHooa?dl=0
All the Linux Binaries you'll want/need are here: https://www.dropbox.com/sh/qcho8bhaoi8cdkc/AACGvmIQlb_3I9OQtNMqIQwva?dl=0
If you use Windows/Mac, just find the binaries equivalents for your platform.
How to use it?
1. Take the aforementioned Kexec Binary, and place it in /system/bin using ADB or A File Explorer, granting it permissions drwxdr-xdr-x (or chmod 0755 it)
2. Over on your desktop, make sure you have Unmkbootimg in an Executable location, and that you've blessed them as executable (chmod 0755 filename). Then run
Code:
unmkbootimg /path/to/your/boot.img
This will dump a zImage (rename it to zImage-dtb now, for semantics sake), and a ramdisk, labeled initramfs.cpio.gz (Initial RAM File System, in the form of a cpio.gz archive).
Now, put the kernel and ramdisk in a folder on your SD Card via MTP/ADB Push, I called mine "kexecstuffs".
3. Now open a mobile terminal, or an ADB Shell, and run
Code:
su
cd /sdcard/PathToYourFolder/
kexec --load-hardboot zImage-dtb –initrd=initramfs.cpio.gz --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)" --boardname=shamu –dtb
Now, lets dissect the different arguments we are passing to Kexec:
--load-hardboot = Tells Kexec to make use of the Kexec Hardboot kernel function, and take the device down for a full reboot as opposed to soft-booting, like that used in the standard Kexec Linux SysCall
zImage-dtb = Name of your kernel file
--initrd = Points to the ramdisk to be used when booting the new kernel, if not set, the current ramdisk in the /boot partition. Most archive types are supported.
--mem-min = A reasonable value in memory where the kernel is loaded, serves as space for Kexec to do its work
--command-line = What arguments are passed to the new kernel, using "$(cat /proc/cmdline)" allows you to pass the currently booted kernel's arguments to the new kernel, which is what we want in the case of Shamu
--dtb = Defines that the board makes use of an Appended Device Tree, can be passed without a value (which will rely on Tasssdar's “boardname” value), or can have a compressed DTB image as its value
--boardname = Tasssdar's way to handle different DTB styles, we just need to pass “shamu” to it, and it'll use our DTB style
Now that we have successfully loaded the kernel into memory, lets execute it!
4. In that same Mobile Terminal/ADB Shell, run:
Code:
kexec -e
Although this guide is for the Nexus 6 (shamu), it should work all devices supported bu MultiROM, or on any device with a kernel that supports Kexec/Kexec Hardboot.
I hope this helped you to better understand what Kexec is/how to use it.
What is the Touchpad Toolbox?
https://forum.xda-developers.com/showthread.php?t=2756314
A set of Scripts (programs) that allows:
Easily manage LVM, one of the greatest features of the TP.
https://wiki.archlinux.org/index.php/LVM
Create Android, WebOS volumens, or total reset.
It can make a fresh /boot directory installation adding moboot.
Reflash the battery Firmware
Install specific, older version of recovery and Rom.
How is done?
https://webos-internals.org/wiki/Angstrom_on_Touchpad
A small Linux OS is built into an img (ext2) file system and is loaded into memory as a RAMDisk.
Angstrom v2015.01
Built from branch: master
Revision: 038d832
Target system: arm-angstrom-linux-gnueabi
This information is from the file angstrom-version located in the /etc folder of the RAMDisk.
Following this instructions will unpack the RAMDisk and Kernel, then can be repack as it would with any Android system.
All this is done on Linux ubuntu 18.04 x64 system. If you have any other OS you can install Linux as a virtual machine.
1 .Create a directory
hptoolbox
2. Unzip TPToolbox-2015-01-08-v42.zip to the directory hptoolbox (http://downloads.codefi.re/jcsullins/cmtouchpad/tptoolbox/TPToolbox-2015-01-08-v42.zip
3. Open terminal in the hptoolbox directoty and paste the following commands.
Code:
dumpimage -i TPToolbox-2015-01-08-v42.bin uImage.kernel
dumpimage -i TPToolbox-2015-01-08-v42.bin -p 1 RAMDisk_Compress
dd if=RAMDisk_Compress of=RAMDisk.xz bs=64 skip=1
xz -d RAMDisk.xz
## The RAMDisk which is 67.1MB is a Linux rev 0.0 ext2 filesystem data img file.
4. Creat a loop disk to have read and write access of the RAMDisk
Code:
sudo udisksctl loop-setup -f RAMDisk
## Mapped file RAMDisk as /dev/loop16 (this is only on my system and it will be different on others)
5. Mount the 67 MB Loop Device, it can easly be done using Disks
6. Open your file manager as sudo in (my system is nautilus, it can be different on other Linux)
Code:
[email protected]:~$ sudo nautilus
[sudo] password for ubuntu:
7. The settings for the ToolBox are in /usr/tptoolbox.
You have complete control on all the files, but read what each script says on top:
Code:
# This script is Copyright (c) 2014 James Sullins, All rights reserved.
# James (JC) Sullins, aka jcsullins
# No modifications or distribution without permission
To repack the Kernel and RAMDisk
1. Unmount the RAMDisk img and Detach the loop device
2 Open terminal in the hptoolbox directory and paste the following commands.
Code:
mkimage -A arm -T ramdisk -C none -n RAMDisk -d RAMDisk uImage.RAMDisk
mkimage -A arm -T multi -C none -n "Tenderloin ToolBOX Modified" -d uImage.kernel:uImage.RAMDisk uImage.ToolBox_Modified
In my system I can not make RAMDisk using xz compression but it works uncompress is just a 70MB file.
If the RAMDisk is compress using (( xz -9 RAMDisk )) then the file size will be as the original but it will not be recognized by the kernel at boot.
3. To load using the novacom driver:
Code:
novacom boot mem:// <uImage.ToolBox_Modified
Many thanks to jcsullins for creating the ToolBox ,which allowed many users to easily transition to Android from WebOS and gave new life to a device that could have been in landfills many years ago. In my opinion this has been the greatest Tool for the TP and finding out how it works made it even more amazing!
HP_TOUCHPAD said:
What is the Touchpad Toolbox?
--SNIP--
Click to expand...
Click to collapse
You've done a great job figuring that out HP_TOUCHPAD! As a result, if Sullins agreed (assuming he would even answer the request), the TPToolbox could be modified fairly easily to handle the latest ROMS, GAPPS, and RECOVERIES. For example, it turns out that there is an unused parameter that would allow TPToolbox to install the zipfiles without any checks. Additionally, it is simple to bypass having to install a GAPPS with the ROM, or to keep all checks but the one that checks for a compatible GAPPS..
shumash said:
You've done a great job figuring that out HP_TOUCHPAD! As a result, if Sullins agreed (assuming he would even answer the request), the TPToolbox could be modified fairly easily to handle the latest ROMS, GAPPS, and RECOVERIES. For example, it turns out that there is an unused parameter that would allow TPToolbox to install the zipfiles without any checks. Additionally, it is simple to bypass having to install a GAPPS with the ROM, or to keep all checks but the one that checks for a compatible GAPPS..
Click to expand...
Click to collapse
Thank you, and yes the ToolBox can be modified very easily only if JSullins agreed.
But there is only one section that needs to be modified to update the toolbox and make compatible with all ROMS now and forever. In my opinion there is no need for the Toolbox to install any ROMS as that is the work of TWRP to do and it does it well.
This is the only modification that needs to be done to update the toolbox and make it useful forever!
In the folder toolbox/bin/make_boot (open the script)
add the following under this line : (do_run cp /usr/tptoolbox/data/moboot /mnt/boot/uImage.moboot)
Code:
do_run cp /usr/tptoolbox/data/uImage.TWRP /mnt/boot/uImage.TWRP
do_run cp /usr/tptoolbox/data/android.default.recovery /mnt/boot/android.default.recovery
do_run cp /usr/tptoolbox/data/moboot.default /mnt/boot/moboot.default
do_run cp /usr/tptoolbox/data/uImage.ToolBOX /mnt/boot/uImage.ToolBOX
copy the files to /usr/tptoolbox/data/
uImage.TWRP
android.default.recovery
moboot.default
uImage.ToolBOX (this is the toolbox.bin, renamed it to be loadable from the moboot menu.
save the script.
I do not need to tell you "the Linux Guru" what is going on, but just for the record.
When recreating the boot it will install TWRP into boot and also the ToolBOX.
Reboot and now you have TWRP and also the ToolBOX in the moboot menu and you can install any ROM using TWRP.
This will make it super easy for all users to start fresh!
Complete reset (it will install TWRP, recovery by default) nothing extra for the user to do!
Reflash battery firmare
Resize Android volumens
Reboot and install ROM
I do not think it can be any easier for anyone than this and the change is minimal!
HP_TOUCHPAD said:
Thank you, and yes the ToolBox can be modified very easily only if JSullins agreed.
But there is only one section that needs to be modified to update the toolbox and make compatible with all ROMS now and forever. In my opinion there is no need for the Toolbox to install any ROMS as that is the work of TWRP to do and it does it well.
--SNIP--
I do not think it can be any easier for anyone than this and the change is minimal!
Click to expand...
Click to collapse
I like what you're suggesting, but it's not that easy. I think you're creating a different application. The python scripts need to be modified to remove the "Install Android" option. Making users decide how to (re)install non-datamedia (DM) or DM ROMS by themselves was one of the things HPToolbox solved. I think that a better way is just to prevent all the checks that are done for three zips, gapp/rom capatibility, etc. and let users install the gapps themselves, although I can see a way to expand the allowable gapps dictionary to include the latest versions
Additionally, unless you resize /boot (which is fixed in one of the python scripts and may require lots of other changes), users who want to retain WebOS (there may be one or two left.) won't be able to install Android because there won't be enough room having uImage.TPToolbox there.
shumash said:
I like what you're suggesting, but it's not that easy. I think you're creating a different application.
There is no changes to the menu is only adding uImage.TWRP to be copy to boot.
In the Toolbox MAIN MENU
The option: Complete Data Reset
Call the script: toolbox/bin/make_boot
It will completely erase and format boot then copy files located in (/usr/tptoolbox/data/) over to /boot
It is part of the toolbox option and how it works. Nothing needs to be added or the main script modified.
By adding this code to the already (toolbox/bin/make_boot) script
Code:
do_run cp /usr/tptoolbox/data/uImage.TWRP /mnt/boot/uImage.TWRP
do_run cp /usr/tptoolbox/data/android.default.recovery /mnt/boot/android.default.recovery
do_run cp /usr/tptoolbox/data/moboot.default /mnt/boot/moboot.default
And copy those files to (/usr/tptoolbox/data/).
When the user select the option in the MENU to Complete Data Reset, it will do as always the only difference is, it will install TWRP automatically, which in my opinion it needs to be there to install and back up.
The python scripts need to be modified to remove the "Install Android" option. Making users decide how to (re)install non-datamedia (DM) or DM ROMS by themselves was one of the things HPToolbox solved.
The Install Android can be there as is and do as you are suggesting which is to remove the limitation and be able to install any recovery or gapps
I think that a better way is just to prevent all the checks that are done for three zips, gapp/rom capatibility, etc. and let users install the gapps themselves, although I can see a way to expand the allowable gapps dictionary to include the latest versions.
Yes that is perfect and the way it should have been from the beginning, to allow installation of any ROM. There is nothing malicious that anybody can do to brick the device. Reloading the toolbox (novacom boot mem:// < uImage.Toolbox) will recreate everything even if /boot is destroy.
Additionally, unless you resize /boot (which is fixed in one of the python scripts and may require lots of other changes), users who want to retain WebOS (there may be one or two left.) won't be able to install Android because there won't be enough room having uImage.TPToolbox there.
Click to expand...
Click to collapse
Correct if uImage.Toolbox ( 11 MB ) file is copy to boot and TWRP there will be 8 MB left for one uImage boot file, only one OS will be able to boot.
That could be an option and does not need to be copy to boot, but it could make it easier for "Android only users" to have it handy and no PC will be required to load it again.
Here is another simple quick modification to avoid confusion and make it easier.
When you select Install Android, the USB media is mounted and a directory /ttinstall is created. At the same time the directory is created a shortcut (link) can be place of a landing web page where the links to all ROM and Recovery can be download from, that the user can click and download the correct Recovery, ROM and gapps.
Make it super easy and avoid confusion of what to install and where to get it from. It could be a landing page any where that can be updated.
This is another issue to think about. To load any uImage to fix a problematic TP, a PC is need it with novacom drivers install.
This is the command that will fix any TP:
novacom boot mem:// <
If novacom is not install in the user PC or not working properly nothing can be done.
Idea.
Create a basic Linux OS, bare minimum that will run anywhere. Have the novacom install and the toolbox in it, with a basic browser to get the files.
The Linux OS can be distributed as a Live CD (.iso) that can be booted on any PC. This will guarantee that the novacom driver will work and load the toolbox or any other uImage into the TP.
I made my own live CD of Ubuntu 18.04 ( is a 2GB file ) that has everything set up and do any kind of work on the TP and be able to use it on any PC.
HP_TOUCHPAD said:
__SNIP__
Click to expand...
Click to collapse
All good ideas, but this is much easier.
shumash said:
All good ideas, but this is much easier.
Click to expand...
Click to collapse
Crazy complicated !
Take a very close look at the steps.
" 1) complete data reset"
Before this happens the novacom driver needs to be install. It used to be an easy one to do, but with new OS, windows or Linux it can get complicated. Nothing can be done unless this driver is properly install and the environment is properly set to load the uImage. This can easily create errors and frustration and not a successful install.
The universal Java installer used to work, not any more. It will be great to have a portable novacom driver, but I do not know if that is even possible to load and work in different OS.
But anyways doing the first steps is to load the Toolbox to do a complete data reset.
Well if the toolbox is modified, once the complete data reset is done uImage.TWRP will be already copy into boot.
The only thing you have to do is reboot the device select TWRP and do the installation as regular.
No more steps need it, and nothing else to download or install.
One step and done!
But now you need to run:
TWRP_TmpLoad_v03_win.bat
Then install TWRP, because is temporally loaded in memory.
What it does is loading uImage.TWRP using:
novacom boot mem:// <uImage.TWRP
The same way the Toolbox gets loaded in the first place.
If the Toolbox restriction gets remove then it will install TWRP, and then reboot.
Like I said the magic command is:
novacom boot mem://
Any boot uImage can be load it that way, but the only thing that will reset everything is the Toolbox.