http://gititbit.ch/sk4gm - sk4g_modules.zip
tun.ko
ext4.ko
ext3.ko
compiled with the sk4g kernel source (obviously)
sidekick4g mirrors can be found at
http://gitbrew.org/sidekick/
Place in /system/lib/modules/
insmod tun.ko ext3.ko ext4.ko
Please let me know if they work.
The only reason I can foresee them not working is if the production kernel version differs from the released source.
So I know im a "noob" but what does this do?
tun.ko enables the use of openvpn, ext3 and ext4 are file system types.
dasmoover said:
tun.ko enables the use of openvpn, ext3 and ext4 are file system types.
Click to expand...
Click to collapse
Would This Mean we could Convert from the default file system type (Rfs i think) to ext4 ? and does this mean the SK4G can have Voodoo lagfix which converts the system file type to ext4 i believe ?
sorry for all the questions im just a lol confused atm
These are kernel modules, they provide added functionality after boot to the stock kernel without having to recompile on the end-user level. Tun.ko lets you connect your phone to a OpenVPN network. Ext3 and Ext4 are file-system types. This would allow you to mount partitions/images with that file-system. I'm not sure if it would be applicable to /system, which is VFAT.
thanks for these. i am trying to figure out where to place them. looking at my system, i don't see a module folder in system/lib. what i have is a couple folders at the top, as shown, and all the rest are libxxxxxxxxx.so files.
Edit: i do see an option to create a new folder. perhaps that's what i need to do?
Don't create any folder, place all the .ko files in that directory you took a screenshot of then do insmod tun.ko as root. You must first mount your /system partition as rw.
Yogi, if you could, please join #sidekick4g on freenode. I am trying to compile AOSP GB for this device but I need to pull proprietary files first.
dasmoover said:
don't create any folder, place all the .ko files in that directory you took a screenshot of then do insmod tun.ko as root. You must first mount your /system partition as rw.
Click to expand...
Click to collapse
ok thanks, will do. is there any risk with this? it seems the Clockwork recovery is having a problem mounting the sd card in some cases, thus i was unable to save my nandroid backup.
Has anyone tested these on hardware yet?
yes, they work.
dasmoover said:
yes, they work.
Click to expand...
Click to collapse
Thanks! Can you build us cifs also? I can't seem to do it myself...
Sent from a toaster.
It's almost working for me (using 'openvpn settings' as a GUI) -- the sequence of messages appearing in the window with my selected configuration are:
Connecting
Auth
Get config
Connected to 173.163.240.62 as
(notes -- I could easily have made some mistakes with capitalization; the last line really does end with the word 'as')
I can't make any connections, and no new routes seem to be getting added to the routing tables.
Meanwhile, on my VPN server, the last two messages in the log are:
Jul 5 16:44:16 pinky ovpn-server[1728]: horizon/206.29.182.131:14412 SENT CONTROL [horizon]: 'PUSH_REPLY,route 10.13.13.0 255.25\
5.255.0,route 192.168.13.0 255.255.255.0,route 10.13.13.1,topology net30,ping 10,ping-restart 120,ifconfig 10.13.13.38 10.13.13.3\
7' (status=1)
Jul 5 16:47:08 pinky ovpn-server[1728]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
It should be mentioned that I'm not trying to connect from the server to my sidekick, so I don't know why that message is occurring (it is almost three minutes after the configuration information was sent).
Any ideas? I'll happily post more of the log if it's appropriate, or I can put it up on my web page.
Found it! The openvpn binary installed by the openvpn-installer package doesn't seem to understand the route pushed by the openvpn host. As a new user I can't post a link, but googling 'android openvpn route issue 26' will turn up a discussion of the problem and a link to an openvpn binary that works (as of tonight, as the first hit).
Related
WARNING: Not responsible for any damage caused by experimenting with the information in this thread
I didn't see this information previously posted anywhere on here. Hope I don't get flamed!
Thanks to ZanzDroid!
My goal is to publish as much information as we're able to discover about the Unrevoked Root Apk which only contains one button and explains very very little while quite a bit happens behind the scene.
The Unrevoked creators, claim they don't want to explain how everything works because people will abuse the root exploit method they found.
I'd rather trust the EVO community to be open but responsible.
I've only figured out a few things and hope this thread will get the ball rolling. I'm hoping with some of the great developers here we can find out more!
Had some free time tonight.
Brief Technical ANALYSIS:
Stock EVO with the OTA update for .6 software and .05 radio
Installed the apk thru the browser, http://www.unrevoked.com/m.
After installing the app and clicking the Start button, 5-6 seconds later it reports, Rooted!
It appears the payload is dumped to /data/DxDrm .
Inside this directory there are three files
ls -l /data/DxDrm
-rwxrwxrwx app_84 app_84 439428 2010-06-09 18:37 unrevoked
-rwxrwxrwx app_84 app_84 177 2010-06-09 18:38 unrevoked.log
drwxr-xr-x root root 1980-01-08 23:35 fuse
unrevoked - looks like the actual rooting application (payload) compiled into a binary so its not text readable. there is where the secret magic happens. name is an active link to the actual binary the .apk installs. it would great if somebody could decompile this or reverse engineer it.
unrevoked.log - shows a brief log of the application running and reporting root status
fuse - is an empty directory, comes stock on the phone.
Since /system is still locked due to NAND protection, unrevoked creates a new directory inside of /data/local called bin-shadow.
This is basically a shadow of /system/bin plus a few extras unrevoked installs - busybox 1.15.2, su and flash_image binaries.
Any file placed into /data/local/bin-shadow appears to be in /system/bin .
A quick run of the mount command shows this as:
/dev/block/mtdblock6 /system/bin yaffs2 rw 0 0
please post any other TECHNICAL details you discover!
unrevoked.apk - application apk file
unrevoked - binary installed by .apk
i wondered where that shadow-bin folder came from and what it was. thanks for tracking that down!
Can you post/send over the unrevoked binary? (from /data/DxDRM not the apk, thx!)
f00kie said:
Can you post/send over the unrevoked binary? (from /data/DxDRM not the apk, thx!)
Click to expand...
Click to collapse
http://www.sdx-downloads.com/evo/uroot/unrevoked
that is the binary, updated the main post with it.
it would be great if this could be reverse engineered or decompile ...
joeykrim said:
http://www.sdx-downloads.com/evo/uroot/unrevoked
that is the binary, updated the main post with it.
it would be great if this could be reverse engineered or decompile ...
Click to expand...
Click to collapse
my atari won't run them but baksmali on a current machine is the tool . http://jf.andblogs.net/2010/04/03/yabbfr/ Anddroid architecture is symbolic, you get to see names, not registers.
willy900wonka said:
my atari won't run them but baksmali on a current machine is the tool . http://jf.andblogs.net/2010/04/03/yabbfr/ Anddroid architecture is symbolic, you get to see names, not registers.
Click to expand...
Click to collapse
Wont help much. The binary in the apk/res folder does the work.
Never used baksmali.. is this what you wanted?
npace said:
Wont help much. The binary in the apk/res folder does the work.
Click to expand...
Click to collapse
if that binary is the same as /data/DxDrm/unrevoked, then i agree, otherwise im hesitant to agree because before the .apk was released, they originally released a single binary which roots the phone.
a rough test i have off the top of my head would be something to the effect of ... i think the unrevoked binary from /data/DxDrm can be copied to the /sdcard, remove the .apk, copy the binary back to /data and run it. it should root the phone w/o the .apk being installed.
The baksmali I posted was from apk, the batch file I found to do it just pulled the information from the apk.
Has anyone done a quick binary compare on the two unrevoked.bin to see if they are the same? (I'm at work otherwise I'd do it)
Vinny75 said:
The baksmali I posted was from apk, the batch file I found to do it just pulled the information from the apk.
Has anyone done a quick binary compare on the two unrevoked.bin to see if they are the same? (I'm at work otherwise I'd do it)
Click to expand...
Click to collapse
just grabbed the unrevoked.bin from your unrevoked.apk and the unrevoked binary from /data/DxDrm i uploaded last night.
md5sums don't match. they might have modified the binary slightly to work inside the .apk or baksmali might have modified things.
unrevoked 27e3c38141ac479344a24006cc88c2b3
unrevoked.bin 47e7d517b972b1703c4a4dc630a4fc62
any idea, although not as technical would be to load both onto the phone and try running them from the command line and see if they give different output ?
now that we have two versions of the binary, it would be nice to find out what it does! decompiling / reverse engineering is not my specialty but hopefully somebody can provide some more insight?
If someone have the rom cooking environment and all installed, they could compile strace which would really help.
Another possibility is to install debian just like we did on the G1 when it first came out.
I tried that last night but I just need the ext2.ko module (again, a rom developer could provide that). It has to be compile for the specific kernel version, otherwise it wont work.
I dont have much time unfortunately
npace said:
If someone have the rom cooking environment and all installed, they could compile strace which would really help.
Another possibility is to install debian just like we did on the G1 when it first came out.
I tried that last night but I just need the ext2.ko module (again, a rom developer could provide that). It has to be compile for the specific kernel version, otherwise it wont work.
I dont have much time unfortunately
Click to expand...
Click to collapse
strace is included in busybox, right?
i have toast's supersonic kernel loaded and compiled, i could try and compile ext2.ko as a module (module compiling was after my main kernel day)? im not understanding how debian and ext2.ko further our efforts?
joeykrim said:
strace is included in busybox, right?
i have toast's supersonic kernel loaded and compiled, i could try and compile ext2.ko as a module (module compiling was after my main kernel day)? im not understanding how debian and ext2.ko further our efforts?
Click to expand...
Click to collapse
strace is not included in busybox. Or at least not in my busybox. If it were there, I would not have gone the debian route.
I just wanted to see if I can quickly run debian and do "apt-get install strace" then strace ./unrevoked.bin instead of having to cross-compile it for arm-eabi.
npace said:
strace is not included in busybox. Or at least not in my busybox. If it were there, I would not have gone the debian route.
I just wanted to see if I can quickly run debian and do "apt-get install strace" then strace ./unrevoked.bin instead of having to cross-compile it for arm-eabi.
Click to expand...
Click to collapse
i have the cross compile toolchain already setup for arm, but might not be the perfect processor match for the EVO. i dont have busybox source files with me, but let me grab them and see if i can compile it with strace ...
will post back with an update in a little bit! hope this works!
edit: strace is not part of busybox. NEXT! i'll see if i can grab the strace source and cross compile for the arm ... cross compiling was throwing errors which seemed like they might take a while to compile . NEXT!
grabbed the debian arm package - http://ftp.us.debian.org/debian/pool/main/s/strace/strace_4.5.14-2_arm.deb .
used a simple script to extract the .tgz from the .deb package
echo "#/bin/sh" > extract.sh
echo "ar p $1 data.tar.gz > `basename $1 .deb`.tgz" >> extract.sh
sh extract.sh strace_4.5.14-2_arm.deb
tar -zxvf strace_4.5.14-2_arm.tgz
the strace arm binary is put into usr/bin/strace and i've uploaded it here:
http://www.sdx-downloads.com/evo/tools/strace-arm.zip
hopefully this helps! let me know if this works or doesnt work and i'll go back to the drawing board on strace!
Used this method for my hero. Today I used it today to root 2 EVO's and I have to say this was an excellent root. I guess knowing the source would be great however I was burned last round of the hero updates when I lost root. You know someone from HTC was browsing these forums in order to figure out how to patch the exploits the devs had found. I just hope this exploit stays available for Froyo.
joeykrim said:
i have the cross compile toolchain already setup for arm, but might not be the perfect processor match for the EVO. i dont have busybox source files with me, but let me grab them and see if i can compile it with strace ...
will post back with an update in a little bit! hope this works!
edit: strace is not part of busybox. NEXT! i'll see if i can grab the strace source and cross compile for the arm ... cross compiling was throwing errors which seemed like they might take a while to compile . NEXT!
grabbed the debian arm package - http://ftp.us.debian.org/debian/pool/main/s/strace/strace_4.5.14-2_arm.deb .
used a simple script to extract the .tgz from the .deb package
echo "#/bin/sh" > extract.sh
echo "ar p $1 data.tar.gz > `basename $1 .deb`.tgz" >> extract.sh
sh extract.sh strace_4.5.14-2_arm.deb
tar -zxvf strace_4.5.14-2_arm.tgz
the strace arm binary is put into usr/bin/strace and i've uploaded it here:
http://www.sdx-downloads.com/joeykrim/evo/tools/strace-arm.zip
hopefully this helps! let me know if this works or doesnt work and i'll go back to the drawing board on strace!
Click to expand...
Click to collapse
I'm getting a 404 so I did the same:
I had forgotten about the debian-arm packages.
I used alien -t to convert it to tgz and upped it here:
http://bottomquark.org/android/strace
It doesnt run though and I think it's not the proper architecture
strace: 1: Syntax error: word unexpected (expecting ")")
npace said:
I'm getting a 404 so I did the same:
I had forgotten about the debian-arm packages.
I used alien -t to convert it to tgz and upped it here:
http://bottomquark.org/android/strace
It doesnt run though and I think it's not the proper architecture
strace: 1: Syntax error: word unexpected (expecting ")")
Click to expand...
Click to collapse
my mistake, link was wrong, fixed it.
ah another dead end...in the process earlier i got busybox to cross compile, but it has a nice make xconfig, dont think strace does...
ill try and devote some more time to getting the cross compiling setup and a working strace unless somebody else posts a working strace arm binary?
joeykrim said:
my mistake, link was wrong, fixed it.
ah another dead end...in the process earlier i got busybox to cross compile, but it has a nice make xconfig, dont think strace does...
ill try and devote some more time to getting the cross compiling setup and a working strace unless somebody else posts a working strace arm binary?
Click to expand...
Click to collapse
I'll go back to the debian route when I get a chance. It helps to have that running.
BTW, thanks a lot for all your work -- I have similar questions about everything you are currently pursuing!
npace said:
I'll go back to the debian route when I get a chance. It helps to have that running.
BTW, thanks a lot for all your work -- I have similar questions about everything you are currently pursuing!
Click to expand...
Click to collapse
good news, strace is part of the PC36IMG.zip. seems the userdebug version has quite a few developer tools in system/xbin. i've set them chmod 755 and setup root access on my ROM which is simple and clean.
if you dont want to load my ROM, you can setup the environment manually from recovery mode on a stock PC36IMG.zip, just chmod 4755 xbin/su and chmod 755 the xbin directory or just the strace binary.
hopefully this helps?
I'm still wet behind the ears, kernel wise. I have built my own vanilla Android kernels, so I have all the tools I need (I think).
For GTab kernels, does anyone have a HOWTO I can leech off of? Ie. I know that we need the tegra git, then the patch that CS supplied. But does anyone have a template .config I can work off of?
Btw, what I'm looking for is CIFS support (already being worked on here) and EXT3 support for flash drive. The latter would make me a very happen person.
Thanks in advance.
roebeet said:
I'm still wet behind the ears, kernel wise. I have built my own vanilla Android kernels, so I have all the tools I need (I think).
For GTab kernels, does anyone have a HOWTO I can leech off of? Ie. I know that we need the tegra git, then the patch that CS supplied. But does anyone have a template .config I can work off of?
Btw, what I'm looking for is CIFS support (already being worked on here) and EXT3 support for flash drive. The latter would make me a very happen person.
Thanks in advance.
Click to expand...
Click to collapse
Attached is a tegra .config file with EXT3, EXT4, and CIFS included in the kernel (not as a module file). Just rename to .config and build.
To configure other options as needed, just do a make menuconfig, go to the file systems menu to configure the EXT3/4 options. For CIFS and other network file systems go to the file systems menu, select "Network File Systems", then configure CIFS, NFS, etc. as needed.
Thanks! I will play around with this.
roebeet said:
Thanks! I will play around with this.
Click to expand...
Click to collapse
Here is an updated version that I made starting from extracting the .config from the kernel in the boot.img in your tnt_lite_v3.00 update file. This just has EXT4 and CIFS added, so this may be a better starting point. Good luck and thanks for all of your work.
Be careful with enabling extra params which the supplied wifi module (from tapntap) is dependant on, as if things mismatch (headers; they will), the module wont load.
I am working towards breaking out this dependancy so we can be completly free.
Like vpn, I found out the hard way
If you look in arch/arm/configs you will see some files called tegra-harmony-defconfig or something like that. Its part of the patch file. if you run make tegra-harmony-defconfig, it will put all the "default" values into a .config for you. Then you can run make menuconfig (or whatever make config you like)
repack-zImage.sh is a bash script for Linux which allows you to unpack a kernel image (zImage) for modification and repack it afterwards into a new working kernel image.
You don't need a kernel tree for this program nor a compiler. It should work with any zImage that contains an initramfs, for whatever phone, operating system or CPU architecture you like.
My main purpose when I wrote it was to modify the initramfs of leaked Samsung i5800 firmware for which no kernel source is available.
Usage:
=====
Put the unzipped script into some directory along your $PATH (e.g., /usr/local/bin). Put the unpacked files from initramfs_utils.zip into /usr/local/bin.
Then simply run 'repack-zImage.sh -u' with your zImage in the current directory and it will create a directory named 'zImage_unpacked' which contains the unpacked blocks of your zImage. Refer to the comments near the start of the program to identify which file corresponds to which fragment of the original zImage. (The file name of the zImage should be "zImage". If it isn't, pass it as the only non-option argument. The subdirectory's name will change accordingly.)
Most notably, there will be a directory 'initramfs' in there, which contains all files from the original initramfs in their original tree. You can modify the contents as you like, but keep in mind that your initramfs cannot grow larger than the space reserved for it in the original zImage. So you're restricted to relatively small changes which should, however, satisfy many needs. You always can call a script or executable on some other partition (including the SD card if already mounted) if you need more room for your modifications.
After your modifications are done, cd back to the directory which contains zImage and zImage_unpacked and run 'repack-zImage.sh -p' to start the packing process.
This will create a directory called 'zImage_packing' which contains your new zImage (and a zImage.tar for loaders like ODIN). It will emit (between others) one or two messages about a padding being done and about how many bytes were padded. This number (or the lower number of the two) is an indication about how many compressed bytes are left for further additions to the initrd.
If your initramfs (or some other modified part) grows too large, the script will abort with an appropriate error message.
In initramfs-utils.zip, three programs are provided. They should be copied to /usr/local/bin:
* cpio_set0. This is a slightly modified cpio (compiled for 32 bit Linux). repack-zImage.sh will run without it, but there may be slightly more room in your initramfs if you use the modified one. It sets all file times in the archive to 0 (epoch), thus yielding better and consistent compression results. Else, the size of the compressed initramfs will differ from invocation to invocation due to differing atimes. Put it somewhere along your $PATH (e.g., /usr/local/bin).
* gen_init_cpio and
* gen_initramfs_list.sh. These are utilities copied from a kernel tree and used to support creation of an initramfs (in certain modes).
'repack-zImage.sh --help' will output usage information.
Happy hacking,
mizch
Current Version: 6
2011-05-03
('repack-zImage.sh --version' will output version information.)
- added support for lzma compressed ramdisks (both directions)
Version 4
2011-02-17
- Workaround for ambiguous gunzip result, see post #20
- Some code cleanup + CLI cleanup
- better error detection
Version 3
2011-01-06
- now also works with unzipped initramfs withing gzipped zImage part (i.e., all kinds of zImages)
Version 1
2011-01-05
- initial version. Works only for gzipped initramfs within gzipped zImage (e.g., G3 Eclair kernels)
-----------------------
repack-zImage.zip contains version 4 of the script.
For the newest version, download repack-zImage.v6.zip and initramfs-utils.zip.
It didn't work on zImage from Froyo firmware i tried. Great work however .
Works however for Eclair firmwares i've tested.
Good work.
Is this based off the i9000 script?
Also, I've noticed with the i5800 Eclair firmwares that the initramfs is gzipped AND cpio'd. So... Kernel + initramfs.cpio.gz are gzipped together.
Basically you need to extract [kernel+initramfs.cpio.gz].gz, extract initramfs.cpio.gz again, then extract initramfs with cpio.
On Froyo, the kernel + initramfs.cpio is gzipped together, but nothing more. So after you extract the kernel and initramfs, you just need to extract with cpio after that.
Hope that kind of helps..
In didn't go into Froyo for the i5800 until now. I used Eclair. It eases testing if you can compare things to a working kernel tree.
I see that Froyo doesn't use a compressed initramfs within the compressed kernel (which I doubt to make much sense anyway since compressing an already compressed part again is likely to produce a larger result). In theory, thus Froyo is easier to cope with than what I have now, but I have to write the code to handle it. This will need some time, maybe tomorrow, maybe the weekend.
And, no, this is not based on code from the i9000. It was written up from scratch. But I took some ideas from there and thank dkcldark for his good work.
mizch said:
In didn't go into Froyo for the i5800 until now. I used Eclair. It eases testing if you can compare things to a working kernel tree.
I see that Froyo doesn't use a compressed initramfs within the compressed kernel (which I doubt to make much sense anyway since compressing an already compressed part again is likely to produce a larger result). In theory, thus Froyo is easier to cope with than what I have now, but I have to write the code to handle it. This will need some time, maybe tomorrow, maybe the weekend.
And, no, this is not based on code from the i9000. It was written up from scratch. But I took some ideas from there and thank dkcldark for his good work.
Click to expand...
Click to collapse
If we can get this modified for Froyo, it will allow for native ext2 mounting within the initramfs. Then we can add things to it like the way CWM works - busybox, adb, etc... So that we have a recovery adb setup before /system mounts.
precurse said:
If we can get this modified for Froyo, it will allow for native ext2 mounting within the initramfs. Then we can add things to it like the way CWM works - busybox, adb, etc... So that we have a recovery adb setup before /system mounts.
Click to expand...
Click to collapse
Exactly, that could be very useful, since we could get ext2 (ext4 maybe if we compile it as a module ?) in /data natively
Gsam101 said:
Exactly, that could be very useful, since we could get ext2 (ext4 maybe if we compile it as a module ?) in /data natively
Click to expand...
Click to collapse
I already tried building ext4 and other modules off the i9000 sources... Didn't seem to work too well. Kept complaining about memmap or some random errors when I tried loading them.
Perhaps we can try them against JPF or something.
Heck.. or even allow a user to use a file off their SD card to loopback mount /system partitions... Or /data partitions - like how the i9000 has a (built-in) 16gb SD card.
precurse said:
I already tried building ext4 and other modules off the i9000 sources... Didn't seem to work too well. Kept complaining about memmap or some random errors when I tried loading them.
Perhaps we can try them against JPF or something.
Click to expand...
Click to collapse
I think so. Maybe we should just try to build an ext4 module with standard linux sources with armv6 as target ? Since i9000 has an armv7 processor..
Gsam101 said:
I think so. Maybe we should just try to build an ext4 module with standard linux sources with armv6 as target ? Since i9000 has an armv7 processor..
Click to expand...
Click to collapse
I setup my .conf to use the same CPU as what the G3 uses. I can't compile a kernel, but the modules compile.
It's a much different error I got from these modules than when I tried loading i9000 modules.
precurse said:
Heck.. or even allow a user to use a file off their SD card to loopback mount /system partitions... Or /data partitions - like how the i9000 has a (built-in) 16gb SD card.
Click to expand...
Click to collapse
Don't forget the internal SD of the sgs is on fast movienand SD memory, if one would loop back to his sdcard he would have to have a class 10 sdcard at least to get decent speed out of it.
I've posted a new version of repack-zImage.sh and the associated utilities in the first article of this thread. This version lifts the restriction which until now allowed only compressed initramfs disks. Now uncompressed ones are also supported.
This modification got somewhat tricky, as a newly created initramfs, when compressed, yields sizes different from the original (even if it contains exactly the same files) due to different ordering of the files. For a 2 MB ramdisk, a difference of 3k may not sound like much, but it is - if it is too large by this number in a zImage where the initramfs must fit into the original's room.
Some black magic was needed. Now the files are ordered like in the original, with additional files (if created by the user) appended at the end. Options are provided to change the optimisations if needed.
I tried with JPF and with JPA-custom, so changes are really good that you won't have to bother with the above and can just go ahead and do your own initramfs modifications.
Yeah, that worked for me. Thanks a lot .
have we (you all) found a way to unpack the froyo zimage yet? it worked great on eclair. thank you. and thanks for any help that you might provide.
i have tried on froyo for the epic but as it is unpacking it keeps looping 2 sets of numbers when i run the script. 5748017 5749018 and keeps repeating. any help would be great.
/Data and /cache ext2 conversion script.
Gsam101 said:
Exactly, that could be very useful, since we could get ext2 (ext4 maybe if we compile it as a module ?) in /data natively
Click to expand...
Click to collapse
hey here's a script that converts /data and /cache to ext2... i tried it.. worked for me.. i did not made this.. !
this is the work of MOTAFOCA !
quadarant score went from 305 to 515 and the best part.. internal memory shrunk from 176Mb to 161 Mb only
the script says its for i5508 but was made for 5800 as said by barquers
anyways.. here's the script.. hoping it will help
http://multiupload.com/O2ET4B8K0A
PS: im using MOTAFOCA's ROM... and script was made by MOTAFOCA not me
spdwiz18 said:
i have tried on froyo for the epic but as it is unpacking it keeps looping 2 sets of numbers when i run the script. 5748017 5749018 and keeps repeating. any help would be great.
Click to expand...
Click to collapse
It should work for any zImage. Sounds like a bug in the end detection for a compressed part. Can you provide me with a link to the zImage or contact me directly (PM/E-Mail) to pass me a copy? Then I'll go into it.
hey. does the script allows us to tweak the kernel so that it can be overclocked? ??
or we still need to wait for the kernel sources?
coolzarjun said:
does the script allows us to tweak the kernel so that it can be overclocked?
Click to expand...
Click to collapse
You cannot do that without writing your own cpufreq driver (if at all). You need the kernel sources to do this.
mizch said:
It should work for any zImage. Sounds like a bug in the end detection for a compressed part. Can you provide me with a link to the zImage or contact me directly (PM/E-Mail) to pass me a copy? Then I'll go into it.
Click to expand...
Click to collapse
Soryy gmail was not syncing for somereason. I will send tou what I have when I get home from work thanks.
Got the zImage, thanks. I could reproduce the problem. What happens:
Using gzip's magic number, I can tell the start of a gzipped section. To determine its end, I need the help of gunzip. It reports "trailing garbage" if its file is too long, "truncated file" if too small, "OK" otherwise.
With your zImage, gunzip reports "truncated" when fed with 5749017 bytes, "trailing garbage" at 5749018. Obviously, only one of the two (not both!) can be correct. But this is what gunzip reports in your case. I found that 5749016 is the correct size. Erm.
As a workaround, I now detect when the gunzip result is oscillating this way and if it does, I search nearby towards lower size values for an exact match. This is not an ideal solution but I have to deal with what gunzip returns and this fits it best.
I'll do some cleanup and some final tests now and if they succeed, I will post the new version in about an hour or so in the first posting of this thread.
EDIT: New version posted.
So, I am trying to build a kernel for my nexus s 4g. I have been following the cm7 instructions. But they have a step where I need to grab the configuration file from /proc but the does not exist on my phone running the latest stable cm7. I have tried to do a make herring_defconfig but that gives me an error about not knowing or having that file.
So can some kind dev either send me a config file or give me some pointers as to how to generate one. All I really am trying to do is figure out the right command line to load the bcm4329.ko driver so I can play with pure adhoc networking, not the adhoc currently supported with a client server mechanism for ip addresses.
Thanks,
-frank
I was looking for a similar topic but I did not find one. Refers to problems with running applications added to "system.img".
I bought UMIDIG S for my father-in-law. It is based on a mediatec chipset. Unfortunately, soft is tragic, and there is no full translation, so I decided to bury it a bit in "system.img".
I can easily install the file in Linux and make changes in it. I can delete applications, I can make changes in configuration files and "buikd.prop".
Unfortunately, all APK files were uploaded to "system.img" even though I set permissions 755 for directories, and 644 for directories. Although the files are root: root, after uploading such "system.img" none of these applications works for the phone. The system sees them and tries to load. Unfortunately, applications hang because of errors. The system informs that the application hangs, and does not load its window. The icons of these applications and the names do not appear either (applications have green robocik as icon, and domain name, e.g. com.android.clock ....)
I am asking for advice. How to add APK files to the unzipped "system.img" so that after packing and uploading to the phone there were no errors ???
Do you have found how add app in system.img?
It's all around, but you can replace apps with others. In the linux system, unpack the img, and mount them. Then you can freely rename files as well as move files within the .img mount point
I chose the applications or other files I did not need, and moved them to the directories (which I named my applications). If the application needed libraries, you also had to get files in a similar way, and place them in arm or arm64 directories.
Then prepared files "stuffed" with data, using the command DD. That is, dd if = (source file) of = (the recipient file at the system.img mount point).
Thanks for reply, so this only on Linux? For Windows there is something?
Markosv76 said:
Thanks for reply, so this only on Linux? For Windows there is something?
Click to expand...
Click to collapse
I do not know, I do not use Windows. Certainly you can in a similar way from BSD systems, probably from Android and MacOS. I read something that Microsoft can somehow support linux shell, but I do not know the details. You can always use some distribution that works with a pendrive.
Thanks, I will try again
Markosv76 said:
Thanks, I will try again
Click to expand...
Click to collapse
You can use Virtual Box to run a Linux distro inside Windows or you can try using Cygwin.
Sent from my LGL84VL using Tapatalk
jaroslawstrauchmann said:
I was looking for a similar topic but I did not find one. Refers to problems with running applications added to "system.img".
I bought UMIDIG S for my father-in-law. It is based on a mediatec chipset. Unfortunately, soft is tragic, and there is no full translation, so I decided to bury it a bit in "system.img".
I can easily install the file in Linux and make changes in it. I can delete applications, I can make changes in configuration files and "buikd.prop".
Unfortunately, all APK files were uploaded to "system.img" even though I set permissions 755 for directories, and 644 for directories. Although the files are root: root, after uploading such "system.img" none of these applications works for the phone. The system sees them and tries to load. Unfortunately, applications hang because of errors. The system informs that the application hangs, and does not load its window. The icons of these applications and the names do not appear either (applications have green robocik as icon, and domain name, e.g. com.android.clock ....)
I am asking for advice. How to add APK files to the unzipped "system.img" so that after packing and uploading to the phone there were no errors ???
Click to expand...
Click to collapse
did you find a solution to this? please reply if yes, I am having the same problem