Related
For a while now I have been wanting to run aircrack on my galaxy nexus so as to have a mobile pentesting device.
So, I finally got it working and thought I would post how. This is not a task for the terminally challenged.
Install Backtrack 5 ARM. The latter is a linux environment designed for pentesting. On a mobile device the easiest way to install it is by chrooting to the mounted img, running on top of the mobile devices kernel.
Since most people seem to think aircrack is unusable on a mobile arm device, it is not included in the BackTrack 5 linux distro above, so you will need to download it manually once you have BackTrack up and running.
Here are the commands to do so:
#!/bin/bash
# Aircrack-ng installer for BackTrack 5 on Android
# By Justin Barrick aka th3p4tri0t
# install dependency for libssl-dev
apt-get install zlib1g-dev
# install libssl-dev
wget http://launchpadlibrarian.net/64412492/libssl-dev_0.9.8k-7ubuntu8.6_armel.deb
dpkg --install libssl-dev_0.9.8k-7ubuntu8.6_armel.deb
rm libssl-dev_0.9.8k-7ubuntu8.6_armel.deb
# get and install aircrack-ng
apt-get install source-aircrack-ng
cd /var/backtrack/sources/aircrack-ng/1.1/bt9/upstream-sources/
tar -xzf aircrack-ng.tar.gz
cd aircrack-ng/
make
make install
# set path variable
echo "export PATH=$PATH:/usr/local/sbin" >> ~/.bashrc
export PATH=$PATH:/usr/local/sbin
Now, the hard part. Or at least the part that took me forever to discover. You need the drivers for the AWUS036H to be insmod'ed into the kernel. You can accomplish this by obtaining your kernel source and the driver source, which is part of the compat-wireless package, more specifically the AWUS036H uses the rtl8187 chipset. Then, you cross compile those two sources to obtain rtl8187.ko, eeprom_93cx6.ko, and mac80211.ko. Then insmod those kernel modules into your kernel (insmod rtl8187.ko). The process is explained here. One can also recompile the enitre kernel, instead, and include the modules as built-in drivers. However, compiling kernel drivers can be difficult (toolchains, kernel source, etc), so luckily, I found a Galaxy Nexus kernel that already has the modules built-in, it is franco.Kernel R140 with modules added.
***Update:farcno.Kernel R200 with RTL8187 modules added, and R248 for JellyBean 4.1.1 with RTL8187 drivers
, so Aircrack-ng is now compatible with JellyBean! Also, R140 is no longer available but R200 is and has the modules needed
Beware, the kernel R200 needs ICS 4.0.4 installed to work properly, and R248 is built for JB 4.1.1.
***Update 04/11/2013:
I couldn't find any kernels with the RTL8187 drivers for JB 4.2.2, so, I built one my self. The kernel is a modified franco.Kernel R370. I didn't package it into a flashable zip, because I find it just as easy to hook my phone to my computer and use fastboot (fastboot flash boot bootJB422-RTL8187.img). The kernel image is attached below. I have been running it for about 4 days now without issue. I actually find it is the stablest version yet. I was able to play N64oid, while running airodump-ng and aireplay-ng. File attached below.
***Update 04/15/2013:
I looked into getting more of the aireplay-ng attacks to work proper with the RTL8187 drivers. There had been some complaints about fragementation attack not working and negative one always being returned as the channel for mon0. So, I found two patches for those issues on the aircrack-ng site and applied them to the franco.Kernl r370 with RTL8187 and recompiled. Now, we have fully functional aircrack-ng RTL8187 driver.
Once you flash the kernel, using the flashable zip and cwm or fastboot flash, then backtrack will be able to recognize the attached wifi adapter.... once you mount the usb bus in BackTrack. And, of course, this needs a OTG USB host cable.
The final step before learning how to use aircrack-ng is:
1. Open a terminal and load BT5, you can load the 'ui' and use an vnc to connect the the xserver desktop if you want. But, I have found it is easier to just use the chroot shell in the android terminal emulator.
2. open another android terminal window, and type:
su
mkdir -p /data/local/bt/dev/bus/usb
mount -o bind /dev/bus/usb /data/local/bt/dev/bus/usb
3. In the new android terminal window, start the BT5 shell (startbt), then type:
lsusb
You should see atleast one device, the usb root, and whatever device you have plugged in to the otg cable, if any.
A note to remember: I re-performed this guide after formatting my phone and got stuck here. lsusb didn't list anything. I rebooted my phone and tried to start BT5 and mount the usb again and it worked. I rebooted, started BT5, tried lsusb without binding usb and was blank as should be, bound usb back in another terminal window, returned to BT5, tried lsusb and root hub displayed.
Now, plug in the AWUS036H and type: airmon-ng
And you should see the device listed.
Read here for how to run aircrack, or view here.
Essentially the commands are:
lshw -disable dmi
(this should list the attached wifi card under NETWORK, my RTL8187 was wlan1)
ifconfig
(you should see wlan1 listed, if not the type "ifconfig wlan1 up" and retype "ifconfig")
airmon-ng start wlan1
airodump-ng mon0
copy BSSID and CHANNEL
New android terminal with BT5 shell (startbt): airodump-ng -w wep -c CHANNEL --bssid BSSID mon0
New android terminal with BT5 shell (startbt): aireplay-ng -1 0 -a BSSID mon0
New android terminal with BT5 shell (startbt): aireplay-ng -3 -b BSSID mon0
After ~50,000 packets collected:
New android terminal with BT5 shell (startbt): aircrack-ng wep-01.cap
To the purpose, with this, if your friend or mom or just some complete stranger forgets their wep key to their network, all they need to do is call you and you can just drive by, plug your wifi adapter into your phone, chroot to BT5 and aircrack their password for them, in a matter of 5 to 10 minutes.
WARNING!!!: In my intial aircrack run on my galaxy nexus, I cracked a wep key in about 5-10 minutes. I was happy, happy, happy. Then, a ruinous moment occurred. Almost the very second aircrack-ng finished cracking the key, my phone came up with a low battery warning, I was using a awus036h wifi adapter and it was draining my battery fast, I had about 50% to begin and had the 14% warning hit me about 10 minutes in, funny thing is the warning is usually 14%, but this time was 13%, go figure? Anyway seconds after the warning my phone just blanks, turns off. I plug it in and reboot and the battery is at 0% and stuck there, so a word of warning:
An external wifi adapter my require more usb host juice then the battery can safely supply. I have seen people using powered hubs to circumvent draining the phone battery, I would defintiely recommend the practice.
UPDATE: I plugged the phone into an AC charger and the battery finally charged (phew). For some reason, it wouldn't recharge on the USB cable after being so drained.
Is there a compatible wifi device that has the same chip set but with its own power supply (cord or battery)? If so that should help. I'm interested if someone can find one.
Sent from my Galaxy Nexus using xda premium
This is amazing work. I used to do some network pen testing as part of my old job and there's a lot of work that goes into making a mobile setup even with a laptop involved. The fact you got this all working coherently on a phone is mind blowing to me. Huge props.
I have no experience with this manufacturer or ebay seller but through some googling I did find this product:
http://www.ebay.com/itm/Solar-Power...970998?pt=PDA_Accessories&hash=item20b72a86b6
USB hubs in theory do not identify as normal USB devices and allow for pass through communication between connected devices. This one supplies external power as well. In other words, you may be able to connect both devices to this as it provides external power, and they can communicate without you having to rewrite any drivers.
However, be careful because some USB chipsets get confused if you try to use them as USB host but supply external power at the same time. So you may want to verify that is safe on the GNEX USB chipset.
Anyone willing to order that hub and test it?
Sent from my Galaxy Nexus using xda premium
Wow just found that and will be testing it at home tonight.
I flashed the V140 kernel via recovery and I can't locate rtl8187.ko anywhere to move it to /data/local/modules
Where is it located once the kernel flashed?
Thanks!
Once you install the R140 kernel mentioned, there is no need to insmod rtl8187.ko. The rtl8187 chipset support is compiled into the kernel boot.img.
I use this external battery pack, and I spliced a spare USB cord with the cord from my wifi adapter, so it only draws juice from the battery pack.
When you cut open a usb cord there are four wires: red, black, green, and white.
Green and white are data, connect them to the cord going to the galaxy nexus.
Red is +5V, connect it to the +5 V or red cord going to the battery pack.
Black is common, connect it to both usb cords.
So, on the cord going to the battery pack, green and white are loose, and on the cord going to the gnex, red is loose.
Or, you could use the solar powered hub mentioned above. You will still need the modified kernel, as the hub will show up as an attached device, but so will whatever is connected to it. You can't communicate with a device, without the appropriate drivers.
I did the bt5 development for the xoom. Reaver works too for h4xRing wps. I make a module pack with about 100 modules for xoom. If this is something the gnex community is interested in ill see what a can do.
bigrushdog, to be honest, during my trek to get this working, I nearly gave up and bought a XOOM, after seeing how well developed it was.
bigrushdog said:
I did the bt5 development for the xoom. Reaver works too for h4xRing wps. I make a module pack with about 100 modules for xoom. If this is something the gnex community is interested in ill see what a can do.
Click to expand...
Click to collapse
Of course I would be interested!!!
Aircrack is working now with my rtl8187!
Great job. However I noticed that this kernel is draining the battery much quicker than the latest Franciscofranco kernel in Android with a normal everyday usage.
You could download the franco.Kernel updater, it lets you set options in the franco.Kernel, like the "Generic Hotplug" option which saves battery by turning off one cpu core when the phone screen is off and allows you to set undervolt settings. It also has a Power Mode setting with Full Power, Balanced, and Power Save options. Full Power is default, which makes your phone faster, but at the expense of battery power.
Be sure not to upgrade the kernel to the current nightly though. The franco.Kernel I listed is specially modified, the rtl8187 drivers aren't normally found in the franco.Kernel.
bigrushdog said:
I did the bt5 development for the xoom. Reaver works too for h4xRing wps. I make a module pack with about 100 modules for xoom. If this is something the gnex community is interested in ill see what a can do.
Click to expand...
Click to collapse
Yes, please! I'd be interested.
Sent from my Galaxy Nexus using xda premium
michaelmotes said:
You could download the franco.Kernel updater, it lets you set options in the franco.Kernel, like the "Generic Hotplug" option which saves battery by turning off one cpu core when the phone screen is off and allows you to set undervolt settings. It also has a Power Mode setting with Full Power, Balanced, and Power Save options. Full Power is default, which makes your phone faster, but at the expense of battery power.
Be sure not to upgrade the kernel to the current nightly though. The franco.Kernel I listed is specially modified, the rtl8187 drivers aren't normally found in the franco.Kernel.
Click to expand...
Click to collapse
I will try the settings as I already have the app! Huge thanks!
Wow I tried to get rtl8187 working since 2 weeks, but never was able to crosscompile the kernel modules.. And you found a kernel, that has these modules already intergrated thank you very very much
It was brought to my attention that the patches for the compat wireless drivers from aircrack-ng haven't been applied to the driver in the kernel I provided. Nonetheless, aircrack-ng, aireplay-ng, airmon-ng, and airodump-ng still work. The only one that might give you a problem is aireplay-ng because it uses the patches to get the channel of the bssid from the driver, which without the patch just returns -1. I was able to get around it by using the command line option --ignore-negative-one when using aireplay and the ARP request replay attack (attack 3) and fake authentication (attack 1) still worked.
Also, a word to the wise, I overheated my cpu while running airodump, aireplay ARP request replay, and aircrack all at once and caused a kernel panic and emergency shutdown. So, I would advise only running airodump and aireplay, then waiting until you have lots of packets, stopping airepaly and airodump, and then running aircrack. Or, maybe even underclocking the cpu while running in backtrack.
michaelmotes said:
It was brought to my attention that the patches for the compat wireless drivers from aircrack-ng haven't been applied to the driver in the kernel I provided. Nonetheless, aircrack-ng, aireplay-ng, airmon-ng, and airodump-ng still work. The only one that might give you a problem is aireplay-ng because it uses the patches to get the channel of the bssid from the driver, which without the patch just returns -1. I was able to get around it by using the command line option --ignore-negative-one when using aireplay and the ARP request replay attack (attack 3) and fake authentication (attack 1) still worked.
Also, a word to the wise, I overheated my cpu while running airodump, aireplay ARP request replay, and aircrack all at once and caused a kernel panic and emergency shutdown. So, I would advise only running airodump and aireplay, then waiting until you have lots of packets, stopping airepaly and airodump, and then running aircrack. Or, maybe even underclocking the cpu while running in backtrack.
Click to expand...
Click to collapse
Could we patch it manually? We would need to download the kernel source somewhere in the chroot session and modify the makefile then?
You can patch it manually. But, like I said, I'm happy with it, I can crack wep keys and that is what I wanted to do, still as an academic exercise, or academic triathlon, you can patch it manually. To start, I would try getting the kernel source for the gnex, or maybe from Kernel-XP I linked. He might give it to you if you asked. Then, I would recompile the kernel with not changes.
The kernel must be recompiled using the arm gcc toolchain, you can get it like:
$ git clone https://android.googlesource.com/platform/prebuilt
$ export PATH=$(pwd)/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH
I would install all the necessaries on a regular desktop and follow the instructions for building kernels here: http://source.android.com/source/building-kernels.html.
Once you get the kernel rebuilt and it works, look into patching the compat-wireless source here: http://www.aircrack-ng.org/doku.php?id=compat-wireless
And then take a look here: http://stackoverflow.com/questions/4849063/cross-compile-lkm-module-for-android-platform. It says how to setup a makefile in the driver source directory to make it cross-compile with the android kernel source.
Nice!
Cool and thanks for all the steps. Last link was the key I was missing for many weeks!
So right now WPA2 won't be working right?
What do you mean "WPA2 wont be working"?
I believe you can still caputre handshakes, and try to brute force the password. All you need is to run airodump to capture the handshake on the wpa router and run aireplay with attack 0 (deauthication) to cause a client to handshake.WPA cracking is slow though, and only possible if the router has password less then or equal to 7 characters, I think after that the odds of cracking it become worse then hitting the lottery after that. There is no way to recover a WPA key without guessing it.
Capturing the handshake just allows one to guess rapidly without the router knowing or being able to ban your mac for repeated auth attempts.
I finally found some time to inspect the NST board for a spare UART and the search was successful!
The serial port can be accessed on U2713, pin 2 is RX, pin 3 is TX, device node is /dev/ttyS1.
I use it with a 3.3V USB-to-UART adapter, but any voltage between 1.2 and 3.6 should be fine, thanks to the TI voltage-level translator TXB0104.
There is also a second uart connected to J151 (ttyS0), but that one has no voltage-level-translator and runs with 2V. (TX is on pin 9 of J151, no idea where RX is).
I'm still trying to redirect the boot console to ttyS1, i think i have to recompile uboot.
/edit:
Patching u-boot worked, I have the boot console on ttyS1.
Good job!
I wanted to look for this sometime, but you beat me to it.
ttyS0 is for the (cell phone) radio
ttyS1 is for the Bluetooth.
Could the connector place there be for JTAG?
Renate NST said:
Good job!
I wanted to look for this sometime, but you beat me to it.
Click to expand...
Click to collapse
I wanted to do this since my last failed kernel porting attempt. I hope it helps me debugging non succesfully booting configurations.
ttyS0 is for the (cell phone) radio
ttyS1 is for the Bluetooth.
Click to expand...
Click to collapse
Is that an actual android standard, or just some leftovers from the reference platform the nst and nook color are based on (the remains in the init.rc)?
Could the connector place there be for JTAG?
Click to expand...
Click to collapse
I think the JTAG is more probably on J151 together with ttyS0, than on U2713.
ttyS0 was the standard console, and it would make more sense that the J151 was used as debug-port.
mali100 said:
The serial port can be accessed on U2713, pin 2 is RX, pin 3 is TX, device node is /dev/ttyS1.
I use it with a 3.3V USB-to-UART adapter, but any voltage between 1.2 and 3.6 should be fine, thanks to the TI voltage-level translator TXB0104.
Click to expand...
Click to collapse
Mali,
My USB-to-UART adapter needs 3.3V (to set “upper voltage” level)
Could you help, where can I get in on Nook board?
Renate NST said:
ttyS0 is for the (cell phone) radio
ttyS1 is for the Bluetooth.
Click to expand...
Click to collapse
Do you know any devices that can be connected to this ports? It would be great to enable only Bluetooth or even cell phone.
ApokrifX said:
Mali,
My USB-to-UART adapter needs 3.3V (to set “upper voltage” level)
Could you help, where can I get in on Nook board?
Click to expand...
Click to collapse
You can use pin 1 of U2713, it's connected to VCCb on the TXB0104. Altough the voltage is disabled when the nook sleeps, but that shouldn't be a problem.
mali100 said:
You can use pin 1 of U2713, it's connected to VCCb on the TXB0104. Altough the voltage is disabled when the nook sleeps, but that shouldn't be a problem.
Click to expand...
Click to collapse
Ok... But it's gotta be 3.3V somewhere, right?
ApokrifX said:
Ok... But it's gotta be 3.3V somewhere, right?
Click to expand...
Click to collapse
Quick! Break the laws of physics and pull power from a penny!
I haven't had a driving need to use this until I tried an upgrade to 1.2 and got a boot loop.
There are various versions of u-boot.bin.
The easiest way to patch it is to simply search for ttyS0 and replace the two occurrences with ttyS1.
ttyS0 appears also in env.txt inside uRamdisk (and uRecRam).
I found a old fax that has the 10 pin connector that fits on the Nook.
I might try to put it on. For now I have the soldered wires.
In any case, the 1.2 boot loops and the last message is:
Code:
binder: 988:1039 transaction failed 29189
I've screwed with a lot of things on my Nook, but the "update" should have wiped about everything.
Just a short update:
I soldered in the connector successfully. It looks nice.
The level converter to standard 9 pin "RS-232" is simple and cheesy, 2 resistors and a transistor.
It works fine though. I can see the boot up.
After that I can switch to logcat over ADB over USB.
Here's a really poor photo of my setup.
My next cell phone must have auto-focus and macro mode.
Excellent setup, especially for the ribbon cable! It seems something nice its going to happen in the next days
Just a bit of an update.
If you want to do your own level shifting you've got access to two UARTs.
The MSP stuff is I2C to the MSP430 microprocessor that handles the touch screen.
You could eavesdrop on that and have a little multitouch pad.
I'm still trying to see which of the rest of the pins are for JTAG on U151.
The other 4 pins on U2713 are 3.3 level but don't come from the TXB0104 level shifter.
The JTAG stuff is apparently on the 22 pin, 0.5 mm pitch CON6.
The four side buttons are on CON6 too.
I've looked at this a bit and I've determined that using UART2 is a dead end.
The TXB0104 is neither powered nor enabled until late in the boot sequence.
Using the default UART1 is a much better choice.
Yes, you could modify things to use UART2 over UART1 but it's an uphill battle.
u-boot has a nice command interface where you can do lots of stuff (edited a bit):
Code:
Texas Instruments X-Loader 1.41 (Dec 7 2012 - 14:34:26)
Starting OS Bootloader from EMMC ...
U-Boot 1.1.4-carbon1.2_1.2.1.24^{} (Dec 7 2012 - 14:34:22)
OMAP3630-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3621-Gossamer 1.2 Version + mDDR (Boot NAND)
DRAM: 256 MB
In: serial
Out: serial
Err: serial
Hardware arch: GOSSAMER rev: EVT3
Power button is not pressed
pmic watchdog time 0
Power Button Active
gossamer charger init
Booting from eMMC
OMAP36XX GOSSAMER # help
? - alias for 'help'
autoscr - run script from memory
base - print or set address offset
battery - gas gauge BQ27520 info
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
calc - perform mathematical operation
charger - charger BQ24073 info
clock - Manage system clocks
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
date - get/set/reset date & time
echo - echo args to console
epd tests dspon dspoff image1 image2
exit - exit script
fastboot- use USB Fastboot protocol
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
fatsave - save binary file to a dos filesystem
ggflash - flash bq27500 from .dffs script
go - start application at address 'addr'
gpio - set/display gpio pins
help - print online help
ibatck - used to track battery id
ibus - Select i2c Bus
icrc32 - checksum calculation
iloop - infinite loop on address range
imd - i2c memory display
iminfo - print header information for application image
imm - i2c memory modify (auto-incrementing)
imw - memory write (fill)
inm - memory modify (constant address)
iprobe - probe to discover valid I2C chip addresses
itest - return true/false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mmcinit - initialize mmc
mmc - Read/write/Erase mmc
mspflash- used to flash a new msp430 firmware file
mtest - simple RAM test
mw - memory write (fill)
nm - memory modify (constant address)
printenv- print environment variables
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv - set environment variables
setenvmem - set environment variable from memory
sleep - delay execution for some time
test - minimal test like /bin/sh
version - print monitor version
OMAP36XX GOSSAMER #
Just adding the battery pinout to the diagram for completeness.
Excellent! I recently bought a JTAG (http://www.ebay.co.uk/itm/Altera-FP...al_Components_Supplies_ET&hash=item257fc5c582)
I will give it a go... is there anything you'd like me to do?
Cheers
Heres a quick hack to talk to uboot over UART2
Edit: all that's different is enabling the TXB0104 by setting gpio 37 high instead of low.
and redefining the uarts so 2 is used instead of 1.
includes the OP's patch so kernel logs show after boot also.
this second version fixes autoboot. UART2 gets a spurious byte which needs to be cleared otherwise autoboot never works.
This patch is meant to be applied without the first one, i put the uart numbers back to normal and just changed the index of which gets used for console.
I also enabled ^C checking for the case where bootdelay is zero, you can't lock yourself out of u-boot by messing with the env variables. ( Guess why I decided to do this?
NB: There is a third uart, uart3. one of the sets of pins it can be muxed onto are the usbhs0_data0 and 1 pins.
these go to the tps65921, which also has a uart mode , whereby we could have uart access over the usb pins without cracking the case.
droid phones had something similar, called emu-uart. i will look into this more when i get a nook with a working usb port.
I have been trying for the past few days to compile my own kernel for the GS3 (without any modifications just to prove it works) and have finally succeeded in both compiling and flashing to my phone.
The whole reason i attempted this was i was aiming to get the phone to act as a HID keyboard so that it could be used for text entry on a PC.
Anyway, after successfully compiling the kernel i ran make menuconfig and started looking threw the options. When i found
Code:
Device Drivers -> USB Support -> USB Gadget Support -> USB Gadget Drivers (HID Gadget)
I got my hopes up that the device may support this right away, but after enabling this and attempting to compile the kernel i received the following error :
Code:
arch/arm/mach-exynos/built-in.o: In function `midas_machine_init':
<PATH_REMOVED>/GS3/Kernel/arch/arm/mach-exynos/mach-midas.c:2756: undefined reference to `s3c_device_android_usb'
I have attempted to research this but can find no one that has experienced this error (just searching for s3c_device_android_usb with just about any other key words returns 0 results on google).
So my question to you is firstly, does HID Gadget do what is expect or is it a wast of time straight away (if so can you suggest which USB driver to compile with to allow HID functionality or if that is not available, the best one to be able to expand and add the functionality). Second if this is the correct driver then any help with the above error would be greatly appreciated.
Thanks for you time
Adrian
Sort of solved
After a lot of mucking around i found that if i set the kernel config file to build the gadget HID driver as a module then ran make modules it worked.
Is it possible to get some kind of UART or Serial port over USB at the start of the phone?
I want to dig into a issue where a ROM - under a specific circumstances - hard bricks my device (that means, no system, no recovery). However, it happens during a early boot stage. I only have a chance of finding the culprit when I have access to the (kernel) log. If Qualcomm devices have even more detailed logs (before the kernel is started?) I would like to read those to.
Mind that saving the log and reading it out doesn't work here... at the point I need to access it my device is already hard-bricked.
I read somewhere that QCSC devices have a USB UART / Serial mode, but I can't find any concrete information about it.
Would love to hear your thoughts about this.
Preface
With this guide I can officially deprecate the other guide I wrote, as we will no longer have to hack together a solution by loading profiles for other carriers. Meaning, that this should just work provided an mbn exists for your carrier - doesn't matter from which device. This has been reported to work on TMO in the US, which did not work with my other method.
Prerequsities
* You must have working DIAG mode. See my other thread for more information on how to set that up.
Downloads
* AsusVoLTE v1.0.1
* EfsTools 0.10 modded 1.2
* EFS items
* Xiaomi Mi 9T MBNs (optional)
Step 1 - setting props
Install the AsusVoLTE app from above, make sure to upgrade if you already have it installed. Run the app and press the Enable VoLTE button; this should set some properties on the device to force-enable VoLTE after we have also done the other steps below. If you already enable VoLTE using my old method you can safely skip this step.
If you prefer to not use the app, simply run this in an adb shell:
Code:
setprop persist.vendor.dbg.ims_volte_enable 1
setprop persist.vendor.dbg.volte_avail_ovr 1
setprop persist.vendor.dbg.vt_avail_ovr 1
setprop persist.vendor.dbg.wfc_avail_ovr 1
If you are unable to set those properties for whatever reason, like if you have returned to stock after flashing the mbn and no longer have root, there is another possibility to force VoLTE/VoWiFi; There's a secret code you can use to force-enable it, but unfortunately it does not survive a reboot (not sure why ASUS didn't make it persistent).
Enter this in the dialler:
Code:
*#*#3642623344#*#*
The number will clear itself, and you shouldn't see any output if it succeeded.
When you have done this, go to (System) Settings -> Mobile network and toggle Mobile data off then on again. You should hopefully see the VoWiFi or VoLTE icon in the status bar now, but like I said above you will have to redo this if you reboot the phone - so if you can, please use the properties method instead.
Step 2 - making sure it works
Before we begin, make sure you close down QPST, otherwise EfsTools will error out because there can not be two clients connected at once.
Unzip EfsTools from above, open up a cmd window and cd to the directory where you extracted it. Depending on how you connect to diag you will need to modify EfsTools.exe.config - if you're connecting via USB you most likely won't have to do anything as it will find the port automatically, unless you have more than one port, in which case you can simply change port from Auto to the COM port of the phone (for example COM13).
If you are connected via wifi you will need to change port to 2500 (or whatever port you used in the AsusVoLTE app) and remote to true. So the efstool line should look something like this:
Code:
<efstool port="2500" remote="true" baudrate="38400" password="FFFFFFFFFFFFFFFF" spc="000000"/>
You can test the connection by running this in the cmd window:
Code:
EfsTools.exe efsInfo
This should report back some info if everything is working. If not, try rebooting the device and redo the bits from the DIAG guide.
Step 3 - disabling mcfg
Extract efs.zip from above to the same directory as EfsTools.exe, and make sure the mcfg_autoselect_by_uim file is there. Now simply run this in the cmd window, one line at a time:
Code:
EfsTools.exe writeFile -i mcfg_autoselect_by_uim -o /nv/item_files/mcfg/mcfg_autoselect_by_uim
EfsTools.exe writeFile -i mcfg_autoselect_by_uim -o /nv/item_files/mcfg/mcfg_autoselect_by_uim -s 1
If everything worked you should see no error messages.
Step 4 - writing mbn
If you are using the Xiaomi Mi 9T mbns zip from above, move it to the EfsTools directory and extract it. Now we simply need to find the mbn for your carrier.
The mbn directory structure is generally laid out like this: <region>/<carrier>/commerci/<country>/mcfg_sw.mbn. For example, the one for my carrier is eu/h3g/commerci/se/mcfg_sw.mbn. Copy the mcfg_sw.mbn file to the same directory as the EfsTools.exe, then go to the cmd window you opened and type this:
Code:
EfsTools.exe uploadDirectory -i mcfg_sw.mbn -o / -v
To get it working on the second SIM slot you will also have to run this:
Code:
EfsTools.exe uploadDirectory -i mcfg_sw.mbn -o / -s 1
If it has worked you should see a bunch of output, but no errors. Try rebooting now, and hopefully after it has booted you will have fully functional VoLTE and VoWiFi.
Source code:
AsusVoLTE - Github
EfsTools - Github
Let me know if this works for you, or if you have any questions.
Regards
I cannot for the life of me get either method to work. Connected via USB. DIAG mode driver is loaded on COM1, even changed Baud rate on the COM port in device manager to 38400. USB method gives me "Critical Error: Bad Command" Remote method does not send any information but indefinitely runs. I'm really not sure what else to try. Im on the latest WW Firmware with Magisk root. Is there anything else I can check? Are you on the 8 GB Tencent version?
xbamaris1` said:
I cannot for the life of me get either method to work. Connected via USB. DIAG mode driver is loaded on COM1, even changed Baud rate on the COM port in device manager to 38400. USB method gives me "Critical Error: Bad Command" Remote method does not send any information but indefinitely runs. I'm really not sure what else to try. Im on the latest WW Firmware with Magisk root. Is there anything else I can check? Are you on the 8 GB Tencent version?
Click to expand...
Click to collapse
Is COM1 the only port available? What does it identify itself as in Device Manager? It should be a Qualcomm ... 902d device.
I'm on the tencent version, yeah, so it should be working for you as well.
HomerSp said:
Is COM1 the only port available? What does it identify itself as in Device Manager? It should be a Qualcomm ... 902d device.
I'm on the tencent version, yeah, so it should be working for you as well.
Click to expand...
Click to collapse
I changed it to that, I'm even trying this on a completely different computer to see. Now its on COM3 on the different system with that driver. I even recently did a full WW firmware flash and factory reset as well. So its pretty much completely stock other than Root and the Apps you made / modified.
Still, Critical error. Bad Command when running efsTools efsInfo
What version of the driver does it say for you?
Edit: When you're able to access efs, What does your sys.usb.state say? I have rndis,adb shown but sys.usb.config is set for rndis,diag,adb. Does your sys.usb.state have diag included?
Use serial port 'COM13'
Critical error. The requested resource is in use.
Use serial port 'COM13'
Critical error. The requested resource is in use.
Use serial port 'COM13'
Critical error. The requested resource is in use.
I keep getting the following error and I'm not sure what the cause may be. Is it possible that a video tutorial could be made to help out in beginning as I'm not sure what I'm doing wrong on my end.
Thank you so much for your work on this though! It is nothing short of amazing.
Does it matter which USB port we use on the device? I've tested both the bottom and the side and neither are working.
Cammarratta said:
Use serial port 'COM13'
Critical error. The requested resource is in use.
Use serial port 'COM13'
Critical error. The requested resource is in use.
Use serial port 'COM13'
Critical error. The requested resource is in use.
I keep getting the following error and I'm not sure what the cause may be. Is it possible that a video tutorial could be made to help out in beginning as I'm not sure what I'm doing wrong on my end.
Thank you so much for your work on this though! It is nothing short of amazing.
Does it matter which USB port we use on the device? I've tested both the bottom and the side and neither are working.
Click to expand...
Click to collapse
Make sure you dont have QPST server running. Its not required if using the tools. I ran into this issue and realized thats what it was that was using it.
How do I make sure the server is not running? I've rebooted and checked but I'm not seeing anything/indication of it doing so. Thank you in advance!
Cammarratta said:
How do I make sure the server is not running? I've rebooted and checked but I'm not seeing anything/indication of it doing so. Thank you in advance!
Click to expand...
Click to collapse
Open up QPST Configuration > at the top click Server > then Stop QPST Server. After that, see if efsTools give you anything. (efsTools efsInfo)
Hrmmm still not working on my end. Not sure what I'm doing wrong but I'll give it a rest for the time being.
My qserver keeps saying that it cannot find my USB or phone either. So I might be missing something. I'll Uninstall and try again though
Cammarratta said:
Hrmmm still not working on my end. Not sure what I'm doing wrong but I'll give it a rest for the time being.
My qserver keeps saying that it cannot find my USB or phone either. So I might be missing something. I'll Uninstall and try again though
Click to expand...
Click to collapse
What does it say for you? It won't find it if you turn it off. What is the COM port / driver that shows up in Device Manager
xbamaris1` said:
I changed it to that, I'm even trying this on a completely different computer to see. Now its on COM3 on the different system with that driver. I even recently did a full WW firmware flash and factory reset as well. So its pretty much completely stock other than Root and the Apps you made / modified.
Still, Critical error. Bad Command when running efsTools efsInfo
What version of the driver does it say for you?
Edit: When you're able to access efs, What does your sys.usb.state say? I have rndis,adb shown but sys.usb.config is set for rndis,diag,adb. Does your sys.usb.state have diag included?
Click to expand...
Click to collapse
Could you try this updated EfsTools: https://github.com/HomerSp/EfsTools...modded-1.1/EfsTools-0.10-modded-1.1-win32.zip Hopefully it should work for you.
sys.usb.state is supposed to say just rndis,adb - diag will only be listed in sys.usb.config.
HomerSp said:
Preface
With this guide I can officially deprecate the other guide I wrote, as we will no longer have to hack together a solution by loading profiles for other carriers. Meaning, that this should just work provided an mbn exists for your carrier - doesn't matter from which device. This has been reported to work on TMO in the US, which did not work with my other method.
Prerequsities
* You must have working DIAG mode. See my other thread for more information on how to set that up.
Downloads
* AsusVoLTE v1.0.1
* EfsTools 0.10 modded 1.1
* EFS items
* Xiaomi Mi 9T MBNs (optional)
Step 1 - setting props
Install the AsusVoLTE app from above, make sure to upgrade if you already have it installed. Run the app and press the Enable VoLTE button; this should set some properties on the device to force-enable VoLTE after we have also done the other steps below. If you already enable VoLTE using my old method you can safely skip this step.
Step 2 - making sure it works
Before we begin, make sure you close down QPST, otherwise EfsTools will error out because there can not be two clients connected at once.
Unzip EfsTools from above, open up a cmd window and cd to the directory where you extracted it. Depending on how you connect to diag you will need to modify EfsTools.exe.config - if you're connecting via USB you most likely won't have to do anything as it will find the port automatically, unless you have more than one port, in which case you can simply change port from Auto to the COM port of the phone (for example COM13).
If you are connected via wifi you will need to change port to 2500 (or whatever port you used in the AsusVoLTE app) and remote to true. So the efstool line should look something like this:
You can test the connection by running this in the cmd window:
This should report back some info if everything is working. If not, try rebooting the device and redo the bits from the DIAG guide.
Step 3 - disabling mcfg
Extract efs.zip from above to the same directory as EfsTools.exe, and make sure the mcfg_autoselect_by_uim file is there. Now simply run this in the cmd window, one line at a time:
If everything worked you should see no error messages.
Step 4 - writing mbn
If you are using the Xiaomi Mi 9T mbns zip from above, move it to the EfsTools directory and extract it. Now we simply need to find the mbn for your carrier.
The mbn directory structure is generally laid out like this: <region>/<carrier>/commerci/<country>/mcfg_sw.mbn. For example, the one for my carrier is eu/h3g/commerci/se/mcfg_sw.mbn. Copy the mcfg_sw.mbn file to the same directory as the EfsTools.exe, then go to the cmd window you opened and type this:
If it has worked you should see a bunch of output, but no errors. Try rebooting now, and hopefully after it has booted you will have fully functional VoLTE and VoWiFi.
Source code:
AsusVoLTE - Github
EfsTools - Github
Let me know if this works for you, or if you have any questions.
Regards
Click to expand...
Click to collapse
Absolutely genius, your work here is greatly appreciated everything is working perfectly VoLTE and VoWiFi with caller display
I used the EE mbn included in the Xiaomi Mi 9T MBNs provided , So for anyone on EE i can say it works without a problem.
Thank you :good:HomerSp
in device manager it shows up as
Qualcomm HS-USB Android DIAG 902D (COM13)
EDIT: It started working oddly enough. Which mi9 file would I flash for tmobile USA to test?
Thank you in advance for this!
Edit 2: got it working! Had to Uninstall, reinstall qpst, open up app and click enable DIAG, then stop the server in qstp and input the commands and it worked!
HomerSp said:
Could you try this updated EfsTools: https://github.com/HomerSp/EfsTools...modded-1.1/EfsTools-0.10-modded-1.1-win32.zip Hopefully it should work for you.
sys.usb.state is supposed to say just rndis,adb - diag will only be listed in sys.usb.config.
Click to expand...
Click to collapse
Thought so, just wanted to make sure.
https://imgur.com/a/WZvKteM is what I get. Is it possible to go back to an earlier RAW rom? I want to see if theres something in earlier ROMS that will make it work. I'm just at a loss. I'm not sure what I'm missing for this to work.
@HomerSp, thanks so much for all your efforts and skills - works a charm on ee UK using Mi9T MBN's
xbamaris1` said:
I cannot for the life of me get either method to work. Connected via USB. DIAG mode driver is loaded on COM1, even changed Baud rate on the COM port in device manager to 38400. USB method gives me "Critical Error: Bad Command" Remote method does not send any information but indefinitely runs. I'm really not sure what else to try. Im on the latest WW Firmware with Magisk root. Is there anything else I can check? Are you on the 8 GB Tencent version?
Click to expand...
Click to collapse
Same issue as you, i had it working at the start then it just stopped altogether. Hoping a next asus update could reset whatever i did to it and retry it again
Mine is getting stuck on "Use serial port 'COM5'" and nothing happens after that. Any recommendations how to make it work?
killerdvd said:
Mine is getting stuck on "Use serial port 'COM5'" and nothing happens after that. Any recommendations how to make it work?
Click to expand...
Click to collapse
I had to Uninstall qpst entirely, reinstall it. Then plug my phone in, open up the Asus volteapp and hit enable DIAG, my device then showed up in device manager, then I stopped the qpst server and it worked for me just fine. Using windows 10 with latest update.
Cammarratta said:
I had to Uninstall qpst entirely, reinstall it. Then plug my phone in, open up the Asus volteapp and hit enable DIAG, my device then showed up in device manager, then I stopped the qpst server and it worked for me just fine. Using windows 10 with latest update.
Click to expand...
Click to collapse
Thanks for the quick response. My device is already showing in device manager with COM 6. I never installed QPST since is not needed for USB connection. QPST is not even mention on OP.
I want to say the first part says that you need to have DIAG enabled.
Prerequsities
* You must have working DIAG mode. See my other thread for more information on how to set that up.
Click to expand...
Click to collapse
Which I think needed QPST installed. Unless I'm sadly mistaken, then please disregard!