[Patch]Malware Exploit for all pre-Gingerbread phones - Epic 4G Android Development

[Patch][Rom]Malware Exploit for all pre-Gingerbread phones
Who is affected? All phones pre-gingerbread
Who should act? Users and developers using pre-gingerbread roms
How do I fix? Flash attached .zip at the bottom of this post or use one of the alternate methods down there
What if I think I was infected? Completely wipe your device, format sdard, go back to stock and re-apply rom, then flash the attached .zip (before installing any apps)
Why should I care? read below...
http://www.androidpolice.com/2011/0...your-phone-steal-your-data-and-open-backdoor/
Link to publishers apps here. I just randomly stumbled into one of the apps, recognized it and noticed that the publisher wasn’t who it was supposed to be.
Super Guitar Solo for example is originally Guitar Solo Lite. I downloaded two of the apps and extracted the APK’s, they both contain what seems to be the "rageagainstthecage" root exploit – binary contains string "CVE-2010-EASY Android local root exploit (C) 2010 by 743C". Don’t know what the apps actually do, but can’t be good.
I appreciate being able to publish an update to an app and the update going live instantly, but this is a bit scary. Some sort of moderation, or at least quicker reaction to malware complaints would be nice.
EDIT: After some dexing and jaxing, the apps seem to be at least posting the IMEI and IMSI codes to http://184.105.245.17:8080/GMServer/GMServlet, which seems to be located in Fremont, CA.
I asked our resident hacker to take a look at the code himself, and he’s verified it does indeed root the user’s device via rageagainstthecage or exploid. But that’s just the tip of the iceberg: it does more than just yank IMEI and IMSI. There’s another APK hidden inside the code, and it steals nearly everything it can: product ID, model, partner (provider?), language, country, and userID. But that’s all child’s play; the true pièce de résistance is that it has the ability to download more code. In other words, there’s no way to know what the app does after it’s installed, and the possibilities are nearly endless.
Click to expand...
Click to collapse
The offending apps from publisher Myournet:
* Falling Down
* Super Guitar Solo
* Super History Eraser
* Photo Editor
* Super Ringtone Maker
* Super Sex Positions
* Hot Sexy Videos
* Chess
* 下坠滚球_Falldown
* Hilton Sex Sound
* Screaming Sexy Japanese Girls
* Falling Ball Dodge
* Scientific Calculator
* Dice Roller
* 躲避弹球
* Advanced Currency Converter
* App Uninstaller
* 几何战机_PewPew
* Funny Paint
* Spider Man
* 蜘蛛侠
Click to expand...
Click to collapse
http://www.androidpolice.com/2011/0...-android-nightmare-and-weve-got-more-details/
Now, on to some more details of the virus. We should point out that this vulnerability was patched with Gingerbread, meaning any device running Android 2.3+ should be fine. In other words, if you’re looking to play the blame game (which I’m not, but having read all the comments on the original post, many people are), then there’s plenty to go around. The hole was fixed by Google, but it’s relatively useless since many phones aren’t yet running a version of Android that is protected. It’s noteworthy that some manufacturers released updates that patched the exploit for devices without updating to Gingerbread; unfortunately, it appears that minority is quite a small one.
Perhaps most important is the question of what infected users can do about their situation; unfortunately, the answer is not much of anything. Because the virus opens up a backdoor and can bring in new code at any time, the only way to really rid an infected device of any damage is to completely wipe the device – not exactly the optimal solution, but it looks like the only one available, at least for now.
Finally, Justin notes that ROM developers working with pre-Gingerbread versions of Android can prevent the virus from backdooring in code by putting a dummy file at /system/bin/profile.
Click to expand...
Click to collapse
As you can see androidpolice.com reports on this backdoor and roots and steals personal information. The apps are removed from the market but that doesn't mean they got them all. Attached is a flashable fix as suggested by androidpolice.com
So users can flash this .zip or simply create a blank file called profile and place it in /system/bin/ (developers are encouraged to include this file in future releases. A blank file is not going to affect performance at all)
Alternate methods:
Using 'adb shell' or terminal emulator (should work on any ROOTED phone) as suggest by xaueious here
Code:
$ su
su
# remount rw
Remounting /system (/dev/stl9) in read/write mode
# touch /system/bin/profile
# chmod 644 /system/bin/profile
#
Alternate 2:
Download blank profile file from here (or create one and name it profile)
Use a program like Root Explorer to copy it to /system/bin/
Then longpress on it and check the permissions should be read/write for user, read for group, and read for others.
Alternate 3:
cyansmoker has put together an apk for the patch here https://market.android.com/details?id=com.voilaweb.mobile.droiddreamkiller
Thanks for pointing this out photoframd and androidpolice.com for investigating and reporting!
UPDATE: I renamed the .zip file and reuploaded it (350 hits wow). Also in the edify scripted version I added 644 permissions to the file (but if you already flashed it then it should have defaulted to that). I also added a pre-edify version of the patch thanks to xaueious for people using a recovery that does not yet understand edify.

Rodderik - very useful, thanks much. This will be in SyndicateROM Frozen 1.0.1.
EDIT: Between this and CIQ removal, we devs have malware removal/prevention covered.

Does Superuser provide a layer of protection against this exploit also?
Sent from my SPH-D700 using Tapatalk

