Access ODBC Driver 32bit in x64 bit version Window

That is so strange in Window architecture. As ODBC Drivers are in C:\Windows\SysWOW64\odbcad32.exe in Window x64 but x64 Application can not access to its drivers.

Any application develop based x64 bit version will got this error.

the strange is the connection pointing to 32bit driver version. In the 32 bit registry does not contain any driver path.

but it is exist in x64 path.

Solution:

Solution:

Creating platform specific apps

Most of the language compilers (like C#) now offer a /platform switch. By using this switch, developers can create binaries targeted for a specific platform type or binaries that are platform agnostic. There are four types of binaries that are emitted

· any cpu – platform agnostic

· x86 – 32-bit platform specific

· x64 – x64 platform specific

By default the compilers (like C#) emit anycpu binaries (also called portable assemblies) which are platform agnostic. In case the users want to create binaries specific to a platform, they can use the appropriate switch and be done.

Cross Compilation

The above concept of /platform switch enables cross compilation of binaries. Cross compilation means compiling binaries to a specific platform type (different from the current platform). This is mostly used in terms of compiling and creating 64-bit assemblies from a 32-bit compiler and vice versa. One point to note here is that cross compilation usually refers to compiling to different target types from the compilers shipped with the 64-bit Redist (WoW and 64-bit). The reason for this is that, while trying to compile for a 64-bit platform from a pure 32-bit machine, the 32-bit Redist would not have the components that are 64-bit specific. In such cases the compilation might go through with warning but execution might lead to runtime exceptions. Also, one should note that while cross compiling, users should stick to the platform architecture type of the machine, viz. x64 or IA. Assemblies for IA and x64 are specific to the platform architecture and cross compilation across architectures is not advised.

 

Advertisements

What is Remote Authentication Dial In User Service (RADIUS)?

Remote Authentication Dial In User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for computers to connect and use a network service. RADIUS was developed by Livingston Enterprises, Inc., in 1991 as an access server authentication and accounting protocol and later brought into the Internet Engineering Task Force (IETF) standards.[1]

Because of the broad support and the ubiquitous nature of the RADIUS protocol, it is often used by ISPs and enterprises to manage access to theInternet or internal networkswireless networks, and integrated e-mail services. These networks may incorporate modemsDSLaccess points,VPNsnetwork portsweb servers, etc.[2]

RADIUS is a client/server protocol that runs in the application layer, using UDP as transport. The Remote Access Server, the Virtual Private Network server, the Network switch with port-based authentication, and the Network Access Server (NAS), are all gateways that control access to the network, and all have a RADIUS client component that communicates with the RADIUS server. The RADIUS server is usually a background process running on a UNIX or Microsoft Windows server.[3] RADIUS serves three functions:

  1. to authenticate users or devices before granting them access to a network,
  2. to authorize those users or devices for certain network services and
  3. to account for usage of those services.

AAA

RADIUS servers use the AAA concept to manage network access in the following two-step process, also known as an “AAA transaction”. AAA stands for “authentication, authorization and accounting”. Authentication and Authorization characteristics in RADIUS are described in RFC 2865 while Accounting is described by RFC 2866.

Authentication and authorization

The user or machine sends a request to a Remote Access Server (RAS) to gain access to a particular network resource using access credentials. The credentials are passed to the RAS device via the link-layer protocol – for example, Point-to-Point Protocol (PPP) in the case of many dialup or DSL providers or posted in an HTTPS secure web form.

In turn, the RAS sends a RADIUS Access Request message to the RADIUS server, requesting authorization to grant access via the RADIUS protocol.[4]

This request includes access credentials, typically in the form of username and password or security certificate provided by the user. Additionally, the request may contain other information which the RAS knows about the user, such as its network address or phone number, and information regarding the user’s physical point of attachment to the RAS.

The RADIUS server checks that the information is correct using authentication schemes like PAPCHAP or EAP. The user’s proof of identification is verified, along with, optionally, other information related to the request, such as the user’s network address or phone number, account status and specific network service access privileges. Historically, RADIUS servers checked the user’s information against a locally stored flat file database. Modern RADIUS servers can do this, or can refer to external sources—commonly SQLKerberosLDAP, or Active Directory servers—to verify the user’s credentials.

RADIUS Authentication and Authorization Flow

The RADIUS server then returns one of three responses to the RAS : 1) Access Reject, 2) Access Challenge or 3) Access Accept.

  • Access Reject – The user is unconditionally denied access to all requested network resources. Reasons may include failure to provide proof of identification or an unknown or inactive user account.
  • Access Challenge – Requests additional information from the user such as a secondary password, PIN, token or card. Access Challenge is also used in more complex authentication dialogs where a secure tunnel is established between the user machine and the Radius Server in a way that the access credentials are hidden from the RAS.
  • Access Accept – The user is granted access. Once the user is authenticated, the RADIUS server will often check that the user is authorised to use the network service requested. A given user may be allowed to use a company’s wireless network, but not its VPN service, for example. Again, this information may be stored locally on the RADIUS server, or may be looked up in an external source like LDAP or Active Directory.

