yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] codelover:
I beat you need to keep the system.img inside Root.fs instead of leaving it outside and throw the one inside. the one you need to remove is system.fs, the one being used by your method is the one inside Root.fs. So far i have not been able to use system.img directly, perhaps only the old 0.6.3 can do that... still researching about that but probably will stop because current method works just fine....
[Android Software/Hacking General [Developers Only]] merrickville:
Thanks for pointing that out, I corrected my original post, just in case.

---------- Post added at 04:31 PM ---------- Previous post was at 04:21 PM ----------

I have removed system.sfs from Root.fs, then I shrunk Root.fs down to the ramdisk.img size, but about 10Megs bigger this worked for me.

However, after a few reinstalls, I just left Root.fs as is, and just copied out the system.sfs (then extracted system.img) I mount that as /dev/sdd1 as RW.

If you examine the init script, it looks inside Root.fs for system.sfs first, then if not found, it looks for system.img.

I have edited the init script to just ignore all that and mount -t ext4 -o ro /dev/sdd1 /system.

---------- Post added at 04:36 PM ---------- Previous post was at 04:31 PM ----------

FYI: I corrected my post that you quoted

vi init NOT vi init.rc
[Android Software/Hacking General [Developers Only]] codelover:
The last time i checked the init provided by bill's root installer, the mount statement is inside system.sfs check which will never get executed, as the system.fs does not exists. maybe his version is a little bit different with yours, but i personally tried putting system.img outside without luck.
[Android Software/Hacking General [Developers Only]] rocketero:
I may getting a bit blind as your init file, extracted as per @merrickvlle indication, from your initrd.img is identilcal to my init file extracted from my initrd.img

One place thou I see that could be the issue with /system RO, is this code in init file:

while :; do
for device in /dev/sr* /dev/sd[a-z]*; do
try_mount ro $device /mnt || continue

what about if I change the word ro to rw in 'try_mount' ?

---------- Post added at 09:57 PM ---------- Previous post was at 09:51 PM ----------

yeah I'm looking at init file, so I guess it's better editing to look for system.img first and second for system.sfs as we know system.fs won't be there in Root.fs

do you meant in this line:

I have edited the init script to just ignore all that and mount -t ext4 -o ro /dev/sdd1 /system.

instead to be:

"I have edited the init script to just ignore all that and mount -t ext4 -o rw /dev/sdd1 /system "

Also in this code: (I edited to be compatible with cygWin (with the ~)

mkdir ~/tmp/init
cd ~/tmp/init
gunzip -c ~/tmp/initrd.img | cpio -im
vi init
cd ~/tmp/init
find . | cpio -H newc -o | gzip -9 > ~/tmp/initrd-new.img

you typed twice: cd ~/tmp/init, shouldn't be the second instance be: cd ~/tmp ?
[Android Software/Hacking General [Developers Only]] codelover:
lol are you sure you didnt messed up your version with mine? as i said there is only 1 byte difference with the ORIGINAL unmodifed version, well you have already got the answer! well done!
[Android Software/Hacking General [Developers Only]] merrickville:
I am running 0.7.5.2700

This version does not have a system.

fs

, so I'm not clear on what you mean here.

The script 'init' inside initrd.img does all the mounting, there is nothing inside system.sfs nor system.img that has anything to do with mounting, because this all takes place very early in the initramfs stage of the boot process.

I'm not familiar with 'bill root installer' and the mount statement is NOT inside the system.sfs on my copy, it's inside the initrd.img

---------- Post added at 05:09 PM ---------- Previous post was at 05:03 PM ----------

If you leave system.img inside system.sfs you NEVER be able to mount /system as RW. Squashfs is a read-only file system, you can not mout it RW.

So, you need to get the system.img file outside of Root.fs, as it mounts it as a read only 'loop'. You add a 4th block device inside your system/registry to be sde1 and point it to system.img file, THEN, you can mount /system as rw.
[Android Software/Hacking General [Developers Only]] rocketero:
When you said you extracted system.img from system.sys I have a question.

while mounting system.sfs to a folder, not matter if one use mount -o loop ... or ... mount -o rw ... it will always mount system.sfs as READ ONLY. So there is not way to write to system.sfs. so when you say: "I mount that as /dev/sdd1 as RW, what are your exactly referring to 'mount' .. system.sfs ? or system.img ? and if is system.img why it doesn't say it in the mount command ?
[Android Software/Hacking General [Developers Only]] codelover:
Sorry some typo, i mean system.sfs's check inside initrd.img -> init, i mean this:

if [ -e /mnt/$SRC/system.sfs ]; then
#mount -o loop /mnt/$SRC/system.sfs /sfs
#mount -o loop /sfs/system.img system
e2fsck -y /dev/sdd1
mount -t ext4 -o ro /dev/sdd1 /android/system

I mean the above statement will never get executed, and i am referring to the rooted version of Root.fs/initrd.img provided by bill, sorry if i caused any misunderstanding :)