mattallica76 said:
Does Superuser provide a layer of protection against this exploit also?
Sent from my SPH-D700 using Tapatalk
Click to expand...
Click to collapse
i wouldn't count on it...i've tried to root the epic using rageagainstthecage without the use of a computer and got no where with it because the only exploit that works for root is an adb bug (that doesn't mean it cannot be done!!!). but it is technically possible that malicious software once installed can install a modified version of superuser or do anything else it want's without the user's knowledge...so I wouldn't count on superuser protecting you.

So, let me understand this.
Are the Apps you download from the official Google app store stored by google or the developers?
If it's stored by Google, how in the world can they not be automating checking for apps like this?
This sounds kind of lame for a company with $11billion dollars in the bank.
Unless apps aren't stored by Google? And if they aren't, why doesn't Google tell you that when you download an app?

DAvid_B said:
So, let me understand this.
Are the Apps you download from the official Google app store stored by google or the developers?
If it's stored by Google, how in the world can they not be automating checking for apps like this?
This sounds kind of lame for a company with $11billion dollars in the bank.
Unless apps aren't stored by Google? And if they aren't, why doesn't Google tell you that when you download an app?
Click to expand...
Click to collapse
apps are stored by google but i dont blame them for stuff like this. google doesn't dissect every single piece of code that gets pushed to the market. it wouldnt be very cost effective for them or motivational for software developers....after all we dont want the android market becoming like apple's store do we?

So this patch (zip) can be applied via CWM3 just like anything else, right?

brickwall99 said:
So this patch (zip) can be applied via CWM3 just like anything else, right?
Click to expand...
Click to collapse
correct
10char

I'm pretty sure I'm in the clear, but this should prevent some future attacks, correct?
And any idea of phone compatibilities, ie MT4G? If you don't know I can flash it and let you know, but if it doesn't work there's no point in trying. Thanks in advance!
Edit: I guess it doesn't matter anyways, I could just create the blank folder. My bad... but thanks.
Sent from my HTC Glacier (Rooted, Stock ROM, Faux123's Kernel) using XDA App

eliasadrian said:
I'm pretty sure I'm in the clear, but this should prevent some future attacks, correct?
And any idea of phone compatibilities, ie MT4G? If you don't know I can flash it and let you know, but if it doesn't work there's no point in trying. Thanks in advance!
Sent from my HTC Glacier (Rooted, Stock ROM, Faux123's Kernel) using XDA App
Click to expand...
Click to collapse
from what i understand it applies to all pre-gingerbread phones that are exploitable by rageagainstthecage (but possibly others) it doesn't hurt anything to put an empty file called profile in /system/bin/ if it prevents the current malware from doing it's damage just to be safe

Thanks for the info, but I don't quite understand what putting an empty file named profile in the bin folder would do.
I'm not seeing any special permissions being set or anything.
How is this fix effective? Couldn't the "malware" simply overwrite the blank file?
I don't get it.
=]
-ps I haven';t taken the time to read through the linked source, so forgive me if this has been explained.

Anyone know exactly what that profile file flags in the OS?
edit: looks like this is a fix for this particular strain only.

the fix is based off of Justin's suggestions in the link...what is to stop future versions of this malware from ignoring this file in the future? nothing! but for now Justin over at andoidpolice.com has combed through the known infected apk files and provided us with this fix and info....i would read the 2 articles quote in the OP for all the goodies
the empty profile file shouldn't affect anything in the market or otherwise....i'm assuming the malware checks if that file exists and if it does then it doesn't try to run but this is speculation on my part. if i need to i can get some more information if the links in the OP don't answer your questions

My guess is that it tries to extract then run a file named profile, and adding the blank might prevent it from working

Would it be safe to assume that if you look in your system/bin directory and already have a file named profile than you have been infected?
Instead of flashing, using Root Explorer could I just create a file named "profile" in the system/bin directory for a fix?
Anyone think an android AV program like Lookout would have caught this if running when the infected app was installed?

rayburne said:
Anyone think an android AV program like Lookout would have caught this if running when the infected app was installed?
Click to expand...
Click to collapse
I suspect it would.

rayburne said:
Would it be safe to assume that if you look in your system/bin directory and already have a file named profile than you have been infected?
Click to expand...
Click to collapse
It is quite possible. Check and see if you installed any of the programs lately from the OP. If so then it is quite possible. It is also quite possible a rom developer put that file in there so that is not a 100% way of making sure.
rayburne said:
Instead of flashing, using Root Explorer could I just create a file named "profile" in the system/bin directory for a fix?
Click to expand...
Click to collapse
Yes indeed!
rayburne said:
Anyone think an android AV program like Lookout would have caught this if running when the infected app was installed?
Click to expand...
Click to collapse
Here is more from the articles I posted
Wow – from our perspective, it’s almost like the world exploded overnight. We have more information and details on the virus – which Lookout has named "DroidDream" (the word was consistently used in package names by the malware developers) – and some updates on where things stand.
Click to expand...
Click to collapse
So I'm assuming that means Lookout scans for or will soon scan for this malware.

Does the file prevent the root exploits from running?
I am not sure if your update.zip actually works, unless you are sure that the file is created with the correct file permissions. I'll test it in a minute. I don't know if your updater script is universal either:
Code:
ui_print("**Installing**");
ui_print("**Mounting Partition**");
run_program("/sbin/mount", "/dev/block/stl9", "/system");
ui_print("**Copying System File**");
package_extract_dir("system", "/system");
ui_print("**Unmounting Partition**");
unmount("/system");
ui_print("**Installation Successful**");
Can someone elaborate more on why this works, if it works?
It takes 10 minutes to throw this into an APK fix on the Market for rooted users, which works better than update.zip.
adb remount
adb shell touch /system/bin/profile
adb shell chmod 644 /system/bin/profile

I ran the patch using clockwork, how do I know if it worked?
The only app I may have downloaded from that list is chess, but I doubt I did install that.
Most of those other apps have keywords I STAY AWAY FROM for this very reason lol!

I redid the update.zip in OP.
Forgot attachment.
Code:
show_progress 0.1 0
copy_dir PACKAGE:system SYSTEM:
show_progress 0.1 10
show_progress 0.2 0
set_perm 0 0 0644 SYSTEM:bin/profile
show_progress 0.2 10
This should work on more devices. Test signed.

Related

[How To] Install AmazonMP3 on Haykuro, Dude's, and JF's Firmware

Hi everyone, as many of you guys have noticed, the newer firmwares do not come with the Amazon MP3 application. For those of you who want this, here is a tutorial on installing.
First, download the com.amazon.mp3.zip file uploaded, and place it on your desktop. DO NOT OPEN IT OR EXTRACT IT. Change .zip extension to .apk. For those of you who do not know how to do that, hit Start> My Computer> Organization> Folder and Search Options> and Uncheck "Hide Extentions for Known File Types". Then, delete the .zip extension and type in .apk. Have your G1 ready and plugged in, as you will be using ADB to install this program.
Open up command prompt and type:
cd desktop
adb install com.amazon.mp3.apk
exit
It should now be installed!
For those of you who do not have ADB installed for whatever reason, place the com.amazon.mp3.apk onto your SDcard. Then, using a file manager on your G1 (I use OIfilemanager) navigate to the location where the file is placed and install.
Also, the com.amazon.mp3.apk can also be extracted directly from RC and JF 1.4x builds.
NOTE TO MODS: I understand that Amazon MP3 is not an open source application. Therefore, if for any reason if you guys do not feel that uploading this apk is allowed, feel free to remove this post.
Paying $1 per mp3 can add up over time
With RC 33 i wanted to removed this program, now that JF 1.50 removed automatically, do you believe that i will tried this? But thanks anyway...
PS- People DL music MP3's on theirs PC' for free, Amazon Sucks!
Sometimes I find Amazon MP3 useful for previewing a CD while I am at the library.
By the way, there is no need to distribute the apk here when anyone can just extract it themselves legally from an official update.zip
jashsu said:
Sometimes I find Amazon MP3 useful for previewing a CD while I am at the library.
By the way, there is no need to distribute the apk here when anyone can just extract it themselves legally from an official update.zip
Click to expand...
Click to collapse
Yeah I understand that, I'm just saving them the trouble of having to do it themselves. However, when you say "legally" do you mean distributing this apk is illegal? If so I will remove it.
SolemnWishing said:
However, when you say "legally" do you mean distributing this apk is illegal? If so I will remove it.
Click to expand...
Click to collapse
It's not expressly forbidden. The general stance on xda is as long as the software in question isn't payware, then it is okay (of course a mod is free to make a judgement otherwise). However, everyone should have a RC33 or somesuch build lying around that they can extract the file from themselves anyway.
Seems that most folks don't appreciate the usefulness of Amazon MP3 as a source of track preview. I just wish that it still integrated into ShopSaavy and CompareEverywhere. Used to be you could scan a barcode of a CD and it would pull up the CD on Amazon MP3. If anyone knows how to make this work with current software versions, let me know.
Thank you for the explicit directions. This worked great on my G1 and my friend's using a mac.
Well, I guess that means we will wait for a mod to say something... next in line.. PDFviewer.
Okay, PDFviewer will not work on my JF1.50 build. Just for fun I also tried to push the H build camera and the H build dialer. The pushed camera resulted in the camera app disappearing all together along with the camcorder, gallery and picture frame widget. The H build dialer caused the phone to be completely unresponsive.
Remember, always use a Nandroid backup when attempting risky procedures
SolemnWishing said:
Well, I guess that means we will wait for a mod to say something... next in line.. PDFviewer.
Okay, PDFviewer will not work on my JF1.50 build. Just for fun I also tried to push the H build camera and the H build dialer. The pushed camera resulted in the camera app disappearing all together along with the camcorder, gallery and picture frame widget. The H build dialer caused the phone to be completely unresponsive.
Remember, always use a Nandroid backup when attempting risky procedures
Click to expand...
Click to collapse
If you want to extract features from Haykuro's H build for 1.50 installation, I suggest you hook up ddms so you can get realtime debugging and see what libraries/functions are being called that are causing problems. It should work in the emulator too.
By the way PDFViewer's dependencies have been well established, but the program checks some unknown properties of the build and will refuse to run for non-HTC builds. Decompiling the dex might lead to clues as to what it is and how to workaround it or patch the apk. I'm actually hoping it will just run unmodified on the official T-Mo 1.5 rom expected any day now.
jashsu said:
If you want to extract features from Haykuro's H build for 1.50 installation, I suggest you hook up ddms so you can get realtime debugging and see what libraries/functions are being called that are causing problems. It should work in the emulator too.
By the way PDFViewer's dependencies have been well established, but the program checks some unknown properties of the build and will refuse to run for non-HTC builds. Decompiling the dex might lead to clues as to what it is and how to workaround it or patch the apk. I'm actually hoping it will just run unmodified on the official T-Mo 1.5 rom expected any day now.
Click to expand...
Click to collapse
hehehhe! We can always dream can't we...
lol HTC dream.. well, I do not know how to work apps, or port them or anything, so that is pretty much out of the question. Ill just stick with the obvious ones.
Much thanks!! I wanted Amazon back.
thanks
works on JF flawless. no issue yet. Thanks.
I installed the Amazon MP3 apk night before last and found that the search function wouldn't open its search box. I uninstalled and then pushed it to /system/app via adb and now it works just fine. FWIW, I have apps on SD (the symlink version).
That is good, and does anyone know if the Teeter game from the original Haykuro H build requires some sort of special resource or something? As the game installs, but force closes on startup.
thank you very much for this... anybody got a fix for myfaves???
jashsu said:
If you want to extract features from Haykuro's H build for 1.50 installation, I suggest you hook up ddms so you can get realtime debugging and see what libraries/functions are being called that are causing problems. It should work in the emulator too.
By the way PDFViewer's dependencies have been well established, but the program checks some unknown properties of the build and will refuse to run for non-HTC builds. Decompiling the dex might lead to clues as to what it is and how to workaround it or patch the apk. I'm actually hoping it will just run unmodified on the official T-Mo 1.5 rom expected any day now.
Click to expand...
Click to collapse
hehehe. the properties aren't unknown. It's a library, and 2 framework files.
TheDudeOfLife said:
hehehe. the properties aren't unknown. It's a library, and 2 framework files.
Click to expand...
Click to collapse
So you have PDFViewer working without the "Only for HTC devices" nag screen?
Haha mind enlightening us??
someone run some diffs on thedudes libs and framework files =P!

To "ROM" cookers: How to avoid receiving a C&D letter...

The answer is simple: do not include any non-open source apks or code that you have not explicitly received permission to distribute.
Instead, after building your entire update.zip, strip out all the proprietary software. Then, create a .bat and/or .sh file that will perform the following tasks:
- Download the official update.zip from the google.com site.
- Extract the required apks, obexes and jars.
- Add them to the correct locations in your update.zip
- Sign the update.zip (so include signapk.jar with your script)
- Rename the file update.zip
Name your zip as "incomplete-update.zip" (or something of the sort) and include your completer script with the file. Users will run the script and receive a complete update.zip as you had intended to distribute. THAT'S IT! A completely license-abiding way to distribute cooked "roms" without infringing on Google's licenses.
I wish google or HTC would contact me, I would say huh, what, me no speak spanish.... lol
Only if that would actually stop lawyers. God I hate lawyers. If that defense worked MMOGlider.com would still be working.
TheArtiszan said:
Only if that would actually stop lawyers.
Click to expand...
Click to collapse
It would, atleast in this case.
TheArtiszan said:
Only if that would actually stop lawyers. God I hate lawyers. If that defense worked MMOGlider.com would still be working.
Click to expand...
Click to collapse
Glider actually had a detrimental effect to the community, these mods don't. Horrible comparison.
afflaq said:
Glider actually had a detrimental effect to the community, these mods don't. Horrible comparison.
Click to expand...
Click to collapse
One man's detriment is another man's free market. It's a tough question.
Disclaimer: I hated MMOGlider and the people who use it, and wish they would've died in car crashes.
jashsu said:
The answer is simple: do not include any non-open source apks or code that you have not explicitly received permission to distribute.
Instead, after building your entire update.zip, strip out all the proprietary software. Then, create a .bat and/or .sh file that will perform the following tasks:
- Download the official update.zip from the google.com site.
- Extract the required apks, obexes and jars.
- Add them to the correct locations in your update.zip
- Sign the update.zip (so include signapk.jar with your script)
- Rename the file update.zip
Name your zip as "incomplete-update.zip" (or something of the sort) and include your completer script with the file. Users will run the script and receive a complete update.zip as you had intended to distribute. THAT'S IT! A completely license-abiding way to distribute cooked "roms" without infringing on Google's licenses.
Click to expand...
Click to collapse
This would work. But, it seems to me you could also take a similar approach that works like this:
1) Strip the proprietary code out of the update before signing.
2) Sign and distribute the update.
3) People install the update and return to the recovery screen.
4) Drop into terminal mode and run a script that downloads and installs the missing proprietary code in the proper places.
5) Reboot and enjoy.
Any reason that wouldn't work equally well (but be somewhat simpler)?
stellarman said:
This would work. But, it seems to me you could also take a similar approach that works like this:
1) Strip the proprietary code out of the update before signing.
2) Sign and distribute the update.
3) People install the update and return to the recovery screen.
4) Drop into terminal mode and run a script that downloads and installs the missing proprietary code in the proper places.
5) Reboot and enjoy.
Any reason that wouldn't work equally well (but be somewhat simpler)?
Click to expand...
Click to collapse
It doesn't seem like it would be a good idea to boot into the OS with major parts missing (esp stuff like framework.apk). However, if it can be worked around then yes, that would be a method too. Any variation on the theme of "partial update.zip plus files from a locally downloaded official update" would be good.
Is it more work to do this than just to distribute a fully complete (but not license compliant) update.zip? Yes. But it not only protects the cook from being C&D'd, it also helps to legitimize the "ROM" cooking scene.
You are still distributing the the unlicensed files, you are just providing a different way to distribute them. instead of including them directly in your ROM, you are supplying a script that adds them to your ROM.
Man all this is too much.... I might get rid of my G1. Google is always trying to ruin the good things for us. -__-"
jashsu said:
It doesn't seem like it would be a good idea to boot into the OS with major parts missing (esp stuff like framework.apk)
Click to expand...
Click to collapse
The framework.apk is APL and part of the Android source. To see what you get without the Googlebits, just run the emulator.
I think the easiest is to have the updater copy the proprietary bits from the phone to your SD card, perform update, then copy back. then reboot.
jashsu said:
It doesn't seem like it would be a good idea to boot into the OS with major parts missing (esp stuff like framework.apk). However, if it can be worked around then yes, that would be a method too. Any variation on the theme of "partial update.zip plus files from a locally downloaded official update" would be good.
Is it more work to do this than just to distribute a fully complete (but not license compliant) update.zip? Yes. But it not only protects the cook from being C&D'd, it also helps to legitimize the "ROM" cooking scene.
Click to expand...
Click to collapse
Read my post again. I am not suggesting that you try to boot without the parts. I am saying to use the terminal WITHIN Recovery. Do the step of re-adding the proprietary bits BEFORE you leave Recovery and reboot.
Actually people, let's not forget that perhaps Cyanogen had to modify some closed-source apps like Market and Camera on several occasions, right? To avoid crashes due to resource-id changes?
So just downloading older binaries might not always work?
--Tim
I sent a twitter to Cyanogen about this last night. Downloading every time would be slow and a waste of bandwidth. I think you could do it one of two ways.
1) add a script to cm-recovery that is executed with ALT+G the extracts the apks, etc from an official google dist file on the sdcard and copy them to the proper locations.
2) add a script (which does the extraction, etc. from a zip on the sd) someplace into update.zip. cm-recovery looks for that script and if it exists then it will automatically execute after the normal update routine is complete
3) a combination where the script is in update.zip but the users has to hit ALT+G to execute it.
I think #2/#3 would be most flexible because you wouldn't have to change recovery image for different ROMs and all ROM developers could have a custom script in their update.zip to fit their needs.
rewrite those applications if they haven't already been rewritten in one way or another many dialers, a couple marketplaces, youtube, all the apps could be developed just like messenger and browser come on lets just get around google and create the missing apps
kanstin said:
I sent a twitter to Cyanogen about this last night. Downloading every time would be slow and a waste of bandwidth. I think you could do it one of two ways.
1) add a script to cm-recovery that is executed with ALT+G the extracts the apks, etc from an official google dist file on the sdcard and copy them to the proper locations.
2) add a script (which does the extraction, etc. from a zip on the sd) someplace into update.zip. cm-recovery looks for that script and if it exists then it will automatically execute after the normal update routine is complete
3) a combination where the script is in update.zip but the users has to hit ALT+G to execute it.
I think #2/#3 would be most flexible because you wouldn't have to change recovery image for different ROMs and all ROM developers could have a custom script in their update.zip to fit their needs.
Click to expand...
Click to collapse
Anything that requires a user to press more keys is dumb. The problem Google has is that their apps are being redistributed by rom makers.
Lets take a look at how Google circumvents the same restrictions for HTC binaries: http://source.android.com/documentation/building-for-dream
Remember they are advocating circumventing HTC's proprietary licenses by running a script to copy these files. We need to do the same thing, and as long as we are coping the files, using the phone as the SOURCE, the process can be transparent to the user.
Edit:
Also has anyone thought about the fact that HTC proprietary files are being redistributed also? The phones are UNUSABLE without these files.
fauxhawk said:
Anything that requires a user to press more keys is dumb.
Click to expand...
Click to collapse
Yeah, it is dumb. Option #2 runs the script automatically and and Option #3 requires pressing ALT+G. Option #3 is in case the lawyers get really nasty; there is no way they can say that option is in violation because it requires user intervention (pressing ALT+G).
would this approach at distribution impact the optimization and tight fit of the ROM?
This is pretty much the same idea I had last night.
http://forum.xda-developers.com/showthread.php?t=564303
camalot said:
You are still distributing the the unlicensed files, you are just providing a different way to distribute them. instead of including them directly in your ROM, you are supplying a script that adds them to your ROM.
Click to expand...
Click to collapse
But you are not distributing these files. The update.zip you supply has absolutely no intellectual property which you are not entitled to distribute. Even the script, the IPR for it would be with the dev who write it. Now it might well be illegal - and personally I'd debate whether it is, but let's leave that for now - to *RUN* that script. But that's not the dev's concern and everything he supplied would be his own IPR.
Say you had a friend who worked for Google. It's the same as the difference between this friend emailing you a copyrighted MP3, versus you using Google to search for the same MP3 and then clicking on a link that appears. In the latter case Google hasn't distributed anything - they've merely provided the means for you to find the file on-line. YOU are then the one who breaks the law by downloading it. In the former case, it's your friend - and possibly Google as the people who provide the email system - who break the law.
Any dev who provided a script to download what is needed from a place on the internet and extract them from a zip would be very difficult to C&D.