Each of these three RADIUS responses may include a Reply-Message attribute which may give a reason for the rejection, the prompt for the challenge, or a welcome message for the accept. The text in the attribute can be passed on to the user in a return web page.

Authorization attributes are conveyed to the RAS stipulating terms of access to be granted. For example: the following authorization attributes may be included in an Access-Accept.

  • The specific IP address to be assigned to the user
  • The address pool from which the user’s IP should be chosen
  • The maximum length that the user may remain connected
  • An access list, priority queue or other restrictions on a user’s access
  • L2TP parameters
  • VLAN parameters
  • Quality of Service (QoS) parameters

Accounting

RADIUS Accounting Flow

Accounting is described in RFC 2866.

When network access is granted to the user by the NAS, an Accounting Start (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value “start”) is sent by the NAS to the RADIUS server to signal the start of the user’s network access. “Start” records typically contain the user’s identification, network address, point of attachment and a unique session identifier.[5]

Periodically, Interim Update records (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value “interim-update”) may be sent by the NAS to the RADIUS server, to update it on the status of an active session. “Interim” records typically convey the current session duration and information on current data usage.

Finally, when the user’s network access is closed, the NAS issues a final Accounting Stop record (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value “stop”) to the RADIUS server, providing information on the final usage in terms of time, packets transferred, data transferred, reason for disconnect and other information related to the user’s network access.

Typically, the client sends Accounting-Request packets until it receives an Accounting-Response acknowledgement, using some retry interval.

The primary purpose of this data is that the user can be billed accordingly; the data is also commonly used for statisticalpurposes and for general network monitoring.

Roaming

Roaming using a proxy RADIUS AAA server.

RADIUS is commonly used to facilitate roaming between ISPs, for example:

  • by companies which provide a single global set of credentials that are usable on many public networks;
  • by independent, but collaborating, institutions issuing their own credentials to their own users, that allow a visitor from one to another to be authenticated by their home institution, such as in Eduroam.

RADIUS facilitates this by the use of realms, which identify where the RADIUS server should forward the AAA requests for processing.

Realms

A realm is commonly appended to a user’s user name and delimited with an ‘@’ sign, resembling an email address domain name. This is known as postfix notation for the realm. Another common usage is prefix notation, which involves prepending the realm to the username and using ‘\’ as a delimiter. Modern RADIUS servers allow any character to be used as a realm delimiter, although in practice ‘@’ and ‘\’ are usually used.

Realms can also be compounded using both prefix and postfix notation, to allow for complicated roaming scenarios; for example, somedomain.com\username@anotherdomain.com could be a valid username with two realms.

Although realms often resemble domains, it is important to note that realms are in fact arbitrary text and need not contain real domain names.

Proxy operations

When a RADIUS server receives an AAA request for a user name containing a realm, the server will reference a table of configured realms. If the realm is known, the server will then proxy the request to the configured home server for that domain. The behaviour of the proxying server regarding the removal of the realm from the request (“stripping”) is configuration-dependent on most servers. In addition, the proxying server can be configured to add, remove or rewrite AAA requests when they are proxied.

Security

Roaming with RADIUS exposes the users to various security and privacy concerns. More generally, some roaming partners establish a secure tunnel between the RADIUS servers to ensure that users’ credentials cannot be intercepted while being proxied across the internet. This is a concern as the MD5 hash built into RADIUS is considered insecure.[6]

Packet structure