Btw I am using 0.7.5.2700 too.
[Android Software/Hacking General [Developers Only]] rocketero:
I see what you meant, one character was hard to find in the whole almost identical files, I did thou saw that 'try_mount ro' that's why mentioned, but in a closer look using this online comparing files site I found the difference: http://www.comparemyfiles.com :good:

I just want to thank all of you for your individual contributions, espcially @codelover, @merrycville and @bill_weckel,

finally I got BlueStacks v.0.7.5.2700 completely rooted: here is now /system RW screenshot:

I added a file to /system, build.backup.prop to show it's now writable.

there was not need to take out system.img and didn't have to use that extra blockdevice -4 for sde1 as merryckville said, I just used my Root.fs rooted, 500MB for /system partition, and the @codelover initrd.img

One thing that it's not working is when using a rooted app, superuser does not prompt to give root-access.

​

there was not need to take out system.img and didn't have to use that extra blockdevice -4 for sde1 as merryckville said, I just used my Root.fs rooted, 500MB for /system partition, and the @codelover initrd.img

==============\

So all one need, is one of the 2 Root.fs rooted files I've created, either the one in which /system partition has only 7MB free space, or the other Root.fs where /system has 365MB free space:

Then download @codelover's initrd.img and place it together, one of the Root.fs, and the initrd.img in c:\programdata\bluestacks\Android (make sure you shutdown bs service/agent, etc, just run c:\program files [x(86)] optinaly for 64bit\bluestacks\HD-Quit.exe)

happy bluestack(ing)!
[Android Software/Hacking General [Developers Only]] codelover:
Congratulations! :good: what take you so long? :D

Btw for the su, the version you are using (su-x86) is the one autogrants root, try using su-x86 3.2 and Superuser 3.1.3/3.2. You should see the miracle then.
[Android Software/Hacking General [Developers Only]] merrickville:
Okay,

I'll just put here what I have done

a) extract system.sfs

b) extract system.img (from system.sfs)

c) rename it to something (Rick.fs) That's me!

d) make a system registry setting ADD a block device '4' {see code}

e) extract init from initrd.img and edit it {see code}

Windows 7 Registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\BlueStacks\Guests\Android\BlockDevice\4]
"Name"="sde1"
"Path"="C:\\ProgramData\\BlueStacks\\Android\\Rick.fs"

My name is Rick, so I renamed system.img -> Rick.fs

This is my initrd.img/init script file

init script

(I removed all the comment lines for easier reading, this is the only portion of the 'init' script that I modified, inside the 'while' loop, nothing else)

while :; do
for device in /dev/sr* /dev/sd[a-z]*; do
try_mount ro $device /mnt || continue
cd /mnt/$SRC
[B] if [ ! -e ramdisk.img ]; then
cd /
umount /mnt
continue
fi[/B]
mount -t tmpfs tmpfs /android
cd /android
zcat /mnt/$SRC/ramdisk.img | cpio -id > /dev/null
[COLOR="Red"]mount -t ext4 -o ro /dev/sde1 system[/COLOR]
mkdir cache mnt mnt/sdcard mnt/sdcard/windowsdata mnt/prebundledapps
mount -t tmpfs tmpfs cache
echo " found at $device"
break
done
mountpoint -q /android && break
sleep 1
echo -n .
done

And that my hacking friends is the 'simplest' way to get your /system to mount rw. Now, some file manager apps may not be able to mount /system rw, but, yes, you can do it from a Android Term window.

