OK, so since getting the 3VO, there's been a small void in my heart whereby i couldn't connect to my home server via OpenVPN on the stock ROM with root...
So i've compiled the required module, and tested it as working.
The loose process, for those who are interested was:
Code:
* Download the HTC EVO 3D kernel source from HTCDev
* Download the Android SDK
* Download an ARM compiler (i used http://www.codesourcery.com/sgpp/lite/arm/portal/release1293)
* Extract all of the archives into seperate dirs.
* Grab a copy of the /proc/config.gz off my handset and drop uncompessed into the HTC source folder
* export ARCH as ARM, and CROSS_COMPILER as the /bin dir of the ARM compiler
* Jump into the HTC source, and run a make menuconfig:
** remove the "kineto" network adapter (it causes make issues...)
** in General> Localversion, set the kernel localversion (ie. -gdb5464d in this case)
** Exit and save changes
* Add CONFIG_TUN=m to 'Makefile'
* Edit the line echo "+" to echo "" in scripts/setlocalversion
* run: make modules SUBDIR=drivers/net
* You should now find "tun.ko" in drivers/net :)
NOTE: Only tested on 2.6.35.13-gdb5464d
Unfortunately, i don't have the time to put it into a flashable zip, so here's some basic instructions.
Pre-Requisites:
A. You have already setup an OpenVPN Server, and know it works
B. You have already downloaded and installed the OpenVPN Application to your handset (install to default locations)
C. You have the required configuration file and client certificate on your device (this example uses '/sdcard/openvpn' as the openvpn config directory.)
Process:
1. Download the tun.zip file below, and unzip it.
2. Place the 'tun.ko' file onto your SD card.
3. Open up a terminal emulator, or better yet, SSH to your phone with something like QuickSSHD (makes life easier, but not essential.)
4. Remount the /system partition as read/write:
Code:
mount -o remount,rw /dev/block/mmcblk0p22 /system
5. Create a symlink of the modules directory:
Code:
cd /system/lib/modules
ln -s . `uname -r`
6. Copy the module into the system modules directory
Code:
cp /sdcard/tun.ko /system/lib/modules/
7. Create a symlink for iptables, as the OpenVPN app seems to not work with the defaults for that...
Code:
mkdir /system/xbin/bb
ln -s /system/bin/ifconfig /system/xbin/bb/ifconfig
8. And now test!
Code:
/system/xbin/openvpn --config /sdcard/openvpn/openvpn.conf
9. Once you're happy that all is well, don't forget to remount /system as readonly, by either rebooting, or:
Code:
mount -o remount,ro /dev/block/mmcblk0p22 /system
And that should be that! Any questions, just shout!
Kudos to:
http://sshrootat.blogspot.com/2011/06/compiling-tunko-for-android-openvpn.html
Did you test it and it's working?
Because the kernel source on htcdev.com is only for the CDMA version i thought, isn't it?
Has this been tested on the new 2.3.4 kernel? tun is included as default as far as i am aware
I posted this in another thread on aug 28th with no replies.
"On the htcdev site the evo 3d kernel source they have listed is:
HTC EVO 3D-CRC-2.6.35
not sure what the "crc" stands for but my Rogers gsm evo 3d is kernel 2.6.35.13
does that mean it is the right one or am I too hopefull?"
that kernel has been there for a while cdma or gsm or cross compatible?
htc0101 said:
I posted this in another thread on aug 28th with no replies.
"On the htcdev site the evo 3d kernel source they have listed is:
HTC EVO 3D-CRC-2.6.35
not sure what the "crc" stands for but my Rogers gsm evo 3d is kernel 2.6.35.13
does that mean it is the right one or am I too hopefull?"
that kernel has been there for a while cdma or gsm or cross compatible?
Click to expand...
Click to collapse
yes, CRC is the 2.3.3 source and as far as I am aware, totally cross compatable (gsm/cdma)... HTC are farr to slow when it comes to source
not sure what it stands for tbh but the 2.3.3 kernel did not have the built in tun module, if you attempt to insmod a tun module on the 2.3.4 kernel it will reject it as the symbols declared are already defined in the zImage.. good old HTC!
OK, so to answer the questions- i'm not sure if the CRC source itself is cross compatible between GSM and CDMA- i would initially assume not due to whatever wireless device modules are contained within, although Leedroid is suggesting otherwise, and i'd probably take his word on it than mine
The tun module is irrelevant however in any case, as im not compiling an entire kernel, just the one module which is not baseband dependant (ie. it *is* GSM/CDMA cross compatible).
Aside from this, the android version (ie. 2.3.3 or 2.3.4 etc) is also fairly irrelevant, on the basis that you compile for the kernel rather than the OS version (it's still roughly the same underlying OS anyway); particularly as there's no major differences that affect tunnelling between the two revisions that i'm aware of- i can however confirm that the source code was for 2.6.35.10 - which i believe is the original/updated CDMA kernel. However, you would need to recompile the module for it to work on any kernel other than *2.6.35.13*, as modprobe will reject it otherwise due to it being compiled for that specific version.
If you happen to need it for another kernel version and don't fancy compiling it yourself, drop me a note and i'll see what i can do. FYI- I'll need it in the format of "2.6.35.13-gdb5464d". Maybe i'll write a n00bs guide sometime...
Second from lastly; you can probably hexedit the version number to one of your choosing! As long as it matches the string length; ie. full kernel number = 18 characters incuding dots; it will work
And lastly, yes it does work, i'm using it now to connect to my home VPN Stock rooted GSM (UK) 3VO, running 2.3.4, and the kernel it was compiled for (2.6.35.13-gdb5464d)
LeeDroid said:
if you attempt to insmod a tun module on the 2.3.4 kernel it will reject it as the symbols declared are already defined in the zImage.. good old HTC!
Click to expand...
Click to collapse
Strange... i haven't seen any such issues here? That's with the HTC stock kernel? CDMA?
dalgibbard said:
Strange... i haven't seen any such issues here? That's with the HTC stock kernel? CDMA?
Click to expand...
Click to collapse
I had initially made the assumption that HTC would have configured the Evo kernel as they did the sensation, turns out this is not the case, sensation 2.6.35.13 includes tun, howerver the EVO kernel does not... Hmm, wonder what they were thinking?...
My reference to 2.3.3 & 2.3.4 was not directed at the kernel but used as a point of reference for the supplied kernels (in noob terms)
Sent from my s-off HTC sensation running LeeDrOiD Sensational
Well htcdev just released the new MR kernel for the 3d......
Sent from my HTC EVO 3D X515m using xda premium
Thanks for the feedback although I'd be inclined to disagree, mainly on the basis that the CONFIG_TUN option in /proc/config.gz isn't set?
I would say though that i've switched to your ROM (which is pretty great!), and a quick 'find /system -name "*tun*"' doesn't yield any results, so its not modulised- and 'zcat /proc/config.gz | grep "CONFIG_TUN" throws back "# CONFIG_TUN is not set"
That and openVPN doesn't seem to be working yet
I am curious about compiling my own modules (would like to try a few other modules out). Which HTC source do you use for a phone running 2.6.35.10-gbc1cf83, I've tried both crc and mr with no luck I am using the compiler in the NDK to compile. I can build the module but it will not load or I get "init_module './tun.ko' failed (Exec format error)" sounds like maybe the compiler is not working correctly. I would like to use the "codesourcery" compiler but I can not seem to find it.
TIA
Jason
Sorry for the delay Jason, been out of the country for a while I struggled to remember whereabouts on their website it was... So try this instead: http://fingaz.info/armeabi.tar.bz2
jayray1- I'm running the same kernel and was experiencing the same error when trying to install the tun.ko I had just compiled. If you check dmesg after performing the insmod it may give you some insight into why its not loading. In my case it was because I had neglected to include '.10-' in the EXTRAVERSION var of the Makefile for the kernel source, so the magic number of the module was not matching the kernel version.
Your Makefile should contain the following to compile modules for 2.6.35.10-g93c03bf.
Code:
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 35
EXTRAVERSION = .10-g93c03bf
Also if you're curious, I compiled tun.ko with shooter-2.6.35_mr, though I don't really understand what the difference between MR and CRC kernel source is.
I've attached the tun.ko that I compiled since I couldn't find one elsewhere on the internetz.
Samsung Galaxy S2 - Lightning rom 6.1 - OpenVPN - BusyBox
On my mobile device (Samsung Galaxy S2+Ligthting rom 6.1 - Gingerbread 2.3.4) I can start OpenVPN and I have ip (10.8.0.10) from remote/home server (Debian Squeeze) but I can't connect on my remote/home lan devices (router, pc, etc.); I used tun.zip
The same OpenVPN files work well on Windows and Linux, I can connect all lan hardware !
[email protected]:/home/gabriele# ssh XXX.XXX.XXX.XXX
The authenticity of host 'XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)' can't be established.
RSA key fingerprint is XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'XXX.XXX.XXX.XXX' (RSA) to the list of known hosts.
QuickSSHD for Android
[email protected]'s password:
# mount -o remount,rw /dev/block/mmcblk0p22 /system
# cd /system/lib/modules
cd: can't cd to /system/lib/modules
# mkdir modules
# ln -s . `uname -r`
# cp /sdcard/tun.ko /system/lib/modules/
# mkdir /system/xbin/bb
# ln -s /system/bin/ifconfig /system/xbin/bb/ifconfig
# /system/xbin/openvpn --config /sdcard/openvpn/client.ovpn
Sat Dec 31 15:08:54 2011 OpenVPN 2.1.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Feb 2 2010
Sat Dec 31 15:08:54 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sat Dec 31 15:08:54 2011 WARNING: file '/sdcard/openvpn/keyone.key' is group or others accessible
Sat Dec 31 15:08:54 2011 LZO compression initialized
Sat Dec 31 15:08:54 2011 Control Channel MTU parms
Sat Dec 31 15:08:54 2011 Data Channel MTU parms
Sat Dec 31 15:08:54 2011 Local Options hash (VER=V4):
Sat Dec 31 15:08:54 2011 Expected Remote Options hash (VER=V4):
Sat Dec 31 15:08:54 2011 Socket Buffers: R=[110592->131072] S=[110592->131072]
Sat Dec 31 15:08:54 2011 UDPv4 link local: [undef]
Sat Dec 31 15:08:54 2011 UDPv4 link remote:
Sat Dec 31 15:08:54 2011 TLS: Initial packet from
Sat Dec 31 15:08:56 2011 VERIFY OK: depth=1, /C=IT/ST=
Sat Dec 31 15:08:56 2011 VERIFY OK: nsCertType=SERVER
Sat Dec 31 15:08:56 2011 VERIFY OK: depth=0, /C=IT/ST=
Sat Dec 31 15:08:58 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Dec 31 15:08:58 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Dec 31 15:08:58 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Dec 31 15:08:58 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Dec 31 15:08:58 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 , 1024 bit RSA
Sat Dec 31 15:08:58 2011 [server01] Peer Connection Initiated with
Sat Dec 31 15:09:00 2011 SENT CONTROL [server01]: 'PUSH_REQUEST' (status=1)
Sat Dec 31 15:09:00 2011 PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,dhcp-option DNS 10.8.0.1,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.10 10.8.0.9'
Sat Dec 31 15:09:00 2011 OPTIONS IMPORT: timers and/or timeouts modified
Sat Dec 31 15:09:00 2011 OPTIONS IMPORT: --ifconfig/up options modified
Sat Dec 31 15:09:00 2011 OPTIONS IMPORT: route options modified
Sat Dec 31 15:09:00 2011 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Dec 31 15:09:00 2011 ROUTE default_gateway=
Sat Dec 31 15:09:00 2011 TUN/TAP device tun1 opened
Sat Dec 31 15:09:00 2011 TUN/TAP TX queue length set to 100
Sat Dec 31 15:09:00 2011 /system/xbin/bb/ifconfig tun1 10.8.0.10 pointopoint 10.8.0.9 mtu 1500
Sat Dec 31 15:09:00 2011 /system/xbin/bb/route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.8.0.9
Sat Dec 31 15:09:00 2011 ERROR: Linux route add command failed: could not execute external program
Sat Dec 31 15:09:00 2011 /system/xbin/bb/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.9
Sat Dec 31 15:09:00 2011 ERROR: Linux route add command failed: could not execute external program
Sat Dec 31 15:09:00 2011 Initialization Sequence Completed
I don't know what file I need to modify on my mobile device, I know Debian Gnu Linux and on this o.s. it is easy solve problem !
GbMax78
Well described issue! I can see the issue too- you see where you've done the "ln -s" for ifconfig? You need to do the same again, but swap "ifconfig" for "route", as openvpn is failing to locate it.
ln -s /system/bin/route /system/xbin/bb/route
That is of course assuming that route is actually in /system/bin/
Samsung Galaxy S2 - Lightning rom 6.1 - OpenVPN - BusyBox [SOLVED]
dalgibbard said:
ln -s /system/bin/route /system/xbin/bb/route
Click to expand...
Click to collapse
QuickSSHD for Android
[email protected]'s password:
# ls
# cd ..
# ls
dropbear home lib shared_prefs
# ln -s /system/bin/route /system/xbin/bb/route
ln: /system/xbin/bb/route: Read-only file system
# mount -o remount,rw /dev/block/mmcblk0p22 /system
# ln -s /system/bin/route /system/xbin/bb/route
# mount -o remount,ro /dev/block/mmcblk0p22 /system
# /system/xbin/openvpn --config /sdcard/openvpn/client.ovpn
Sun Jan 1 16:12:38 2012 OpenVPN 2.1.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Feb 2 2010
Sun Jan 1 16:12:38 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sun Jan 1 16:12:38 2012 WARNING: file '/sdcard/openvpn/keyone01.key' is group or others accessible
Sun Jan 1 16:12:38 2012 LZO compression initialized
Sun Jan 1 16:12:38 2012 Control Channel MTU parms [ X:XXXX X:XXX XX:XX XX:X XX:X XX:X ]
Sun Jan 1 16:12:39 2012 Data Channel MTU parms [ X:XXXX X:XXXX XX:XX XX:XXX XX:0 EL:0 AF:3/1 ]
Sun Jan 1 16:12:39 2012 Local Options hash (VER=V4): 'XXXXXXXX'
Sun Jan 1 16:12:39 2012 Expected Remote Options hash (VER=V4): 'XXXXXXXX'
Sun Jan 1 16:12:39 2012 Socket Buffers: R=[110592->131072] S=[110592->131072]
Sun Jan 1 16:12:39 2012 UDPv4 link local: [undef]
Sun Jan 1 16:12:39 2012 UDPv4 link remote: XX.XXX.XX.XX:1194
Sun Jan 1 16:12:39 2012 TLS: Initial packet from XX.XXX.XX.XX:1194, sid=XXXXXXXXXXXXXXXXXX
Sun Jan 1 16:12:40 2012 VERIFY OK: depth=1, /C=IT/ST=XX/L=XXXXXXXXXX/O=XXXXXX/OU=XXXXXX/CN=server01/name=XXXXXXXX/[email protected]
Sun Jan 1 16:12:40 2012 VERIFY OK: nsCertType=SERVER
Sun Jan 1 16:12:40 2012 VERIFY OK: depth=0, /C=XX/ST=XX/L=XXXXXXXXXX/O=XXXXXX/OU=XXXXXX/CN=server01/name=XXXXXXXX/[email protected]
Sun Jan 1 16:12:42 2012 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Jan 1 16:12:42 2012 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jan 1 16:12:42 2012 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Jan 1 16:12:42 2012 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jan 1 16:12:42 2012 Control Channel: TLSv1, cipher TLSv1/SSLv3 XXX-RSA-AES256-SHA, 1024 bit RSA
Sun Jan 1 16:12:42 2012 [server01] Peer Connection Initiated with XX.XXX.XX.XX:1194
Sun Jan 1 16:12:44 2012 SENT CONTROL [server01]: 'PUSH_REQUEST' (status=1)
Sun Jan 1 16:12:45 2012 PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,dhcp-option DNS 10.8.0.1,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Sun Jan 1 16:12:45 2012 OPTIONS IMPORT: timers and/or timeouts modified
Sun Jan 1 16:12:45 2012 OPTIONS IMPORT: --ifconfig/up options modified
Sun Jan 1 16:12:45 2012 OPTIONS IMPORT: route options modified
Sun Jan 1 16:12:45 2012 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Jan 1 16:12:45 2012 ROUTE default_gateway=XXX.XX.XXX.X
Sun Jan 1 16:12:45 2012 TUN/TAP device tun0 opened
Sun Jan 1 16:12:45 2012 TUN/TAP TX queue length set to 100
Sun Jan 1 16:12:45 2012 /system/xbin/bb/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1500
Sun Jan 1 16:12:45 2012 /system/xbin/bb/route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.8.0.5
Sun Jan 1 16:12:45 2012 /system/xbin/bb/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.5
Sun Jan 1 16:12:45 2012 Initialization Sequence Completed
Fantastic !!! Wonderful !!! THANK YOU VERY MUCH !
Happy new year !!!
GbMax78
No problem, glad it worked.
One last thing- "keyone01.key" should only be root readable, that's why your getting an error about it for group perms.you can fix that by doing:
chmod 600 /path/to/keyone01.key
Not essential, but fairly wise from a security point of view, and it'll fix that error
Samsung Galaxy S2 - Lightning rom 6.1 - OpenVPN - BusyBox [SOLVED]
dalgibbard said:
No problem, glad it worked.
Click to expand...
Click to collapse
You solved a big problem, I know Debian Gnu Linux, I use Zenwalk and Slackware but Android it isn't the same...
dalgibbard said:
One last thing- "keyone01.key" should only be root readable, that's why your getting an error about it for group perms.
Click to expand...
Click to collapse
I don't understand what are Android perms and when I start the phone I don't know if I am root or normal user !
There is message "WARNING: file '/sdcard/openvpn/keyone.key' is group or others accessible" because all users can access this file ? Now keyone01.key is 777 ? But if I make keyone01.key root readable only I have problems if I start the phone as normal user ?
dalgibbard said:
you can fix that by doing:
chmod 600 /path/to/keyone01.key
Click to expand...
Click to collapse
Ok when I have one minute I do that !
dalgibbard said:
Not essential, but fairly wise from a security point of view, and it'll fix that error
Click to expand...
Click to collapse
I would like to understand perms on Android, on Linux if you change files perms for root only, normal user can't use them but if there is one user, root, this is the reason to change perms for root only !
GbMax78
Sorry, regarding that whole permissions thing, ignore it-even as root you can't change the perms of the file (namely the owner) as it had to keep the sdcard_rw group in order for you to list the file... Probably still worth chmodding it to 600 though, you just can't change the owner to root, meaning that error won't go away it's not a problem though really, more an observation.
The idea was that openvpn is run as root (standard users can't access the tun module) and therefore in order to protect your secret key (which normally you should as it gives anyone with access to the file, access to you network...), the key should be owned by the person who runs the app (in this case "root") and the permissions changed to only allow them access. It in the same manner as Linux/UNIX permissions anyway
For reference for anyone that doesn't know, the chmod is broken down into three elements-the first digit is for the "owner", the next is for the "group", and the last is for everyone else. The numbers are added up from the following dependant on which perms are required:
4= read
2= write
1= execute
So 600 means to give read and write access without execute to the file owner. The zeros elsewhere mean to give those users/groups nothing.
Hope that helps!
PS for the Linux geeks on here reading this, there is a fourth value too for sticky bit etc, but I won't cover that here
Any chance of getting a tun.ko module compiled for kernel 2.6.35.13-g84f8edd (EVO 3D CDMA running stock kernel and Fresh Evo 3d 4.1.0)?
I tried the tun.ko in this thread and I get an exec error when I try insmod which I believe usually indicates a kernel/compile mismatch.
Thanks!
Related
Hi all,
I'm trying to get OpenVPN running on my Galaxy S2. I installed the OpenVPN Installer and OpenVPN Settings from Market (OpenVPN 2.1.1), and I am starting with an OpenVPN config file that I know works (it's a working config that I use on my XUbuntu system):
client
dev tun
proto udp
remote somehost.somedomain.com 1194
ifconfig 192.168.21.10 255.255.255.0
redirect-gateway def1
nobind
ca ca.crt
cert my.crt
key my.key
verb 3
mute 10
The first thing is that the "ifconfig" doesn't seem to be accepted:
Options error: Unrecognized option or missing parameter(s) in config.ovpn:5: ifconfig (2.1.1)
If I comment this out, I get:
Fri Dec 30 21:32:07 2011 NOTE: unable to redirect default gateway -- VPN gateway parameter (--route-gateway or --ifconfig) is missing
However, I ALSO do not see any "ifconfig" calls in the openvpn log this way, which makes me thing that OpenVPN isn't actually setting up the tunnel, which probably explains the later errors (see below).
If I add a "route-gateway 192.168.21.5", (that's the def gateway that my Xubuntu system ends up with when i start this VPN connection) I get:
Fri Dec 30 21:34:27 2011 /system/xbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 192.168.21.5
route: SIOCADDRT: No such process
Fri Dec 30 21:34:27 2011 ERROR: Linux route add command failed: external program exited with error status: 1
Fri Dec 30 21:34:27 2011 /system/xbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 192.168.21.5
route: SIOCADDRT: No such process
Fri Dec 30 21:34:27 2011 ERROR: Linux route add command failed: external program exited with error status: 1
On my Xubuntu system I don't actually need to add any "route-gateway", as I think the OpenVPN version there (2.2.0) understands the "redirect-gateway" directive, while I don't think that OpenVPN 2.1.1 understands that yet.
Can anybody recommend correct settings so I can make this work?
Regards
[edit] Oh, nice. I flashed an insecure ROM to my phone, then used the "openvpn-static.bz2" binary from this location (copied to /system/xbin/openvpn), and now it works.
Hello guys
so i got openvpn and installed it and everything but somehow when i click the .ovpn file it doesn't work, it doesn't put a tick mark next to it, it says that it was granted superuser permission but nothing else happens.
so what could be the problem if anyone had this before and was able to fix it
any help would be greatly appreciated thank you in advance.
Can you post your .ovpn file? Be careful not to post anything that could compromise your privacy!
Please also post a screenshot of the 'OpenVPN Settings' App when clicking Menu -> Advanced.
Which Vpn are you using ?, when i tried using open vpn on mine it didnt work, The vpn provider told me to set it up through the vpn settings in the phone itself and that worked fine for me, could be worth a try
Thaw.Bytes said:
Which Vpn are you using ?, when i tried using open vpn on mine it didnt work, The vpn provider told me to set it up through the vpn settings in the phone itself and that worked fine for me, could be worth a try
Click to expand...
Click to collapse
He is using OpenVPN, not "part of the phone".
Ahhh sorry my mistake i misread his post
Sorry for the delay in replying, but here are 2 images of the settings but i don't think the .ovpn files has any issues i think its only the phone or openvpn itself.
Well, if you think your .ovpn file is fine and certificate(s) and key(s) are at correct locations then you should take a look at the log.
To do this use 'adb' with the 'logcat' command. As soon as 'logcat' is running try to tick your OpenVPN configuration and check the log for any errors.
This is what I get when the status bar asks me to enter the certificate password (did some manual formatting for better reading ):
Code:
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-mgmt(12164): attach(): using management port at 27460
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-mgmt(12164): attaching to OpenVPN daemon: failed to connect to /127.0.0.1 (port 27460): connect failed: ECONN REFUSED (Connection refused)
W/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn](12164): start(): choosing random port for management interface: 39157
[B]D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-daemon(12164): invoking external process: /system/xbin/su[/B]
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-daemon(12164): invoking command line: /system/xbin/openvpn --cd '/sdcard/openvpn' --config 'VPNTEST.ovpn' --writepid '/data/data/de.schaeuffelhut.android.openvpn/files/com.d/_sdcard_openvpn_VPNTEST.ovpn-pid' --script-security 1 --management 127.0.0.1 39157 --management-query -passwords --verb 3
D/OpenVPNDaemonEnabler(12164): Received OpenVPN daemon state changed from Unknown to Startup
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-daemon-stdout(12164): Mon Apr 30 16:22:11 2012 OpenVPN 2.1.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Jan 6 2012
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-daemon-stdout(12164): Mon Apr 30 16:22:11 2012 MANAGEMENT: TCP Socket listening on 127.0.0.1:39157
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-daemon-stdout(12164): Mon Apr 30 16:22:11 2012 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-daemon-stdout(12164): Mon Apr 30 16:22:11 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
[B]D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-daemon-stdout(12164): Mon Apr 30 16:22:11 2012 Need password(s) from management interface, waiting...[/B]
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-mgmt(12164): started
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-mgmt(12164): attach(): using management port at 39157
V/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-mgmt(12164): Successfully attached to OpenVPN monitor port
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-daemon-stdout(12164): Mon Apr 30 16:22:11 2012 MANAGEMENT: Client connected from 127.0.0.1:39157
V/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-mgmt(12164): Socket IO established
D/OpenVPNDaemonEnabler(12164): Received OpenVPN daemon state changed from Unknown to Enabled
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-mgmt(12164): >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-daemon-stdout(12164): Mon Apr 30 16:22:11 2012 MANAGEMENT: CMD 'state'
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-daemon-stdout(12164): Mon Apr 30 16:22:11 2012 MANAGEMENT: CMD 'state on'
D/OpenVPNDaemonEnabler(12164): Received OpenVPN network state changed from Unknown to Connecting
V/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-mgmt(12164): onState("1335795731,CONNECTING,,,")
D/OpenVPN-Settings-getprop(12164): invoking external process: /system/bin/sh
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-daemon-stdout(12164): Mon Apr 30 16:22:12 2012 MANAGEMENT: CMD 'bytecount 0'
D/OpenVPN-Settings-getprop(12164): invoking command line: getprop net.dnschange
D/OpenVPN-Settings-getprop-stdout(12164): 66
I/OpenVPN-Settings-getprop-stdout(12164): terminated
I/OpenVPN-Settings-getprop-stderr(12164): terminated
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-mgmt(12164): =============> 0 == 66 resetting dns, leaving dns alone
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-mgmt(12164): SUCCESS: real-time state notification set to ON
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-mgmt(12164): SUCCESS: bytecount interval changed
D/OpenVPNDaemonEnabler(12164): Received OpenVPN network state changed from Connecting to Connecting
Note: OpenVPN is waiting here for the password. I did not enter it yet.
From what you said you do not even reach this 'checkpoint' so for now there is no need to debug any further.
This is what i get:
Code:
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPN-Server.ovpn]-mgmt(30883
): attach(): using management port at 24475
E/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPN-Server.ovpn]-mgmt(30883
): attaching to OpenVPN daemon: /127.0.0.1:24475 - Connection refused
W/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPN-Server.ovpn](30883): st
art(): choosing random port for management interface: 41258
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPN-Server.ovpn]-daemon(308
83): invoking external process: /system/bin/su
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPN-Server.ovpn]-daemon(308
83): invoking command line: /system/xbin/openvpn --cd '/sdcard/openvpn' --config
'VPN-Server.ovpn' --writepid '/data/data/de.schaeuffelhut.android.
openvpn/files/com.d/_sdcard_openvpn_VPN-Server.ovpn-pid' --script-
security 1 --management 127.0.0.1 41258 --management-query-passwords --verb 3
E/su (31797): sudb - Opening database
E/su (31797): sudb - Database opened
E/su (31797): sudb - Database closed
D/su (31797): 10198 de.schaeuffelhut.android.openvpn executing 0 /system/bi
n/sh using shell /system/bin/sh : sh
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPN-Server.ovpn]-daemon-std
out(30883): Options error: Unrecognized option or missing parameter(s) in VPN-Server.ovpn:12: dhcp-renew (2.1.1)
D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPN-Server.ovpn]-daemon-std
out(30883): Use --help for more information.
I/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPN-Server.ovpn]-daemon-std
out(30883): terminated
I/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPN-Server.ovpn]-daemon-std
err(30883): terminated
D/OpenVPn Settings(30883): Closing log file /sdcard/openvpn/VPN-Ser
ver.log
I/WindowManager( 1650): CREATE SURFACE Surface(name=Toast, identity=1061, mNat
iveSurface=0) IN SESSION [email protected]: pid=30916 format=
-3 flags=0x0 / Window{40555140 Toast paused=false}
D/PowerManagerService( 1650): acquireWakeLock flags=0xa tag=KEEP_SCREEN_ON_FLAG
uid=1000 pid=1650 myUID=1000 myPID=1650 myTID=1845
D/OpenVPNDaemonEnabler(30883): Received OpenVPN daemon state changed from Unknow
n to Startup
D/OpenVPNDaemonEnabler(30883): Received OpenVPN daemon state changed from Unknow
n to Disabled
thank you
Seems to be a problem with root. From your log:
Code:
E/su (31797): sudb - Opening database
E/su (31797): sudb - Database opened
E/su (31797): sudb - Database closed
If I'm not mistake OpenVPN must be executed as superuser. From my log:
Code:
[B][COLOR="SeaGreen"]D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-daemon(12164): invoking external process: /system/xbin/su
[/COLOR][/B]D/OpenVPN-DaemonMonitor[/sdcard/openvpn/VPNTEST.ovpn]-daemon(12164): invoking command line: /system/xbin/openvpn --cd '/sdcard/openvpn' --config 'VPNTEST.ovpn' --writepid '/data/data/de.schaeuffelhut.android.openvpn/files/com.d/_sdcard_openvpn_VPNTEST.ovpn-pid' --script-security 1 --management 127.0.0.1 39157 --management-query -passwords --verb 3
Look at the green bold line: it is running su, only afterwards OpenVPN is invoked.
From your log (same location as in mine) I can see that there is a problem with root access.
To test this you can use 'adb' and the 'shell' command. Enter 'su' yourself to get root access. Then enter the command line from your log. I bet if 'su' succeeds, i.e. you get root access, then OpenVPN will start .
I'm sorry if this seems stupid but what exactly i should enter from my log
i got to the part where it says
su
#
but i just need to know what exactly should i enter afterwards
thank you so much
No, not stupid, I was just going way too fast. If one does not understand an explanation this is usually due to the explanation not being accurate, in short: my mistake
It took me some time but I think I found a better way to examine your problem.
First we need an alternative possibility to enter the password of the key file when starting OpenVPN manually from the adb console. OpenVPN is supposed to ask for the password on stdin if started with option '--askpass' without any file to lookup passwords. Though this dos not work on my phone, hence I have created a file name 'test.passwd' containing only one line with my OpenVPN key password. This file must be located in the same directory as the 'ovpn' file.
When your done with this you are ready to start OpenVPN 'manually' by doing this:
1) run 'adb shell'
2) type 'su'
3) type 'whoami' and make sure you are root (userid 0)
4) type
Code:
/system/xbin/openvpn --cd '/sdcard/openvpn' --config VPN-Server.ovpn --askpass test.passwd
Assuming you named the file holding your password 'test.passwd'
OpenVPN should now connect to your server and you should see something similar to this:
Code:
Tue May 1 10:55:03 2012 OpenVPN 2.1.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Jan 6 2012
Tue May 1 10:55:03 2012 WARNING: file 'test.passwd' is group or others accessible
Tue May 1 10:55:03 2012 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Tue May 1 10:55:03 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue May 1 10:55:03 2012 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue May 1 10:55:03 2012 WARNING: file './[email protected]_one_cares.p12' is group or others accessible
Tue May 1 10:55:03 2012 LZO compression initialized
Tue May 1 10:55:03 2012 UDPv4 link local: [undef]
Tue May 1 10:55:03 2012 UDPv4 link remote: xxx.yyy.zzzz.wwww:1194
Tue May 1 10:55:04 2012 [openvpn.myvpn.server] Peer Connection Initiated with xxx.yyy.zzzz.wwww:1194
Tue May 1 10:55:06 2012 TUN/TAP device tun0 opened
Tue May 1 10:55:06 2012 /system/bin/ifconfig tun0 192.168.101.6 pointopoint 192.168.101.5 mtu 1500
Tue May 1 10:55:06 2012 Initialization Sequence Completed
At this point you should invoke another 'adb shell' and type 'busybox ifconfig'. If you see a tun0 device then the OpenVPN connection is established.
On my system this looks like this:
Code:
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:171 errors:0 dropped:0 overruns:0 frame:0
TX packets:171 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:11713 (11.4 KiB) TX bytes:11713 (11.4 KiB)
[B]tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.101.6 P-t-P:192.168.101.5 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)[/B]
wlan0 Link encap:Ethernet HWaddr 12:34:56:78:9A:BC
inet addr:xyz.vw.11.32 Bcast:xyz.vw.11.255 Mask:255.255.255.0
inet6 addr: f370::6sd6:f891:fz8e:9qqb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8185 errors:0 dropped:271 overruns:0 frame:0
TX packets:9578 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2058632 (1.9 MiB) TX bytes:1000224 (976.7 KiB)
If not check the output of the other shell, it will tell you about where to search for the problem (hopefully ).
Unfortunately this didn't work, i get this when i enter that command
Code:
Options error: Unrecognized option or missing parameter(s) in VPN-S
erver.ovpn:12: dhcp-renew (2.1.1)
Use --help for more information.
and when i do the 'whoami' command i get this
Code:
whoami: unknown uid 0
but I think the password is not the issue because when I click on the server to open it in openvpn( put a tick next to it) it doesn't put a tick it doesn't even reach the password point i think its an issue much earlier than the password point.
I just get the superuser message 'OpenVPN Settings has been granted superuser permissions' and nothing else happens at all.
I can tick/start the main button on the top 'OpenVPN' but I can't start the server.
just to note that i used doom lord rooting tool kit version 4 to root the phone if the issue is root related or something.
Thank you again.
xdaian948 said:
Unfortunately this didn't work, i get this when i enter that command
Code:
Options error: Unrecognized option or missing parameter(s) in VPN-S
erver.ovpn:12: dhcp-renew (2.1.1)
Use --help for more information.
Click to expand...
Click to collapse
As I said in my very first post: please provide the contents of your .ovpn file. Even if you believe it is correct it seems to contain options that do not work, as stated by the error message!
and when i do the 'whoami' command i get this
Code:
whoami: unknown uid 0
Click to expand...
Click to collapse
This is fine, you are root.
but I think the password is not the issue because when I click on the server to open it in openvpn( put a tick next to it) it doesn't put a tick it doesn't even reach the password point i think its an issue much earlier than the password point.
Click to expand...
Click to collapse
I did not say (and to tell the truth I don't believe) it is a problem with the password since, as I described in my last post, you do not even reach the point where OpenVPN could ask you for the password.
I just get the superuser message 'OpenVPN Settings has been granted superuser permissions' and nothing else happens at all.
I can tick/start the main button on the top 'OpenVPN' but I can't start the server.
Click to expand...
Click to collapse
The method I proposed for debugging boils things down to the bare minimum and therefore reduces the chance of any other misconfiguration then the one of OpenVPN. You better don't use the 'graphical interface' until OpenVPN runs fine from the command line.
just to note that i used doom lord rooting tool kit version 4 to root the phone if the issue is root related or something.
Click to expand...
Click to collapse
Don't know what this is but sounds cool , anyway it seems rooting is ok.
Thank you again.
Click to expand...
Click to collapse
You are welcome, but please consider that your .ovpn configuration file could have an error. The error reported in your log is due to a misconfiguration in your .ovpn file I believe. This is why OpenVPN exits.
Alright i'll send you the .ovpn files in a PM now
Thank you.
this is the rooting method i was talking about btw
Code:
http://forum.xda-developers.com/showthread.php?t=1321582
Ok, got your files by PM.
Besides the remote destination you would connect to and perhaps the names of the certificate and key file there is no security relevant information you could not post here I think.
Anyway: the files look like you are connecting to a VPN server that is not your server, i.e. you have no control of the OpenVPN server, correct? In this case I can't really help you, you should ask the VPN provider.
If the VPN server was your own server I would have suggested to radically comment options until you manage to establish a basic connection. Your log clearly shows that there seems to be problem with the option 'dhcp-renew' but as you are not running the VPN server I do not know if you can comment this or any other option, sorry .
My .ovpn file looks like this:
Code:
; OpenVPN client configuration for
; access to xyz enterprise
;
client
dev tun
proto udp
remote xxx.yyy.zzz.www 1194
nobind
comp-lzo
pkcs12 ./p12_ca_cert_private_cert_and_key_bundle.p12
verb 1
This configuration works perfect including routing and DNS resolution by the internal DNS servers of xyz enterprise.
You can try to eliminate (comment) options in your .ovpn file yourself hoping you get a result having no offending option left, but this might be tedious without knowledge of the server end . If you try this please note that your configuration uses 3 individual files, one for the CA cert, one for your cert and one for the key while my configuration uses only one file (certs and key bundled). You must keep your 'three file' configuration.
Well, i'll just ask the support of the VPN provider and see what they can do there might be a problem on their end, and i want to thank you so much for everything you have done
After lots of discussion about the famous "SuperBrick" issue on GT-I9100 4.0.4 stock kernels, I wrote a script to allow everyone to check it on their own and hopefully patch it if needed.
Main goal - Detection
Detect if a STOCK kernel has MMC_CAP_ERASE enabled (unsafe) or not (safe).
I have validated it against XWLPG, XWLPM, XWLPO, XWLPT, XXLP5, XXLP5-CFRoot and all of them were detected correctly: safe on 4.0.3 kernels, unsafe on 4.0.4 ones.
I also checked it against Siyah 3.5.2 (despite knowing from the sources it's safe) and it was also correctly detected.
However, for custom kernels I don't expect the code patterns to be always the same and therefore it's possible that the detection is inconclusive - you will see that in the output.
Secondary goal - Fixing (instructions provided, not the tools)
When an unsafe kernel is detected, provide instructions on how to patch the code so it's safe.
For that, you'll need:
* an external kernel unpack/repack script (just search the forum as there are several available)
* a Linux box
* a hex editor
* any other requirements for the repack script: CROSS_COMPILE, etc.
Requirements for this script
This is pretty much self contained and can be run on either:
* Linux
* Windows with Cygwin
Running on the device itself would be theoretically possible but it ultimately depends on the installed Busybox version, in particular the parameters accepted by the "grep" command.
On my v1.20.0-cm9 version it's not possible to make it work.
Sample outputs
Here are some executions against existing kernel images:
The latest XWLPT (4.0.4):
Code:
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: XWLPT/zImage
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012
1 ocurrences of the bad code signature
0 ocurrences of the good code signature
***************
!!! WARNING !!!
***************
[COLOR="Red"]The kernel appears to have MMC_CAP_ERASE *enabled*, which is dangerous on many devices[/COLOR]
Unpacked kernel code stored at: XWLPT/zImage_unpacked
The unsafe instruction can be found at offset 0x00594ec0
==================== Disassembly of the instruction ====================
XWLPT/zImage_instruction: file format binary
Disassembly of section .data:
00000000 <.data>:
0: e3811b01 orr r1, r1, #1024 ; 0x400
========================================================================
*** Instructions for patching ***
- Choose one of the existing unpack/repack scripts
- Unpack the kernel code, initramfs, etc.
- Do a binary edit of the unpacked code
- At offset 0x00594ec0, replace "01 ?b 8? e3" with "00 ?b 8? e3" - change just the first byte to 00
- Repack the kernel, including the changed code and all original contents
- Re-run this script to confirm that the newly generated file no longer has MMC_CAP_ERASE enabled
XWLPG (4.0.3):
Code:
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: XWLPG/zImage
Kernel: Linux version 3.0.15-I9100XWLPG-CL619441 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Thu May 24 18:09:27 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
[COLOR="SeaGreen"]The kernel appears to be good (MMC_CAP_ERASE disabled)[/COLOR]
XXLQ5-CFRoot (4.0.4):
Code:
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: XXLQ5_CFRoot/zImage
Kernel: Linux version 3.0.15-I9100XXLQ5-CL753921 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Thu Jun 28 14:16:15 KST 2012
1 ocurrences of the bad code signature
0 ocurrences of the good code signature
***************
!!! WARNING !!!
***************
[COLOR="Red"]The kernel appears to have MMC_CAP_ERASE *enabled*, which is dangerous on many devices[/COLOR]
Unpacked kernel code stored at: XXLQ5_CFRoot/zImage_unpacked
The unsafe instruction can be found at offset 0x00594ef4
==================== Disassembly of the instruction ====================
XXLQ5_CFRoot/zImage_instruction: file format binary
Disassembly of section .data:
00000000 <.data>:
0: e3811b01 orr r1, r1, #1024 ; 0x400
========================================================================
*** Instructions for patching ***
- Choose one of the existing unpack/repack scripts
- Unpack the kernel code, initramfs, etc.
- Do a binary edit of the unpacked code
- At offset 0x00594ef4, replace "01 ?b 8? e3" with "00 ?b 8? e3" - change just the first byte to 00
- Repack the kernel, including the changed code and all original contents
- Re-run this script to confirm that the newly generated file no longer has MMC_CAP_ERASE enabled
Finally, here's the expected output of a kernel after the patch has been applied.
I didn't actually do the entire kernel repack, but I changed the code and compressed the file in a similar way as it will appear in a "complete" zImage file.
Patched XWLPM:
Code:
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: XWLPM-patched/zImage
Kernel: Linux version 3.0.15-I9100XWLPM-CL837163 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Thu Jul 5 11:26:14 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
[COLOR="Blue"]The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe[/COLOR]
Disclaimers
My main goal here is to provide information, not a one-click solution. I'm personally not worried about this issue since I run a kernel compiled from sources rather than a stock one.
Despite my best effort, I can't promise that:
- The detection will be flawless (although checks exist to make sure there's exactly 1 occurrence of either the "good code snippet" or the "bad code snippet" and an inconclusive result is reported if that's not the case)
- The patch will work or even be a runnable kernel (you might need to reflash another one from download mode). I have not performed the full unpack/repack process to test it out, although it's something already done elsewhere such as the CF-Root kernels and others.
That being said, enjoy
(Reserved)
WOW, << That's one small step for man, one giant leap for "s2 community" >> !!!!!
Now this is what XDA is all about. Good stuff man, much appreciated!
sorry for my "stupid" question;
I've a linux notebook, I've connected my device with the usb cable. Now how can I send command to the device? with adb and android sdk?
Tkanks
hahaha yes man nice one... i hope that give us some nice ''stock'' roms
ps i was number 500 that hit your thanks button LOL
xky1980 said:
sorry for my "stupid" question;
I've a linux notebook, I've connected my device with the usb cable. Now how can I send command to the device? with adb and android sdk?
Tkanks
Click to expand...
Click to collapse
If you read the requirements section, you'll see it's not likely that it runs successfully on the device itself, due to BusyBox limitations.
Just place the zImage file somewhere on your notebook, along with the script, and run it from a terminal.
Tungstwenty said:
If you read the requirements section, you'll see it's not likely that it runs successfully on the device itself, due to BusyBox limitations.
Just place the zImage file somewhere on your notebook, along with the script, and run it from a terminal.
Click to expand...
Click to collapse
Oooohh! So the kernel must be read from the same path of the script, not from the device! OK thanks
Inviato dal mio GT-I9100 con Tapatalk 2
---------- Post added at 09:18 AM ---------- Previous post was at 09:02 AM ----------
I've executed the script with siyah 3.5.2
the result is: The kernel appears to be good (MMC_CAP_ERASE disabled)
So it means that is possible to safely make wipes and nandroid restores from recovery on my XWLPT?
Thanks
Genius!
Sent from my GT-I9100 using Tapatalk 2
great work
Amazing work
Sent from my GT-I9100 using xda premium
Did someone test it on S2 with CWM ?
Great work dude!!
Keep it up
00raq00 said:
Did someone test it on S2 with CWM ?
Click to expand...
Click to collapse
What do you mean?
If you're talking about the detection, there's no such kernel as "CWM"
What exists is:
1. stock kernels, with stock recovery (faulty for all 4.0.4 builds so far)
2. CF-Root, which is just the stock kernel code but with stock recovery replaced by CWM, root included, etc. (but it's still the original kernel code and it still has he bug)
3. custom kernels built by kernel developers from source, which unless they forgot to do so, has the source code changed to be safe
If you're asking about item no 2, I *think* Chainfire changed the code of the CWM version he included in the package to make it safer, but the kernel is still vulnerable and flashing a .zip file in recovery (which could run some code it might include) is still potentially unsafe.
This is a great piece of work. I have attempted to build a patched kernel for XWLPT but I'm a bit of a noob at hacking zImage.
I set up the repack-zImage.v6 scripts and unpacked the kernel. I am a bit concerned about the error however:
Code:
repack-zImage.sh -u
Separating gzipped part from trailer in 'piggy.gz+piggy_trailer'
Trying size: 4184870 6277305 5231087 4707978 4969533 5100311 5165700 5133005
5116657 5108483 5112570 5114614 5113592 5114103 5113847 5113975 5114039 5114071
5114055 5114047[COLOR="Red"]/usr/local/bin/repack-zImage.sh: line 284: [: : integer expression expected[/COLOR]
padding check (may take some time): 1
Found uncompressed ramdisk.
Detecting padding (may take some time): 1
Unpacking initramfs
4300 blocks
4300 blocks
Success.
The unpacked files and the initramfs directory are in './zImage_unpacked'.
However I persevered and found and patched the byte in "piggy" using okteta and then repacked the kernel by doing:
Code:
repack-zImage.sh -3 -p
Creating piggy.gz
Padding './zImage_packing/piggy.gz' to 5114048 bytes (+1)
Assembling zImage
Successfully created './zImage_packing/zImage'
Generated file: './zImage_packing/zImage.tar'
This checks out OK as having been patched OK.
Code:
./check-kernel-MMC_CAP_ERASE.sh
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: zImage
gzip (pos = 18101)
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe
but sadly gets stuck at the boot screen
Does anyone know what I have done wrong and might be able to help? I'll share the kernel if I can get it built.
Peter
Tungstwenty said:
What do you mean?
If you're talking about the detection, there's no such kernel as "CWM"
What exists is:
1. stock kernels, with stock recovery (faulty for all 4.0.4 builds so far)
2. CF-Root, which is just the stock kernel code but with stock recovery replaced by CWM, root included, etc. (but it's still the original kernel code and it still has he bug)
3. custom kernels built by kernel developers from source, which unless they forgot to do so, has the source code changed to be safe
If you're asking about item no 2, I *think* Chainfire changed the code of the CWM version he included in the package to make it safer, but the kernel is still vulnerable and flashing a .zip file in recovery (which could run some code it might include) is still potentially unsafe.
Click to expand...
Click to collapse
If we can detect brick bug in kernel and know what must be changed so why we can't fix stock kernel? If we can fix stock kernel my question is did someone do that and test it with fake cwm and wipe?
Sent from my GT-I9100 using Tapatalk 2
whiskerp said:
This is a great piece of work. I have attempted to build a patched kernel for XWLPT but I'm a bit of a noob at hacking zImage.
I set up the repack-zImage.v6 scripts and unpacked the kernel. I am a bit concerned about the error however:
Code:
repack-zImage.sh -u
Separating gzipped part from trailer in 'piggy.gz+piggy_trailer'
Trying size: 4184870 6277305 5231087 4707978 4969533 5100311 5165700 5133005
5116657 5108483 5112570 5114614 5113592 5114103 5113847 5113975 5114039 5114071
5114055 5114047[COLOR="Red"]/usr/local/bin/repack-zImage.sh: line 284: [: : integer expression expected[/COLOR]
padding check (may take some time): 1
Found uncompressed ramdisk.
Detecting padding (may take some time): 1
Unpacking initramfs
4300 blocks
4300 blocks
Success.
The unpacked files and the initramfs directory are in './zImage_unpacked'.
However I persevered and found and patched the byte in "piggy" using okteta and then repacked the kernel by doing:
Code:
repack-zImage.sh -3 -p
Creating piggy.gz
Padding './zImage_packing/piggy.gz' to 5114048 bytes (+1)
Assembling zImage
Successfully created './zImage_packing/zImage'
Generated file: './zImage_packing/zImage.tar'
This checks out OK as having been patched OK.
Code:
./check-kernel-MMC_CAP_ERASE.sh
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: zImage
gzip (pos = 18101)
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe
but sadly gets stuck at the boot screen
Does anyone know what I have done wrong and might be able to help? I'll share the kernel if I can get it built.
Peter
Click to expand...
Click to collapse
Did you use this script here http://forum.xda-developers.com/showthread.php?t=901152 ? I used that one and asked tungstwenty for help. He discovered, that that one was faulty. I have my own kernel build now but still couldn't test it.
Safe version of XWLPT stock.
whiskerp said:
This is a great piece of work. I have attempted to build a patched kernel for XWLPT but I'm a bit of a noob at hacking zImage.
I set up the repack-zImage.v6 scripts and unpacked the kernel. I am a bit concerned about the error however:
Edit: Variable was assigned to nul rather than zero and was not a real problem.
Code:
repack-zImage.sh -u....
However I persevered and found and patched the byte in "piggy" using okteta and then repacked the kernel by doing:
Code:
repack-zImage.sh -3 -p
...[CODE]./check-kernel-MMC_CAP_ERASE.sh
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: zImage
gzip (pos = 18101)
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe
Click to expand...
Click to collapse
I have now rebuilt this and it works! and it is available at the Dropbox link below.
http://dl.dropbox.com/u/46833344/Kernel_XWLPT_eMMC_safe.tar
Does someone else want to check this out? I re-did the build above after fixing two unassigned variables in repack-zImage (fixed build files below)
http://dl.dropbox.com/u/46833344/repack-zImage.v6-fixed-scripts.tar.gz
whiskerp said:
I have now rebuilt this and it works! and it is available at the Dropbox link below.
http://dl.dropbox.com/u/46833344/Kernel_XWLPT_eMMC_safe.tar
Does someone else want to check this out? I re-did the build above after fixing two unassigned variables in repack-zImage (fixed build files below)
http://dl.dropbox.com/u/46833344/repack-zImage.v6-fixed-scripts.tar.gz
Click to expand...
Click to collapse
Did you already test CWM Wipe?
whiskerp said:
This is a great piece of work. I have attempted to build a patched kernel for XWLPT but I'm a bit of a noob at hacking zImage.
I set up the repack-zImage.v6 scripts and unpacked the kernel. I am a bit concerned about the error however:
...
Click to expand...
Click to collapse
darth_mickrig said:
Did you use this script here http://forum.xda-developers.com/showthread.php?t=901152 ? I used that one and asked tungstwenty for help. He discovered, that that one was faulty. I have my own kernel build now but still couldn't test it.
Click to expand...
Click to collapse
whiskerp said:
I have now rebuilt this and it works!
Click to expand...
Click to collapse
After having the detection, I was also trying to get it to work using exactly that same repacker script, which darth_mickrig tipped me about.
I also found it has some errors, not only in the line you mentioned but also in the packing when using "-3" so that piggy can be edited directly rather that its inner blocks in separate files (which would require subtracting something from the offset displayed by my script).
wiskerp, I'm glad you had it sorted out already. I didn't have a chance to properly testing my patched+repacked zImage from one of the 4.0.4 versions (was planning on testing it despite the fact that I'm running a 4.0.3 ROM) so your feedback is great.
The repack-zImage.v6 script appears to no longer be maintained and its author doesn't post on XDA for a while now, but I'll try to see if I can reach him to know whether he's ok with updating that script for newer kernels in addition to fixing the existing bugs. It might work properly in other shells / bash versions, who knows...
In the meantime, I was also asked by a couple of N7000 guys to make the detection work for their kernels, which apart from the "really stock" ones have a different compression - lzma/xz instead of gzip on the outer layer. On the inner parts (initramfs) it's also not working correctly, so I'll need to check it out. CF-Root, for instance, uses a different compression than the base stock, probably so that the additional payload fits the partition size.
Oh, one note:
Keep in mind that despite being a patch on the stock kernel, the yellow triangle will appear and the counter will be incremented if you flash the patched version through Odin. It's no longer properly signed by Samsung.
Kudos to wiskerp for beating me to share a patched version :highfive:. I had already done the repackaging and was waiting to get home to flash and try it out to see if it would boot before posting it
Hi,
I would like to add some usb devices drivers like usb serial etc
I already rooted my kyobo, with the boot.img I found on this forum
I pulled the /boot/config.gz to build my own kernel
I load the config with make menuconfig save it but after the config is very deifferent from the one I pulled
I build the msn kernel 2.6.35 downloaded from google with that config, but my zImage seems to be small against the boot.img/zImage currently installed
[email protected]****u:~/kyobo/msm$ ls -l arch/arm/boot/zImage
-rwxrwxr-x 1 jpdumont jpdumont 3103940 Dec 26 15:15 arch/arm/boot/zImage (the zImage generated with my kernel build)
[email protected]****u:~/kyobo/msm$ ls -l ../boot/zImage
-rw-rw-r-- 1 jpdumont jpdumont 3661940 Dec 26 15:04 ../boot/zImage (the zImage extracted from boot.img currently installed on my rooted device)
So i'm affraid to install my own boot.img
Is there any method to test a kernel without risk on the device itself ???
Thanks in advance
JP
Hi JP,
How is this project with the Kyobo progressing?
I've recently picked one up myself and am trying to achieve the same thing, except for sailing rather than soaring. I've overcome the first hurdle in a different manner, I've used the TetherGPS app to wifi in my gps location in from an android phone. I took a bit of fiddling as the "ACCESS MOCK LOCATION" is not available in the development menu of Kyobo. Instead I've edited the settings.db and changed a 0 to 1 next to MOCK LOCATION to get it working.
I'd still like to get other NMEA data in from various instruments in the future and will possibly continue down the wifi route rather that the usb option you are attempting.
regards Simo
Hello,
is there any working linux script for extracting v30 kdz firmware and dz files?
Big thanks for help
H930g - lgv30 - kdz extract - linux
djsven said:
Hello,
is there any working linux script for extracting v30 kdz firmware and dz files?
Big thanks for help
Click to expand...
Click to collapse
Yes sir , I have found one
https://github.com/ehem/kdztools
Here are the output from my first test:
[email protected]:~/Android/kdztools-master$ ./unkdz -f H93011m_00_OPEN_EU_OP_1229.kdz -l
[!] Warning: Data between headers and payload! (offsets 826 to 83768)
[+] KDZ Partition List (format v2)
=========================================
0 : H93011m_00.dz (3563995785 bytes)
1 : LGUP_c.dll (3079120 bytes)
2 : LGUP_c.dylib (1229456 bytes)
[email protected]:~/Android/kdztools-master$ ./unkdz -f H93011m_00_OPEN_EU_OP_1229.kdz -x
[!] Warning: Data between headers and payload! (offsets 826 to 83768)
[+] Extracting all partitions from v2 file!
[+] Extracting H93011m_00.dz to kdzextracted/H93011m_00.dz
[+] Extracting LGUP_c.dll to kdzextracted/LGUP_c.dll
[+] Extracting LGUP_c.dylib to kdzextracted/LGUP_c.dylib
[+] Extracting extra data to kdzextracted/kdz_extras.bin
So far this is the only steps I have tried, I will give a later try to extract the whole DZ file
For your information I m running Ubuntu 16.04 LTS
I wish you good luck
Edit : Unfortunately I got this error when I try to list the DZ file
[email protected]:~/Android/kdztools-master$ ./undz -f H93011m_00.dz -l
[!] Error: Value supposed to be zero in field "reserved5" is non-zero (0x5900)
Sorry For this deception, maybe you know what this error is meaning ?
The format changed slightly, but the extraction still works. I didn't feel like figuring out what the data in the reserved field is for, so just comment out the two sys.exit(1).
You can use this patch...
Code:
diff --git a/undz.py b/undz.py
index 1078248..aa386a0 100755
--- a/undz.py
+++ b/undz.py
@@ -74,7 +74,7 @@ class UNDZUtils(object):
dz_item[key] = dz_item[key].rstrip(b'\x00')
if b'\x00' in dz_item[key]:
print("[!] Error: extraneous data found IN "+key, file=sys.stderr)
- sys.exit(1)
+ #sys.exit(1)
elif type(dz_item[key]) is int:
if dz_item[key] != 0:
print('[!] Error: Value supposed to be zero in field "'+key+'" is non-zero ('+hex(dz_item[key])+')', file=sys.stderr)
@@ -86,7 +86,7 @@ class UNDZUtils(object):
# To my knowledge this is supposed to be blank (for now...)
if len(dz_item['pad']) != 0:
print("[!] Error: pad is not empty", file=sys.stderr)
- sys.exit(1)
+ #sys.exit(1)
return dz_item
@@ -195,7 +195,7 @@ class UNDZChunk(dz.DZChunk, UNDZUtils):
zdata = self.dz.dzfile.read(self.dataSize)
# Decompress the data
- buf = zlib.decompress(zdata)
+ buf = zlib.decompress(zdata)
crc = crc32(buf) & 0xFFFFFFFF
-- Brian
runningnak3d said:
The format changed slightly, but the extraction still works. I didn't feel like figuring out what the data in the reserved field is for, so just comment out the two sys.exit(1).
You can use this patch...
Code:
diff --git a/undz.py b/undz.py
index 1078248..aa386a0 100755
--- a/undz.py
+++ b/undz.py
@@ -74,7 +74,7 @@ class UNDZUtils(object):
dz_item[key] = dz_item[key].rstrip(b'\x00')
if b'\x00' in dz_item[key]:
print("[!] Error: extraneous data found IN "+key, file=sys.stderr)
- sys.exit(1)
+ #sys.exit(1)
elif type(dz_item[key]) is int:
if dz_item[key] != 0:
print('[!] Error: Value supposed to be zero in field "'+key+'" is non-zero ('+hex(dz_item[key])+')', file=sys.stderr)
@@ -86,7 +86,7 @@ class UNDZUtils(object):
# To my knowledge this is supposed to be blank (for now...)
if len(dz_item['pad']) != 0:
print("[!] Error: pad is not empty", file=sys.stderr)
- sys.exit(1)
+ #sys.exit(1)
return dz_item
@@ -195,7 +195,7 @@ class UNDZChunk(dz.DZChunk, UNDZUtils):
zdata = self.dz.dzfile.read(self.dataSize)
# Decompress the data
- buf = zlib.decompress(zdata)
+ buf = zlib.decompress(zdata)
crc = crc32(buf) & 0xFFFFFFFF
-- Brian
Click to expand...
Click to collapse
hey , this doesnt work at all, its still showing the same error as before , im trying to extract G7 ThinQ kdz
[email protected]:~/kdztools-master$ ./undz.py -x -f G71010b_00.dz
[!] Error: Value supposed to be zero in field "reserved5" is non-zero (0x5900)
[email protected]:~/kdztools-master$
Click to expand...
Click to collapse
This was a quick hack to get V30 Nougat KDZs to extract. V30 Oreo KDZs require additional work, and I haven't even looked at G7 KDZs yet.
-- Brian
Encounter the same issue, patched the sys.exit() calls and flipped this line to avoid the error with reserved5:
('reserved5', ('I', False)), # currently always zero
But still errors. Further info at: hxxxs://github.com/ehem/kdztools/issues/16#issuecomment-435356938
SALT works perfectly fine with V30 oreo kdzs, doesnt work though with G7/V40 kdzs ?
i mean... SALT actually can do way more than just extracting kdzs ... but thats the only use i have for it atm
SGCMarkus said:
SALT works perfectly fine with V30 oreo kdzs, doesnt work though with G7/V40 kdzs ?
i mean... SALT actually can do way more than just extracting kdzs ... but thats the only use i have for it atm
Click to expand...
Click to collapse
Managed to unpack a modem partition LG changed the compression algorithm from zlib to zstd on LG V40 kdzs
SGCMarkus said:
SALT works perfectly fine with V30 oreo kdzs, doesnt work though with G7/V40 kdzs ?
i mean... SALT actually can do way more than just extracting kdzs ... but thats the only use i have for it atm
Click to expand...
Click to collapse
Thank you very much for posting this.
It turns out I had a corrupt download of the H932 20o KDZ and no -- LG hasn't made any additional changes to the KDZ format.
When I saw that SALT was working for you, then I knew my extractor should work as well and that lead me to start looking elsewhere.
-- Brian
BINGO! LGV40 unpacked!
Code:
[20:10 [email protected] dzextracted] > sudo mount -t ext4 vendor_a.image /media/edu/ext4_tmp
[sudo] password for edu:
[20:10 [email protected] dzextracted] > cd /media/edu/ext4_tmp
[20:10 [email protected] ext4_tmp] > ll
total 220K
drwxr-xr-x. 10 root 2000 4.0K Dec 31 2008 app
drwxr-xr-x. 6 root 2000 8.0K Dec 31 2008 bin
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 carrier
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 dsp
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 els
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 eri
drwxr-xr-x. 23 root 2000 4.0K Dec 31 2008 etc
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 ffu
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 firmware
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 fota
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 framework
drwxr-xr-x. 11 root 2000 16K Dec 31 2008 lib
drwxr-xr-x. 9 root 2000 16K Dec 31 2008 lib64
drwx------. 2 root root 16K Dec 31 2008 lost+found
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 media
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 mpt
drwxr-xr-x. 83 root 2000 4.0K Dec 31 2008 overlay
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 package
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 persdata
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 persist-lg
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 power
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 priv-app
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 radio
drwxr-xr-x. 5 root 2000 4.0K Dec 31 2008 rfs
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 sns
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 srtc
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 vzw
-rw-------. 1 root root 8.8K Dec 31 2008 build.prop
-rw-r--r--. 1 root root 1.9K Dec 31 2008 compatibility_matrix.xml
-rw-------. 1 root root 684 Dec 31 2008 default.prop
lrw-r--r--. 1 root root 12 Dec 31 2008 factory_data -> /system/data
lrw-r--r--. 1 root root 19 Dec 31 2008 factory_etc -> /system/factory_etc
lrw-r--r--. 1 root root 19 Dec 31 2008 factory_lib -> /system/factory_lib
lrw-r--r--. 1 root root 21 Dec 31 2008 factory_lib64 -> /system/factory_lib64
-rw-r--r--. 1 root root 36K Dec 31 2008 manifest.xml
-rw-r--r--. 1 root root 16K Dec 31 2008 ueventd.rc
runningnak3d said:
Thank you very much for posting this.
It turns out I had a corrupt download of the H932 20o KDZ and no -- LG hasn't made any additional changes to the KDZ format.
When I saw that SALT was working for you, then I knew my extractor should work as well and that lead me to start looking elsewhere.
-- Brian
Click to expand...
Click to collapse
I PM you with the URL. I guess you don't need it but figured you would want an official link from LG Bridge.
Sent from my LG-H932 using XDA Labs
eduuk said:
Managed to unpack a modem partition LG changed the compression algorithm from zlib to zstd on LG V40 kdzs
Click to expand...
Click to collapse
Hello eduuk,
What did you do to get V40 to unpack? I have a feeling it could work for the LG G7. Thanks for any help.
Dvalin21 said:
Hello eduuk,
What did you do to get V40 to unpack? I have a feeling it could work for the LG G7. Thanks for any help.
Click to expand...
Click to collapse
I am also unable to get a useful unpack of a G7 or V40 KDZ.
@eduuk You don't even need to share your code, but if you could just point out the differences between the V30 and V40 KDZ format it would be appreciated.
-- Brian
@eduuk i got passed the reserved5 but now i get this error: [!] Error: extraneous data found IN pad
Also, if you can provide help with changing the compression algorithm from zlib to zstd i would appreciate it.
Dvalin21 said:
@eduuk i got passed the reserved5 but now i get this error: [!] Error: extraneous data found IN pad
Also, if you can provide help with changing the compression algorithm from zlib to zstd i would appreciate it.
Click to expand...
Click to collapse
I hate doing work that someone else has already done -- it is just a waste of time, but since it seems that he isn't willing to share the changes, I am spending the day mapping out the structure of the G7 / V40 KDZ format, and updating the extractor so that it can deal with the new version.
As soon as I have it functional, I will post a link to the repo.
-- Brian
runningnak3d said:
I hate doing work that someone else has already done -- it is just a waste of time, but since it seems that he isn't willing to share the changes, I am spending the day mapping out the structure of the G7 / V40 KDZ format, and updating the extractor so that it can deal with the new version.
As soon as I have it functional, I will post a link to the repo.
-- Brian
Click to expand...
Click to collapse
You rock sir, thank you
Dvalin21 said:
You rock sir, thank you
Click to expand...
Click to collapse
Well, that was more of a pain in the butt than it needed to be, but repo is incoming once I clean up some of my debug code:
Code:
[swango:~/dev/kdztools/kdzextracted] master(+11/-8)* ± ../undz2.py -f G71010f_00.dz -l
[+] DZ Partition List
=========================================
0/ 0 : PrimaryGPT_0.bin (1363 bytes)
0/ 1 : PrimaryGPT_0.bin (277 bytes)
0/ 2 : PrimaryGPT_0.bin (277 bytes)
0/ 3 : PrimaryGPT_0.bin (335 bytes)
0/ 4 : PrimaryGPT_0.bin (2355 bytes)
0/ 5 : PrimaryGPT_0.bin (404 bytes)
0/ 6 : PrimaryGPT_0.bin (213 bytes)
1/?? : mpt (<empty>)
2/?? : drm (<empty>)
3/?? : sns (<empty>)
4/?? : ssd (<empty>)
5/ 7 : persist_13446.bin (743 bytes)
6/?? : misc (<empty>)
7/ 8 : ftm_21894.bin (75 bytes)
8/?? : power (<empty>)
9/?? : encrypt (<empty>)
10/?? : eksst (<empty>)
11/?? : rct (<empty>)
12/?? : fota (<empty>)
13/?? : srtc (<empty>)
14/?? : pstore (<empty>)
15/?? : els (<empty>)
16/?? : carrier (<empty>)
17/?? : persdata (<empty>)
18/ 9 : oem_a_77574.bin (738 bytes)
<snip>
and
Code:
θ78° [swango:~/dev/kdztools/kdzextracted] master(+11/-8)* 3s ± ../undz2.py -f G71010f_00.dz -s 20
[+] Extracting single slice^Wpartition!
[+] Extracting vendor_a_81670.bin to vendor_a.image
[+] Extracting vendor_a_114503.bin to vendor_a.image
[+] Extracting vendor_a_147206.bin to vendor_a.image
[+] Extracting vendor_a_147701.bin to vendor_a.image
<snip>
[swango:~/dev/kdztools/kdzextracted] master(+11/-8)* 130 ± cd dzextracted/
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± mkdir mnt
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± sudo mount vendor_a.image ./mnt
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± cd mnt
[swango:~/dev … kdzextracted/dzextracted/mnt] $ ls -al
total 208
drwxr-xr-x 27 root root 4096 Dec 31 1969 .
drwxr-xr-x 3 swango swango 4096 Dec 15 10:29 ..
drwxr-xr-x 8 root 2000 4096 Dec 31 2008 app
drwxr-xr-x 6 root 2000 8192 Dec 31 2008 bin
-rw------- 1 root root 8664 Dec 31 2008 build.prop
drwxr-xr-x 2 root 2000 4096 Dec 31 2008 carrier
<snip>
The quick and dirty is that the header changed -- which is why there was data in the pad (that is the zero padding at the end of the header to make it 512 bytes) -- so I defined those, and they also changed the compression from zlib to zstandard (you need version 0.9 or greater) NOT zstd.
Lastly, when the compress, they don't include the size in the zstandard header, so I just picked a value that was big enough to decompress the largest partition.
Again, I have a lot of cleanup to do, and then I will commit this. Eventually I will make it so you can pass something like --zlib or --zst so that one file can be used to extract both old and new format KDZs, but for now there is undz2.py
-- Brian
OK - thread and link are here.
Please let me know if you come across any KDZs that you can't extract, but please post the errors in that thread.
-- Brian
Dvalin21 said:
Hello eduuk,
What did you do to get V40 to unpack? I have a feeling it could work for the LG G7. Thanks for any help.
Click to expand...
Click to collapse
runningnak3d said:
OK - thread and link are here.
Please let me know if you come across any KDZs that you can't extract, but please post the errors in that thread.
-- Brian
Click to expand...
Click to collapse
hey guys,
sorry but I didnt get the time to answer you. Took me an entire day to patch the python code. It's so so ugly code, so I would prefer not share it if anyone can code it better than me
There was a guy who was sending me private messages to do the same as me, and he got it too. The only thing to do is to change the algorithm and patch out asserts and other checks.
Please let me know if you can do it without my ugly code. Otherwise, I will share it of course.
---------- Post added at 12:54 AM ---------- Previous post was at 12:51 AM ----------
runningnak3d said:
Well, that was more of a pain in the butt than it needed to be, but repo is incoming once I clean up some of my debug code:
Code:
[swango:~/dev/kdztools/kdzextracted] master(+11/-8)* ± ../undz2.py -f G71010f_00.dz -l
[+] DZ Partition List
=========================================
0/ 0 : PrimaryGPT_0.bin (1363 bytes)
0/ 1 : PrimaryGPT_0.bin (277 bytes)
0/ 2 : PrimaryGPT_0.bin (277 bytes)
0/ 3 : PrimaryGPT_0.bin (335 bytes)
0/ 4 : PrimaryGPT_0.bin (2355 bytes)
0/ 5 : PrimaryGPT_0.bin (404 bytes)
0/ 6 : PrimaryGPT_0.bin (213 bytes)
1/?? : mpt (<empty>)
2/?? : drm (<empty>)
3/?? : sns (<empty>)
4/?? : ssd (<empty>)
5/ 7 : persist_13446.bin (743 bytes)
6/?? : misc (<empty>)
7/ 8 : ftm_21894.bin (75 bytes)
8/?? : power (<empty>)
9/?? : encrypt (<empty>)
10/?? : eksst (<empty>)
11/?? : rct (<empty>)
12/?? : fota (<empty>)
13/?? : srtc (<empty>)
14/?? : pstore (<empty>)
15/?? : els (<empty>)
16/?? : carrier (<empty>)
17/?? : persdata (<empty>)
18/ 9 : oem_a_77574.bin (738 bytes)
<snip>
and
Code:
θ78° [swango:~/dev/kdztools/kdzextracted] master(+11/-8)* 3s ± ../undz2.py -f G71010f_00.dz -s 20
[+] Extracting single slice^Wpartition!
[+] Extracting vendor_a_81670.bin to vendor_a.image
[+] Extracting vendor_a_114503.bin to vendor_a.image
[+] Extracting vendor_a_147206.bin to vendor_a.image
[+] Extracting vendor_a_147701.bin to vendor_a.image
<snip>
[swango:~/dev/kdztools/kdzextracted] master(+11/-8)* 130 ± cd dzextracted/
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± mkdir mnt
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± sudo mount vendor_a.image ./mnt
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± cd mnt
[swango:~/dev … kdzextracted/dzextracted/mnt] $ ls -al
total 208
drwxr-xr-x 27 root root 4096 Dec 31 1969 .
drwxr-xr-x 3 swango swango 4096 Dec 15 10:29 ..
drwxr-xr-x 8 root 2000 4096 Dec 31 2008 app
drwxr-xr-x 6 root 2000 8192 Dec 31 2008 bin
-rw------- 1 root root 8664 Dec 31 2008 build.prop
drwxr-xr-x 2 root 2000 4096 Dec 31 2008 carrier
<snip>
The quick and dirty is that the header changed -- which is why there was data in the pad (that is the zero padding at the end of the header to make it 512 bytes) -- so I defined those, and they also changed the compression from zlib to zstandard (you need version 0.9 or greater) NOT zstd.
Lastly, when the compress, they don't include the size in the zstandard header, so I just picked a value that was big enough to decompress the largest partition.
Again, I have a lot of cleanup to do, and then I will commit this. Eventually I will make it so you can pass something like --zlib or --zst so that one file can be used to extract both old and new format KDZs, but for now there is undz2.py
-- Brian
Click to expand...
Click to collapse
Yeah 0x200 bytes of header, i removed that first with dd and then I coded in python changing offsets. Sorry but I dont have the time of coding this properly.
---------- Post added at 12:59 AM ---------- Previous post was at 12:54 AM ----------
eduuk said:
hey guys,
sorry but I didnt get the time to answer you. Took me an entire day to patch the python code. It's so so ugly code, so I would prefer not share it if anyone can code it better than me
There was a guy who was sending me private messages to do the same as me, and he got it too. The only thing to do is to change the algorithm and patch out asserts and other checks.
Please let me know if you can do it without my ugly code. Otherwise, I will share it of course.
---------- Post added at 12:54 AM ---------- Previous post was at 12:51 AM ----------
Yeah 0x200 bytes of header, i removed that first with dd and then I coded in python changing offsets. Sorry but I dont have the time of coding this properly.
Click to expand...
Click to collapse
The best way is to do a pull request at the main repo https://github.com/ehem/kdztools
---------- Post added at 01:00 AM ---------- Previous post was at 12:59 AM ----------
runningnak3d said:
I hate doing work that someone else has already done -- it is just a waste of time, but since it seems that he isn't willing to share the changes, I am spending the day mapping out the structure of the G7 / V40 KDZ format, and updating the extractor so that it can deal with the new version.
As soon as I have it functional, I will post a link to the repo.
-- Brian
Click to expand...
Click to collapse
Dude, did you read this by any chance? https://github.com/ehem/kdztools/issues
Cheers mate
Thanks for the answer @eduuk, however Brian did a kdztool working that I was able to fully extract all the image files for the G710TM10n firmware for T-Mobile. Still with that said we still appreciate all your work!