RADIUS packet data format.

The RADIUS packet data format is shown to the right. The fields are transmitted from left to right, starting with the code, the identifier, the length, the authenticator and the attributes.

RADIUS Codes (decimal) are assigned as follows:

Code Assignment
1 Access-Request
2 Access-Accept
3 Access-Reject
4 Accounting-Request
5 Accounting-Response
11 Access-Challenge
12 Status-Server (experimental)
13 Status-Client (experimental)
255 Reserved

The Identifier field aids in matching requests and replies.

The Length field indicates the length of the entire RADIUS packet including the Code, Identifier, Length, Authenticator and optional Attribute fields.

The Authenticator is used to authenticate the reply from the RADIUS server, and is used in encrypting passwords; its length is 16 bytes.

Attribute value pairs

RADIUS AVP layout.

The RADIUS Attribute Value Pairs (AVP) carry data in both the request and the response for the authentication, authorization, and accounting transactions. The length of the radius packet is used to determine the end of the AVPs.

AVP Type Assignment
1 User-Name
2 User-Password
3 CHAP-Password
4 NAS-IP-Address
5 NAS-Port
6 Service-Type
7 Framed-Protocol
8 Framed-IP-Address
9 Framed-IP-Netmask
10 Framed-Routing
11 Filter-Id
12 Framed-MTU
13 Framed-Compression
14 Login-IP-Host
15 Login-Service
16 Login-TCP-Port
17 (unassigned)
18 Reply-Message
19 Callback-Number
20 Callback-Id
21 (unassigned)
22 Framed-Route
23 Framed-IPX-Network
24 State
25 Class
26 Vendor-Specific
27 Session-Timeout
28 Idle-Timeout
29 Termination-Action
30 Called-Station-Id
31 Calling-Station-Id
32 NAS-Identifier
33 Proxy-State
34 Login-LAT-Service
35 Login-LAT-Node
36 Login-LAT-Group
37 Framed-AppleTalk-Link
38 Framed-AppleTalk-Network
39 Framed-AppleTalk-Zone
40 Acct-Status-Type
41 Acct-Delay-Time
42 Acct-Input-Octets
43 Acct-Output-Octets
44 Acct-Session-Id
45 Acct-Authentic
46 Acct-Session-Time
47 Acct-Input-Packets
48 Acct-Output-Packets
49 Acct-Terminate-Cause
50 Acct-Multi-Session-Id
51 Acct-Link-Count
52-59 (reserved for accounting)
60 CHAP-Challenge
61 NAS-Port-Type
62 Port-Limit
63 Login-LAT-Port

[edit]Vendor-specific attributes

RADIUS is extensible; many vendors of RADIUS hardware and software implement their own variants using Vendor-Specific Attributes (VSAs). Microsoft has published some of their VSAs.[7] VSA definitions from many other companies remain proprietary and/or ad-hoc.

UDP port numbers

RADIUS has been officially assigned UDP ports 1812 for RADIUS Authentication and 1813 for RADIUS Accounting by the Internet Assigned Numbers Authority (IANA). However, prior to IANA allocation of ports 1812 and 1813, ports 1645 and 1646 (authentication and accounting, respectively) were used unofficially and became the default ports assigned by many RADIUS Client/Server implementations of the time. The tradition of using 1645 and 1646 for backwards compatibility continues to this day. For this reason many RADIUS Server implementations monitor both sets of UDP ports for RADIUS requests. Microsoft RADIUS servers default to 1812 and 1813. Cisco RADIUS servers listen on RADIUS ports UDP 1645 and UDP 1812 for authentication; on ports 1646 and 1813 for accounting and can be configured with non-standard ports. Juniper Networks‘ RADIUS servers listen on both unofficial and official ports 1645, 1812, 1646 and 1813 by default but can be configured with arbitrary ports.SBR

Security

The RADIUS protocol does not transmit passwords in cleartext between the NAS and RADIUS server (not even with PAP protocol). Rather, a shared secret is used along with the MD5 hashing algorithm to obfuscate passwords. Because this particular implementation is not considered to be a very strong protection of the user’s credentials,[8] additional protection – such as IPsec tunnels or physically secured data-center networks – should be used to further protect the RADIUS traffic between the NAS device and the RADIUS server. Additionally, the user’s security credentials are the only part protected by RADIUS itself, yet other user-specific attributes such as tunnel-group IDs or vlan memberships passed over RADIUS may be considered sensitive (helpful to an attacker) or private (sufficient to identify the individual client) information as well.[citation needed] The RadSec protocol claims to solve aforementioned security issues.