Rick
[Android Software/Hacking General [Developers Only]] rocketero:
I did install superuser updater fixer (https://play.google.com/store/apps/details?id=com.noshufou.android.su.fixer) and then I updated the superuser apk from the Google Store to the latest 3.1.3 https://play.google.com/store/apps/details?id=com.noshufou.android.su,, but still there is not a popup to ask to give root access to apps that ask for or require it

how could this be fixed?

Edit. but even that I installed 'superuser update fixer' I still can not run the binary updater: as it fails gaining root access step
[Android Software/Hacking General [Developers Only]] merrickville:
The su.x86 is AUTO-GRANT-SUPER-USER. This is something that has been present since we've been hacking BlueStacks. Some programmer on here could better answer, and maybe recompile an su.x86 that respects the superuser or SuperSU apps?

Remember, su.x86 is not for phones, it's for the BlueStacks emulator. We are talking apples and oranges. The 'su' on on your phone is for the ARM processor, the su on your bluestacks is for the x86 processor.

So, updating from the Google market 'superuser' OR 'SuperSU' does not install the su.x86 binary, it only deals with the su (ARM) binary.

Like Mac & Windows LOL
[Android Software/Hacking General [Developers Only]] rocketero:
I see that merricville attached a thumbnail, how do I do that here in this forum, I've never done it, I've usually place an img bb code.

---------- Post added at 11:51 PM ---------- Previous post was at 11:47 PM ----------

@codelover / @merrickville

have you tried placing this code you mentioned above ?

if [ -e /mnt/$SRC/system.sfs ]; then
#mount -o loop /mnt/$SRC/system.sfs /sfs
#mount -o loop /sfs/system.img system
e2fsck -y /dev/sdd1
mount -t ext4 -o ro /dev/sdd1 /android/system

I did added in addition to the try_mount rw change, but once I repacked initrd.img and booted with it, bluestacks started and then like magic it disappeared the next second.

the checking of the sdd1 it's good to have to keep the system tuned up
[Android Software/Hacking General [Developers Only]] merrickville:
Go Advanced Editing

Manage Attachments

Follow file extension rules to upload your attachments.

---------- Post added at 06:53 PM ---------- Previous post was at 06:51 PM ----------

That code was my 'early' days of trying to do this. I would watch the Core.log and it would report that the file system is corrupt, so I put the e2fsck -y in there to make sure the file system was in a 'sane' state before being mounted. As I believe this was why it was failling.

Please see my last post with the init script code, this is very simple, and it just works.
[Android Software/Hacking General [Developers Only]] codelover:
yaya, merrickville is right! dont be lazy! just like how you find a busybox 1.18 x86, find su x86 and manually put it in inside system.img or /system/xbin then you are fine, oh and don't forget the permission +6755
[Android Software/Hacking General [Developers Only]] rocketero:
instead of creating extra work by editing the registry and adding another blockdevice (4) and using again system.img (renamed to Rick.fs), why instead don't you avoid all that and in the 'try_mount ro' in init (initrd.img) just change it to 'try_mount rw' as @codelover advised?, I did it and it's working fine with not extra registry changes or extra blockdevices!

And Yes, some file system apps like ES File Explorer don't mount /system RW or even see Root, but Root Explorer does, I haven't tested 'solid explorer' or 'file manager' but I will.
[Android Software/Hacking General [Developers Only]] merrickville:
Cool!

Post your code, let us all try it. I just found something that works for me and shared it.

---------- Post added at 07:07 PM ---------- Previous post was at 07:01 PM ----------

Did you extract system.img from system.sfs for this work around?
[Android Software/Hacking General [Developers Only]] codelover:
Confirmed this method works too! And this seems much easier! Thanks merrickville for sharing! You deserve a click for the button under your nick, the one with a :good: ;)
[Android Software/Hacking General [Developers Only]] merrickville:
Can you tell me what two files are inside your Root.fs file?

Thanks.
[Android Software/Hacking General [Developers Only]] codelover:
He is using bill's rooted version Root.fs + some modification by him.

Root.fs/android/ramdisk.img

Root.fs/android/system.img

Right, rocketero?
[Android Software/Hacking General [Developers Only]] shinobisoft:
Damn yall have been busy this afternoon. Made life much easier for me. Now I don't have to delve into it :silly:.

My installer should still do the trick too. Especially for those who haven't rooted BS yet. ;) Just remember the installer needs to be in the same folder/directory as the patched files.
[Android Software/Hacking General [Developers Only]] merrickville:
Cool, that sounds right to me.

The method I posted is for the do-it-your-self guy. You don't need to download anything from the Internet, you have all the files you need.

But yes, since someone repacked Root.fs with system.img, and Root.fs can be writable, so too can system.img be mounted rw. This is 'less' work, and you are downloading someone else files, which is cool.

For those who want a challenge and learn something..., my method is for the DIY, and it requires some knowledge of Linux and initramfs (editing initrd.img)

