Android Studio 2.0にアップデートしたら「Error:Cannot configure the 'publishing' extension after it has been accessed.」というエラーが出て数時間無駄にした話
忌々しきエラー:
Error:Cannot configure the 'publishing' extension after it has been accessed.
いくら調べても調べても解決できないので新しくプロジェクトを作り直してライブラリの追加〜からやり直していったらVolleyライブラリを追加したところで当該エラーが発生していることが判明した。
とりあえずの解決策としてはvolleyのbuild.gradle内の「apply from: 'bintray.gradle'」をコメントアウトすると良いらしく、自分もコメントアウト後は問題なく動作した。しかし原理は不明である（おそらく根本の原因はbintray.gradle内のpublishing〜の記述周りだと思うので時間があったら調べてみたい...）
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:2.0.0'
}
}
apply plugin: 'com.android.library'
repositories {
jcenter()
}
android {
compileSdkVersion 22
buildToolsVersion = '22.0.1'
}
apply from: 'rules.gradle'
// apply from: 'bintray.gradle' ← コメントアウト！！！スタックオーバーフローに圧倒的感謝:)
stackoverflow.com
2016/04/14 追記
git submodule addでライブラリを追加していたためにトラブルが発生したらしい…mavenのリポジトリにアップロードされているライブラリはdependenciesに記述する方法でライブラリ追加する方が簡単だしトラブルにもなりにくいだろう…
解決までの手順
- git submodule deinit -f volleyのパス
- git rm -f volleyのパス
- build.gradleに「compile 'com.mcxiaoke.volley:library:1.0.19'」を追加
- 設定のVersion ControlからVolleyを削除（右上のポップアップからConfigureで移動できる）
- ビルドからClean Projectを行った後でRun！
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
testCompile 'junit:junit:4.12'
compile 'com.android.support:appcompat-v7:23.2.1'
compile 'com.android.support:design:23.2.1'
// compile project(':modules:volley') // ← 削除
compile 'com.mcxiaoke.volley:library:1.0.19' // ← 追加
}
AndroidにおけるUID(Uniqe IDentifier)とその取得方法の一覧
Androidにおける端末を個体識別する目的で利用可能なIDとその取得方法をまとめる．※ importやpermissionの記載は割愛
端末ID（IMEI）
// TelephonyManagerを利用するアクセス TelephonyManager tm = (TelephonyManager)getSystemService(TELEPHONY_SERVICE); String imei = tm.getDeviceId(); // SystemPropertiesを利用するアクセス String imei = android.os.SystemProperties.get(android.telephony.TelephonyProperties.PROPERTY_IMSI);
端末のソフトウェアバージョン
// TelephonyManagerを利用するアクセス
TelephonyManager tm = (TelephonyManager)getSystemService(TELEPHONY_SERVICE);
String deviceSvn = tm.getDeviceSvn();
端末ソフトウェアバージョン番号（IMEI/SV）
TelephonyManager tm = (TelephonyManager)getSystemService(TELEPHONY_SERVICE); String imei_sv = tm.getDeviceSoftwareVersion();
加入者ID（IMSI）
TelephonyManager tm = (TelephonyManager)getSystemService(TELEPHONY_SERVICE); String imsi = tm.getSubscriberId();
SIMシリアルID（ICCID）
TelephonyManager tm = (TelephonyManager)getSystemService(TELEPHONY_SERVICE);
String iccid = tm.getSimSerialNumber();
// String iccid = tm.getIccSerialNumber();
電話番号（GSMのMSISDN）
TelephonyManager tm = (TelephonyManager)getSystemService(TELEPHONY_SERVICE);
String line1Number = tm.getLine1Number();
// String msisdn = tm.getMsisdn();
GSMのアルファベットタグ
TelephonyManager tm = (TelephonyManager)getSystemService(TELEPHONY_SERVICE); String line1AlphaTag = tm. getLine1AlphaTag();
ボイスメール名
TelephonyManager tm = (TelephonyManager)getSystemService(TELEPHONY_SERVICE); String voiceMailAlphaTag = tm. getVoiceMailAlphaTag();
ボイスメール番号
TelephonyManager tm = (TelephonyManager)getSystemService(TELEPHONY_SERVICE); String voiceMai = tm.getVoiceMailNumber();
Android ID（OS初回起動時に生成される16桁の乱数=端末ID）
String udid = Settings.Secure.getString(getContentResolver(), Settings.System.ANDROID_ID);
MACアドレス
WifiManager wifi = (WifiManager)getSystemService(Context.WIFI_SERVICE); String mac = wifi.getConnectionInfo().getMacAddress();
UUIDの生成例
public class Installation { private static String sID = null; private static final String INSTALLATION = "INSTALLATION"; public synchronized static String id(Context context) { if (sID == null) { File installation = new File(context.getFilesDir(), INSTALLATION); try { if (!installation.exists()) writeInstallationFile(installation); sID = readInstallationFile(installation); } catch (Exception e) { throw new RuntimeException(e); } } return sID; } private static String readInstallationFile(File installation) throws IOException { RandomAccessFile f = new RandomAccessFile(installation, "r"); byte[] bytes = new byte[(int) f.length()]; f.readFully(bytes); f.close(); return new String(bytes); } private static void writeInstallationFile(File installation) throws IOException { FileOutputStream out = new FileOutputStream(installation); String id = UUID.randomUUID().toString(); out.write(id.getBytes()); out.close(); } }
複数のUIDを組み合わせたUUIDの生成例
TelephonyManager tm = (TelephonyManager) getBaseContext().getSystemService(Context.TELEPHONY_SERVICE); final String tmDevice = "" + tm.getDeviceId(); final String tmSerial = "" + tm.getSimSerialNumber(); final String androidId = "" + Settings.Secure.getString(getContentResolver(), android.provider.Settings.Secure.ANDROID_ID); UUID deviceUuid = new UUID(androidId.hashCode(), ((long)tmDevice.hashCode() << 32) | tmSerial.hashCode()); String deviceId = deviceUuid.toString();
参照：java - Is there a unique Android device ID? - Stack Overflow
A Machine-learning Approach for Classifying and Categorizing Android Sources and Sinks を読みました
FlowDroidというAndroidにおける静的テイント解析の中ではおそらく最先端の論文を読んでいたら，「FlowDroidはそのソースとシンクにSuSiプロジェクトで推測されたソースとシンクを用いている」との記載があったので読みました．自分の研究でも静的解析の際にソースとシンクのリストが必要だったのでとてもありがたいです．
機械学習についてはまったく詳しくないどころかあまり興味もない分野なのですが，どのようにソースコードからソースとシンクを分類したのかが純粋に気になりました．なんとも優しいことに，教師あり学習の分かりやすい例について第4章のA項で丁寧に説明してくれるありがたい論文でした．分類器の訓練にはソース/シンクであるかどうかがアノテーションされた訓練データを使用する教師あり学習を使用しています．その分類には意味的・構文的な特徴とデータフロー特徴(粗い近似の静的テイント解析でソースからシンクへのデータフローがあったかどうか)が組み合わせて使用されます．評価の中で一番気になっていた，マルウェアで最も利用されているソースとシンクですが，そのうちの多くが研究当時の分析ツールにおいて検出できていないことが分かります(評価の項の図を参照)．
評価や機械学習の項は大分アバウトに纏めているので詳細については原文をお読み下さい．また，ソースとシンクのリストについてはGitHubで公開されています．
github.com
あらまし
スマートフォンユーザがインストールする多くのアプリケーションは，センシティブな情報へのアクセスを行っており，開発者によって言及されていたとしても，その信頼性を判断するのは困難である．この問題に対して，研究者はより洗練された静的および動的解析ツールを研究開発することによってこの問題に対処してきた．しかしながら，これらのツールは信頼できないオブザーバにデータを漏洩する可能性のあるシンク，および，センシティブなデータのソースのリストを手動で構成しなければならなかった．ソースおよびシンクとなる可能性のある全てのAPIを手動で網羅することは現実的ではない．
そこで，著者らは機械学習アプローチによってAndroidにおけるSourceとSinkを特定するSuSiを提案している．ソースおよびシンクであるかどうかが手動で注釈付けされたトレーニングセットを与えることで，SuSiはAPI全体のソースとシンクを自動的に特定する．また，SuSiはさらにソースとシンクを特定のカテゴリに分類している．
Android4.2においてSuSiは数百ものソースとシンクを92%以上の精度で特定し，その多くが既存のテイント解析ツールでは見落とされているものであった．約11,000のマルウェア検体の評価により，これらのソースとシンクの多くが実際に使用されていることを確認している．また，SuSiがGoogle GlassやChromecast APIにおける未知のソースとシンクをも確実に分類できることを示している．
モチベーション
ソースとシンクの包括的なリストを用意するのは難しく，既存研究ではソースやシンクとして非常によく知られているAndroid APIメソッドのみが含まれていると言うのが現状である．悪質なアプリケーション開発者は，そのような既存の分析ツールを回避するために，一般的によく知られていないソースやシンクを選択することが可能である．以下に，一般的ではないソースとシンクを利用してデータ漏洩を偽装しようとする例を示す．
void onCreate() { TelephonyManager tm; GsmCellLocation loc; // 位置情報の取得 tm = (TelephonyManager) getContext().getSystemService(Context.TELEPHONY_SERVICE); loc = (GsmCellLocation) tm.getCellLocation(); // ソース: セルID int cellID = loc.getCid(); // ソース: エリアコード int lac = loc.getLac(); boolean berlin = (lac == 20228 && cellID == 62253); String taint = "Berlin: " + berlin + " (" + cellID + " | " + lac + ")"; String f = this.getFilesDir() + "/mytaintedFile.txt"; // シンク FileUtils.stringToFile(f, taint); // ファイルを誰でもリード可能にする Runtime.getRuntime().exec("chmod 666 "+f); }
このシナリオでは，2つのソースメソッドが利用される．まず，getCid()を呼び出してセルIDを取得している．次に，getLac()を呼び出して，エリアコードを取得している．両方のピースを組み合わせることで，現在のGSMセルにサービスを提供する放送塔を特定することができる．これは，正確な場所ではないものの，ユーザのおおよその居場所を提供する．上記のコードでは,ドイツのベルリンでよく知られているセルタワーIDをチェックしている．実際の悪質なアプリは，より包括的なリストで位置検索を実行する．
最後に，取得したデータを攻撃者が利用できるようにする必要がある．上記コードでは，パーミッションなしで他のアプリケーションからアクセスすることができるファイルを携帯端末の内部ストレージに作成する．Javaの通常のファイル書き込み関数を使用する代わりに，このコードは通常SDKから隠されているあまり知られていないAndroidシステムの関数を使用している．
上記の攻撃は，著者らが実際に検査したマルウェアの代表的な例である．Fortify SCAやSCanDroid，IBM AppScanやTaintDroidなどの公に利用可能な静的および動的テイント解析ツールでこの攻撃例をテストしたところ，これらのツールのいずれも漏洩を検出しないことを確認している．これは，悪質な動作を検出するためのソースおよびシンクの包括的なリストを生成することが，いかに重要であるかを示している．SuSiはこの例で使用されるすべてのソースとシンクを発見して，適切に分類することが可能である．
ソースとシンクの定義
ソースとシンクを推測する前に，まず「ソース」と「シンク」という用語の正確な定義が必要となる．いくつかのテイント/情報フロー解析の分野ではソースとシンクが議論されているが，これらの用語の正確な定義については開示されていない．トレーニングデータをより良いものにするためには正しい用語の定義が欠かせない．テイント解析ではプログラムを介してデータの流れを追跡する．ソースは，プログラムのどこで追跡するデータの入力が行われたかであり，シンクはデータがどこでプログラムから離れたかを示している．以下に，各用語の厳密な定義を示す．
データ
データは値であるか，または値を参照するものである．
Androidシンク
シンクは，新しい値が書き込まれているか，または，既存のリソースに上書きされた場合に，アプリケーションコードから少なくとも1つの非定数データ値をパラメータとして受け取っている「リソースメソッド」への呼び出しである．
例えば，IMEI情報は「データ」の一部であり，IMEI情報を読みだすためのメソッドTelephonyManager::getDeviceId()はリソースメソッドである．そして，getDeviceId()メソッドはAndroidソースである．これは，アプリケーション内に，すべての携帯端末において異なる値（すなわち非定数値）である値を返すリソースメソッドだからである．一方，SmsManager::sendTextMessage()メソッドは特定の電話番号にテキストメッセージを送信するリソースメソッドであり，そのリソースはGSMネットワークである．また，sendTextMessage()メソッドはAndroidシンクであり，これは非定数値であるメッセージテキストと電話番号をパラメータとして受け取るリソースメソッドらかである．
分類アプローチ
(Poster LearningSourceSinksより)
上図は，SuSiの全体的な概要を示している．SuSiは学習において2つのラウンドを実行する．入力フェーズでは，Android APIメソッド（ラベル無しデータ）と，訓練された分類器，特徴データベースを用意する．第1ラウンドではソースか，シンクか，またはそれ以外であるかどうかを分類して，第2ラウンドでは第1ラウンドの結果，ソースとシンクに選ばれたものを特定のカテゴリに分類している．トレーニングデータは手動でソースおよびシンクであるかどうかが注釈付けされたラベルデータからランダムに選ばれたもので作成される．出力フェーズにおいて，ソースとシンクの分類リストを出力する．
分類において最も重要となる特徴データベースであるが，著者らはAndroidのメソッドを分類するために144の構文的および意味的な特徴のセットを用意している．単一の特徴だけでは，与えられたAndroidのメソッドがソース，シンク，またはそのどちらでもないかを決定するために明らかに不十分である．しかしながら，すべての特徴を組み合わせることで，非常に正確に分類器を訓練することが可能となる．その主な理由は，Androidフレームワークの多くの開発者が実際には一定の規則的なコーディングスタイルに従うか，または新たなものを実装する際に既存のメソッドの実装の一部を複製するからである．これらソフトウェア開発の社会的側面が，コードベースにおける規則性と冗長性につながっており，著者らの機械学習アプローチに適していると考えられる．
具体的にSuSiは以下の1st Runの分類における特徴クラスを使用している．例えば，「メソッド名がgetで始まる」特徴クラスなど．
- メソッド名
- パラメータを持つメソッド
- 戻り値の型
- パラメータの型
- インタフェースとなるパラメータ
- メソッドの修飾子
- クラスの修飾子
- クラス名
- 戻り値へのデータフロー
- シンクメソッドへのデータフロー
- 抽象シンクメソッドへのデータフロー
- 必要なパーミッション
また，2nd Runのカテゴリ分類における特徴は以下のようにグループ化されている．例えば，「Contacts」や「SmsManager」など特定の文字列を含んでいるかなど．
評価
10分割の交差検証より，ソース/シンク/それ以外を約92%の精度で特定できることが示されている．また，訓練した分類器によってChromecast APIやGoogleGlass APIのソースとシンクを分類してマニュアルでその成否を検証したところ，Chromecast APIについては適合率・再現率ともに100％，Google GlassAPIについては98%の適合率と100％の再現率であった．
上図は，約11,000のマルウェア検体で最も頻繁に使用されているソース(上段)とシンク(下段)，および著名な解析ツールにおける検出結果の表であり，研究当時ではTaintDroidやSCanDroidといった著名なツールにおいても特定のソースとシンクについては検出できていないことが分かる．
リミテーション
SuSiはその「ソース」の定義上，コールバックメソッドを発見することができない．すなわち，位置情報を取得するために利用されるonLocationChangedのようなコールバック関数にはSuSiは適用できない．しかしながら，Andoroid OSにおける，コールバックインタフェースの数は，マニュアルで検査するには十分に少ない数しかなく，すべてのコールバックメソッドを既知の小規模なデータセットとして定義することで，静的解析の際に検出可能となるだろう．
また，Androidでは，XMLファイルを介してレイアウト制御を定義している．ソースコード内で，システムのfindViewByIdメソッドに渡されたIDによって，ラベルやボタン，パスワードフィールドへの参照を返すことになる．このように，IDに応じて，このメソッドはソースになるかどうかが変化するため，正確な分析のためにはAndroidのリソースシステムをモデル化しなければならない．UIソースがパスワードフィールドのみに制限されれば問題ないが，全ての入力フィールドをソースとして認識する場合には，多くのフォルスポジティブに繋がる可能性がある．
ハッカソン初参加
自身のための備忘録です。
1月23日に福井情報システム工業会さん主催で開催された防災アプリハッカソンに参加してきました。(内定者合宿を除けば)初めてのハッカソンということで、期待と不安が入り混じるような感じで始まりました。
私のチームは全員がハッカソン初参加でした。自己紹介から始まり、お昼までにメンバーで1時間半をかけてアイデア出しをして、午後にアプリ実装と発表資料作りを分担して作業しました。が、最終的には自分が担当していた部分で「動くもの・見せられるもの」が出来上がらないまま時間切れとなってしまいました。
たくさん反省点はあるのですが、3点だけピックアップします。
1. 前日にアイデアを練ってはいけない
ハッカソンテーマは事前に分かっていたので、前日に一人でアイデアを練りに練ってのぞみました。
まず、既存の避難所アプリをいくつか見つけて来て機能の列挙や差別化されている点などをまとめました。例えば、「みたチョ」というアプリは普段からアプリ使いを行わせるために防災グッズと交換できるポイントを貯められる広告システムを備えています。
ハッカソンのテーマとして「避難アプリにゲーム性をもたせる」というのがありました。このテーマの元となっているのが、福井県オープンデータコンテストのアイデア部門で最優秀賞となった「街の防災はかせくん」というアイデアになります。
最近の避難所アプリは災害時の通信混雑・断絶を考慮してオフラインでも利用できることが求められます。ゲーム性を持たせることでアプリ利用を促進し、（一度でも使ってもらえれば）避難所情報やマップタイルのキャッシュを保持しておけるため、このアイデアは優れているなと個人的に感じました。
他にも、ゲーム性をもたせる場合はターゲットユーザが子どもか子供を持つ親になるだとか、お年寄りにはどうしようとか、GoogleのDirections APIでは最短の経路をナビすることはできるけれども、そこに本当に道があるのかとか、そこが安全な道であるかは考慮されていないんだとか、前日数時間かけてうんうん考えてきました。
で、個人的なアプリ案として自宅から最寄りの避難所までをトラッキングして、かかった時間やルートなどを保存して避難ランキングのようなものを作成する避難訓練アプリを考えてきました。最短避難経路情報を家族などで共有できるような用途を考えていました。災害時には保存してあった最短避難ルートを利用したり、小学生が自由研究（避難経路マップ作成など）にも利用できるよう考えていました。
このようなアイデアを前々から考えておくというのは「ハッカソン」を行う上では愚かな行為でした。ハッカソンは一人で行うものではないからです。他人のアイデアと自分のアイデアが不一致した時に軋轢を生みかねません。最悪、前日考えるにしても既存のアプリにどんなものがあるのかとか、使えるデータやAPIの情報をチーム内で共有する程度に留めた方が良いかなと思いました。
2. 時間の見積もりが甘かった
時間と作業の見積もりです。時間が限られているのに昼食に時間がかかりすぎてしまった、などです。お昼は近くのお蕎麦屋さんに行きました。てっきり他のチームもお蕎麦屋さんに来ているのではと思ったのですが、どうやら作業時間を考えて早く食べて出られるお店を選択していたようです。
お昼に食べた亀蔵のかき揚げおろしそば、かき揚げの大きさに圧倒されました。かき揚げは思ったほど油っこくなくおろし汁を少しかけて崩しながら食べましたが、とても美味でした:)
蕎麦は美味しかったのですが、混んでいたため出てくるまでに少し時間がかかり、お昼休憩にかかった時間が移動込みで1時間、会場に戻ったところで発表の時間まで2時間半しかありませんでした。今回はWebアプリの開発ということだったのですが、僕はWebアプリ開発に関しては正直言って初級者です。とりあえず、発表までに動くレベルのものを目指して、福野さんの1日1創アプリのソースを眺めながら手を加えていきました。マップ上にルートを描画する機能とクイズの問題を生成する機能、クイズ座標と自座標の接近判定までは作成できましたが、クイズ座標に近づくとクイズがポップアップするという肝心要の機能までは作成できませんでした。
3. こだわってはいけない
ハッカソンは開発にかけられる時間が限られていました。今回の場合は特にそれが顕著（昼食込み5時間）でした。開発の途中でクイズの問題をポップアップするダイアログが作成できないという、壁にぶち当たりました。ネイティブアプリだったらカスタムビューやカスタムダイアログを利用できるのですがWebアプリで3択クイズをポップアップさせるのってどうすればいいの？とうんうん悩んでる間にただただ時間が過ぎて行きました。
ここでの最適解ですが、「ポップアップさせる」ということをさっさと諦めて、とりあえず地図の下にクイズの問題と選択する答えのリストを表示するだけでよかったのです…！ここで機転がきかなかったところが非常に悔やまれます。これさえできれば見せられるものが出来上がっていたのです。
他のチームでも実装が間に合わなかった部分は見せかけだけにしている部分が結構ありました。
終わりに
ここまで書いたのですが、なんだかんだいって自身の実力の無さが如実に現れた部分が大きいです。同期では僕より5歳年下なのにゴリゴリJSかける変態がいます。俺も負けてられない！！！俺、修論発表終わったらWebアプリ開発勉強するんだ・・・！
次回ハッカソンに参加する機会があれば、上記の点に気をつけつつ柔軟に取り組めるようにします。しましょう。絶対。
UPXにおけるIATのマニュアル再構築 【分析編】
i53.hatenablog.jp
前回の記事でIATについて大雑把に勉強したので、その情報を元にIATのマニュアル再構築を試みます。
# 勉強したてホヤホヤなので間違いなどがあれば是非コメントにて指摘して頂けると助かります...!
続きを読むIAT：インポートアドレステーブルについて
そもそもIATってなんぞ
現状アンパック作業におけるIATの再構築はOllyDumpやImpRecなどのツールアシストで行っていましたがツールが利用できなかったとしたら分析者はマニュアルでこれを再構築する必要が生じます。IATのマニュアル再構築のためにまずIATについて理解しておく必要があります。またIATフックなどのテクニックを利用する場合にもIATの構造を理解しておく必要があります。自身の理解のためにIATについて簡単にまとめました。
# 簡単化のためにRVA(Relative Virtual Address)という単語はすべて(イメージベースからの/仮想アドレスにおける)オフセットという言葉に置き換えています
続きを読む