RADIUS history

RADIUS was originally specified in an RFI by Merit Network in 1991 to control dial-in access to NSFnet. Livingston Enterprises responded to the RFI with a description of a RADIUS server. Merit Network awarded the contract to Livingston Enterprises that delivered their PortMaster series of Network Access Servers and the initial RADIUS server to Merit. RADIUS was later (1997) published as RFC 2058 and RFC 2059 (current versions are RFC 2865 and RFC 2866).[1]

Now, several commercial and open-source RADIUS servers exist. Features can vary, but most can look up the users in text files, LDAP servers, various databases, etc. Accounting records can be written to text files, various databases, forwarded to external servers, etc. SNMP is often used for remote monitoring and keep-alive checking of a RADIUS server. RADIUS proxy servers are used for centralized administration and can rewrite RADIUS packets on the fly (for security reasons, or to convert between vendor dialects).

The Diameter protocol is the planned replacement for RADIUS. Diameter uses SCTP or TCP while RADIUS uses UDP as the transport layer.

Reference : http://en.wikipedia.org/wiki/RADIUS

Google Maps vs. Bing Maps: A Showdown of Satellite Images

Let’s take a head-to-head look at Google Maps and Bing Maps to see which service provides a better view of various locations around the world.

Microsoft has set its sights on Google Maps, adding more than 165 terabytes of new satellite imagery to Bing Maps. This is the biggest ever data release for Bing Maps, which had 129TB of data at its disposal.

Of course, Google isn’t standing pat; the company has added detailed 3D landmarks to its service.

Let’s take a head-to-head look at Google Maps and Bing Maps to see which service provides a better view of various locations around the world.

Hagia Sophia — Istanbul, Turkey

Google Maps vs. Bing Maps: A Showdown of Satellite ImagesLooking at the Hagia Spohia museum in Istanbul, Google Maps’ satellite view has more vivid colors, but Bing Maps has the upper hand when it comes to noticeable details, especially looking at the intricacies of the roof.

Continue…

Reference : http://www.pcworld.com/article/258328/google_maps_vs_bing_maps_a_showdown_of_satellite_images.html#tk.hp_bus

A Beginner’s Guide to Android Kernels

When people mention the advantages of rooting, one of those words that get thrown around a lot is “kernel.” When I first started looking into rooting, I was never quite sure what a kernel exactly was. Obviously it wasn’t a piece of popcorn, but nobody ever sufficiently explained what a it did and why I should be interested in them.

However, once I did figure out what they were it certainly changed my attitude toward them. Swapping out your kernel is one of the best ways to take advantage of rootingand I highly, highly recommend you try it. With the right kernel, you can double your battery life or squeeze it for that extra performance. Understanding this concept is very helpful, and here’s why.

Alright, What’s a Kernel?

The term kernel comes from Linux, which is kind of the forerunner of Android. All Android phones come with a kernel installed on them. It is the communication link between hardware and software. One of its most important functions is Battery usage and the kernel dictates the life of your phone battery.

Your phone ships with the stock kernel. Phone manufacturers like HTC and Samsung are not exactly known for their willingness to take risks. The stock kernel put in your phone by the manufacturers is nice and safe that won’t ever break down.

HTC-logo

The stock kernel provides a constant stream of battery power to the phone. It doesn’t matter if the phone is on or off or using lots of processing power. It sends a steady and totally safe amount of battery.

However, that safety comes with a price. A phone with the stock kernel uses the same amount of power even when not in use. That’s not very efficient. Plus, what if you want to run a processing-intensive app like an N64 emulator? More processing requires more power, but the stock kernel won’t scale up the amount of battery used.

New and Improved Kernels

This is where the Android community comes in. If you’re rooted and have some sort of recovery system like ClockworkMod or Amon-Ra installed, you can flash (install) a new kernel that’s more efficient.

The advantage of custom one is that they can output variable amounts of power. Say you want to save the battery. You can undervolt the phone’s processor. Undervolting is when you tell the kernel to only provide a tiny amount of power for the phone to run.

