Auraboxで遊ぶ

Auraboxの改造

まだ具体的な機能追加などできてませんが Aurabox の改造をしてみたレポートです

Auraboxパッケージ
Aurabox本体外観
Auraboxとは 主要機能としては Bluetoothスピーカですが
ところがもう一歩進んでいて「攻めた」機能を持っています

スマートフォンと連動しプログラマブルな表示ができる LEDディスプレイ
マイク や 温度センサ や バッテリなど独自の作り込みが行われています
Aurabox梱包内容
パッケージの中身です 黒で統一されています
化粧箱もがっちりとした強度で 実はこちらも気に入っています

中にマイコンが入っていて IoTデバイスとしての使い方もできるのでは? と思い立ち
中身の調査をすることにしました
Auraboxのカバーを外したところ
まず本体を覆っているゴムのような材質のカバーを慎重に取り外し
Auraboxの内部に迫る
プラスチックケースをこじ開けます スイッチ類のところからが比較的開けやすいです
左下の丸いものは実は マイクで間違ってドライバを突っ込んで壊してしまいました
Auraboxを開けたところ
何とか開きました 基盤 大きなスピーカ バッテリが見えます
Auraboxが 2つに割れたところ
バッテリ や スピーカ に接続しているケーブルを外しました
ここから部品構成を確認していこうと思います
Auraboxインターフェース部分
Auraboxのインターフェース部分です
操作用のスイッチと 左下に(壊してしまいましたが)スピーカ そして
スイッチの上に見える突起は温度センサでしょう
Auraboxディスプレイ背面基盤
ディスプレイの丁度背面にあたる部分の基盤です ICが4つくらい見えます
中央のは STM8 と刻印されています LEDディスプレイ制御用の 8bitマイコンですね
残りの 3つは型番を調べたところ LEDコントローラです
Auraboxメイン基盤
Auraboxのメイン基盤です
特に左側の青い基盤はマイコンとなっていて 3つの大きな ICが載ってます
写真中央右の大きめのICは オーディオアンプです
写真右のチップは 電源制御関連と思われます
ICの刻印をネットで調べながら 次の構成が見えてきました

Auraboxの 代表的なIC構成
AK1050 安凱微電子(ANYKA)製 ARM926EJ-Sプロセッサ
ARMv5TE(32bitARM+16bitThumb) 192KRAM
STM8S003K3 STM8 8bitCPU
25Q16CS1G 2MB Flashメモリ
MBI501* LEDコントローラ 2つ
MBI502* LEDコントローラ
HT6818 3.3W Ultra Low-EMI Anti-Clipping ステレオD級オーディオアンプ
MT5036 6.6A 800kHz 96%変換効率 バッテリコントローラ
REALTEK8761AT Bluetooth2.1~4.0LE UART制御コントローラ

ほとんど中国製の部品で作られています
Aurabox取り付け部品
今回写真の部品を取り付けました
壊してしまったマイクとシリアル用のコネクタです
シリアル用のコネクタは Auraboxのフラッシュメモリを直接外から読み書きできるよう
外出しするためのものです フラッシュメモリを書き換えられれば自由に制御できるかなと…
Auraboxの フラッシュメモリに配線
フラッシュメモリに線をはんだ付けして外だしします 写真の右の方です
Aurabox改造完了
こうしてどうにか マイクを交換し シリアルコネクタを取り付けました
Aurabox動作チェック
一応元の機能のまま Auraboxは動作しています
フラッシュメモリのデータ吸い出しなどは まだできていません (2017-12)

GitHubには こんなプロジェクト も見つけられます
時間を見つけて試してみたいですね

Android開発

Android Studio

