Hello there, Mr. hidden skype apk
So I’ve been reading all the hype about the new Skype application released on Verizon. Sadly I neither have a droid or any friends with a rooted droid. As one would assume, the apk is located in /data/app-private so I needed access to a rooted droid to get this app… Or do I?
Silly me, I forgot all the research I had done for Market Enabler! After a friend sent me their getprop I was off spoofing my values, no more than two minutes went by and ta-da! Got myself the new Skype application.
The following setprop commands must be run to gain access to the Verizon only part of the market.
setprop gsm.sim.operator.numeric 310004
setprop gsm.operator.numeric 31000
setprop gsm.operator.alpha “Verizon Wireless”
setprop gsm.sim.operator.alpha Verizon
setprop gsm.sim.operator.iso-country us
setprop gsm.operator.iso-country us
Note that you will need to restart your Vending (Market) application to have these values take affect, you can do that by running the following commands via a terminal:
# ps | grep vending
app_5 2699 75 181176 26384 ffffffff afe0dca4 S com.android.vending
# kill 2699
Pffhh, yea right...
Changing the properties..
Note: This might be well, a little low level for some people to understand -
though I’m sure this will end up finding the right people. If you understand this post -
then you’ll understand the significance of what the purposes of doing this would be
for
Just randomly looking to do specific things with the Market, I finally figured out a way
to force the Market into accepting any certificate. It turns out there is actually a little bit
of code (leftover from testing?) that if special parameters are set, will allow you to
disable ssl certificate checking. This essentially allows us to well, do lots of things we
otherwise wouldn’t be able to do!
Obviously your going to need root to enable this – and I’m going to provide you the
way I’ve enabled it; using adb. Again like I’ve stated countless times, anything you do
via ADB you should be able to do via a console on the device, I’m not sure why people
always repaste everything and say just do it via a console thinking it’s some big news…
The two variables we’re going to have to set are ro.secure and
vending.disable_ssl_cert_check. Personally, my devices both have ro.secure
already set (properly) to 0. Vending.disable_ssl_cert_check is a new variable that we
will be creating, setting it to “TRUE”. Simply fire up adb and run the following
commands (as root);
setprop ro.secure 0
setprop vending.disable_ssl_cert_check TRUE
You can quickly run a “getprop” to verify you typed everything correctly; ro.secure
should be located as the first variable and the vending one is the last (since it is new).
You can verify that these settings are correct and working by watching your console
log for the Vending.apk via DDMS. The following string should appear while loading
the Market: “Turning off SSL certification check.” This can be seen below:
Also as a final reminder, every reboot these variables must be reset, since there is no program actually setting them already. You must reinitialize these variables (in my case, I only have to initialize vending.disable_ssl_cert_check) if you would like to use this mode.
Hopefully this will be of use to someone other than myself!
Finding the Android ID (img blacked out)
In a previous article I had posted some information about how it is possible to spoof the Android ID that is returned when calling the Settings.System.Android_ID function. Though I had noted at the end of my post the following;
Note that this will NOT change the android id used by google products since they use one that is linked to your gmail account that the phone is associated with…
This bugged me a little bit because I wanted to know how the google applications where using and getting the android information – did they pull it directly from the hardware? Where they just using private API that was more secure? So after a little research, I found exactly what was going on, and again how it would be possible to spoof the id.
Essentially the google applications use googleapps to store the android id, this is the program on the phone named “com.google.android.googleapps”. This is a very interesting program that sadly developers do not have access to as of yet, though hopefully this will change shortly.
Anyway, this program is also susceptible to being force-fed spoofed values. The method is essentially the same as the previous one, though just performed on a different database. From within adb or the shell, do the following;
$sqlite3 /data/data/com.google.android.googleapps/databases/accounts.db
update system set value=’deadbeef0000badf00d’ where name=’androidId’;
This program also store in that table the imsi number linked to the phone, for simcard tracking purposes.
Just yesterday I noticed there was an application published to overclock your G1 — it reminded me of a few files that I had seen when browsing system files on my device. At first I thought it must be a scam, or using some feature just hidden into the system, much like the garbage collection method used in memory free pro – but it seems t actually change the value. Whether this really speeds up the G1 without harming it is left unknown right now. Anyway, the file I had previous seen and was watching was “acpu_clk”. It can be found in the /system/debugfs/clk_rate/ folder.
So, essentially to get your current CPU do the following in the terminal or through adb;
$sh
#cat /system/debugfs/clk_rate/acpu_clk
To modify this file to change your clock speed you need to remount your /system to be writeable and then modify the file.
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
mkdir /system/debugfs
mount /system/debugfs /system/debugfs -t debugfs
This will remount debugfs, the folder to be visible and allow you to edit it. To change the value simple pipe and echo to the file;
echo ’245760000′ > /system/debugfs/clk_rate/acpu_clk
Afternote:
Just noticed that someone at xda-developers posted nicer shell code than mine, so I’ve just pasted in theirs. Enjoy!
Easier than baking a cake!
Currently working on some random things on the Android OS source – which of course if I can get my little, “additions”, to work properly I’ll be releasing them. Though I was having a few problems getting the code to compile – so I figured I’d throw together this post just in case anyone else is having similar trouble.
Essentially in the post I was originally reading here, stated the following;
At the time of writing, the Android Dream build was broken. I needed to do the following to make it work:
* Several (relatively minor) changes in the Dream audio driver code to fix compilation issues.
* Copied libOmxCore.so to mydroid/out/target/product/dream/system/lib (this was a missing step in the Building for Dream documentation, and something that should be in the HTC provided script)
Well that wasn’t the problem I was getting though — the erorr I had been getting was actually:
In file included from frameworks/base/libs/audioflinger/AudioResamplerCubic.cpp:20:
system/core/include/cutils/log.h:68:1: warning: this is the location of the previous definition
target thumb C++: libaudioflinger <= frameworks/base/libs/audioflinger/AudioFlinger.cpp
make: *** No rule to make targetout/target/product/dream/obj/lib/libaudio.so’, needed byout/target/product/dream/obj/SHARED_LIBRARIES/libaudioflinger_intermediates/LINKED/libaudioflinger.so'. Stop.
...
make: *** No rule to make target/tmp/dream/target/product/dream/obj/lib/libcamera.so', needed by/tmp/dream/target/product/dream/obj/SHARED_LIBRARIES/libcameraservice_intermediates/LINKED/libcameraservice.so'. Stop.
...
make: *** No rule to make target/tmp/dream/target/product/dream/obj/lib/libOmxCore.so', needed by/tmp/dream/target/product/dream/obj/SHARED_LIBRARIES/libopencorecommon_intermediates/LINKED/libopencorecommon.so'. Stop.
...
/media/other-storage/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/../lib/gcc/arm-eabi/4.2.1/../../../../arm-eabi/bin/ld: warning: librpc.so, needed by /tmp/dream/target/product/dream/obj/lib/libaudio.so, not found (try using -rpath or -rpath-link)
...
make: *** No rule to make target/tmp/dream/target/product/dream/system/lib/libaudio.so', needed by/tmp/dream/target/product/dream/system/lib/libaudioflinger.so'. Stop.
...
make: *** No rule to make target/tmp/dream/target/product/dream/system/lib/libcamera.so', needed by/tmp/dream/target/product/dream/system/lib/libcameraservice.so'. Stop.
...
make: *** No rule to make target/tmp/dream/target/product/dream/system/lib/libOmxCore.so', needed by/tmp/dream/target/product/dream/system/lib/libopencorecommon.so'. Stop.
(This list was compiled over multiple re-runs of make)
The simple fix was essentially what was stated in the original post, though it just took me a few minutes to figure this out. After running the locate command like a mad man and not finding anything on my developer machine, I finally reread *everything* and checked the device for the file - and there it was!
I just ended up throwing this into my extract-files.sh;
adb pull /system/lib/libaudio.so proprietary/libaudio.so
adb pull /system/lib/libcamera.so proprietary/libcamera.so
adb pull /system/lib/libOmxCore.so proprietary/libOmxCore.so
adb pull /system/lib/librpc.so proprietary/librpc.so
So my resulting file looked like this;
[code]
#!/bin/sh
mkdir -p proprietary
adb pull /system/etc/AudioFilter.csv proprietary/AudioFilter.csv
adb pull /system/etc/AudioPara4.csv proprietary/AudioPara4.csv
adb pull /system/etc/gps.conf proprietary/gps.conf
adb pull /system/bin/akmd proprietary/akmd
adb pull /system/lib/libhtc_ril.so proprietary/libhtc_ril.so
adb pull /system/lib/libaudioeq.so proprietary/libaudioeq.so
adb pull /system/lib/libqcamera.so proprietary/libqcamera.so
adb pull /system/lib/libaudio.so proprietary/libaudio.so
adb pull /system/lib/libcameraservice.so proprietary/libcameraservice.so
adb pull /system/lib/libcamera.so proprietary/libcamera.so
adb pull /system/lib/libOmxCore.so proprietary/libOmxCore.so
adb pull /system/lib/librpc.so proprietary/librpc.so
chmod 755 proprietary/akmd
adb pull /system/etc/wifi/Fw1251r1c.bin proprietary/Fw1251r1c.bin
adb pull /system/etc/wifi/tiwlan.ini proprietary/tiwlan.ini
[/code]
libaudio.so, libcameraservice.so, libcamera.so, libOmxCore.so, librpc.so then needed to be copied over to TARGET/dream/target/product/dream/obj/lib/ and also to the locked folder TARGET/dream/target/product/dream/system/lib/
Ta-da! After approximately 10 runs, it finally compiled for me... Hopefully this helps anyone who ran into the same problems as me.
Recent Comments