set-cpu-android-kernel

Undervolting does make your phone lag quite a lot, but its ability to save battery is incredible. I doubled my phone’s battery life with undervolting. A phone modified in this way with a custom kernel can seriously go days without charging.

Alternatively, you can overclock a phone. This is when the kernel outputs large amounts of power, amounts higher than the phone usually uses. This will eat through a battery extremely quickly, but it is great for apps that would lag otherwise (like N64 emulators). Not to mention everything loads extremely quickly when a phone is overclocked.

There are a few risks to installing a new kernel. If you tell it to use an amount of battery that’s too small, there is a chance that the phone won’t be able to turn on. This is called bootlooping, or when the phone cannot access enough power in order to start itself. However, there is a way around bootlooping, as we will discuss later.

Picking a Kernel

There are a million different options out there. That’s probably a good thing, seeing as there are about a million different phone-ROM combinations with Android. Finding a good one for your specific phone and ROM can be a bit difficult, though.

I recommend starting with Kernel Manager Lite. It’s a free app from the Android Market that will list out a couple popular kernels for some of the more popular ROMs like CyanogenMod7 and MIUI.

miui-cyanogen-mod-7-popular-android-custom-roms

When deciding a kernel, people will throw a lot of different terms at you. You’ll see abbreviations like CFS, HAVS, and SBC. Keeping track of what everything means is a chore, so we’ll summarize.

Each abbreviation and item like overclocking and undervolting is a power mode that comes with that kernel.CFSHAVS, and BFS are all power plans that scale the amount of power used up and down, depending on how much battery your phone requests. Each plan scales differently (faster or slower), but the concept is the same.

Terms Commonly Used with Kernels:

  • Completely Fair Scheduler (CFS) is generally more consistent and stable. Stock HTC kernel uses CFS.
  • Brain F*** Scheduler (BFS) is faster and generally gives more battery life but may be a bit inconsistent.
  • Hybrid Adaptive Voltage Scaling (HAVS) manipulates the phone voltage for a better battery life. Performance usually varies for different devices.
  • Static Voltage Scaling (SVS) provides a steady voltage.

You might also see SBC. That stands for Superior Battery Charging. Most phones battery percentage drops to 90% or so right after you unplug it due to the fast rate of charging. SBC charges a battery very slowly it doesn’t lose 10% immediately. Best used for charging phones overnight.

set-cpu-power-scaling-control-management

Undervolting and underclocking are different things but basically accomplish the same thing (saving battery). Overclocking is already explained.

When looking for a kernel, ideally you want one with as many of these features as possible. It’s nice to have choices. A good kernel comes at least undervolting, overclocking, and some sort of scaling plan (like CFS/HAVS/BFS).

If you don’t find any in Kernel Manager that look good, the last resort is lots of Googling. Just search “(your phone) (your ROM) kernels” and something from XDA Developers should come up.

Installing (Flashing) The Kernel:

Once you’ve found that perfect kernel that is compatible with your phone model and ROM, you have to actually install it. Download the kernel from whatever website or Kernel Manager. It should come as a .zip file. Copy that over to your SD card.

For installing a kernel, there are two options. If you pay for Kernel Manager Pro, the app will install the kernel for you. That’s the nice and easy way.

android-kernel-manager

However, it’s not too hard to install a kernel without Kernel Manager. I wouldn’t recommend buying the Pro version. The other way to do it involves booting into recovery. If you don’t know how to do that on your phone, CM7’s wiki has a handy chart.

Once in recovery there are a few things that have to be done to prepare the way for the kernel. First and most importantly, make a nandroid backup of your phone. If anything goes wrong or if the phone gets stuck in an endless bootloop, this is how to fix it. Backups are very important.

There should be an option to “wipe cache.” Choose this and let it run. Next wipe the Dalvik cache. If you don’t see either of those options, look under “advanced” in ClockworkMod.

Now choose to install a .zip and choose the option to pick one from the SD card. Navigate to wherever you put the downloaded kernel. Pick the kernel and let it install. Once it’s finished, reboot your phone.

clockworkmod

If everything went right, then you should have a new kernel. You can check by going to Settings > About phone > Software information and looking under “Kernel.” Hopefully, you’ll see the name of whatever kernel you flashed. Next step, controlling the kernel.

