hamiltont / clasp Goto Github PK

This can involve asking Clasp, for example, to run tasks across a full factorial or LHS of configuration options.

Also add method to build an avd given a configuration object

Currently, the personas module is hard-coded to load a persona on an emulator before the emulator has finished booting: https://github.com/bamos/ataack/blob/master/src/core/phones.scala#L158

This works for a small number of hooks, but restructuring this could be advantageous. The idea would be a function add_emulator_prehook and store a list of functions to execute before saying an emulator has booted.

This would allow users to give Clasp custom hooks to load whatever they want onto the emulators, and would also better organize our code.

If you use netcat to listen on an arbitrary socket, and then direct Android's
radio socket (an emulator command line parameter) to talk on that socket, you
start getting some protocol for communication. There are a number of
recognizable messages if you do something like send an SMS message from the
device.

I'm wondering if that protocol is the one defined in this document:
http://m10.home.xs4all.nl/mac/downloads/3GPP-27007-630.pdf

A lot of the commands in that document look familiar, I may have seen them when
I was playing with this radio thing. If this is the right protocol, perhaps we
can find a library or create one that allows us to read/write to this protocol
and interface with the radio chip on Android devices in a more comprehensive
manner.

would be awesome.

The end goal would be similar to: https://www.manymo.com/ (which uses noVNC apparently)

Relevant technologies:
noVNC
Guacamole

The profiling application needs to be upgraded before we can run more experiments.

As we add modules such as emulator communication and Docker containers, having the resource utilization of modules will be useful.

Because Android changes so much between versions, and
because configuring personas with adb isn't very well documented
or in use, there will probably be a lot of difficulties setting
personas across multiple versions.

A good first step to addressing this would be to write tests
across many different Android versions to locate areas where
parts of personas are not set, and then document those in
personas.scala. (This issue)