So..., what's next LOL ???
[Android Software/Hacking General [Developers Only]] rocketero:
Well basically I followed your lead, I mounted the original Root.fs I had, then extracted system.sfs, mounted system.sfs, extracted system.img, mounted system.img, injected su.x86, busybox-1.18.4, and superuser.apk, desmounted system.img, re-sized this new/edited system.img to 500MB and copied this new edited system.img to Root.fs. (where Root.fs was mounted to ../android folder (where ramdisk.img was located))

Then unmouted the Root.fs, copied this new Root.fs and the initrd.img by @codelover, to .../Android folder, rebooted Bluestacks and that's all.

I didn't do anything to initrd.img, my original one differs only in one character with @codelover's initrd.img
[Android Software/Hacking General [Developers Only]] codelover:
Next? We wait Bluestack next version and give us some more challenges? lol

Btw have you figure out where the D/TelephonyManager function actually located? tried telephony apk wasnt there... yaya imei things... if you get what i mean :silly:
[Android Software/Hacking General [Developers Only]] rocketero:
I edited the posts where I had placed a link to my Root.fs (with system.img normal and the other with system.img re-sized to 500MB), due to the busybox-1.18.4 I took from the TitanuimBackup installation folder, works but it has some limitations like some applets are not understood by bluestacks kernel, like the command $ifconfg -a was giving me :applet not found.

So now I have replaced busybox, while bluestacks was running, to the previous busybox-1.16.2 which is so far the best one working.