ここでは Android Studio を簡単に紹介します
Android デベロッパーのページで開発情報提供やツール配布が行われています
ここから Android Studioをダウンロード インストールします
Windowsで検証しました Windows用にエミュレータも提供されていて Windows上で開発・検証が可能です
Android Studio トップ画面
Android Studioでサンプルアプリを開発してみます メニューから New Projectを開きます
Android Studio New Project
開発ターゲットの Androidバージョンを選択します
Android Studio ターゲットプラットフォーム選択
Activity ということで Androidアプリのテンプレートがいくつか選べます
ここでは 簡単なアプリということで Empty Activity を選択しました
Android Studio 開発Activityの選択
IDE(統合開発環境)のメニュー項目です
Runを選ぶと Windows上でアプリケーションがビルドされ Androidエミュレータ上で動作確認できます
Android Studio メニュー項目
Android Studiの 画面レイアウトです
左から リソース(関連ファイルなど)ブラウザ ソースコードエディッタ エミュレータ と配置されています
Android Studio 画面レイアウト1
Hello World! を表示させるアプリケーションをビルドして実行してみました
Android Studio ビルド実行テスト
アプリのウィジェット配置など レイアウト関連の機能も充実しています
Android Studio ウィジェットレイアウト
ボタンを配置してみましょう 配置したい GUIコンポーネントを指定して 画面上の位置を選択するだけ
Android Studio ボタン配置
コンポーネントのプロパティから ボタンのラベル名称や外観をカスタマイズします
Android Studio GUIプロパティ
Go To Declaration を選択すれば GUIがクリックされたときのイベント処理の定義にジャンプします
Android Studio イベントハンドラ定義
OnClickイベントを受信した際のアクションを記述します テキストラベルに pushed! を表示します
Android Studio イベント記述
アプリの実行状況です ボタンが押されると pushed! と表示されます
Android Studio アプリ実行画面

OpenSSH用パッチ OpenSSL-1.1.x化対応

OpenSSH用のパッチを公開しています

最近は OpenSSLを初めとした オープンソース系の脆弱性情報も頻繁に公開されるようになりました

OpenSSLは 0.9.x系 1.0.x系 1.1.x系 といくつかバリエーションがありますが
「OpenSSL-1.1系の最新版を使うことを推奨します」といった文句を受けて OpenSSL-1.1.0に更新したら
これが地雷だったようで 1.1.0になっていくつか APIの仕様が変わったため対応作業が必要になりました

検証システム
CPU AMD A10-7800 (3.1GHz 4コア)
メモリ 16GB
OS Gentoo-1.12.14 Linux-4.7.0 x86_64 UTF-8
コンパイラ gcc-6.1.0
Cライブラリ glibc-2.24
OpenSSL OpenSSL-1.1.0
OpenSSH OpenSSH-7.3p1

OpenSSLに依存しているアプリケーションは ソースコードレベルで修正行ってましたが
特に OpenSSHが修正量が大きめだったので修正パッチを作りついでに公開します

OpenSSH-7.3p1向け OpenSSL1.1.x対応 Unix98PTY化パッチ

  • 他のサイトで公開されているパッチをベースにしています
  • 自環境は Unix98仕様の PTY(擬似端末環境)ですが
    OpenSSHがなぜか BSD仕様 PTY環境と認識してしまい うまく仮想端末が開かないため
    sshpty.c も修正を行い強制的に Unix98仕様にしています

Unix98仕様かどうか確認するには /dev/ 配下に ptmx と pts** があるか確認
BSD仕様かどうか確認するには /dev/ 配下に pty** と tty** があるか確認

パッチの摘要は openssh-* ディレクトリ配下で下記のようにコマンドを打ってください

$ patch -p1 < ../openssh-7.3p1-ssl1.1.x.patch
patching file cipher-3des1.c
patching file cipher-bf1.c
patching file cipher.c
patching file cipher.h
patching file dh.c
patching file dh.h
patching file digest-openssl.c
patching file kexdhc.c
patching file kexdhs.c
patching file kexgexc.c
patching file kexgexs.c
patching file monitor.c
patching file regress/unittests/sshkey/test_file.c
patching file regress/unittests/sshkey/test_sshkey.c
patching file rsa.c
patching file rsa.h
patching file ssh-dss.c
patching file ssh-ecdsa.c
patching file ssh-keygen.c
patching file ssh-pkcs11-client.c
patching file ssh-pkcs11.c
patching file ssh-rsa.c
patching file sshkey.c
patching file sshpty.c
$
 
OpenSSHを普通にビルドすると 下記のようにエラーとなります

OpenSSH has been configured with the following options:
                     User binaries: /usr/bin
                   System binaries: /usr/sbin
               Configuration files: /usr/etc/ssh
                   Askpass program: /usr/libexec/ssh-askpass
                      Manual pages: /usr/share/man/manX
                          PID file: /var/run
  Privilege separation chroot path: /var/empty
            sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin
                    Manpage format: man
                       PAM support: no
                   OSF SIA support: no
                 KerberosV support: no
                   SELinux support: no
                 Smartcard support: 
                     S/KEY support: no
              MD5 password support: no
                   libedit support: no
  Solaris process contract support: no
           Solaris project support: no
         Solaris privilege support: no
       IP address in $DISPLAY hack: no
           Translate v4 in v6 hack: yes
                  BSD Auth support: no
              Random number source: OpenSSL internal ONLY
             Privsep sandbox style: seccomp_filter

              Host: x86_64-unknown-linux-gnu
          Compiler: gcc
    Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-strong -fPIE 