Install App From another Android?

I got my self the hero, and my wife the Moment. I am slightly jealous of the hardware she has..but that aside, I am in love with my Hero.
However, she does have one app that i really want and the market place does not have. I assume this is an app installed by sprint.
It is Photo and Video uploader. You set an email address or other location and after a video or photo is taken, it automatically uploads the photo to the predetermined destination. GREAT FOR BACKING UP PICTURES! But, her camera hardware blows. 3.2 MP and it is sooo slow. So picture quality is no where near that of the Hero's 5 MP.
So the real question here - -
Can I ADB into her phone and just take the .APK and ODEX file for this app and push it to my phone? Is it that easy???
Some apps are that easy. Give it a try and find out! The worst thing you'll get is some force closes.
However most stock apps require files from /system/lib that help run that apk. And they don't have the same naming convention therefore you won't know which one(s) it is amongst the 100s there. But I always say try and see what happens.
And if it works upload that .apk for the rest of us!
Thinking out loud here...well..you get the point.
Could I copy all of system/lib and only copy the files that dont already exist?
That could be a giant waste of space though, and it could still rely on a file that I have, not just one that isn't there....
Also since I am not "installing" the app, could Apps2SD hinder me? I am not entirely sure how a2sd works other than tricking the phone into using the SD card as a partition and unioning it with the existing part.
I love how open android is supposed to be, but how the darn manufacturers kill us with the different platform crap.
thedudejdog said:
And if it works upload that .apk for the rest of us!
Click to expand...
Click to collapse
Am I aloud to do that? I have seen XDA Mods get on to some people about uploading APK's. I guess I should read the EULA for that app before I do?
Kcarpenter said:
Thinking out loud here...well..you get the point.
Could I copy all of system/lib and only copy the files that dont already exist?
That could be a giant waste of space though, and it could still rely on a file that I have, not just one that isn't there....
Also since I am not "installing" the app, could Apps2SD hinder me? I am not entirely sure how a2sd works other than tricking the phone into using the SD card as a partition and unioning it with the existing part.
I love how open android is supposed to be, but how the darn manufacturers kill us with the different platform crap.
Click to expand...
Click to collapse
Copying the ../lib/ over and not replacing existing files could work. lol. As for apps2sd... you kind of have two ways you can try installing this. Without copying the lib and all that just try putting the apk on to your sdcard and browsing to it using astro or linda (a file manager) and click on the apk and installing it. See if it errors out or fails. If it does, THEN try copying it and the odex to /system/app (if it has an odex I'm pretty confident you won't be able to install it using package manager). If that still fails then you can go crazy and trying copying the lib ha.
Kcarpenter said:
Am I aloud to do that? I have seen XDA Mods get on to some people about uploading APK's. I guess I should read the EULA for that app before I do?
Click to expand...
Click to collapse
I don't remember if I read it on here or ppcgeeks but I believe officially the only stock apk's not allowed is quick office. But don't quote me on that.
So I hooked up to the Moment through ADB last night.
Found out really quickly that I can SU with it....
There is a "non permanent" hack out there to become root, but I tried it and still couldn't mount the file system to copy from it.
Any ideas guys?
From what I understand the Moment uses an FS16? file System? Something Odd that non of the other droids seem to be using.
Just an Idea, thought I would throw it out there.
Does the temporary root allow for running applications as root an the device itself?
There is an app in the market called root explorer that allows copy/paste/cut/delete from the system/app folder.
It may be possible to use that app to copy the needed filed to your sdcard and then extract them from there.
This would all be contingent on the app being able to mount the directory as r/w though, so who knows, worth a shot though i guess.
rockcrawler said:
Just an Idea, thought I would throw it out there.
Does the temporary root allow for running applications as root an the device itself?
There is an app in the market called root explorer that allows copy/paste/cut/delete from the system/app folder.
It may be possible to use that app to copy the needed filed to your sdcard and then extract them from there.
This would all be contingent on the app being able to mount the directory as r/w though, so who knows, worth a shot though i guess.
Click to expand...
Click to collapse
This root doesn't allow you to run Root apps. not sure why, seems like root would be root.
After some reading, the root method that is being used on the Moment is not the safest. Apparently if you skip a step you have a brick. And with no Nandroid backup at the moment(pun?) I would HATE to attempt it. Apparently though Root sticks until you reboot. There is an INit. script that runs and resets the permisions.
I know, "Don't skips steps and you'll be ok"
I may get brave and try it tonight...
as far as I can tell you cannot install this app on the hero. I'm not sure what the app is called and unless it starts in the /data folder it is under the system dumps
http://www.4shared.com/file/149766091/c3a7ee61/momentsystem.html
nelson8403 said:
as far as I can tell you cannot install this app on the hero. I'm not sure what the app is called and unless it starts in the /data folder it is under the system dumps
http://www.4shared.com/file/149766091/c3a7ee61/momentsystem.html
Click to expand...
Click to collapse
ROCK ON! Thanks for the link to the dump, I hadn't thought about looking around in one of these.
I will post what I find out.
WOOT IT WORKS!!!!!
So any how the application is in that Dump under apps, its only an APK
xms-android-1.0.42-prod.apk
If you are interested in what it does:
You setup predetermined "places" Flikr, FB, EMAIL, what ever.
Any picture or video you take automatically gets put in an upload queue and it sent to your predetermined places.
I am using it for back up, I have 2 kids and sometimes the cell phone is the quickest way to snap a great picture. Keeping these pictures in mutltiple places, like your 7 gig google account, is a nifty way to backup.
I am waiting for a Mod to get back to me if I can post the APK or not. I don't want to get in trouble.
wonder if their youtube app has better picture quality than ours?
BrianDigital said:
wonder if their youtube app has better picture quality than ours?
Click to expand...
Click to collapse
I will let you know in a few minutes. As soon as I get done with my WiFi teether I will compare the two. Pretty sure they should be the same.
EDIT: I am not sure if it is hardware or not. Running the same youTube video side by side - Our HERO has better color quality, Deeper blacker. The Moment has slightly sharper edges to the pictures, not quite as blurry. the moment does not go "Full Screen" for videos either which could be contributing to the sharper look to things. My assumption would be that this is a difference in the hardware. Quality of youTube videos seems to have diminished over the years anyways, none of the really look "good" any more. Probably in an effort to save bandwidth.
However, if you want to take a look personally, I will post the APK for you. Just please don't blame me if you forget to back up the original and want to revert....I love disclaimers.
I was trying to use that picture uploader, for me it stalls on picking a new location. Wonder if it is because I am on gutted rom and missing some pointers somewhere
BrianDigital said:
I was trying to use that picture uploader, for me it stalls on picking a new location. Wonder if it is because I am on gutted rom and missing some pointers somewhere
Click to expand...
Click to collapse
I am using MoDaCo + Optimizations w/ ZipAlign. Not sure if its worth the switch for you or not.
I have never used Gutted so I do not know what it offers/doesn't have.
Gutted is as vanilla as our Rom can get. It's quick too
that's pretty cool and sounds like a great idea for backing up pics so what all would I need to do to get this and install it I have root access already
Kcarpenter said:
WOOT IT WORKS!!!!!
So any how the application is in that Dump under apps, its only an APK
xms-android-1.0.42-prod.apk
If you are interested in what it does:
You setup predetermined "places" Flikr, FB, EMAIL, what ever.
Any picture or video you take automatically gets put in an upload queue and it sent to your predetermined places.
I am using it for back up, I have 2 kids and sometimes the cell phone is the quickest way to snap a great picture. Keeping these pictures in mutltiple places, like your 7 gig google account, is a nifty way to backup.
I am waiting for a Mod to get back to me if I can post the APK or not. I don't want to get in trouble.
Click to expand...
Click to collapse
Wow... that's a really cool program... and just so you know, you can "install" it using adb and it still works fine
Code:
adb install xms-android-1.0.42-prod.apk
Then it will install in /data/apps (or if you have apps2sd, on the sdcard under /system/sd/apps)
Works great on the Sprint Hero and MoDaCo ROM
Kcarpenter said:
I am waiting for a Mod to get back to me if I can post the APK or not. I don't want to get in trouble.
Click to expand...
Click to collapse
The only rule regarding it would be
6. Do not post warez.
If a piece of software requires you to pay to use it, either pay or find your cracks and serials somewhere else. We do not accept warez nor do we permit any member to promote or describe ways in which Warez, cracks, serial codes or other means of avoiding payment, can be obtained.
Click to expand...
Click to collapse
which your app doesn't fit in to. Posting it is not outside of the rules and should be fine.