Next, separate cases should be put in here to handle
each version and pass the tests. (https://github.com/bamos/ataack/issues/46)

• Update termination conditions to catch and graceful term even if someone
  sends us signal 15 via the kill command
• Upon shutdown request, system waits 10 seconds then requests a non-graceful
  termination. However, while waiting for user input the system could
  successfully terminate, in which case the prompt should be abandoned to allow
  the system to finish termination
• When a node has a java process running on it, Clasp won't fully terminate.

It would be good to have and always-on daemon that clients could
connect to remotely and either query for current jobs or submit
jobs to. Eventually this daemon would likely also serve the website.
I'm thining something like docker's setup where they have a daemon
that exposes a REST API to connect to and query for container
information.

EmulatorBuilder doesn't check if the AVD was actually created before trying to start it

Because Android changes so much between versions, and
because configuring personas with adb isn't very well documented
or in use, there will probably be a lot of difficulties setting
personas across multiple versions.

A good first step to addressing this would be to write tests
across many different Android versions to locate areas where
parts of personas are not set, and then document those in
personas.scala. (https://github.com/bamos/ataack/issues/45)

Next, separate cases should be put in here to handle
each version and pass the tests. (This issue)

this could allow someone to configure aws, launch our code, then decommission aws automatically when done

TODO: Write this section.

From @hamiltont on September 11, 2014 17:1

The system is unable to shutdown cleanly when using --local

It's currently a bit murky what happens when you run multiple ActorSystems on the same host (either as master or clients), and what happens when you run multiple emulators on the same host. Generally separate runs of clasp and separate project running within the same clasp system should not bump into each other. Roughly speaking, that's filesystem and process isolation.

Emulators should probably live within a virtual environment that can isolate their process from the system. Along these lines, would it be possible to build a docker container for each emulator and limit the system resources? Each container could also isolate an instance of the adb server and the filesystem that's used by that emulator. If we set it up right, the default docker filesystem would already contain 90% of the data needed by the emulator (e.g. system.img, etc) and performance would essentially be unaffected. To start going down this road we could 1) get an emulator running inside docker, 2) ADB running inside docket, 3) adb ports forwarded outside docker to the host system running clasp's client ActorSystem. At this point we can experiment with changing the docker container size and see if we can figure out at what point an emulator starts to fail. This approach may have the added benefit of allowing us to snapshot easily (without relying on Android's buggy snapshot functionality).

Add options on both initialization and tear-down for finer sdcard control.

Provide an SdcardOptions class containing:

• [bool] Initialize emulators with sdcards,
• [int] Size of sdcards,
• [bool] Wipe sdcards at boot.

Add an option to delete all sdcard images on shutdown

This module would allow someone to specify that the emulators should receive sensor data

That's pretty easy, actually we got it working. We should define a common interface for a configuration and that's all. It would be require to add at least, a solver (e.g. http://www.emn.fr/z-info/choco-solver/ ), and 2/3 FaMaClasses (we can pack them inside a jar or put them directly in a different package inside your structure).

Regarding the 2nd question. There is already a mechanism for that. Basically we tell the reasoner to use a staged configuration, lets say (Android4:0, WVGA:1 ...), so the solver will return as many possible valid configuration fits that staged configuration. Moreover, that's the mechanism used to enable attributes per feature/device so we can only run devices that takes less than XXX time to start ... still unsure if the time per feature makes any sense but the mechanism is in there :)

So yes, I think it wont be a problem to code that. Maybe it takes 1/2weeks in the worst case.

Saludos
José Ángel Galindo Duarte

....

José,

What I'm thinking, is would it be hard for you to write a Java class that had an interface like this that we could then all use:

public class AndroidSimpleConfigurationFactory {
public List getAllValidConfigurations();
}

If the only method needed was "getAllValidConfigurations()" - how much code (and/or dependencies) would it take to wrapper your existing software and expose just this method? I feel like we could then build a unit test suite that told us how many of these configurations we could run, and allow passing in a Configuration when creating an emulator. I think you started on this already, but the question is more relevant now that you have a completed software suite ;p

If that's not too crazy, how hard would it be to extend the SimpleConfigurationFactory above into the ComplexConfigurationFactory below? The "getConfigurationsWithXXX" are a pretty poor mechanism to constrain the returned configurations, you probably have something more elegant in mind.

public class AndroidComplexConfigurationFactory {

• public List getAllValidConfigurations();
• public List getConfigurationsWithScreenSize(ScreenSize);
• public List getConfigurationsWithAndroidVersion(int version);
• etc
  }

How can we build tests that show that clasp is working properly across code changes? Examine how scala/akka projects do testing. We should probably separate core tests from module tests.

Behavioral analysis of Android applications at runtime is a trending
topic, initially explored by Shabtai \etal \cite{shabtai2012andromaly}.
Profiling information for behavioral analysis includes device resource
utilization, such as battery usage, IPC, and network traffic.
We use a user-space Android application to collect the features
listed in Table~\ref{tab:features}.

• Add the functionality within EmulatorActor to restart an emulator.
• Once we have rebooting, add a flag to wipe the device when
  rebooting, and test this thoroughly.
  I've had issues wiping an entire device before.
  Reset system and user information.

System call analysis of Android applications at runtime is
well-researched. However, analysis of logging information for behavioral
analysis at runtime is unexplored.
This experiment shows initial results from applying text-based
machine learning classification on unmodified Android logs.
Modifying the Android logging mechanism to apply machine learning
models to the log before flushing to file
could be an effective dynamic malware detection scheme
for industry-secure Android systems.

If using -w 0 to specify zero workers, then the system is unable to shut down properly

From @bamos :

Zhou and Jiang \cite{zhou2012dissecting} released
1260 malicious applications grouped into 49 families
to the research community.
This experiment trains classifiers with the earliest 47 families
and all benign applications from Google Play.
We observe the performance of the detection methods on the
2 latest families in the dataset, KMin and RogueLemon.
Dynamic detection techniques, in theory, are advantageous to
detect new malicious applications and families.

Reference: http://stackoverflow.com/questions/14966414
Trying to use tools/pack-sigar.sh.

Would be really cool to tie this into the GUI.

http://cs.gmu.edu/~astavrou/research/Behavioral_Analysis_Android.pdf
"To achieve that, we developed a comprehensive software inspection framework."

Create logic to automatically inject root CA into emulator cacerts file,
add options for redirecting traffic to a proxy that now has the ability to MITM the
emulator. See http://intrepidusgroup.com/insight/2011/08/setting-up-a-persistent-trusted-ca-in-an-android-emulator/
and http://www.floyd.ch/?p=244 and http://www.portswigger.net/burp/downloadfree.html
and https://github.com/wuntee/androidAuditTools

This is definitely an engineering idea, but could be cool.

My pitch:
Many research areas, such as mobile compilation, malware
detection, and continuous authentication,
benefit from obtaining profiling information
from Android applications.
Profiling information can be at the system-level
(memory, CPU, and power utilization every 15 seconds) or
application-level
(number of system calls of each application every 15 seconds).
Mobile devices have severe power limitations, and
querying the device every 15 seconds is expensive.
Therefore, profilers should collect a minimal set of information
to minimize resource overhead of the profiler itself.

Current profilers have to be written by hand and can involve
parsing kernel-specific formats from the proc filesystem.
Furthermore, development of applications could require
a user to constantly trim and add information.

This idea is to make a profiler library to allow users to easily
select different features they want to profile, allowing
a researcher without a profiler to bootstrap from our library,
and allowing a researcher exploring different options to
easily change the settings in our library rather than modifying
code by hand.

http://eprints.pascal-network.org/archive/00004171/01/2008-dimva.pdf

http://link.springer.com/chapter/10.1007/978-3-642-39235-1_3

If "android list targets" is empty, then creation of an emulator will always
fail. The failure currently happens when a new emulator is constructed, but it
should happen sooner and a more intelligent error message should appear. When
the framework starts a Node, that Node should cache the available targets and
something should predict from the EmulatorConfig that the emulator boot will
fail. More importantly, we can likely auto-fix the issue by calling 'android
update sdk --no-gui' on the command line.

Randomly generate names, emails, phones, photos.

This is because websockify does not react to SIGTERM. The hack is just to close all the browser windows that were VNC'ed to the emulators. The proper fix is to wrap scala's Process method into a different thread and use kill -9 when on linux :-/