Apps for Kernel Management:

The kernel can work its magic now that it’s installed. However, you have to tell it to do so first. You can manually control it from the settings with certain ROMs like CyanogenMod. Everyone else will need third-party apps like SetCPU and Tasker.

SetCPU is simple and it works. Just tell it which power plan (undervolt, overclock, etc) you want to use and it does it for you. SetCPU works just fine with no glitches or anything. Just be careful how high you set the voltage- I crashed my phone once by overclocking it a little too much.

tasker-scheduler-automatic-power-scaling

However, Tasker is my personal favorite app for the various purposes of controlling my kernel. Tasker automates certain processes, including kernel management. The best feature here is that you can set to app to automatically undervolt your phone every time the screen is off (like when you’re not using the phone).

This small change makes a titanic difference. Now my phone only uses a fraction of its battery power when it sits in my pocket. Instead of lasting about a day on a full charge, I can go twice as long without going near a power cord.

Of course, the ultimate judge of battery is how often you use your phone and how rigorously that usage gets. However, automated undervolting is a fantastic way to cut down on battery drain.

Final Thoughts

Installing a new kernel can be a bit dicey, but when done correctly there’s really a minimal risk. As long as you make a nandroid backup, there’s no reason to not try flashing a new, more efficient kernel. Besides, if you’re scared of diving into recovery mode you can just get Kernel Manager Pro to do the work for you.

Reference : http://www.vikitech.com/8239/beginners-guide-android-kernels

What is a kernel?

Android A to Z

What is a kernel?  If you spend any time reading Android forums, blogs, how-to posts or online discussion you’ll soon hear people talking about the kernel.  A kernel isn’t something unique to Android — iOS and MacOS have one, Windows has one, BlackBerry’s QNX has one, in fact all high level operating systems have one.  The one we’re interested in is Linux, as it’s the one Android uses. Let’s try to break down what it is and what it does.

Android devices use the Linux kernel, but it’s not the exact same kernel other Linux-based operating systems use.  There’s a lot of Android specific code built in, and Google’s Android kernel maintainers have their work cut out for them.  OEMs have to contribute as well, because they need to develop hardware drivers for the parts they’re using for the kernel version they’re using.  This is why it takes a while for independent Android developers and hackers to port new versions to older devices and get everything working.  Drivers written to work with the Gingerbread kernel on a phone won’t necessarily work with the Ice Cream Sandwich kernel.  And that’s important, because one of the kernel’s main functions is to control the hardware.  It’s a whole lot of source code, with more options while building it than you can imagine, but in the end it’s just the intermediary between the hardware and the software.

When software needs the hardware to do anything, it sends a request to the kernel.  And when we sayanything, we mean anything.  From the brightness of the screen, to the volume level, to initiating a call through the radio, even what’s drawn on the display is ultimately controlled by the kernel.  For example — when you tap the search button on your phone, you tell the software to open the search application.  What happens is that you touched a certain point on the digitizer, which tells the software that you’ve touched the screen at those coordinates.  The software knows that when that particular spot is touched, the search dialog is supposed to open.  The kernel is what tells the digitizer to look (or listen, events are “listened” for) for touches, helps figure out where you touched, and tells the system you touched it.  In turn, when the system receives a touch event at a specific point from the kernel (through the driver) it knows what to draw on your screen.  Both the hardware and the software communicate both ways with the kernel, and that’s how your phone knows when to do something.  Input from one side is sent as output to the other, whether it’s you playing Angry Birds, or connecting to your car’s Bluetooth.

It sounds complicated, and it is.  But it’s also pretty standard computer logic — there’s an action of some sort generated for every event.  Without the kernel to accept and send information, developers would have to write code for every single event for every single piece of hardware in your device.  With the kernel, all they have to do is communicate with it through the Android system API’s, and hardware developers only have to make the device hardware communicate with the kernel.  The good thing is that you don’t need to know exactly how or why the kernel does what it does, just understanding that it’s the go-between from software to hardware gives you a pretty good grasp of what’s happening under the glass.  Sort of gives a whole new outlook towards those fellows who stay up all night to work on kernels for your phone, doesn’t it?