[Q] Disabling Android 2.2 DropBoxManager

Good Day Folks.
I'm a Noob in need of help and i'm hoping the more experienced among us might be able to assist. I have an issue with disappearing phone storage. Over the course of a week I realized that I was losing about 1MB a day. My phone would basically be dormant and I would still see my storage space dropping by this amount everyday.
Cache cleaning didn't work. Later I realized that Android creates a bunch of log files in Data/System/Dropbox that was responsible for the disappearing phone storage trick I've been seeing for a while now.
I know now that Google has incorporated into Android as of the 2.2 iteration, a DropBox Manager that's responsible for logging all of the events that take place during the course of a running Android session. Everything from what took place at boot to force close details.
I understand that this is used for debugging purposes but I'm no developer . So my question is.... Can this DropBox Manager be disabled....somehow.
I really don't need all these files (and its A LOT OF THEM) being created as they serve no practical purpose for me. Not sure if anyone else might have noticed this but I'm hoping to receive some help. Even if it means pointing me in the right direction so I can work on it myself.
I really don't have a clue on how to start. Any help will be appreciated....Seriously...
Currently using G1 with CM6 Magpie running on EZTERRY's 2.6.34.7 kernel.
Its perfect except for this annoying problem.......
Hm what happens if you rename the directory. It might throw some errors in the logger, but probably won't create anymore files.
I just deleted the content of my dropbox folder, the DropboxManagerService was throwing some errors that he could not open files, but the phone was fine, no FCs or anything.
Renaming the directory just results in a random reboot. My guess is that when Android tries to create a new log, its unable to find the directory and then it just freezes and after a while it reboots. Once restarted it just reappears... I've tried that too.
And its true.. Its ok to delete the files. Its what I do currently. All of those files in Data/System/Dropbox as well as the ones located in Data/Tombstones are ok to delete. As I said, its just used for debugging purposes. Whats really annoying though is that, no matter how many times you delete anything, they just get repopulated just as fast as they're deleted. I'm ok with micro-managing my memory and phone storage (its a G1 after all) but this is ridiculous. It just creates too many of these log files too quickly.
If there was a way to turn the DropBoxManager service off then that would be the end of it all.
What's unusual about it too is that in my particular case, the contents of these text files just have two things listed in them. Pertaining to my online accounts associated with the phone: My Google account and My Whatsapp account...
It just repeats the same thing over and over again. I'm starting to think that the event data might actually be synchronization data or at least synchronization attempts made at regular intervals. But ultimately i'm guessing....
I really don't have a clue... Have you ever heard of anything like this on XDA......possible resolutions of this issue?
epolaris said:
I really don't have a clue... Have you ever heard of anything like this on XDA......possible resolutions of this issue?
Click to expand...
Click to collapse
Not yet .
What about replacing the folder by a symlink to /dev/null ?
You could also try to change permission on the folder.
Ok... I'm a real Noob but I'll take a shot.. When you say symlink what do you mean.
I'm not really familiar with Android at that level yet its really just flashing and such.
But I know a symlink is really just a reference to a location that the OS would interpret and follow (like a pointer i think). So, is it that you're suggesting some sort of redirection where the Data/System/Dropbox directory is pointed to another arbitrary location. Kind of like a creating a dead link that Android is unable to follow up on. Or maybe, redirecting the folder to an entirely new location that Android would then follow. I'm not sure... How do you perform a symlink in Android... I'm willing to try.
You can do it with a console on the phone it self or using adb shell. You need root of course.
You could make a link to another location where you have more space?
Or you change to permissions of that directory to write only.
Or you can mount a different file system to that directory that is read only.
On how to do that just google a bit for linux tutorials on that topic.
I have just googled a bit and it seems you can't symlink directories to /dev/null.
If all that doesnt help post again, there might be an option to make an app delete the files automaticly, first time they get created.
If that would be an option too let me know, im in the mood to program something intresting .
Disabling Android 2.2 DropboxManager [RESOLVED]
I took your advice and did the research you suggested and it worked.
The first thing I tried was changing the permissions on the "Data/System/Dropbox" directory and it worked. But I didn't use CHMOD and console command line to do it.
I have a program called Root Explorer that allows me to permanently change the permissions on any file or folder I select. I set all of the offending folders to read only and the log files stopped being written to those folders.
These are the directories I set to read only:
1. "Data/System/Dropbox"
2. "Data/System/UsageStats"
3. "Data/Tombstones"
Since changing the permissions on these folders my phone storage has stopped dwindling out of control. No additional programming necessary
Disabling the DropBoxMangerService itself is not necessary which is good.
I'm going to take your advice and read up some more on Linux commands (specifically Ubuntu as its what I currently use).
You have been very helpful, thanks for the advice. If you have any ideas about Froyo ROMS (Maybe even Gingerbread ) I should try let me know.
Thanks again....
I have also found these files. They can take MUCH space in memory and nothing seems to delete them. I made the dropbox system folder RO but I think this is a bug. It should be reported to the dropbox team. Is there a bug report form somewhere? I did not find it... Just found the forum, QA,...
[edit]I reported it in the forum... Just see http://forums.dropbox.com/topic.php?id=41227 [/edit]
vax said:
I have also found these files. They can take MUCH space in memory and nothing seems to delete them. I made the dropbox system folder RO but I think this is a bug. It should be reported to the dropbox team. Is there a bug report form somewhere? I did not find it... Just found the forum, QA,...
[edit]I reported it in the forum... Just see http://forums.dropbox.com/topic.php?id=41227 [/edit]
Click to expand...
Click to collapse
You are mistaken: /data/system/dropbox, has NOTHING todo with www.dropbox.com !
See http://developer.android.com/reference/android/os/DropBoxManager.html
Dark3n said:
You are mistaken: /data/system/dropbox, has NOTHING todo with www.dropbox.com !
See http://developer.android.com/reference/android/os/DropBoxManager.html
Click to expand...
Click to collapse
Hey, just looked at your SD Maid app (looks cool).
So what do you know about /data/system/dropbox? I just read that htc uses the dir to store phone events which is then sent to the htc cloud of spying-on-your-ass. But since non-htc phones have this dir, is htc merely misusing the directory and it has other legit uses, or is this a directory we should try to keep cleaned out?
(I like the idea of changing perms so nothing writes to it if that's the case.)
600 MB additional free storage
Hi all
Just found a smart way to increase your Dropbox account with 600 MB:
1 Sign into your existing Dropbox account (or create a new account)
2 Goto https://www.dropbox.com/free
3 Follow instructions ... and voila 600 MB additional free storage
Mittaa said:
Hi all
Just found a smart way to increase your Dropbox account with 600 MB:
1 Sign into your existing Dropbox account (or create a new account)
2 Goto https://www.dropbox.com/free
3 Follow instructions ... and voila 600 MB additional free storage
Click to expand...
Click to collapse
Yay, nice to see you didn't read the thread at all.
This has nothing todo with dropbox.com
Yea other day I got the SD Maid, and the Pro version after I saw how handy it was. I too on my G1 (with 2.2) see that dropbox folder.. and lately Ive been thinking its causing my G1 to constantly reboot. When I look, it has 300+ files in it. So I clear that folder and seems to stop rebooting for a lil while.
Not sure what the deal is here however, been trying to find out. HOWEVER it only seems to reboot once its connected to the internet, so I am wondering if this is where it tries to upload and so. Not really sure. That and its hard to tell in logcat whats going on before it reboots.
Thanks
Excellent information. This works on my Sony Ericsson Xperia Pro MK16a, Rooted. Thank you so much. My best regards.
Try to change the permisions of the folder, I'm not sure if it would work but you could try ^^
Sent from my GT-I9001 using xda premium
All is ok
All was fine. The permissions :laugh:changed with root explorer. Thank you so much
Note completely disabled but only 1 file in the /data/system/dropbox folder with these Android shell commands (or use Sqlite3 editor):
content insert --uri content://settings/secure --bind name:s:dropbox_max_files --bind value:i:1
Or for Android 4.2+
content insert --uri content://settings/global --bind name:s:dropbox_max_files --bind value:i:1
settings put global dropbox_max_files 1
Reboot.
more dropboxmanager settings:
dropbox_age_seconds
dropbox_max_files
dropbox_quota_kb
dropbox_quota_percent
dropbox_reserve_percent
I've been using the advice from this thread to control this "dropbox" data collection directory for several years now until I updated to 9.0 and found that the folder and default permissions were restored after every reboot. Was irritating bc I can use root to modify /system but no longer have control over my own data partition Something is over-riding my root-user!!!
I tried different apps, TWRP's FM, adb, and almost gave up when init.d scripts wouldn't work either. init.d will work tho. A simple script to run
Code:
#!/system/xbin/sh
busybox rm -f /data/system/dropbox
at boot. You can probably chown and chmod if you want but I just deleted it. Just put it in your init.d folder and make sure you give it the correct permissions (root:shell -755), then immediately perform a soft reboot. Use hardware keys if you have to. You want the phone to go immediately OFF, no spinny wheels or "powering off" notifications. That's the only way I could get rid of the damn thing.
Anyway, I came across this thread while searching for a solution and thought I would add this in case any other paranoids like me are concerned about this mysterious "dropbox" directory. This will probably break any ability for google to troubleshoot your phone but I don't think that's real anyway. It's just spyware as far as I'm concerned.
p.s. (off-topic) Thanks @Dark3n I'm also a frequent SD Maid user btw and in case you happen to read this, I thought I might mention I intended to send a donation via your app the other day (i like to show love when ppl share badass works) but balked at the only available option for "pizza," not bc I don't appreciate it that much but I can afford a little every now and then. If you add a smaller option, "coffee" or beer or whatever, maybe even an outside of googlePlay option, BTC perhaps. I'd be happy to shoot a few dollars at you.

[TOOL] ApkSpy v1.8 - Resurrected (APK: view manifest on PC and/or Install APK via PC)

APKSPY - RESURRECTED​
First:
I want to thank @ido for the original application -- It was his idea (and his code I've hacked :cyclops and modified.
Second:
Since Ido seems not to be active anymore I'll re-publish the application here.
Unless for some reason Ido will specifically ask me to remove it.
The original post
ido said:
ApkSpy is a simple tool I hacked up tonight which allows you to easily view the manifest of an APK (screenshots attached - not up to date though) just by double clicking it. (It can even associate with the .apk filetype, yay!)
ApkSpy relies on the aapt.exe tool from the android SDK, so you must have that installed (or just copy aapt.exe from somewhere, that's the only file needed to run ApkSpy).
Click to expand...
Click to collapse
Third:
Requires Microsoft©® .Net Framework v4
(Kind of since I've done it some time ago and waited for Ido [the orignal developer] to respond and allow or disallow me to re-publish... So, I don't remember all the changes I've already done...)
v1.8.19 CHANGELOG:
Fixed some Date parsing function (zipped file with no time stamp) in ZipStorer (by @Jaime Olivares) maybe causing some of the error reported here...
v1.8 CHANGELOG:
Changed Icon - CONTRIBUTED BY @Jarmezrocks
Removed unneeded tabs (System, Batch Rename, Log)
Minimize / Maximized restored back
v1.7 CHANGELOG:
(Actually 4.1.7.870, but the first and the last parts are internally used :fingers-crossed:)
Try to automatically find adb.exe and aapt.exe in ApkSPY directory or in PATH variable: If failed finding any of the executables, the user is asked to manually locate them
(★ Currently the location is not saved... ★).
Check if the ADB server is running and Start or ask if to Restart ADB server
Tidy up the code
Refining the original libraries written by Ido related to ADB and AAPT
Some more minor code updates
Revised most of the "General" tab (other tabs ware not touched) of the UI:
Grouped and ordered controls on form
Added DropDown of devices attached (★ Not automatically updating upon plugging... ★)
Added some control over ADB actions
Added status bar that some other details are shown, e.g. device type (Nexus, I9100...), OS version (4.1.2, 4.4.2...) and OS build (KOT49H, KVT49L...)
Added (nice looking) information panel with clickable links (for actions on the form) and coloring
Other changes (I can't recall right now, since I've done it some time ago and waited for a response from Ido for permission to republish)
(★ Maybe I'll add an option for this later, depending on my -- not to much -- free time and requested by users .... ★)
Known bugs:
Sometimes ADB fails to return build.prop property for the status bar (however it has not caused any critical problem, so (I think) it can be safely ignored) -- haven't been able (yet) to find the exact state it is happening
Please take the time to look at the application ABOUT tab
Any Other ideas are welcome!
If you like it, Don't forget to Thank me
If you enjoy using this application as much as I have enjoyed re-writing it
please donate to show your appreciation​
RESERVED
Nice
Sent from my SM-N900T using Tapatalk
Good news
Bug report, every time I open this program, this dialog pops up, after click OK, this program works well.
PS, aapt.exe is in the same dir with ApkSpy
I got this errors:
1:
2:
Error in property: [email protected]@usrdata
cmlx said:
Good news
Bug report, every time I open this program, this dialog pops up, after click OK, this program works well.
PS, aapt.exe is in the same dir with ApkSpy
Click to expand...
Click to collapse
Hey dude,
I am not sure what you are doing wrong on your PC but it's certainly not the app as it works perfectly fine on my computer? Out of interest and for the sake or helping the new dev I thought I would raise a few points just to eliminate any finger pointing. There's a wishy-washy area when it comes to building/hacking things that were originally someone elses work...so yeah one can easily make great improvements yet open the door to bugs at the same time too. Anyway...thought I'd ask this:
Does aapt sit on your path? I know you said it is in the same directory, however just like a batch script in Windows it needs to "CD" or change directories to the %~dp0 if it is to understand what an executable is that happens to be sitting in the same directory as it's self. So this is is kinda directed at the new dev now. What I think is happening is that aapt is assumed to be in the system path when quite often it is not (i.e. those on XDA who have not yet played with the Android SDK properly). Put simply unless the application knows it is in the same directory as your executable it won't at all understand what aapt is. Does that make sense?
@dmagician , I would make sure that the apkspy app can do a check (even if it is a string search for the first few lines returned from aapt.exe), a simple if statement before throwing that error ....actually it would likely be an 'if not' statement. I don't have any of the code in front of me atm but I can help you out if you like? I was hacking this app myself sometime ago when ido first released it just using reshacker.
Note: If you are stuck and don't have source code you technically could write a full AutoIT wrapper for this app that could do all the checks and more and then bundle everything up into the one exe still. Check out the newer WinAPI stuff for AutoIT and in particular "Run binary" (yes that's correct you can just about run anything repackaged now and not need to deploy the original exe's or even libraries....they can all be stream fed to AutoIT @Compile time and need not be typically "installed" like you used to have to do. Anyway...I am waffling on shoot me a PM man.
@cmlx, to overcome your ApkSpy woes, and until dmagician can put his finger on what the cause is or what ido did when building it ages ago.....then you will firstly need to be patient (props to dmagician to figuring sh!t out so far) but till then where ever you have dumped the ApkSpy and aapt.exe on your system; just copy the address and put it on your system path. To do this 1) right click on My Computer or Computer if you are on Win 7 or 8. 2) Choose properties. 3) Advanced System settings and then at the bottom of tab you will see 'Environment Variables', click it and you will see some "User" and "System" options. Depending on your User access rights on the system you are running on (hopefully you are running as Admin surely?) then you can choose to edit your main system path or create a new variable in your user settings called 'path' Note User variables are always postfix to system variables but should always work anyhow.
Disclaimer: cmlx, if however you have already got an aapt.exe already existing on your system path but it is dodgy then you have to ensure that the good aapt.exe in your app directory is placed on path BEFORE the dodgy one....just sayin. Cause your system searches till it finds what it wants and then doesn't search anymore. Simple but can stuff people up quite often....and likely your case. Nowdays we tend to work from the known application location and not from a "Global environment path" when we know that there are going to be conflicts...and I can assure you that aapt is possibly the worst and most modified binary out there LOL. Hence this is also a note to the dev to ensure that ApkSpy reads from the current directory.....or like I am suggesting, wrap aapt up in the main application as well and that way there is no confusion EVER.
And I am done.....
Oh wait no I am not....sorry bug reports LOL :good: you thought I was all praise eh? Got another thing coming man
OK....so um the red boxes should explain everything. A picture says a thousand words (and yeah I needed at least 1 picture for this god damned long arsed post - sry). Um why in gods name would you remove the minimise and expand buttons? WTF? Anyway...it works but errrm yeah it doesn't wrap the text anymore? and it cuts the words off lol.
Other than that....I only really have one suggestion and it isn't even really a suggestion as I have kind of already made it so I can just give it to you if you want it? And that is that most people (well I can't say most as I am not speaking for everyone) tend not to like how apps take over their system. This isn't your fault at all in anyway as the first dev thought it was a good idea back then.....and back then hardly anything in Windows knew what a freakin apk was so it was a GOOD thing.....However now, every man and his dog wants to steel .apk extension for himself. I myself tend to be all over the shop with apks so I tend not to want to have any particular Windows app take it away from my control. I use WinZip as the main app for simple double click open as I want to see the contents of apks without needing to decompile them (great for theming) however I have apk shell extensions displaying the apks main icon to explorer, so if I set WinZip as default I get a nice lumping hunk of gold turd/box running rampet all over my Windoze bro ......so if you like I can show you my code that allows me to have default apps for specific tasks without interfering with anyones existing sh!t It looks neat too as you can right click any apk and just choose from a dropdown list what particular app you want at the time. If one has the need to use more apps then they need only put those apps in a list. There is nothing worse than double clicking an apk to find that Bluestacks or some other rubbish Windoze crApp has taken offf with your apk.
Lastly I thought I'd ask, Why no config file? Why store everything in memory? I know it's only small....but seeking for things everytime it is executed is a pain in the arse and not good practice. At the very least if you have no idea how to make an exe totally portable then you could reference a config file in the same directory....Or do as most do and write entries to the registry all neat and tucked away. If we get paranoid about "portable-ness" then we write to temporary space in the registry and make sure we clean up upon closing and/or inspect at runtime. simple!
I have plenty of AutoIT scripts that do exactly that too, so if you are stuck for ideas let me know. Anyway I have rambled enough, good luck and I will keep reporting bugs haha
Edit: That's waaaay too many emoticons. Oooops someone is a little high aren't they?
PS: I have attached my PNG of the icon I used for this bugger waaaaaay back....it's less generic and feel free to take it and abuse it and do as you please.
cmlx said:
Good news
Bug report, every time I open this program, this dialog pops up, after click OK, this program works well.
PS, aapt.exe is in the same dir with ApkSpy
Click to expand...
Click to collapse
Yes, I know of this one (and I've specifically wrote about it in the OP), it is NOT related to AAPT executable but to the way ADB is acting (sorry, out of my hands... :angel:
Explanation
The error comes from the application when trying to query the "ro.build.id" property via adb ('ADB shell getprop "ro.build.id" ') command.
I've came across this one but cannot determine the exact situation it is happening (as it can occur when first launching of the app, but after the app is loaded, clicking on refresh does not show this error)...
[ I've tried it on with the (only) two devices I own (1st dev. is stock (only the kernel is changed) 4.4.2 Nexus 4, 2nd dev. is S2-i9100 with customized RR ROM)and it seems to happen ONLY on the S2...]
It looks that in times, the getprop is being executed before the whole "build.prop" is being processed by ADB (This one I cannot control since it is happening on the ADB shell side [running on the device] -- unless MAYBE doing some [UGLY] delay after first initialization of ADB, which is, by far NOT best practice of process handling according to the literature)...
CyberianIce said:
I got this errors:
1:
2:
Error in property: [email protected]@usrdata
Click to expand...
Click to collapse
Which came first, the "SpkSpy spy stopped working" or the "Error in property" (if anyways related)?
Was it on the same run or two different runs?
As of the 1st one:
I do not have enough information from your post to check it up...
I'll post a new version which shows the exception details
As of the 2nd one:
Can you send me a copy of your /system/build.prop (so i'll be able to dig trough it and check it)?
It looks like my name-value splitter character exist as part of a given value in your build.prop .
Wooow, Long one! But it is nice to know people are using (trying) it!
Jarmezrocks said:
Hey dude,
I am not sure what you are doing wrong on your PC but it's certainly not the app as it works perfectly fine on my computer? Out of interest and for the sake or helping the new dev I thought I would raise a few points just to eliminate any finger pointing. There's a wishy-washy area when it comes to building/hacking things that were originally someone elses work...so yeah one can easily make great improvements yet open the door to bugs at the same time too. Anyway...thought I'd ask this:
Does aapt sit on your path? I know you said it is in the same directory, however just like a batch script in Windows it needs to "CD" or change directories to the %~dp0 if it is to understand what an executable is that happens to be sitting in the same directory as it's self. So this is is kinda directed at the new dev now. What I think is happening is that aapt is assumed to be in the system path when quite often it is not (i.e. those on XDA who have not yet played with the Android SDK properly). Put simply unless the application knows it is in the same directory as your executable it won't at all understand what aapt is. Does that make sense?
Click to expand...
Click to collapse
Hi
As I've replied to @clmx, This error is not related to AAPT (either executable [location or whatever] or results), but to the ADB command being used...
Jarmezrocks said:
@dmagician , I would make sure that the apkspy app can do a check (even if it is a string search for the first few lines returned from aapt.exe), a simple if statement before throwing that error ....actually it would likely be an 'if not' statement. I don't have any of the code in front of me atm but I can help you out if you like? I was hacking this app myself sometime ago when ido first released it just using reshacker.
Click to expand...
Click to collapse
Sorry I did not understand... Check for what?
Jarmezrocks said:
Note: If you are stuck and don't have source code you technically could write a full AutoIT wrapper for this app that could do all the checks and more and then bundle everything up into the one exe still. Check out the newer WinAPI stuff for AutoIT and in particular "Run binary" (yes that's correct you can just about run anything repackaged now and not need to deploy the original exe's or even libraries....they can all be stream fed to AutoIT @Compile time and need not be typically "installed" like you used to have to do. Anyway...I am waffling on shoot me a PM man.
Click to expand...
Click to collapse
I do not need the Auto-IT to wrap these files (although I am using it for other automation in windows), as I can do it right in the C# code (on one of my early versions these files was embedded...)
BTW, I know there are some antiviruses out in the wild that do not like the embedded executables -- but it can be done -- and probably will save some time to anyone using this app...
If it will be required / asked, I'll embed the 4 binaries (AAPT.EXE, ADB.EXE, and two DLL's AdbWinApi.dll and AdbWinUsbApi.dll [I'm not sure both are required]) needed by the application.
Jarmezrocks said:
@cmlx, to overcome your ApkSpy woes, and until dmagician can put his finger on what the cause is or what ido did when building it ages ago.....then you will firstly need to be patient (props to dmagician to figuring sh!t out so far) but till then where ever you have dumped the ApkSpy and aapt.exe on your system; just copy the address and put it on your system path. To do this 1) right click on My Computer or Computer if you are on Win 7 or 8. 2) Choose properties. 3) Advanced System settings and then at the bottom of tab you will see 'Environment Variables', click it and you will see some "User" and "System" options. Depending on your User access rights on the system you are running on (hopefully you are running as Admin surely?) then you can choose to edit your main system path or create a new variable in your user settings called 'path' Note User variables are always postfix to system variables but should always work anyhow.
Disclaimer: cmlx, if however you have already got an aapt.exe already existing on your system path but it is dodgy then you have to ensure that the good aapt.exe in your app directory is placed on path BEFORE the dodgy one....just sayin. Cause your system searches till it finds what it wants and then doesn't search anymore. Simple but can stuff people up quite often....and likely your case. Nowdays we tend to work from the known application location and not from a "Global environment path" when we know that there are going to be conflicts...and I can assure you that aapt is possibly the worst and most modified binary out there LOL. Hence this is also a note to the dev to ensure that ApkSpy reads from the current directory.....or like I am suggesting, wrap aapt up in the main application as well and that way there is no confusion EVER.
Click to expand...
Click to collapse
The application IS searching for AAPT and ADB executables; The order is
Application directory (where ApkSpy.exe resides)
PATH environment variable
Jarmezrocks said:
OK....so um the red boxes should explain everything. A picture says a thousand words (and yeah I needed at least 1 picture for this god damned long arsed post - sry). Um why in gods name would you remove the minimise and expand buttons? WTF?
Click to expand...
Click to collapse
Mostly I like it this way, otherwise - No specific reason...
It will be back in the next version...
Jarmezrocks said:
Anyway... it works but errrm yeah it doesn't wrap the text anymore? and it cuts the words off lol.
Click to expand...
Click to collapse
This Tab was NOT changed by me in any way... To be honest, I've thought of removing it completely -- But -- out of respect to Ido's work -- I've left it in.
I assume it is not wrapping due to Font size changed by me globally...
I'm seriously giving it second thoughts -- if it should stay at all (It was originally meant for batch rename of multiple APK's... I haven't used it even once...)...
I'm Really, REALLY, think of removing it completely (unless someone is / will be using it -- then I'll fix it all)...
Jarmezrocks said:
Other than that....I only really have one suggestion and it isn't even really a suggestion as I have kind of already made it so I can just give it to you if you want it? And that is that most people (well I can't say most as I am not speaking for everyone) tend not to like how apps take over their system. This isn't your fault at all in anyway as the first dev thought it was a good idea back then.....and back then hardly anything in Windows knew what a freakin apk was so it was a GOOD thing.....However now, every man and his dog wants to steel .apk extension for himself. I myself tend to be all over the shop with apks so I tend not to want to have any particular Windows app take it away from my control. I use WinZip as the main app for simple double click open as I want to see the contents of apks without needing to decompile them (great for theming) however I have apk shell extensions displaying the apks main icon to explorer, so if I set WinZip as default I get a nice lumping hunk of gold turd/box running rampet all over my Windoze bro ......so if you like I can show you my code that allows me to have default apps for specific tasks without interfering with anyones existing sh!t It looks neat too as you can right click any apk and just choose from a dropdown list what particular app you want at the time. If one has the need to use more apps then they need only put those apps in a list. There is nothing worse than double clicking an apk to find that Bluestacks or some other rubbish Windoze crApp has taken offf with your apk.
Click to expand...
Click to collapse
The application is NOT taking over anything, Unless you've clicked the asterisk ("*") button on the System Tab...
Was it registered for you without clicking this button?
If so, I'll recheck the code (may be it's some residue from the original code).
BTW
As the previous part of the answer I've wrote -- this one was left in as of respect to @ido's work...
2nd BTW
I'd like to see that explorer extension (and [preferable] the code of it - if you are willing to share it) you ware writing about...
Jarmezrocks said:
Lastly I thought I'd ask, Why no config file? Why store everything in memory? I know it's only small....but seeking for things everytime it is executed is a pain in the arse and not good practice. At the very least if you have no idea how to make an exe totally portable then you could reference a config file in the same directory....Or do as most do and write entries to the registry all neat and tucked away. If we get paranoid about "portable-ness" then we write to temporary space in the registry and make sure we clean up upon closing and/or inspect at runtime. simple!
Click to expand...
Click to collapse
Yep, I've thought of it... But... I was thinking, that (at least) everyone is as geeky as me dauuh , and the most are setting the path correctly...
It'll be added in next version (I hope... TIME, TIME!!!! :cyclops...
Jarmezrocks said:
I have plenty of AutoIT scripts that do exactly that too, so if you are stuck for ideas let me know. Anyway I have rambled enough, good luck and I will keep reporting bugs haha
Click to expand...
Click to collapse
I prefer writing my own code (sorry, I'm a developer in heart and soul...) then using automation like Auto-IT...
Jarmezrocks said:
Edit: That's waaaay too many emoticons. Oooops someone is a little high aren't they?
Click to expand...
Click to collapse
Jarmezrocks said:
PS: I have attached my PNG of the icon I used for this bugger waaaaaay back....it's less generic and feel free to take it and abuse it and do as you please.
Click to expand...
Click to collapse
(@Jarmezrocks please see my PM to you.)
PHEW...
Long Answer, BUT HEY, I'm not the only one writing longies... :angel: (and i like referencing each and every part separately)...
dmagician said:
PHEW...
Long Answer, BUT HEY, I'm not the only one writing longies... :angel: (and i like referencing each and every part separately)...
Click to expand...
Click to collapse
Ahh yes. I write long messages sometimes when my medication has kicked in and I am high....not my fault I kinda need to get all the info out of my head in one go while I am awake.....or else there would just be zeds on the response zzzzzzzzzzzzzzzzzzzzzz lol :laugh: (ref narcolepsy).
I commend you on your efforts at responding to such gibberish and making good sense of it! :highfive:
I have responded to your PM accordingly, and hopefully covered all you need? I have attached all info and sources etc.....well most of it...actually a fair bit of it you will have to workout your self but that is part the fun. Shoot me any questions if you need to...although I have a feeling that you will have mostly all of it covered as you are streets ahead of my knowledge already. I may have misjudged a little in my previous post (although hopefully not to make you feel any less than you actually are? please excuse me if I had said anything that may offended - being naive or what ever....you ARE definitely on the right track). As for the middle menu....I think you could easily remove it and not offend the original dev. It wasn't being used as you mention...and I think it could make way for more/better functionality don't you think? (discuss). However I would ensure all the things I mentioned in my PM first before going too deep and releasing on here.
Good move on bringing the buttons back. They were functional. But I DO like the single button close GUI myself on just about everything else....It looks clean. We have similar taste in that regard. It just isn't functional for me to pressing the task notification desktop link everytime I want to minimise the app LOL.
The rest I we can discuss via PM, this is pretty much only posted here as an open area for other forum members to provide input and opinion (or complaint....like how often it usually is, eh?).
CyberianIce said:
I got this errors:
1:
2:
Error in property: [email protected]@usrdata
Click to expand...
Click to collapse
I'd got the same error!
For me it helped to copy two files to the install dir
"adb.exe" and "AdbWinApi.dll"
Both are installed with the well known MyPhoneExplorer into "Program Files\MyPhoneExplorer\DLL"
Hope it helps!
Feature Request
I use this tool for testing new APK builds on a project I am working on it. It allows me to quickly verify the version number and push to the device. However, since I am usually installing another version of an existing installed APK, I must manually uninstall before using APKSPY. Would it be possible to add a check box that would uninstall any previous versions? It would be really helpful.
Nevermind - I didn't fully read the message presented when it fail. It say uninstall/update and it allows the installation. HOWEVER, that brings up a question... Does it uninstall or does it update? There is a difference as you know.
Thanks,
Jonathan
Hi, I try to run this on Mac via Wineskin Winery, but no luck. Do I need something like .Net, or something else to run ApkSpy?
Thank you.
Ja_som said:
Hi, I try to run this on Mac via Wineskin Winery, but no luck. Do I need something like .Net, or something else to run ApkSpy?
Thank you.
Click to expand...
Click to collapse
The only requirement is the Microsoft .Net 4.
(I'll add this to OP)
jmo said:
I use this tool for testing new APK builds on a project I am working on it. It allows me to quickly verify the version number and push to the device. However, since I am usually installing another version of an existing installed APK, I must manually uninstall before using APKSPY. Would it be possible to add a check box that would uninstall any previous versions? It would be really helpful.
Nevermind - I didn't fully read the message presented when it fail. It say uninstall/update and it allows the installation. HOWEVER, that brings up a question... Does it uninstall or does it update? There is a difference as you know.
Thanks,
Jonathan
Click to expand...
Click to collapse
Yes I know there is difference between the two (update vs uninstall and install again).
It is updating the application (like using "adb install -r apk_file_name.apk"), not doing remove and install
Removed unneeded tabs (System, Batch Rename, Log)
Click to expand...
Click to collapse
The unneeded Batch Rename tab was the only tab I needed really. :laugh: Luckily I found Ido's original version. It's ideal for renaming all those apk's I downloaded and still have the package name when I back them up to my PC.
I have an Asus Memo Pad 10 and an Asus Memo Pad 7 and neither are recognised by APKSpy. Not that it's a problem as I have no problem copying to and from them with Windows Exploder or Total Commander.
Other than that, it's been a handy little app for this tablet/smartphone virgin newbie.
Martin.
wolrik said:
The unneeded Batch Rename tab was the only tab I needed really. :laugh: Luckily I found Ido's original version. It's ideal for renaming all those apk's I downloaded and still have the package name when I back them up to my PC.
I have an Asus Memo Pad 10 and an Asus Memo Pad 7 and neither are recognised by APKSpy. Not that it's a problem as I have no problem copying to and from them with Windows Exploder or Total Commander.
Other than that, it's been a handy little app for this tablet/smartphone virgin newbie.
Martin.
Click to expand...
Click to collapse
Hello.
1st:
I can -- if requested - re-add the Batch rename.
2nd:
I don't know why these two devices are not being recognized -- unless not being recognized by ADB itself -- since I'm spawning devices by parsing the resulting text of "ADB devices" command, So unless being unrecognized by ADB, there should be NO PROBLEM detecting ANY android device with ADB on...
if you have any exception messages thrown by the application, please post them here.
dmagician said:
Hello.
1st:
I can -- if requested - re-add the Batch rename.
2nd:
I don't know why these two devices are not being recognized -- unless not being recognized by ADB itself -- since I'm spawning devices by parsing the resulting text of "ADB devices" command, So unless being unrecognized by ADB, there should be NO PROBLEM detecting ANY android device with ADB on...
if you have any exception messages thrown by the application, please post them here.
Click to expand...
Click to collapse
No need to re-add the tab just for me, but thanks for the offer. As I get to know my way around Android I'll probably need such things less and less.
Sorry, but I know nothing about ADB other than APKSpy needing it. As you can see from the attached pic, the Asus is recognised by Total Commander
Martin.
Hi dmagician,
Nice work, and a shout-out to Ido who originally created it.
I have a feature request:
Could you add the option to remove certain permission(s) and save the modified APK file?
There are many apps which I feel allow themselves way too much permissions, and this option could be very useful to tame them apps.
One more thing:
I noticed that APKSpy v1.8.2 doesn't work with the latest version of AAPT.exe (1432KB), from the Android SDK r24.
So I had to use a previous version of AAPT.exe (833KB), which worked.
Thanks,
Eric
Hey does anybody know where the name of the apk is in the XML files inside the apk?

Categories

Resources