So if one wants to create a re-sized /system partition can follow my link here: and also if one wants to re-size the SDcard (using bluestacks 0.7.3.x and previous) and then upgrade to 0.7.5.x, can go here and do so (re-size SDcard from 2GB to any GB's one desire)
[Android Software/Hacking General [Developers Only]] shinobisoft:
I'd say the next step is how to upgrade Android versions:D I'm getting really partial to JellyBean :p
[Android Software/Hacking General [Developers Only]] rocketero:
what about this su-3.1.1-x86-signed, from http://downloads.androidsu.com/superuser/

I am guessing here, but if i extract the su inside that zip, without having to place it in system.img, I could just place one copy in /system/bin, while BS is normally running, then delete the one in /system/xbin because I would have still root rights (the su in /sytem/bin), then I could copy it also to /system/xbin.

But not sure if this su is good for bluestacks.
[Android Software/Hacking General [Developers Only]] mtmerrick:
ok, so i just (re)installed bluestacks. accidentally hit sync everything, so all my phone apps transferred over, including google play version 3.9. 16.

and guess what?

google play works perfectly without rooting it or anything o_O i didn't even know google play needed to be hacked onto bluestacks until i googled how to get rid of the recommended apps bar...

and the really weird part? when i go to google play website and look at my devices, it shows up as "T-Mobile Samsung GT-I9100"

anyone have any light to shine on this?
[Android Software/Hacking General [Developers Only]] codelover:
yeap, either way should work. did you see the 'su' subdir? you can use any version even the latest one (su-3.2-x86) works fine as long as its a x86 ver. same goes to Superuser, only that you might have prob viewing the info page about the su ver blah blah blah which is not important as the prompt requesting permission and click work just fine.

---------- Post added at 02:17 PM ---------- Previous post was at 02:12 PM ----------

I thought Google Play comes with the latest ver? as for the GT-I9100, Bluestack is either emulated as SII or note, depends on OEM.
[Android Software/Hacking General [Developers Only]] shinobisoft:
Just edit /system/build.prop.
[Android Software/Hacking General [Developers Only]] rocketero:
Google Store is installed by default I believe starting Bluestacks 0.7.4.x, as when I installed 0.7.3.x didn't installed, but the latest one I did installed, 0.7.5.2700 placed Google Store. There is a window that flash very quick after installing, talking about XDA Developers website and how is installing Google Play.

For the GT-I9100, as @codelover said, is one of the build.prop backups that was included in BS latest releases, as well as one with Samsung GT-N7000. As a test, open a terminal window and you see that the prompt is: app_75@GT-N7000

---------- Post added at 07:32 AM ---------- Previous post was at 07:31 AM ----------

So my question is still standing, about using the su file that is located in su-3.1.1-x86-signed, from http://downloads.androidsu.com/superuser/, I don't want to mess up and discover that I lost my root rights by installing this version.
[Android Software/Hacking General [Developers Only]] codelover:
Don't worry i am using that ver and i can assure you that it works!
[Android Software/Hacking General [Developers Only]] rocketero:
Great!,

I have now the popup for superuser showing up asking to give permission::

But the superuser.apk has a red message that you don't have, got not idea what is it or why it shows up

.

Edit: Something weird happened. after copying su (3.2 x86 as pic above) to /system/xbin and /system/bin, while bluestacks was live running, and chmod them 06755 and chown 0:2000, it was working fine for a while.

Then I opened Root Explorer and saw that /data was empty, so I went to a terminal and typed su, and got permission denied. and ls -la su shows as 0755 in both /system/bin and /system/xbin. somehow they got changed and I'm 100% sure I double checked when I chmod them 06755.
[Android Software/Hacking General [Developers Only]] codelover:
Why don't you try chown first then chmod ;) (Edit: I have mine 0:0 btw).

The red message shown because the sutools installed by Superuser in /data/data is also ARM version.. lol...

No worries there is a x86 version inside the apk itself, replace it. 3.2 more horrible...but it still works anyway! as i mentioned earlier it just for info, perhaps ota function which is not needed for BS.
[Android Software/Hacking General [Developers Only]] Zoltan-X:
So thanks will be just permitted after.

My way: I used the installer many threads before posted replaced there the initrd.img run it and succeed running AdAway with overwriting the /system/etc/hosts file. So easy it was. Thanks thanks and thanks

---------- Post added at 12:27 PM ---------- Previous post was at 12:19 PM ----------

PS.: Special Thanks to bill weckel for the root installer and to codelover for the modded initrd.img
[Android Software/Hacking General [Developers Only]] merrickville:
Agreed, I'm sure that would be quite the undertaking without Bluestacks themselves doing it first. JB is nice, I'm running it on my old Galaxy S, SlimROM(JB) Would be slick to get BlueStacks running it.

---------- Post added at 09:34 AM ---------- Previous post was at 09:19 AM ----------

I've never messed with the telephony apk's. That would require the code to emulate cellular phones? Sounds complicated LOL

I have successfully used Viber I can place and receive calls using that app in bluestacks. Unable to get Dell Voice (Fongo) to work though.
[Android Software/Hacking General [Developers Only]] ThumbDriveCorps:
Anyone have bluestacks working on a Vista (Home Premium) PC..?

If so, how'd you get the graphics card driver updated..?

I went to the manufacturer website, and did the update from there..but bluestacks still won't install.
[Android Software/Hacking General [Developers Only]] rocketero:
if you were going to place a filesystem check for errors to /data or /system partitions, what code would you place in init (initrd.img) to make it run? /dev/sdd1 contains the prebundled.fs, that would be the right blockdevice?

and what about something to check out how well this command went with something like:

/system/bin/e2fsck -p -y -v /dev/sda1 > /system/fsck_sda1.log

or:

/system/bin/e2fsck -p -y -v /dev/sda1 > /system/fsck_sda1.log

if [[ $? -eq 2 ]]

then /system/bin/reboot

fi;

to check for errors on sda1 where Root.fs is mounted --> blockdevice 0 ?

Another question I have is, in init I changed the path to add /data/bin to the list,

PATH=/sbin:/bin:/system/bin:/system/xbin:/data/bin; export PATH

Now when I run a terminal, and echo $PATH it doesn't show :/data/bin at the end, just the original. I did double checked the init file had the changed line for PATH= and it does. So I'm wondering why is not taking it after boot. Once I boot and see the /init.rc it says in 'setup the global environment': export PATH /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin but does not have /data/bin as I had changed on init.
[Android Software/Hacking General [Developers Only]] LfcFan1977:
Thanks very much. BS is now very usefull..................... but

I'm struggling to get the Superuser.apk (allow/deny) pop up to show.

Tried several su files, busybox files and Superuser.apk's suggested and posted but I'm evidently doing something different and getting permissions wrong aswel.

Could I please get some clarity on which of ^ those files are best suited and exactly how to apply them?

Windows 7 64bit with clean install of the latest Bluestacks from thier website into ProgramFiles (x86) folder.

Overwriten with Bluestacks 0.7.5.2700

Using codelover's initrd.img from post 443

and rocketero's 500Mb root.fs (i think it was) from post 438.

Root check shows success. Can write from /sdcard to /system, no problem.

Superuser.apk v3.1.3 but with error:

su binary

vlegacy (0)

/data/data/com.noshufou.android.su/files/sutools[1]:syntaxerror:/system/xbin/su