Preprocessor flags: -I/usr/include 
      Linker flags: -L/usr/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong -pie
         Libraries: -lcrypto -ldl -lutil -lz  -lcrypt -lresolv

$ make

....

In file included from ssh_api.h:26:0,
                 from ssh_api.c:20:
cipher.h:69:17: エラー: フィールド ‘evp’ が不完全型を持っています
  EVP_CIPHER_CTX evp;
                 ^~~
make: *** [ssh_api.o] エラー 1
$
 

OpenSSL-1.1.0になって EVP_CIPHER_CTXなどのインスタンスが直接生成てきなかったり
他にも OpenSSLが提供する関数を経由しなければ利用できなくなったりといった変更があります

そのうち 他のアプリも含めて OpenSSL-1.1.x系に対応するようになるのでしょうか

 
 

GCC-6.1.0 での g++ によるシステムヘッダ検索パス

GCC-6.1.0 での g++ によるシステムヘッダ検索パス

久々に GCCを更新して最新の 6.1.0にしましたが g++でコンパイルできないトラブルがありました
GCC-6.1.0 での環境設定上の注意点をメモします

環境は次のとおりです

検証環境
CPU AMD A10-7800 (3.5GHz 4コア)
マザーボード F2A88XM-D3H(GIGABYTE製 AMD A88X Micro-ATX)
メモリ 16GB (DDR3-1333)
HDD HITACHI HDP725025GLA380 (SATA 250GB)
イーサネット Realtek GbE RTL8111F?
グラフィック RadeonR7 (内蔵GPU)
サウンド Realtek ALC887 codec (オンボード)
Linux 3.10.1
GCC 6.1.0
glibc 2.23
binutils 2.26.1

発生した問題と原因

Linux を 64bit化したときのメモ を参考にしながら binutils glibc GCC を最新化しました
で 下記テストプログラムをコンパイルすると…

$ cat tes.cpp
#include <iostream>

int main() {
 std::cout << "Hello World\n";
 return ( 0 );
}

$ g++ -o tes tes.cpp
In file included from /usr/gcc/6.1.0/x86_64/include/c++/6.1.0/ext/string_conversions.h:41: ,
                 from /usr/gcc/6.1.0/x86_64/include/c++/6.1.0/bits/basic_string.h:5402,
                 from /usr/gcc/6.1.0/x86_64/include/c++/6.1.0/string:52,
                 from /usr/gcc/6.1.0/x86_64/include/c++/6.1.0/bits/locale_classes.h:40,
                 from /usr/gcc/6.1.0/x86_64/include/c++/6.1.0/bits/ios_base.h:41,
                 from /usr/gcc/6.1.0/x86_64/include/c++/6.1.0/ios:42,
                 from /usr/gcc/6.1.0/x86_64/include/c++/6.1.0/ostream:38,
                 from /usr/gcc/6.1.0/x86_64/include/c++/6.1.0/iostream:39,
                 from tes.cpp:1:
/usr/gcc/6.1.0/x86_64/include/c++/6.1.0/cstdlib:75:25: 致命的エラー: stdlib.h: そのようなファイルやディレクトリはありません
 #include_next <stdlib.h>

コンパイルを停止しました。
$
 

単純な C++プログラムがコンパイルできないという現象でした
#include_next <stdlib.h> で stdlib.h が見つからないというのが直接の原因です

<cstdlib> (C言語で言う stdlib.h のようなもの) 内での <stdlib.h> の呼び出しが
#include から #include_next に変わったのが 最近の GCC での変更点ですが そもそも #include_next とは何でしょうか

#include_next とは システムオリジナルのヘッダ.h を 同名のヘッダでオーバーライドできる仕組みです
オリジナルの glibcのヘッダでは 問題が出るため GCCでは上書き用のヘッダを用意することでビルド環境の整合性を保っています
図にすると下記イメージです
(ユーザプログラム) #include <stdlib.h> → (GCC stdlib.h) #include_next <stdlib.h> → (glibc オリジナル stdlib.h)
stdlib.h の例では ユーザプログラム側で #include <stdlib.h> すると
glibcの stdlib.h が呼ばれる前に GCCの stdlib.h が呼ばれる仕組みとなっています
GCCの stdlib.h では必要な変更点が記載されており 変更不要な定義は glibcの stdlib.h を呼び出す動作となります

このような オーバーライドの仕組みを担保するために
#include_next で確実にオリジナルのヘッダディレクトリが探索される必要がありますが
g++ではこの辺りの挙動が変わったようです