Tracking Variables

From AtlasWiki
Revision as of 13:03, 1 June 2015 by Kscott (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

"Where does this variable come from?"

Atlas can trace the origins of local variables that acquire their values from other areas of code. This is often useful for taking stock of what values a variable can have and under what conditions. Since a variable might have been affected by several other classes, plotting its history can help account for all possible states of the variable you are using. This tutorial outlines the process with a simple case in ConnectBot, an open source Secure Shell client for the Android operating system. The variable we are concerned with is the PrivateKey variable, "priv," used in the method changePassword.


ChangePassword.png


The value of this variable is set by a call to the decodePrivate method in PubkeyUtils. Let's have a look at this method.


DecodePrivate.png


The implementation here is simple; the parameters, encoded and keyType, are passed along to another method of the same name. In the event that a secret is provided, the encoded parameter is first decrypted with a call to decrypt.

This is the first split in the history of our variable, priv.

We can use the Smart View to inspect this method more easily. The Forward Call script will show us all methods called when generating our PrivateKey. Through the course of evaluating this method, eighteen library methods are called from android.jar. For easy viewing, we can click the minimize button in the upper left corner of the graph element to collapse it.


DecodePrivate ForwardCall.png        DecodePrivate LibraryAccess.png


This graph provides insight into a few points of interest. The conditional call to decrypt represents the bulk of the calls required for this operation. After encoded is decrypted, the rest of the work is handled in the overloaded method decodePrivate. Clicking on this method shows what library calls it makes in decoding.

Now we know that a data flow analysis extending as far as this method will show us information that is exchanged in generating our PrivateKey. The Connection View can build this dataflow graph for us. Enter changePassword in the Roots pane and decodePrivate into the Leaves pane of the view.


Dataflow in.png


The Connection View shows the two parameters being passed around, across package lines. They find their way into local variables in the decodePrivate method closest to the the Android library. One informative feature of the graph is the absence of dataflow within this method. This shows that decodePrivate performs no logical operation on either parameter before using them in library calls. We can expose all dataflow within this method by adding it to the Roots pane as well as Leaves.


DataflowWithinMethod.png


Here, the functionality of decodePrivate is revealed to us. The private key and key type are provided to the security library to get a KeyFactory and EncodedKeySpec. These, in turn, are sufficient for generating the PrivateKey that is returned to us in our changePassword method.

We might remember, from the source code we viewed earlier, that the result of this method will be the same as what gets assigned to the variable priv. No other adjustment is made to the value before we acquire it. We can confirm this assertion by following the return value as it flows back to the variable assignment in question. The Connection View can display this flow; we need only swap the contents of Roots and Leaves. This is accomplished either by clicking the swap button or by clicking and dragging to obtain the desired configuration.


Dataflow out.png


Back to Learning Atlas