Related
I'm trying to figure out how to write an app that uses HTC API's. Specifically I want my app to switch scenes but I can't figure out how to call in to their libraries.
I unzipped Rosie.apk and it is only resources, no java.
it's the classes.dex
Right but how do I import something from a dex in eclipse and build it?
manicmethod said:
Right but how do I import something from a dex in eclipse and build it?
Click to expand...
Click to collapse
no way.
.dex is compiled, not source.
does java have a way to forward-declare classes so I can tell java they'll be there when it tries to run?
I haven't done much (read: any) actual development on Android yet, as I just got my Hero recently (developing solely on an emulator? ewww), but isn't the typical way of interacting with other applications on Android through Intents and Actions?
Browsing through the AndroidManifest.xml file in Rosie.apk, there seems to be a reference to com.htc.launcher.ThemeChooser.action.theme_change - Maybe this would be a place to start?
Ah yes, I'm still in the mindset of calling other peoples interfaces to do things. Thanks for the tip.
trying to figure out what to do with it will be fun, I'm sure
So com.htc.launcher.ThemeChooser.action.theme_change launches the chooser. I need to be able to change the scene under the covers by telling it what theme to switch to, any one have any ideas?
Glad to see that you made a little bit of progress I did some more searching, but this time in Rosie.odex. I found an ACTION_THEME_CHANGE string. Perhaps it could be something like this:
Component Name: com.htc.launcher.ThemeChooser.action.theme_change
Action: ACTION_THEME_CHANGE
Data: ?
Like I mentioned, I'm new to this stuff I'm not sure if there is a way to log or monitor intents (that would sure make this easy, wouldn't it?).
After looking at this more I think I need to hook into the htc settings content provider and see if I can change the settings like that. I found this in the manifest.xml:
E: provider (line=191)
A: android:name(0x01010003)="LauncherProvider" (Raw: "LauncherProvider")
A: android:readPermission(0x01010007)="com.htc.launcher.permission.READ_SETTINGS" (Raw: "com.htc.launcher.permission.READ_SETTINGS")
A: android:writePermission(0x01010008)="com.htc.launcher.permission.WRITE_SETTINGS" (Raw: "com.htc.launcher.permission.WRITE_SETTINGS")
A: android:authorities(0x01010018)="com.htc.launcher.settings" (Raw: "com.htc.launcher.settings")
so according to http://developer.android.com/guide/topics/providers/content-providers.html it looks like the Uri should be:
Uri u = Uri.parse("content://com.htc.launcher.settings");
except when I try that I get an exception saying that is an invalid URI :\
I'm not sure that it would be a setting. I mean, I'm sure you could find an attribute to set, but I don't think the switch would be instantaneous (likely requiring a reboot to show), unless there is something listening for changes to the settings. I could be wrong, of course.
Figured it out:
final Uri u = Uri.parse("content://com.htc.launcher.settings/widget_workspaces");
And the resulting table has
_id, display_name, created, status, and ancestor_id
So I think I can change status and then figure out how to throw a notify
I guess you were right, it looks like the widget_workspaces table has all the scenes available but the status field doesn't do what I assumed it would, rather it looks like it indicates whether a scene was shipped by HTC, is your saved scene or is unsaved.
I was really hoping this would do it because I don't know where to look now.
Well, looking at the ddms, it seems like I am wrong. It looks like ThemeChooser activity will do the swapping itself after you have selected a different scene. So it doesn't look like you will be able to make use of HTC's packages to do the swapping for you. Unfortunately, the only thing I can think that you could do next, is figure out how it is storing the scenes and load it and call all of the loading functions yourself...
Well, I have no way of calling their loading functions so I guess I'm out of luck :X
Check out smali and baksmali to snoop around in the classes.dex.
P
I used ddx1.7 to snoop in the dex files and found the tables and everything they were storing settings in. Unfortunately it looks like they neither store the current active scene in the table nor have an intent to call that will switch it without popping up the dialog.
It looks like what I want to do isn't possible.
alright, im a regular of the xda-devs irc. there have been more people the last 2 weeks that have come in there with questions that couldve been solved by a 2 minute read on the wiki.
i've read the annoucement, however i do not..understand what the issue was.
XDA's old wiki software was hacked and represented a security threat to the entire site.
Click to expand...
Click to collapse
i'd like to ask would it not be more timely to fix the hack. i'm unsure as to what they did, however from the sound of it they got database access.
in which case, move the tables from mainserver to another and make them readonly. i cannot grasp why shutting down the wiki for weeks on end is a better idea than a few file adjustments as a stopgap.
somebody willing to put out more information on the matter?
cheapusenet said:
alright, im a regular of the xda-devs irc. there have been more people the last 2 weeks that have come in there with questions that couldve been solved by a 2 minute read on the wiki.
i've read the annoucement, however i do not..understand what the issue was.
i'd like to ask would it not be more timely to fix the hack. i'm unsure as to what they did, however from the sound of it they got database access.
in which case, move the tables from mainserver to another and make them readonly. i cannot grasp why shutting down the wiki for weeks on end is a better idea than a few file adjustments as a stopgap.
somebody willing to put out more information on the matter?
Click to expand...
Click to collapse
The wiki software is old, and probably has a few vulnerabilities. I'm guessing it's more than just the wiki's database been hacked that is the securing concern. Most of the db tables will probably be written to, so read-only might not be a viable option. Remember the old wiki has integrated login with vB.
The admins have setup a new MediaWiki wiki and people are currently helping migrate the content over. I'm not sure of the "Go Live" for it, but it's starting to shape up.
Dave
i just now found it, its looking..pretty good. still seems to me an hours work on the old one could fix it enough to suffice until the new ones all ready to go.
At the moment, there's only a handful of folks working on porting (migrating) the information over.
We could use (and appreciate) any and all help on this effort. If you or others members are wish to assist, please contact svetius via PM.
Cheers,
so its still dead for the foreseable future. why is it we don't give my plan some thought. it cannot hurt. it'd be alot faster and alot better than waiting for every page to be moved over by a handful of people, and at the rate its going it's not exactly speedy.
cheapusenet said:
so its still dead for the foreseable future. why is it we don't give my plan some thought. it cannot hurt. it'd be alot faster and alot better than waiting for every page to be moved over by a handful of people, and at the rate its going it's not exactly speedy.
Click to expand...
Click to collapse
Every visit to a page writes to the database, so read-only's not an option.
To use it, it still needs read access to the vB user login database, so we cannot secure XDA's vB database from it, meaning if there are SQL IV vulnerabilities someone could access parts of our vB database.
Dave
o use it, it still needs read access to the vB user login database,
^
bingo, why. why does it HAVE to access login data?
as for writing to the database stripping that code out couldnt be that hard,.
cheapusenet said:
o use it, it still needs read access to the vB user login database,
^
bingo, why. why does it HAVE to access login data?
as for writing to the database stripping that code out couldnt be that hard,.
Click to expand...
Click to collapse
It will have access to the login data so that we only need one login for the wiki and for vB.
I've seen the code for it from when it was on Source Forge, it's a mess - if we miss something that could be a problem.
Also if we were still getting SQL IV attack's against read-only databases, I'd still be worried .
Dave
I've started a thread for discussion on the wiki migration:
http://forum.xda-developers.com/showthread.php?t=729576
daveshaw, you're missing my point completely. the data in the wiki is in no way dependant on userlogins. it could be moved to a completely different server if needbe, mysqlhaxing across into another db onto another server .. over xda, would be a pretty darn extravagant feat id say.
cheapusenet said:
alright, im a regular of the xda-devs irc. there have been more people the last 2 weeks that have come in there with questions that couldve been solved by a 2 minute read on the wiki.
i've read the annoucement, however i do not..understand what the issue was.
i'd like to ask would it not be more timely to fix the hack. i'm unsure as to what they did, however from the sound of it they got database access.
in which case, move the tables from mainserver to another and make them readonly. i cannot grasp why shutting down the wiki for weeks on end is a better idea than a few file adjustments as a stopgap.
somebody willing to put out more information on the matter?
Click to expand...
Click to collapse
As Dave mentioned, the old wiki software has inherent vulnerabilities, and because it is no longer supported, we don't get periodic updates from the creator. MediaWiki is much better supported, so that over time we can continually update the software to keep it secure, etc.
in no way am i objecting to using mediawiki. moving it all over to mediawiki is a great idea, i agree.
however restricting access to the current one for weeks just because somebody doesnt want to edit some files, jerry-rig it a bit, is a bit of a..pain for everyone. alot of data is stored in that wiki.
cheapusenet said:
in no way am i objecting to using mediawiki. moving it all over to mediawiki is a great idea, i agree.
however restricting access to the current one for weeks just because somebody doesnt want to edit some files, jerry-rig it a bit, is a bit of a..pain for everyone. alot of data is stored in that wiki.
Click to expand...
Click to collapse
We're just trying to migrate it as fast as possible.
I've been working on fixing the GPS data validity bug (where positions are reported at a lat/long of approximately 0,0 prior to lock)
Attached is a version of libhardware_legacy.so that should do the following:
Improve debugging of GPS operation (change printf()s in the main GPS library file to Android logging macros)
Fix/workaround the 0,0 bug (I say workaround because I have yet to identify the root cause of the issue - however it is "fixed" from the point of view of an end user
A few "under the hood" cleanups/fixes
Things that are NOT implemented/fixed in this library:
XTRA (driver/library support for QuickGPS data loading)
Obtaining satellite status prior to GPS lock on Rhodiums (behavior on non-Rhodium unknown, but this should not change actual behavior at all except for the false 0,0 fixes)
Any methods for improved lock speed - all this does is prevent you from appearing south of Africa prior to lock
To test this fix (Intended for FRX05, may work with other 2.2.2 based builds that are derived from xdandroid FRX05):
Unzip the attached zip file
Place libhardware_legacy.so somewhere on your SD card. For organization, I use bindfiles/system/lib/libhardware_legacy.so
Open conf/froyo.user.conf in your favorite text editor
Within the custom_shells{} section of froyo.user.conf, add:
mount --bind /sdcard/bindfiles/system/lib/libhardware_legacy.so /system/lib/libhardware_legacy.so
Restart, and at this point:
1) 0,0 false locks should go away
2) You'll see lots of new GPS debugging info in ADB logcats
Edit: For testing, I usually use the "GPS Status and Toolbox" app from the market, since Google Maps does not show sat status.
With the stock GPS libraries, GPS Status and Toolbox will immediately report a 0,0 fix on startup
With this library, you should see that funky "wait for it circle" in the lower status area until you are locked. As mentioned above - you will not see satellite signal strength reports prior to lock
I was just looking at setting up the kernel build environment myself the other day.
The main useful reference I found was this:
http://forum.ppcgeeks.com/tp2-andro...modules-tinboot-nand-boot-more-beginners.html
However, that one's a bit of a firehose, too, since it deals with a lot of stuff specific to NAND.
In short clone these two repositories into the same directory:
Code:
git clone git://android.git.kernel.org/platform/prebuilt.git
git clone git://gitorious.org/linux-on-qualcomm-s-msm/linux-msm.git
The first is the vanilla kernel, and the second is the XDAndroid kernel modifications. You'll need the first to compile.
From that guide, compile:
Code:
cd android
mkdir modules
cd linux-msm
make clean
make ARCH=arm htc_msm_android_defconfig
make ARCH=arm CROSS_COMPILE=~/android/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- INSTALL_MOD_PATH=~/android/modules zImage modules modules_install
Follow that guide for putting together the modules for wifi and the location of your compiled files.
Thanks! I will take a look at that, although I get the impression from reading through things that that GPS handling is at a layer somewhere above the kernel but below where we start having to deal with Java. I just can't quite figure out where since I have never done any Android development before.
I am probably going to poke at the kernel at some point though to try and fix the LED behaviors. It is clear from the "sleep of death fix" test kernels that there is knowledge of how to change these behaviors - at the very least I want to make it turn things *off* when in deep powersave. (Seems nonsensical to me to indicate that the device is in a deep power save mode by turning on a bright power-burning LED, although maybe the LED consumption is negligible even when the device is asleep.)
Entropy512 said:
Thanks! I will take a look at that, although I get the impression from reading through things that that GPS handling is at a layer somewhere above the kernel but below where we start having to deal with Java. I just can't quite figure out where since I have never done any Android development before.
I am probably going to poke at the kernel at some point though to try and fix the LED behaviors. It is clear from the "sleep of death fix" test kernels that there is knowledge of how to change these behaviors - at the very least I want to make it turn things *off* when in deep powersave. (Seems nonsensical to me to indicate that the device is in a deep power save mode by turning on a bright power-burning LED, although maybe the LED consumption is negligible even when the device is asleep.)
Click to expand...
Click to collapse
Whoops, didn't read carefully enough at where you'd narrowed the problem down to. I haven't gotten around to setting up an environment for the system build yet, sorry I couldn't be more of a help!
Yup, http://gitorious.org/xdandroid/hardware_libhardware_legacy/blobs/master/gps/gps_msm7k.c is my first target. There may also be issues in gps-rpc.c
http://xdandroid.com/wiki/Getting_the_Source goes thru how to build the system image. It starts with getting the source and cascades all the way thru building a system image.
I'm setup to build it as well, and I've always wondered how we could fix this problem... Love to see it squashed!
Thanks! I'll start working on that, although probably not until after the weekend is over at this point.
The ghetto approach as an interim fix would be to not set GPS_LOCATION_HAS_LAT_LONG if both are exactly zero - This is not the right way to do it, but the chances of it affecting anyone before a proper validity condition is identified are slim. (Even if you ARE near lat/long of 0/0, there will be enough noise in the GPS solution that you'll almost never actually be blanked).
Probably should assume that all of the other validity flags should not be set if we don't have a position fix. (Assumption: The MSM7k GPS does not take inputs from the magnetometer or accelerometer, if the Rhodium even has a magnetometer, didn't think it did.)
Of course, I haven't quite figured out how GPS_LOCATION_HAS_LAT_LONG and such roll up to higher levels. There's some odd interactions in terms of when SV status becomes available, for example.
Entropy512 said:
Thanks! I'll start working on that, although probably not until after the weekend is over at this point.
The ghetto approach as an interim fix would be to not set GPS_LOCATION_HAS_LAT_LONG if both are exactly zero - This is not the right way to do it, but the chances of it affecting anyone before a proper validity condition is identified are slim. (Even if you ARE near lat/long of 0/0, there will be enough noise in the GPS solution that you'll almost never actually be blanked).
Probably should assume that all of the other validity flags should not be set if we don't have a position fix. (Assumption: The MSM7k GPS does not take inputs from the magnetometer or accelerometer, if the Rhodium even has a magnetometer, didn't think it did.)
Of course, I haven't quite figured out how GPS_LOCATION_HAS_LAT_LONG and such roll up to higher levels. There's some odd interactions in terms of when SV status becomes available, for example.
Click to expand...
Click to collapse
Yup, definitely no magnetometer in the Rhodium.
Good luck with this, it'll be a nice little fix if you can get GPS to stop reporting locks before it has one.
Source downloaded, have a build going. (First an unchanged one...)
I'm working on a Froyo tree for the moment, since I think in the Gingerbread alphas GPS is simply "not working", although the degree of "not working" was not defined. Once I'm more familiar with the GPS handling code I might take a look at how it works for Gingerbread.
A few notes about the Froyo repo in its current state:
The URL for Google Apps that device/xdandroid/msm/unzip-files.sh is outdated. cyanogen-mirror.local.host.name does not exist any more. android.local.host.name does but doesn't have the HDPI Froyo apps. I forget which mirror I used - the list is in the CyanogenMod wiki if you search for gapps
The froyo build scripts direct you to http://source.android.com/download - URL no longer exists, it is http://source.android.com/source/download.html now
The process for installing Sun Java 5 on Ubuntu 10.10 is in the URL above - you need it to do a froyo build.
Also, the wiki instructions are missing lib32readline5-dev as an Ubuntu package that needs to be installed (it's in the source.android.com docs tho) - I'll try to update the wiki later.
Entropy512, glad to see someone is interested in looking at the GPS code. I helped phh with it in the last go around to get the RPC messaging part working working, but nothing has been done since.
The NMEA parsing stuff you see in the current gps lib is unused, all the data comes from RPC. Before getting the data directly from RPC was working, we took advantage of the fact that NMEA is output to smd27 and parsed that string data. In any case, once the GPS is brought up, that NMEA data is still viewable by catting /dev/smd27.
If you want to check out other similar code, look at the vogue gps code. I think it supposed to work pretty well, and the RPC behind it is similar. Theirs is a bit different in that they split the gps processing across the kernel and userland, where ours is all userland.
Ultimately, this stuff needs a bit of a rewrite, because the libhardware_legacy interface to GPS that the current lib is written to, is gone for Gingerbread. If we could just get the RPC stubs generated, we might be able to plug into the reference Qualcomm implementation and take advantage of that well sorted code. Check out the cyanogenmod libhardware gps to see what that looks like.
Thanks for the additional pointers bzo.
I'm at the stage where I managed to build the froyo tree, but have not yet had a chance to test the built system ext2 image. That's a goal for tomorrow.
OK, dumb question - Since I'm now trying to understand that RPC code - Where do all those printfs in gps-rpc.c print to?
edit: Never mind, figured it out - it's buried in the logcat... Was trying to go back in time using Android System Info, but adb logcat lets me view it as it happens.
edit 2: Nope, those are D() statements in gps_msm7k.c - don't know where the printf()s in gps-rpc.c are going - nowhere? Should these be D() statements???
those printfs were from when that code was a console test application. Not surprising that they wouldn't show up by default in the logcat. I'm sure there is some way to make them show up. Dunno off hand, but some googling on android debug logging and redirection of stdout and such may dig up that info.
bzo said:
those printfs were from when that code was a console test application. Not surprising that they wouldn't show up by default in the logcat. I'm sure there is some way to make them show up. Dunno off hand, but some googling on android debug logging and redirection of stdout and such may dig up that info.
Click to expand...
Click to collapse
Ah. That makes sense why they aren't D() statements like in gps_msm7k.c
I tried changing as many of the printf()s to D() macros as I could, I'll test it tonight.
Edit: Had a chance to test it this morning. No output from any of the printf()s that I changed to D()s. Either I did something wrong, or none of those code paths are hit in a no-signal/low-signal situation prior to lock. Doing a make clean followed by a rebuild to make sure.
Those debug statements don't display by default. You'll have to change some compile and/or android settings to have them show up.
btw, if you're not already doing this, building just the gps lib and doing a mount --bind with just the lib in your startup.txt is a big timesaver, as opposed to updating the entire build
bzo said:
Those debug statements don't display by default. You'll have to change some compile and/or android settings to have them show up.
btw, if you're not already doing this, building just the gps lib and doing a mount --bind with just the lib in your startup.txt is a big timesaver, as opposed to updating the entire build
Click to expand...
Click to collapse
Hmm, got any pointers in this regard? They are working for gps_msm7k.c, but not my changes to gps-rpc.c - these are built by the same Makefile and components of the same library as far as I can tell. Is there a log tag filter somewhere?
Thanks for the mount --bind tip - will try that on my next build attempt.
if you copied over the same #define for D(...) from gps_msm7k.c, it seems like it should work the same in the other file. I haven't looked that much into android logging though.
For some reason my copy-and-pasted #defines for D() were failing.
Using LOGD() directly works.
I'm adding another set of LOGD()s now - It appears that something is calling update_gps_location() with bogus data.
BINGO! - It appears we are receiving PDSM_PD_EVENT_HEIGHT and PDSM_PD_EVENT_VELOCITY events prior to a position fix. No clue why - but even though GPS_LOCATION_HAS_LAT_LONG is not set, apps assume lat/long is valid when an update_gps_position() callback occurs.
Going to make it so we only do the update_gps_location() callback when GPS_LOCATION_HAS_LAT_LONG is set. Also going to try and figure out the right situations where we can call update_gps_svstatus() - right now it is only done when we get a PDSM_PD_EVENT_POS.
bzo said:
btw, if you're not already doing this, building just the gps lib and doing a mount --bind with just the lib in your startup.txt is a big timesaver, as opposed to updating the entire build
Click to expand...
Click to collapse
This is a good suggestion, but the bind mount statement would go in the froyo.user.conf, not the startup.txt .
arrrghhh said:
This is a good suggestion, but the bind mount statement would go in the froyo.user.conf, not the startup.txt .
Click to expand...
Click to collapse
yea, yea, that's what I meant , thanks for the correction
As it is known that HTCUtility.dll will provide complete, unrestricted access to the TCB chamber on HTC devices, can this be used to unlock (at any level) the OS?
I have not heard anyone speaking of it and exists on my HTC Arrive. Seems to be a bypass for unrestricted access to anything within HTC devices.
I am looking at it myself, but thought I would share.
See details here...
http://labs.mwrinfosecurity.com/files/Advisories/mwri_htc-htcutility-kernmem_2011-11-10.pdf
Your link is down
very interesting but you link is down so please fix it so I can take a look. I too have a HTC arrive and have been working on an unlock.
Don't know what happened to the link.
Here is the link to the google docs version.
https://docs.google.com/viewer?a=v&...1C1HkN&sig=AHIEtbTwK-r8RyAyFmt1ai119m7EVAqsNA
-Paul
This looks promising, I'd like to know if what's written there is true ...
The paper is a couple months old, so it *could* have been patched by HTC... but hey, it also might not have been! This bears investigation post-haste.
It's easy enough to use this to execute some arbitrary code at high permissions, which is certainly useful as-is (do things like unrestricted registry and filesystem access). The real potential of it, though, is to turn off the security restrictions for specific apps. Essentially, get the benefits of a "fully unlocked" ROM but on a stock ROM, and only for the apps you specify.
One thing to note here: this is still going to require an interop-unlocked phone. It's opening a handle to a driver, and just like everything else that does so, it needs ID_CAP_INTEROPSERVICES. This is great news for owners of interop-unlocked/unlockabe phones (since this makes interop-unlock useful again) but probably doesn't help on 2nd-gen phones or on the Arrive (unless you want to roll back to NoDo, in which case this can probably be used to make an interop-unlock that works on Mango, though it wouldn't be easy).
I hope some one gets this working for the Arrive ASAP
Oh this was talked about a while back. It was patched back in NODO
Really? The paper is from only 3 months ago (assuming USA numeric date style, 2 months otherwise). You don't typically publish security advisories for things that were patched more than 6 months prior.
In any case, HTCUtility.dll still exists on my phone. No idea yet if that IOCTL still works, though. I'll try it out in any case, and report back.
For those asking about it for the Arrive though, you're likely out of luck even if this works. It is *not* a way to interop-unlock a phone, and it is *not* a way around interop-unlock. It's a way to do more things on an interop-unlocked phone. You can't even reach a driver (which is what HTCUtility.dll is) unless your app has ID_CAP_INTEROPSERVICES - that's what the capability is actually for, accessing drivers - and you can't install a homebrew app with that capability unless interop-unlocked (or on pre-Mango).
GoodDayToDie said:
I'll try it out in any case, and report back.
Click to expand...
Click to collapse
Thank you
GoodDayToDie said:
Really? The paper is from only 3 months ago (assuming USA numeric date style, 2 months otherwise). You don't typically publish security advisories for things that were patched more than 6 months prior.
In any case, HTCUtility.dll still exists on my phone. No idea yet if that IOCTL still works, though. I'll try it out in any case, and report back.
For those asking about it for the Arrive though, you're likely out of luck even if this works. It is *not* a way to interop-unlock a phone, and it is *not* a way around interop-unlock. It's a way to do more things on an interop-unlocked phone. You can't even reach a driver (which is what HTCUtility.dll is) unless your app has ID_CAP_INTEROPSERVICES - that's what the capability is actually for, accessing drivers - and you can't install a homebrew app with that capability unless interop-unlocked (or on pre-Mango).
Click to expand...
Click to collapse
Yeah I think it was mentioned here on XDA and it was believed to already have been patched.
I think by "patch" they mean that Interop was restricted as of Mango, thereby securing this exploit, in Mango. But for those that are Interop unlocked, this should still grant full access to everything else.
Just my observations. I have an Arrive and am not Interop unlocked yet, so I can't test it.
Looking at the hand-free provisioning to see if I can find a way to leverage that....
-Paul
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
GoodDayToDie said:
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
Click to expand...
Click to collapse
All the information looks like it is in the advisory. KDataStruct is what you want. That is equivalent to the PEB in Windows CE.
GoodDayToDie said:
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
Click to expand...
Click to collapse
Can you confirm this works only on already Interop Unlocked device ?
Thx for your efforts.
Could htclv.dll be helpful in setting security on an app? It supports the following functions:
LVModInitialize LVModUninitialize LVModAuthenticateFile LVModRouting LVModAuthorize LVModGetPageHashData LVModCloseAuthenticationHandle LVModGetHash LVModProvisionSecurityForApplication LVModDeprovisionSecurityForApplication LVModGetSignerCertificateThumbprint LVModSetDeveloperUnlockState LVModAuthorizeVolatileCertificate LVModGetDeveloperUnlockState
In particular the "Deprovision Security for App" and "Get/set DeveloperUnlock" or maybe "Authorize Volatile Certificate"....
Or maybe htcpl.dll which seems to be the HTC policy engine interface. Supports:
GetFunctionTable PolicyCloseHandle PolicyEngineInit PolicyRuleAbortTransaction PolicyRuleAddRawData PolicyRuleBeginTransaction PolicyRuleBuildRawData PolicyRuleCommit PolicyRuleCommitTransaction PolicyRuleCreate PolicyRuleDelete PolicyRuleFindFirst PolicyRuleFindNext PolicyRuleGetInfo PolicyRuleOpen PolicyRuleParseRawData PolicyRuleReadRawData
These all look good to modify the security policies on HTC, assuming Interop-Unlocked.
-Paul
@dragonide: Confirmed, this requires interop-unlock since the very first step is opening a handle to a driver.
@Paul_Hammons: The LVMod functions look quite interesting indeed. Where are you getting these functions from (straight out of the DLLs, or some doc somewhere, or decompiled code, or...?), are they user or kernel entry points, and what permissions do they require? The ability to modify app security doesn't do as much good if you already have to be high-privileged to call it, though it might simplify my current goal.
@n0psl3d: Cool, I'll get to work on it.
@n0psl3d: KDataStruct contains kernel information, but I'm pretty sure what I need is in a PROCESS struct (such as is pointed to by pCurPrc). The problem is, I can't find any documentation for that struct. I'm searching online but so far coming up empty. CE doesn't seem to use PEBs or TEBs as I've seen them on NT (not terribly surprising, but annoying).
EDIT: I'm downloading the Embedded CE toolkit, which comes with source code. It'll take a while but hopefully that will have what I need.
OK, digging through the CE source I've found some interesting things. No idea if this will work yet; it'll be exciting just to make it compile.
PROCESS struct -> hTok (handle to a Token) -> phd (PHDATA, pointer to the handle data) -> pvObj (PVOID to the actual object, which is probably a TOKENINFO) -> psi (pointer to ADBI_SECURITY_INFO) -> contains the actual ACLs and privileges, and can be created from an account ID.
Probably the easiest option is to find a relatively high-privilege process and clone its token or some such. Token re-use (if I increment the reference count, this should work) may be easier. Modifying an existing token might also be doable.
Anyhow, I'm not going to have this finished tonight, but it'll get there. For those wondering wht you can do with this, it basically breaks you out of the sandbox entirely. You can call any function, access any resource, etc. that is available to a userland process (executing in kernel mode is also possible but trickier). Practically speaking, this makes all the other high-privilege COM DLLs useless - instead of ComFileRW, just use the file IO methods (anywhere you want), instead of DMXMLCOM just call ConfigProvXml directly. Even things like launching native EXEs directly should become possible (run those Opera ports on a stock ROM, for example).
I'm sorry, I still don't know what any of that means. But it sounds good! I wish I knew how to do this kind of stuff. Thanks for all of your work!
All samsung "touchwiz" based devices contain files in /system/csc that set variables dictating how certain parts of the phone act, what is pre-configured, etc. In the case of the AT&T variants, the contents of these files are often dictated by AT&T.
This post is an attempt to try and catalog some of the more useful values that can be changed (and the result of changing them.) Not all the variables seem to do much, and only by trial and error can we really know what will happen... So far, I've only played around with items I found interesting, but will continue to expand in this and if people reply to this post with actual experience changing other variables, I'll add the information to this thread.
PLEASE TEST THINGS AND CONTRIBUTE TO THIS THREAD.
Please don't reply with guesses as to what things may or may not do or with requests about specific variables. I'm hoping that eventually document every CSC variable available and "requests" won't make it go faster. If you want to know what a not-yet-documented variable does, try it out (and post your results.)
First, in order to play with the csc files, your phone should be rooted. This isn't optional, as you'll need the ability to overwrite files in the phone's /system partition (the firmware - sometimes improperly called the "ROM")
I'd strongly suggest making a nandroid (or backup via CWM Recovery or TWRP) before making changes. It's possible to mess things up badly enough that the phone won't boot properly.
It's possible to edit the CSC files directly on the phone, but I'd strongly suggest not doing that. Therefore, you should have a good text editor on your computer that's able to properly deal with unix/linux style line endings (notepad isn't good enough.) Notepad++ is a very good editor and freely available. Google "notepad++" For a linux box, plain "gedit" is fine.
In order to edit the files, you'll need to be able to mount the /system partition as read-write, and to move files from /system/csc to your PC or other location for editing. You have several options for this including root explorer, ES File Explorer, or just using adb. I prefer adb myself, but I'm a commandline type of person.
I won't be spending time describing how to get the CSC files off your phone to your PC, nor will I tell you how to overwrite the existing ones with your edits. This isn't because I'm elitist, an a**hole, or anything like that. (I _am_ some of those things, but that isn't my reason here.) My purpose for leaving out the information is to force inexperienced users to learn these things before editing system files. If I give you all the information, you become dependent on me for more information, and I don't want that (and trust me - neither do you.) As well, if I spoon-feed this, you won't have any idea what do to when something goes wrong.
Find this post helpful? If so, please make it MORE helpful by testing one of the other CSC features and replying to this thread telling us what result you had.
First up... feature.xml...
feature.xml
The CSC "feature.xml" file is in XML format. This means that everything "variable" has a start and end tag. Both contain the name of the variable,
but the end tag has a slash in it. The value of the variable is between the start and end tags. For example: <VariableName>value</VariableName>. So, if this message describes changing "CscFeature_SamsungSucks" from "false" to "true", you'd search in the xml file for "CscFeature_SamsungSucks" and might find this:
Code:
<CscFeature_SamsungSucks>false</CscFeature_SamsungSucks>
You'd change the "false" to "true" (no quotes!) and be done. In some cases, the entire line can be deleted (as noted.)
This file has a LOT of variables in it and this post will concentrate on that particular file. Almost all tinkering will occur in this file, and it's also the easiest to edit (as there aren't any complex xml structures.)
CscFeature_Common_DisableMenu4GalSearch: setting this to false didn't seem to bring up any new global address list options on my device (I'm connected to an exchange server) in the email app or contacts/dialer app.
CscFeature_Settings_DisableMenuFindMyMobile: (see next line)
CscFeature_Settings_FindMyMobile: setting "DisableMenuFindMyMobile" to false and this entry to true will enable the "find my mobile" entries in the Settings->Security menu. I'm unable to get these items to function properly, however. (They worked with my international note2, so it might be that there are other support files missing on the AT&T variant I'm using now.)
CscFeature_FMRadio*: editing these seem to have no effect (I don't think any of the LTE capable NoteII phones are capable of FM Radio.)
CscFeature_NFC_StatusBarIconType: If you delete this line, it will get rid of the "N" statusbar icon when NFC is turned on.
CscFeature_Message*: Be warned that editing some of these may break SMS/MMS messaging on your device. There appears to be many carrier specific settings in here that have dependencies on the specific carrier. For example, I don't think that AT&T's network supports proper SMS Delivery reports, so even setting the corresponding variable to "true" would be futile.
CscFeature_Email_UseFixedBgColorAsWhite: if changed from true to false, the email app will appear inverted (with a black background and white/gray text.)
CscFeature_Sip_DisableAutoCorrection: doesn't seem to have any impact on the samsung keyboard
CscFeature_Sip_DisableSpaceSuggestion: doesn't seem to have any impact on the samsung keyboard
CscFeature_Sip_DefaultOff4AutoSubstitution: doesn't seem to have any impact on the samsung keyboard
CscFeature_Launcher_*: all these seem to be for setting defaults for the touchwiz launcher, so no sense in changing them.
language.xml
(coming soon)
This appears to control what languages are available to the system. Canadian users might want to play with this file to see if adding en_US to the "Display" and/or "SupportList" tags will allow them to choose US English (and perhaps get google's TTS to talk to them in google now.)
others.xml
(coming soon)
This appears to set some carrier defaults, including the APN information and the carrier built-in dialer contacts (such as "AT&T Customer Care")
customer.xml
(coming soon)
I've only glanced at this file so far, but it appears to be carrier specified network information, some carrier specified settings defaults, and even some carrier specified browser bookmarks. There also appears to be some APN related information in here, but I'm not certain what it's in here for.
Nice how to guide man its very informative, im going to play around with this later when I get home...do you mind if I add it to my reference thread so it doesnt get lost when this thread begins to get bigger?
Sent from my SAMSUNG-SGH-I317 using xda premium
mjwhirly said:
Nice how to guide man its very informative, im going to play around with this later when I get home...do you mind if I add it to my reference thread so it doesnt get lost when this thread begins to get bigger?
Click to expand...
Click to collapse
This isn't mine to control. This "belongs" to the community, and I hope that the community contributes to it in a meaningful way. Please feel free to reference it elsewhere - perhaps with (contributions welcome) noted. My ONLY demand is that no one profits from effort I've given freely.
My secret motive is to nudge people out of the "MyRom" mentality and more into the "lets all work together to learn, develop and share" mentality often seen with kernels and open source projects.
Take care
Gary
Gary, have you seen the CSC feature web, set user agent?
Possibly an option to set "Desktop" as default user agent in browser, I for one despise mobile sites.
antiochasylum said:
Possibly an option to set "Desktop" as default user agent in browser, I for one despise mobile sites.
Click to expand...
Click to collapse
Not sure if this is what you are looking for or not: Start the browser, tap the "menu" button. Turn on the "desktop view" checkbox.
There are some UAgent related entries in the feature.xml file. Please play with them and post your results:
CscFeature_Web_SetUserAgent // currently empty
CscFeature_Web_SetUAProfile
CscFeature_Web_Bool_EnableUAProfile // currently false
Thanks so much for this. Sorry for the noob question but I haven't done much with xml files. What is the character to just comment out a line?
Sent from my SAMSUNG-SGH-I317 using xda premium
Romee74 said:
Thanks so much for this. Sorry for the noob question but I haven't done much with xml files. What is the character to just comment out a line?
Click to expand...
Click to collapse
In XML, in order to comment out a line (instead of completely deleting it), it has to be surrounded by special tags:
On the left of the commented out area, you need "<!--" (no quotes) and on the right, you need "-->"
See the below code block for an example.
Code:
<Is_This_Commented> false </Is_This_Commented>
<!-- <Is_This_Commented> true </Is_This_Commented> -->
Take care
Gary
On my Galaxy S III, the file /system/etc/feature_default.xml appears to contain default settings, and feature.xml can override those defaults. I'm not sure how comprehensive the list of settings in feature_default.xml are, but I would imagine that many of the available ones are covered there.
Thundersnuz said:
On my Galaxy S III, the file /system/etc/feature_default.xml appears to contain default settings, and feature.xml can override those defaults. I'm not sure how comprehensive the list of settings in feature_default.xml are, but I would imagine that many of the available ones are covered there.
Click to expand...
Click to collapse
That's interesting. Which variant of sgs3 do you have? Would you be willing to attach the two files to a reply in this thread (or point me to someplace I can find the firmware your using to investigate?)
Thank you
Gary
It would be amazing if we could somehow enable auto-replace on the samsung keyboard. I ended up switching to swiftkey because of how many mistakes I've been making with the stock keyboard, but now I don't get to take advantage of swipe, stylus writing, or the one-handed features...
UCLAKoolman said:
It would be amazing if we could somehow enable auto-replace on the samsung keyboard. I ended up switching to swiftkey because of how many mistakes I've been making with the stock keyboard, but now I don't get to take advantage of swipe, stylus writing, or the one-handed features...
Click to expand...
Click to collapse
I completely agree, but I wasn't able to get it working when tinkering with the CSC values (as noted in the corresponding post.) Perhaps there's some other combination of values that might get it going.
Please give it a try and let us know how it works out.
Take care
Gary
Removing the NFC icon from the staus bar is awesome but has anyone tried switching this line;
<CscFeature_NFC_DefaultCardModeConfig>DISABLE</CscFeature_NFC_DefaultCardModeConfig>
To enable? Im not sure why att would "block" this feature, especially with google wallet getting more support for non-nfc devices.
Sent from my SAMSUNG-SGH-I317 using xda app-developers app
MonsterBandit said:
...but has anyone tried switching this line...
Click to expand...
Click to collapse
I'm not sure why people keep asking if other people have done this, that, or the other thing. TRY IT and let us know what happens.
garyd9 said:
I'm not sure why people keep asking if other people have done this, that, or the other thing. TRY IT and let us know what happens.
Click to expand...
Click to collapse
fair enough...thanks btw...im slowly growing the courage to make changes and explore deeper into these devices...changed the value to "ENABLE" (minus the quotes) and seemingly nothing changed. Google Wallet app still says Not supported. That might be on Google Wallet's end tho. I guess the better question might be has anyone with a Note 2 gotten Google Wallet to work?
When I first got my GN2 running stock, carrier billing worked. I then flashed Jedi 3.3, and it disappeared. I remember that on my HOXL, someone mentioned a fix on the build.prop. Is there anything I can do on the GN2's build.prop to get my carrier billing back?
I'm on AT&T by the way.
silentecho13 said:
When I first got my GN2 running stock, carrier billing worked. I then flashed Jedi 3.3, and it disappeared. I remember that on my HOXL, someone mentioned a fix on the build.prop. Is there anything I can do on the GN2's build.prop to get my carrier billing back?
I'm on AT&T by the way.
Click to expand...
Click to collapse
this is pretty much a how to thread ..
you seem to be having issues with a rom , you should post in there ..
here is how I fixed it in previous roms ..
compare your build.prop form your att rom to the one you are using ..
and add / replace with the att stuff .