Related
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!
Very bad news.
I appear to have had an accident with /efs. Not 100% sure what I did but suspect it related to a product code change.
My SGS2 now will not show an IMEI or connect to the cell network.
I connected with /adb and saw a number of files were updated earlier today
drwxrwxr-x 5 root root 4096 Jan 1 2000 .files
drwxrwxr-x 2 radio radio 4096 Jan 1 2000 imei
-rw-rw-rw- 1 radio radio 832 Jan 1 2011 nv.log
-rw-rw-rw- 1 radio radio 1 Jan 1 2011 .nv_state
-rwx------ 1 radio radio 32 Jan 1 2011 .nv_data.bak.md5
-rwx------ 1 radio radio 2097152 Jan 1 2011 .nv_data.bak
-rwx------ 1 radio radio 32 Jan 1 2011 .nv_core.bak.md5
-rwx------ 1 radio radio 1048576 Jan 1 2011 .nv_core.bak
-rw-r--r-- 1 root root 1 Jan 1 2011 cryptprop_rebootMode
drwx------ 3 system system 4096 Jan 1 2011 dmp
-rw-r--r-- 1 system system 14 Jan 1 2011 cryptprop_persist.sys.timezone
-rw-r--r-- 1 system system 9 Jan 1 2011 cryptprop_applied_result
-rwxrwxr-- 1 radio radio 880 Jan 1 2011 redata.bin
-rw-rw-rw- 1 system system 6 Aug 12 22:43 calibration_data
-rw-rw-rw- 1 system system 256 Oct 4 15:55 edk_p
-rw-r--r-- 1 system system 3 Nov 2 01:27 cryptprop_persist.sys.language
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lockscreen.patterneverchosen
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lockscreen.password_type
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_visible_pattern
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lock_pattern_tactile_feedback_ena
bled
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_autolock
-rw-r--r-- 1 root root 3 Nov 2 21:08 cryptprop_securewipedata
-rwx------ 1 radio radio 32 Nov 3 17:44 nv_data.bin.md5
-rwx------ 1 radio radio 2097152 Nov 3 17:44 nv_data.bin
-rw-r--r-- 1 system system 0 Nov 3 18:02 cryptprop_onetimeboot
drwxrwx--x 5 radio system 4096 Nov 3 21:23 .
drwxr-xr-x 21 root root 0 Nov 3 21:58 ..
You can see the changes to nv_data.bin.md5 and nv_data.bin -- I have no idea what crptprop_onetimeboot is but it looks a little suspicious.
Firstly I have a copy of the above as
- a directory on my sdcard
- a dd'd image on my sdcard
- a file copy on my PC (!)
I also see I still have backup files, so with a lot of difficulty (fs kept going read only when trying to copy files, so I ended up renaming the old name to the new name)
ie
.nv_data.bak -> nv_data.bin
.nv_data.bak.md5 -> nv_data.bin.md5
This didn't work (still no service/no imei), so I removed(renamed) the .md5 file -- but it still doesn't work
so it now looks like
# ls -latr
ls -latr
drwxrwxr-x 5 root root 4096 Jan 1 2000 .files
drwxrwxr-x 2 radio radio 4096 Jan 1 2000 imei
-rwx------ 1 radio radio 32 Jan 1 2011 nv_data.bin.md5.orig
-rwx------ 1 radio radio 2097152 Jan 1 2011 nv_data.bin
-rw-rw-rw- 1 radio radio 832 Jan 1 2011 nv.log
-rw-rw-rw- 1 radio radio 1 Jan 1 2011 .nv_state
-rwx------ 1 radio radio 32 Jan 1 2011 .nv_core.bak.md5
-rwx------ 1 radio radio 1048576 Jan 1 2011 .nv_core.bak
-rw-r--r-- 1 root root 1 Jan 1 2011 cryptprop_rebootMode
drwx------ 3 system system 4096 Jan 1 2011 dmp
-rw-r--r-- 1 system system 14 Jan 1 2011 cryptprop_persist.sys.timezone
-rw-r--r-- 1 system system 9 Jan 1 2011 cryptprop_applied_result
-rwxrwxr-- 1 radio radio 880 Jan 1 2011 redata.bin
-rw-rw-rw- 1 system system 6 Aug 12 22:43 calibration_data
-rw-rw-rw- 1 system system 256 Oct 4 15:55 edk_p
-rw-r--r-- 1 system system 3 Nov 2 01:27 cryptprop_persist.sys.language
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lockscreen.patterneverchosen
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lockscreen.password_type
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_visible_pattern
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lock_pattern_tactile_feedback_ena
bled
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_autolock
-rw-r--r-- 1 root root 3 Nov 2 21:08 cryptprop_securewipedata
-rwx------ 1 radio radio 32 Nov 3 17:44 nv_data.bin.md5.bk
-rwx------ 1 radio radio 2097152 Nov 3 17:44 nv_data.bin.bk
-rw-rw-rw- 1 root root 0 Nov 3 20:55 p
drwxrwx--x 5 radio system 4096 Nov 3 21:48 .
-rw-r--r-- 1 system system 0 Nov 3 21:52 cryptprop_onetimeboot
drwxr-xr-x 21 root root 0 Nov 3 21:58 ..
#
[/FONT]
I DID NOT BACKUP EFS beforehand (only just learnt I need to) and know this may now be screwed, but I'm still hopeful I have the original file and just made a silly error.
I could also
- try recreating the whole fs and copying files back
- checking the prod code within the rom (but why?)
- flashing original firmware
- modifying the dd'd image *offline*, swapping the files, and dd'ing the image back
Any advice. PLEASE....
if you have a backup the easiest way I have found is to use root explorer.
go in to the /efs folder, set to read/write, mark everything and delete (not scrictly necessary simply copying over will work) but if you have been tinkering probably better.
then paste all the back up files and folders in
finally reboot (in my experience when something has gone wrong even this is not necessary)
Root explorer is worth every penny
and keep multiple backup's of your /efs on different drives
If this does not work you are screwed. The file contains your IMEI encrypted and the only way to get that restored is by returning it.
oh I just realised you are saying the back up you have is only of it in the current state?
If that's the case you are probably screwed, have you ever used any apps like nitrality or any unlocking tools? they will create copies of your efs folder on the scard in various locations. have you run a file seach on you sdcard to see if there is any copies at all?
if you have no backups of this folder then I think you will find its a return to manufacturer / sevice centre / provider issue.
I *think* I have restored the files -- and the dates look reasonable, as if they were the originals.
I've now flashed an old ROM (KE5) for good measure, but still no signal
One discrepancy I did notice is that after installing a rom there was some bootup message about csc and XEU when copying files.
My original sales code was VOD (UK vodafone). I had then run XEU firmware and just recently tried to set the sales code to XEU using a *# code. I subsequently flashed back to vodafone firmware today.
So somewhere there's a lingering reference to XEU -- this prod code incompatability could be causing the error?
I definately feel I should have the data to fix this -- after all I have the encrypted file, but am not quite sure of all the factors involved (one being "you're stuffed I know")
type *#06# this should display you IMEI number
if this does not match your IMEI from the box then you have not fixed this
if it shows all zeros or 004999010640000 then you are on a generic IMEI number
strangely when I screwed mine up and got the generic one above I was still able to use mine with a vodafone (UK) sim but not an orange on
if this is the case, and there is no efs backup prior to this you might well be screwed.
if this backup is all you have an you believe the .bak file is intact then I believe you will find solutions for deleting the primary version of the file and keeping only the backups and rebooting
the log file should give you more information on how successful this was, but if this was the result of flashing you probably overwrote both primary and backup
*#1234# is returning a reasonable CSC I9100VODKE2
Checking the nv data files, it appears
- the new ones modded today contain XEU
- the original ones contain VOD
This is consistent with what happened, so I am still confused why the renamed original files do not work, and why there's a reference to multi-csc XEU during bootup.
Some remnant of XEU?
*#06# is currently showing blank -- but those .bak files looked fine.
Annoyed and frustrated...
In that case I would try deleting nv_data.bin and nv_data.m5 and rebooting
(assuming you have copies of everything
with just nv_data.bak nv_data.bak.md5
At least with the SGS1 this would work provided those bak files are the originals but the nv.log file will tell you more after the boot.
HOWEVER the SGSII has a lot more in this folder and I do not claim to fully understand them all but if you have a back up it's worth a shot
planetf1 said:
*#1234# is returning a reasonable CSC I9100VODKE2
Checking the nv data files, it appears
- the new ones modded today contain XEU
- the original ones contain VOD
This is consistent with what happened, so I am still confused why the renamed original files do not work, and why there's a reference to multi-csc XEU during bootup.
Some remnant of XEU?
Click to expand...
Click to collapse
Took some inspiration from http://www.communityhosting.net/sgsunlock/i9000.html and decided to check permissions & recreation of md5.
md5 wasn't recreated, so no matter, I had a backup. that is restored, but I don't know if the .bak files are needed. Yet trying to create them I get:
# mv nv_data.bin.md5.orig nv_data.bin.md5
mv nv_data.bin.md5.orig nv_data.bin.md5
# cp nv_data.bin .nv_data.bak
cp nv_data.bin .nv_data.bak
cp: write error: Read-only file system
#
This isn't a space issue.
There could be another cause -- /efs/imei/mps_info.dat contains the 3 characters "XEU" even though the file is dated Jan 2011
So either
- the date has been manually fudged
OR
- the code always was XEU -- unlikely.
I'm currently working on the basis that fundamentally the IMEI is intact, that the original nv_data.bin is intact & that the phone is validating the CSC in mps_info.dat (XEU) against nv_data.bin (VOD) and failing.
Though this wouldn't explain why before the fix, with XEU in the nv_data.bin, it wasn't working
Unless the issue is the filesystem itself. could it be corrupt? Is this in fact why it switched to R/O mode each time? I've tried multiple kernels including insecure. surely they wouldn't all "protect" this fs.
But if this is the case where is fsck? maybe I need to copy the fs image to another linux box with ext4 & inspect/correct before shipping back and dd'ing
Continuing.
Found /system/bin/e2fsck -- ran this against /efs with
# /system/bin/e2fsck /dev/block/mmcblk0p1
/system/bin/e2fsck /dev/block/mmcblk0p1
e2fsck 1.41.11 (14-Mar-2010)
ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determini
ng whether /dev/block/mmcblk0p1 is mounted.
/dev/block/mmcblk0p1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found. Create<y>? y
yes
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(3202--3203) +4104
Fix<y>? yes
/dev/block/mmcblk0p1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p1: 60/1280 files (1.7% non-contiguous), 2188/5120 blocks
**** >>> I NOW HAVE AN IMEI <<< ****
AND SIGNAL
LOGGED ONTO VODAFONE
WOOOHAY.
THIS HAS BEEN FUN. LOOK AND LEARN..
and seriously thanks to all the other articles and some moral support here tonight.
Going to put back proper firmware , remove dodgy kernels and GET A BIG BEER OR THREE
planetf1 said:
Continuing.
Going to put back proper firmware , remove dodgy kernels and GET A BIG BEER OR THREE
Click to expand...
Click to collapse
and make several backups of the /efs folder in its current state one would assume
Phone seems working. restoring over a HSPA connection happily, recognized voda sim.
now reinstalling titanium backup and copying down from dropbox...
The final step was restoring from titanium backup.
I had erased my sdcard -- though my backup was on dropbox.
However titanium backup is awful at copying files to/from dropbox -- as is IMO the phone when in "phone/kies" mode.
Finally I simply copied the dropbox directory back in USB debug=mass storage mode which was quick and reliable -- and then restored most items en-masse (I have a pro license).
For the record so far phone is fine - and indeed I've since run a new efs backup
The key takeaways from this are
* Backup efs and save it somewhere offline
* get titanium backup pro. it's good (better if it backed up efs too!)
* usb mass storage mode is the most reliable way for file xfer
* backup efs (again)
* don't get complacent
And of course if you do get a similar problem to mine
a) take a backup of efs with dd if=/dev/mmcXXX of=/mnt/scard/myefs.img (check name - I forget)
b) copy files you can to sdcard
c) copy both of this to a seperate pc
d) Just try running fsck (as above) - If I'd done this sooner I'd have saved hours. I should have gone with the obvious -- I've seen this on enough linux systems in the past to know what was happening but was thrown by no kernel messages.
Thanks for letting us know, might be a nice reference for future problems, especially the filesystem check.
Writing about it also helped keep me sane.giving up and hitting the beer was becoming increasingly attractive.
I do think making the warning about efs clearer would help.backup really should be a must at the earliest opportunity
Sent from my GT-I9100 using Tapatalk
Another thought.do unmount /efs before fsck
Sent from my GT-I9100 using Tapatalk
Unable to restore
I know I had a valid IMEI during the last week or so.
I have flashed several ROM's during the last month.
Last night lost IMEI
Now , no matter what I try, I can't seem to restore my IMEI. I have the fake one that ends in a bunch of zero''s
My SDCARD has a folder called EFS_BACKUP with multiple efs_xxxxxxx.tar.gz files in it. If I extract any of these and try to restore them to the /EFS folder I still have the fake IMEI number.
Please help - I didn't understand all the adb code in this post
Hi there,
/efs is fairly new to me too, to be honest it took hours of careful rooting before I gained some useful knowledge in how that area works.
-- what I would suggest before *anything else* is to copy anything you do have left in /efs. You will need to be root to do this. I found the gui root explorer type tools a bit clunky so I used the android SDK (adb is one of the tools in this package) to help. IF YOU NEED HELP WITH THIS SAY. You need to copy the files to multiple places for safety. Someone OFF your phone, ie on a PC. This is just in case things get worse. Do the same with any of those .gz backups you have. Maybe you'll need them *if* you make things worse...
If you're familiar with linux/unix systems this is all fairly easy, but if you're not it can be quite scary. For example you have to be able to write to /efs as well as list files and move them around. One wrong step and you could make things worse.
If you're unsure perhaps you could find a friend who knows *nix well to help you out. The bottom line is that you need to
a) ensure the right files are in there
b) The filesystem itself was intact
I definately suffered from b -- less sure about a.
What you need to do will depend a fair bit on what files you find in there, and what dates they are.
You said you had some backup files. Are you sure you have some from before the problem started? Can you look inside those backup files (I think winzip or similar will expand them for you). WIthout divoluging the actual contents (since you don't want to share your IMEI with anyone), is there an nv_data.bin file in there? Out of all the files it seems to be the most critical. When's it dated (mine was Jan 2011). If you cant' find that file how about .nv_data.bak - is that a good size, and again an old one.
If you have either of these -- even without anything else I think you can probably recover.
If you can get up and running with adb, a good start would be
adb shell
ls -laR /efs
Thank you very much, fsck method fixed my efs. Phone just broke it while doing nothing :/
I love you
You just saved my Galaxy S2
Yay. Brilliant news
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
Hello, i have some scripts on shell level like logging battery stats and PPTP VPN, but since the system is very aggressive on sleep mode, my scripts often stops.
This is example from battery logging, which should log every 10 minutes:
65;3863;310;Discharging;02. 02. 2014 00:05:39
61;3889;300;Discharging;02. 02. 2014 00:39:40
61;3828;300;Discharging;02. 02. 2014 01:25:39
57;3843;300;Discharging;02. 02. 2014 02:20:26
56;3815;300;Discharging;02. 02. 2014 02:38:16
55;3814;300;Discharging;02. 02. 2014 03:24:49
52;3795;310;Discharging;02. 02. 2014 03:42:24
49;3827;300;Discharging;02. 02. 2014 05:21:06
49;3781;310;Discharging;02. 02. 2014 05:38:35
48;3775;310;Discharging;02. 02. 2014 06:25:47
44;3749;310;Discharging;02. 02. 2014 06:43:36
40;3765;300;Discharging;02. 02. 2014 08:47:48
40;3741;300;Discharging;02. 02. 2014 09:05:26
35;3752;300;Discharging;02. 02. 2014 10:55:18
46;3843;300;Charging;02. 02. 2014 11:08:15
50;3841;300;Charging;02. 02. 2014 11:18:14
53;3830;300;Charging;02. 02. 2014 11:28:13
It is infinite loop with 599s sleep command.
I could write a user lock to wake_lock, but that would keep the system awake all the time.
Is there any way how to control this, either disable some power management to keep processing the shell scripts or making an interrupt or something?
I think i cannot do this from the script, because when the system sleeps, the script seems to be suspended too.
The device is Xperia X10 mini with CM10 ROM, 4.1.2.
Thanks.
Hi guys, im doing a project which requires the tablet to auto start when power is available through USB.
im using a datawind tablet d705 model with a mediatek cpu and kitkat version 4.4.2.
Here is a info dump from MTKtools:
Hardware : MT8312D
Model : D705
Build number : ALPS.KK1.MP7.V1.25
Build date UTC : 20150727-023443
Android v : 4.4.2
Baseband v: MOLY.WR8.W1315.MD.WG.MP.V64, 2014/08/02 09:47
Kernel v : 3.4.67 ([email protected]) (gcc version 4.7 (GCC) ) #1 SMP Mon Jul 27 10:31:34 CST 2015
Uboot build v : -----
LCD Driver IC : 1-rgb_mt6571_wvga
i have attached files that will help with figuring out the file that is loaded to show charging animation.
i have also tried most of the available methods on various forums to try to boot the tablet but failed.
fastboot oem off-mode charge 0 does not work
1. search in /system/bin/ for playlpm, ipod, lpm, kpoc_charger or any other file that have inside some reference to battery animation.
2. edit that file, delete all content inside and add
#!/system/bin/sh
/system/bin/reboot
i have a ipod file but it is not used for animation, deleteting the file from boot.img makes no difference at all.
1. Unpack boot.img and edit init.rc.
2. Add following to the end of file:
#Check if chargermode and start autoreboot service.
on property:ro.bootmode=charger
start autoreboot
#autoreboott service which command reboot
service autoreboot /su/bin/su /system/bin/reboot -c reboot now
user root
oneshot
none of the above worked. i also tried various methods to edit init.rc and init.charger.rc but nothing worked.
could some one please help me with this. im ready to donate for your kind help