Check out smali/baksmali on http://jf.andblogs.net
On Tue, Aug 25, 2009 at 3:27 AM, allstars<[email protected]> wrote: > > But for 3rd party apps or apps on Android Market > can the dex or odex be reverse engineered? > e.g. decompile to source code > > thanks > > > > On Aug 25, 8:14 am, Dianne Hackborn <[email protected]> wrote: >> A forward locked app has its resources copied out into another file that is >> made public (so it can take significantly more space in flash that a >> non-forward locked app). >> >> >> >> On Mon, Aug 24, 2009 at 2:22 PM, Scytmo <[email protected]> wrote: >> >> > Thanks for the response, Dianne, but that doesn't tally with my >> > observation about ownership and permissions for 'forward lock' >> > applications. These appear to be stored in /data/app-private, >> > uid=system, gid=app_XX (that is, whatever uid/gid the app has been >> > assigned) with mode=0640 (that is, read-write for uid=system, read- >> > only for gid=app_XX, and no access for world). >> >> > Is my observation about 'forward lock' applications incorrect? Or are >> > there some caveats to applications needing to be world readable? >> >> > Thanks. >> >> > On Aug 24, 8:10 pm, Dianne Hackborn <[email protected]> wrote: >> > > Sorry, there isn't any way to do this. Applications need to be world >> > > readable so that other applications can access their resources -- for >> > > example for a home app to display its icon and label, for intent >> > resolvers >> > > to display icon and label, for an app widget host to inflate the widget >> > from >> > > its resources, for a status bar to display its icon and inflated details >> > > layout, etc. >> >> > > On Mon, Aug 24, 2009 at 2:04 AM, Scytmo <[email protected]> wrote: >> >> > > > Hi, >> >> > > > Is there any way for an OEM to give the same level of protection to >> > > > packages loaded into /system/app as is given to 'forward locked' >> > > > downloaded packages (which are placed in /data/app-private without >> > > > world read permission)? >> >> > > > I understand that the packages in /system/app should have had dexopt >> > > > run, so the APKs do not contain classes.dex, and there is a >> > > > separate .odex file alongside. However, for a package that does not >> > > > require any 'signature' or 'signatureOrSystem' permissions, it seems >> > > > possible to extract the APK and odex, and create a new self-signed >> > > > package. This would appear to need an 'undexopt' step, to get >> > > > classes.dex back from the .odex file - and, while I can't see any >> > > > tools available that would do this at the moment, it doesn't seem >> > > > intractible. >> >> > > > Is there any particular reason why the files in /system/app are world- >> > > > readable? Could a permission scheme like that used in /data/app- >> > > > private be used, uid=system, gid=app_XX, mode=0640? I guess one issue >> > > > would be determining the correct gid. Any other issues with doing >> > > > this? >> >> > > > Scytmo >> >> > > -- >> > > Dianne Hackborn >> > > Android framework engineer >> > > [email protected] >> >> > > Note: please don't send private questions to me, as I don't have time to >> > > provide private support, and so won't reply to such e-mails. All such >> > > questions should be posted on public forums, where I and others can see >> > and >> > > answer them. >> >> -- >> Dianne Hackborn >> Android framework engineer >> [email protected] >> >> Note: please don't send private questions to me, as I don't have time to >> provide private support, and so won't reply to such e-mails. All such >> questions should be posted on public forums, where I and others can see and >> answer them.