Reference : http://www.androidcentral.com/android-z-what-kernel

Reversing Android Apps

First blog post in a long time, so I figured I should start back off with something I’ve been getting a lot of questions about lately, which is how to get started with learning more about Android application security.

I think the absolute best way to understand what’s going on is to start looking at real world applications. This tutorial will show you how to download an Android application and convert it back into a format that we prefer, which is its original Java code. Hopefully this will be the first tutorial of many, so be sure to check back from time to time.

I hope this post can be of use to developers as well, in order to better understand that the code they allow to be distributed on mobile devices can easily be decompiled. If you are storing hardcoded credentials or reference other things you don’t want the user (or bad guys) to know about, you should re-evaluate that design choice.

My disclaimer is that this should not be used for malicious purposes, etc etc and all of the other stuff no one will likely listen to.

To get started, you will need these applications on your box:

Android SDK
dex2jar
apktool (JAR and dependencies)
JD (or a similar Java decompiler)

The first step is to download the Android SDK (Software Development Kit). You will rely on this heavily when testing applications and interacting with Android devices. There are many useful utilities bundled with it including Android Debug Bridge (ADB) and the emulator.

The next step is to download an interesting application to rip open. Most of us are Twitter fans, so why don’t we take a look at the Twitter application for Android?

At this point, you have 2 choices:

-Download it to your physical Android device
-Download it to a virtual device running in the Android emulator

By default, the virtual devices available using the emulator that comes with the Android SDK do not have the Google Market application installed. You can either 1) spend time finding ways around this or 2) install an image that has the software pre-loaded. Here is an excellent tutorial on how to go that route, although you may want to use a more up to date image than the ones referenced. They use older versions of Android.

Android Emulator Tutorial

Assuming you have either plugged your phone in or started an Android virtual machine, in the tools folder of the Android SDK folder, you’ll find several utilities incuding ADB. I recommend familiarizing yourself with it, as you will use it almost constantly if you are working with the Android platform.

ADB allows us to do many things including connect to the device and have shell access. We first need to figure out where the application we downloaded is stored. Under the /data/app/ directory, we will find all of the APK files for applications we’ve downloaded. Under /system/app is all of the applications included with your Android distribution. For this tutorial, we are concerned with /data/app as this is where our Twitter application will be located.

Now that we know what we want to download, we need to transfer the file to our local system for further analysis. This can be achieved also by using ADB.

We will not be using the shell this time, but rather the “pull” command which allows us to select and retrieve files from the Android device. The general format for this command is: adb pull apk_file destination_directory

Now that we have the APK file, we’ll need to unzip it. The APK is simply in standard ZIP format, so any of your existing ZIP compatible utilities will work.

After unzipping the APK file, there are two things you should be primarily concerned with at this point: looking at the manifest file, and getting the .DEX file into a more desirable format to work with. The manifest contains juicy information like permissions, intent filters, and lots more. If you aren’t familiar with the manifest file and how its used with Android applications, I highly recommend reading the documentation on the Android development site:

Manifest Intro

If you try to open the AndroidManifest.xml file that was just unzipped, you’ll find that it isn’t in plain text. We’ll use apktool at this point to convert it into a format we are comfortable with. We’ll use apktool to decode the entire APK, and then the manifest file should be much easier on the eyes:

After running apktool, this is what the AndroidManifest.xml file should look like when viewed in a text editor or Eclipse:

The classes.dex file in the originally unzipped APK file is the crown jewel here. It contains all of the application’s code, but in the Dalvik Executable format.

There are tools such as dedexer and apktool that will convert .DEX into smali assembly format, but again we are concerned with looking at the Java code. We can use dex2jar to achieve this:

dex2jar.bat path_to_classes.dex

Once we’ve run dex2jar, there will be a classes.dex.dex2jar.jar file in the folder where the original .DEX file was located. Simply unzip this JAR file. Upon unzipping it, we see a bunch of .class files.

Nothing to worry about, this is familiar territory at this point. Simply use your favorite Java decompiler to convert from bytecode to easily readable code.

We now have complete access to the entire client application. In the tutorials to come, I’ll show you some things you should be paying close attention to when reviewing or designing an Android application.

 

Reference : http://jack-mannino.blogspot.com/2010/09/reversing-android-apps-101.html