オリックス給油カード＆リパークの駐車後払い法人カードを拾ったので届けてみたら

♪三井のリパーク～♪

先日、保育園の送り迎えに使用している駐車場の精算機で
カード挿入口にカードが置き忘れられていることに気づきました

説明書を隅から隅まで読むタイプの人は気づいているかもしれませんが、

クレジットカード等には習得時の連絡先と、会社によっては

「薄謝進呈」

と書かれていることがよくあります。皆さん自分のカードを確認してみましょう。

さて、クレジットカード、交番に届けたところで実はお礼なんてもらえません。

しかし、センターに連絡するとお礼がもらえるそうです。

これはこれは。

いや、マジでお礼が欲しいわけではなく、その内容そのものに興味があったのでセンターに電話してみました。

拾得したことを伝えると、時間、場所、こちらの連絡先を聞かれ、
後日返送用封筒を送るので、カードにはさみを入れて返送してくれ、とのことでした。
特にここでお礼についての話はありません。

ははーん、返信用封筒とともに送られてくるか、送付後に別途そっと送られてくるんだな？？

大体、なんかしらのお礼、って言ったらQUOカードやろ。５００円か？ええんやで？？

などと思いつつ数日、返送用封筒とお礼の手紙が到着しました。

「ささやかではございますが、お礼の品を同封いたします」

おっなんやなんや

ど　どーん！！！！

ボールペン！！！

オリックス　バッファローズの　ボールペン！！！！

…ありがとうございます！！！！！

googleで検索してみると、クレジットカード会社によってはQUOカードだったりすることはあるみたいです。
これが、只の法人支払いカードだからなのか、ご時世なのか、会社の力やそのほか諸々のことなのかはわかりませんが、とりあえずこのカードを届けると、バッファローズのボールペンがもらえることがわかりました。

ゲームギアミクロのLCDに何か出す & 1.15インチの謎に迫る

この手のハードの解析について、みんなの興味があるところなのは
ほかのゲームのエミュとかROMを入れられるとかそういうところなんだと思いますが、
それははっきり言って最終的には「できる」んですよ。

でも、それをすること自体には、いろいろな問題、
情報発信の責任がついてきてしまいます。

「ネタ」としてその手のことに近いことをやることはあると思いますが、
例えば簡単な入れ替えツールや明確なROMの引っこ抜き方はこのブログには出てきませんのであしからず。

さて、このハード、Linuxとしてデバイスが抽象化されていますので、その辺のハンドルを試してみます。

内蔵LCDはST7789VWというわりとハイスペックな240x240の液晶が搭載されています。

shikarunochi.matrix.jp

Linuxから画面に表示させるには、フレームバッファというデバイスに何かしらのデータを書き込むと、割り当てられたディスプレイに何かが表示されます。
普通のマシンでは、 cat /dev/urandom > /dev/fb0 として、画面にごみが表示されることを確認することが多いです。

seenaburns.com

ゲームギアミクロでも同様に、/dev/fb0が存在していますのでこれを試してみます…

ゲームのUIをストップさせてこのコマンドを実行させてみますが…何も表示されません。

あれれ？どういうことだろう。

ゲームのUIを動かしたまま、上記コマンドを実行すると一瞬画面にごみが表示されました。

おやおや。どうやらこのマシンでは、fbに書き込んだデータは別の仕組みでlcdに転送されているようです。

いろいろ調べてみると、"/sys/kernel/screen_update/update”　というファイルが見つかりました。このファイルに"1"を書き込むと、ドライバがfb0からlcdに転送してくれる仕組みになっているようです。

では改めて、urandomからfbに書き込み。

さらに、クロスコンパイルしたfb-testを実行してみます。

コマンドだけ打ち込んでもLCDが変わりません。

ここは手動で/sys/kernel/screen_update/updateを更新します

実行している動画です。

ゲームギアミクロのlcdになんか出すテスト pic.twitter.com/MgyedXrmpM

— ひろみつ(honeylab) (@bakueikozo) 2020年10月7日

このように、一応fb0に連動してlcdを更新させることができました。
fbを使用するアプリケーションはlcdへの転送を組み込むか、別途バックグラウンドで転送するアプリを動作させれば(syncの問題は出ますが)
普通のLinuxのアプリのように動作させることが可能です。

もしくは、このdispドライバが非同期更新の仕組みを持っていると助かるのですが…

ところで、公式スペックによると画面サイズは1.15インチということになっています。 

発売前、液晶の解像度とこの1.15インチという値から、内蔵されるLCDを探していたのですが見つかりませんでした。
こんな中途半端(160x144)の値の液晶をカスタムで作るわけはないため、オーバーサイズの液晶をマスクして使うことは想定していました。

上記の動画を見るとわかるように、左上の点が下にオフセットされています。

つまり、こんな感じでゲームギアミクロでは正方形の液晶の上下をマスクして長方形に見せています。

ドライバのパラメータを見てみると、以下のように設定されていました。

内部fbは256x238として使用されていて、エミュレータでは160x144に描画、
これをLCDの[0-240,38-180]の範囲に拡大表示する、という動作です。
つまり横方向1.5倍、縦方向…ちょっと合わない…？

まぁ、最終的に整数倍にならないのはたぶんそれをやるとゴリゴリの表示になっちゃう、とかいう理由で調整したんじゃないですかね。たぶん。
（計算でぴったり合わせてドヤ顔するつもりだったんだけどなぁ…）

ところで、このLCD、スペック的には1.3インチということになっています。

では、公式スペックの1.15インチはどこから来たのでしょう。

…出た！！！1.15インチ！！！　この中途半端な値はここから来たのね！

ふぅ、すっきりした…三平方の定理ってこうやって使うのよ。

ゲームギアミクロを分解＆解析(システムにログイン)

honeylab.hatenablog.jp

↑前回からの続き

/etc/shadowを引っ張ってきてhashcatにかけたけど全然終わらん

これは過去の例を見て対策されたに違いないｗ

ということでいったんパス解析をあきらめてfs直接書き換えてログインを試みようとするが、手持ちのflashリーダではggミクロに乗っているspi nandにアクセスできないことが分かった

もともとのrootfsパーティションはsquashfsファイルシステムでnand上にあり、uboot上からパッチをあてるのは結構難しい

いろいろ考えていると、どうやら搭載nand上のhパーティションががら空きであることが分かった。
もともと存在するrootfsパーティションは結構でかいサイズだが、中身は大した量ではないようだ。

そこで、いったんシングルユーザモードでrootfsにアクセスしてシステム軌道に必要なファイルをnandh上にコピーし、

(/etc/shadowも書き換えてパスワードを削除する)ubootでのkernel起動パラメータを書き換えて、nandhをrootfsにして起動させてみることにした。

ログイン成功

さて、ログインできたはいいが、今のところ外部から何かを持ち込む手法がないな…
起動ログを見るとandroid_usb0は生きてるみたいなのでrndisを試してみるが、なんかバグってるらしくて動かない

あとはmass_stroageかな。

ゲームギアミクロを分解＆解析(初報)

ゲームギアミクロ ブラック

届いた

箱に対して小さいｗ

分解

SoC Allwinner F1C200s (ARM926EJ-S [41069265] revision 5 (ARMv5TEJ))

メガドライブミニなどに使用されていたAllwinner

…違った！あれはZUIKIだ！！（棒読み）…

ゲフン、 Allwinner製のARM CPUが採用されています。

小型LCDが使用されていることから、Licheeあたりに使われてるこの辺だと想定はしていましたが、まさにその通りでした。

SPI Flash ROM に bootloader/linux/game/romが書き込まれています。

フォームファクタ考えると妥当。予想通り。

FELモード用ボタン

基板上にタクトスイッチがついています。

このボタンを押しながらUSBを接続するとFELモードになりますが、
一般的なユーザには今のところ使い道はありません。

ファミコンミニなどから続く、書き換えツールなどはこのモードを使用することになります。

シリアルコンソール

分解して基板上にあるこのJP2の端子がシリアルIOです。

15200bpsで接続し、各種操作ができます。

bootloaderの起動中に's'を送り続けることでu-bootのシェルに残れます。

その後、Linuxのコンソールの表示、ログインプロンプトまではスムーズに進めます。

ログインのためのパスワードは現在調査中です。

LCD

ゲームギアの解像度は160x144ですが、
これをちょうど満たすようなこの大きさのLCDはありませんでした。
そのため、これより一回り大きな液晶を使うのだと考えていましたが、やはりその通りでした。ドライバ上からは240x240と認識されているので、1x1等倍ではなくもしかしたら1.5倍になってるのかも？？

いまのところ面白いのはこのぐらい。

あと、セガのHPからOSSのアーカイブがダウンロードできるはずなんだけど…

ゲームギアミクロ | セガ | オープンソースのライセンスおよびソースコードアーカイブ

まだ出てきてない。リンクミスだと思う。

プログラマー向けカロリーメイトのサイトでドヤ顔するためのまとめ

一部界隈で話題の、プログラマー向けカロリーメイトのCUIサイト

https://www.otsuka.co.jp/cmt/to_programmer/cui/

こちら、Rubyのまつもとゆきひろ氏監修ということもあって遊びごごろあふれたページのようです。

「プログラマー向け」とは書いてありますが、これは「一般人」から見たいわゆるカタカタやってる人向け、ぐらいの意味ですね。

ページを開くと、いわゆる黒いコマンド画面が表れます。
ここで、いろいろな操作をして楽しんでください、とのことです。

我々のようなこういう機械に慣れ親しんだ者から、
そして何か準備されたもの、ということを考えると、
すべての機能を把握するのは割と簡単です。
しかし、あまりなじみのない人にとっては全く楽しむことができないでしょう。

せっかくなので、この黒い画面で遊ぶ方法をいくつか紹介します。
また、この黒い画面、あくまでもブラウザ内で動いているだけなので、
めちゃくちゃをやっても壊れたりすることは全くありません。
安心して遊びましょう。

ちなみに、トップページのコメントにはこんなことが書かれています。

T.I氏　何者ですかね。

では、促されたようにUNIXコマンドをいくつか試してみましょう。

まず、ファイルリストを取得するコマンド「ls」をタイプしてみます。
小文字でls（エル　エス）とタイプし、Enterキーを押します。

about,artibles,campain,messages,product　というリストが表れました。

これだけで、見たことない一般人に対してドヤれるレベルですのでどんどんドヤりましょう。

このリスト、最初はファイルだと思って、ファイルを表示するコマンド「cat」を実行してみました。しかし、

思ったような動作はしません。そこで、ディレクトリ移動コマンド「cd」を使います。

cd　スペース　を打った後、ab とタイプし、おもむろに[tab]キーを押すとaboutが保管されますので、[Enter]を押します。

aboutディレクトリに入りましたので、ここでまた「ls」します。

about.txtが表示されました。

では、 cat about.txt とタイプしてみましょう

about.txtの中身が表示されました！

このディレクトリはこれでおしまいのようです。

上の階層に戻るには「cd ..」または、「cd」コマンドでホームディレクトリに戻ります。 

このように、この５個のディレクトリに入り、中身を見ることができます。

また、現在の絶対ディレクトリを確認する「pwd」コマンドが使えます。

どうやら「/CalorieMate/LIQUID」ディレクトリにいるようです。

ここから、いろいろなディレクトリを辿ってどんなファイルがあるかを探すことができます。

ところで、ここでおもむろに「help」とタイプしてみましょう。

なんと、このコンソールで使えるコマンド一覧が出てきます。
しかし、「Basic commands」とあるように、あくまでも一部で、それ以外は自分で探せ、ということのようです。
imgcatコマンドは、各ディレクトリ内にあるpngファイルを表示することができます。

例えば、

こんなかんじ。

また、openコマンドでは上記にある「twitter.link」などのリンク先をブラウザで開くことができます。

基本的なコマンドは上記のリスト通りですが、ついでに内部構造をちょっと調べて、すべての利用可能なコマンドを確認してみました。

コマンドリストは上記で全部です。たぶん。
「システム」と分類したものは、いわゆるUNIXコマンドのようなコマンドとして使用できます。
「ネタ」となっているコマンドは、その挙動とは違った結果を返すものです。
是非実行してみてください。

slコマンド、絶対入ってると思ったのになかったなぁｗ

しかし、私は口が軽いので以下ネタバレを含みます。

ちゃんと自分で実行してみたい人は、ここから下は後で読むことにしてくださいね。

ATOMCamの検知画像を自由に保存したり飛ばしたりするhack

現在のATOMCamのアプリは、24時間連続録画による分刻みの録画がmicroSD内に残りますが、
動き・音声検知した動画はかならずクラウドにアップされ、ローカルには残りません。
仕組みとして、検知した動画は/tmp/alarm_reocord.mp4という固定ファイルに一旦保存され、
クラウドにアップされると消去されてしまうからです。
※よく考えると、検知動画１４日以上を有料化プランするような話もあったので
技術的なものに加え、その方法のほうが都合がいいのかもしれません…
というわけで、この検知ファイルをローカルに保存しつつ、
例えば自分のNASやslackなどに投稿するためのhackスクリプトです
hackなので、そのうち使えなくなるかもしれません。
※公式で実装してくれるのが一番うれしいんですがね

making tar script

#!/bin/sh

# making Test.tar script

cd /media/mmc
mkdir work
cd work
touch factory
mkdir Test
touch Test/factoryTestProcess
touch Test/singleBoadTest
touch Test/checksum

cat > Test/test.sh << EOF
#!/bin/sh

/media/mmc/pre.sh

/system/bin/hl_client &
/system/bin/iCamera_app &

/media/mmc/post.sh

EOF


chmod a+x Test/test.sh
tar cfv Test.tar Test factory
cp Test.tar /media/mmc

mmc/pre.sh

#!/bin/sh


echo "exploit pre app functions" > /dev/ttyS1

cp -r /bin /tmp/bin
busybox rm /tmp/bin/rm
mount /tmp/bin /bin
cp /media/mmc/norm.sh /tmp/bin/norm.sh
ln -s /tmp/bin/norm.sh /bin/rm

mmc/post.sh

#!/bin/sh
echo "exploit post app functions" > /dev/ttyS1

mmc/norm.sh

#!/bin/sh

if [ -e $1 ]; then
  echo "$1 is file parameter"
        FILE=$1 
        OPT=$2
fi
 
if [ -e $2 ]; then
  echo "$2 is file parameter"
        FILE=$2
        OPT=$1
fi

if [[ "$FILE" = "/tmp/alarm.jpg" || "$FILE" = "/tmp/alarm_record.mp4" ]]; then

	FMT=`date +"%Y%m%d_%H%M%S"`
	echo $FMT > /dev/ttyS1
	mkdir /media/mmc/alarm_files/

	str=`echo ${FILE} | awk -F "/" '{ print $NF }'`
	echo "basename:${str}"

	OUTPATH="/media/mmc/alarm_files/"$FMT"_"$str
	echo "outpath:$OUTPATH" > /dev/ttyS1
	cp $FILE $OUTPATH

fi

busybox rm $1 $2

カメラアプリ内でrmが呼ばれていることを利用して、ファイルを横取りします。
引数処理が適当なので自分でrmコマンドを使おうとすると変になるけど
全体の動作としてはちゃんと動きます（そのうち直す）

ATOM Cam内部解析：あれこれして圧縮前の静止画を取得する

なんだか結構ATOM Camのことで検索してくる人が多いようです。
面白いプロダクトで、中の人も積極的にサポートしてくれてるようでユーザの反応も悪くないのですかね。
普通に使ってもいいですが、やはり我々頭のおかしい人間にとっても結構面白いものなので、やばくない範囲でこの機械を徹底解剖していきます。

ネットワークカメラ ATOM Cam(アトムカム):1080p フルHD 高感度CMOSセンサー搭載 赤外線ナイトビジョン 動作検知アラート機能 防犯カメラ/ペットカメラ/見守りカメラ/ベビーモニター ATOM tech製

尚、気づいてる人もいると思いますが、今年の頭ぐらいから結構頑張ってamazonのリンクを張ったりしています。
もしブログが気に入った方、私の生活費になりますのでブログ内のリンクからいろいろ買ってみてくださいね。（現在、500円/月ぐらいアフィリエイト報酬を頂いています）

というわけで、今回のターゲットは改めてこちら。

このへんの記事で結構書いていますが、中身はLinuxですので結構いじることができます。

honeylab.hatenablog.jp

しかし、実はできることは少ないのです（矛盾？）

いわゆる、組み込みLinuxボード、例えばraspbery piに汎用のusb webカメラなどを接続して監視カメラを作った場合、デバイスはVideo For Linuxの標準的な方法で取り扱うことができ、対応しているストリーミング、キャプチャ、画像認識などのアプリケーションが利用可能です。

それに対し、このような出来合いの、特に中国で設計されている監視カメラでは、
イメージセンサの入力が直接SoC内に接続されたり、SoC内のエンコーダに接続され、独自形式のデータストリームとなってしまい、一般的なLinuxアプリケーションから取り扱うことが難しくなっています。
この ATOM Camでも Ingenicというメーカーの「T31にイメージセンサを接続するためのSDK」を使用しているため、ユーザが頑張って、例えばmjpg-streamerなどのアプリをインストールしたところで全く動かすことはできません。
製造メーカでは、このSDKにリンクする形でカメラ映像を自社のサーバに転送できるようにアプリを書くことでこの製品の機能を実現しています。
それ以外の機能を実装しようとしても、元のアプリを改造するか、改めてチップメーカ提供のSDKを利用してアプリを書くしかありません。
しかし、そういったSDKは入手が困難です。

そこで、もともと入っているシステムを解析したり、改造したりする必要が出てきます。

ATOMCamは

・電源を入れるとブートローダ(u-boot)が起動する

・u-boot内で、RESETボタンが押されていればSDからファーム更新を行う

・そうでなければLinuxを起動する

・Linuxが起動すると以下のプロセスが起動する

・・shell call sdk tool ： "localsdk"が外部プロセスを実行させる仕組み

・・「assis」プロセス　：ファームウェア更新など

・・「iCamera_app」プロセス　：イメージセンサから画像を取得する。動画を保存したりする。

・・「hl_client」プロセス　：　クラウドとの接続・P2Pの仲介を行う

hl_clientはtcp:9999ポートで待ち受けて、iCamera_appプロセスとプロセス間通信で協調動作します。また、iCamera_appは 先述した"localsdk"と呼ばれるイメージセンサからの画像取得・動画保存関数を呼び出しています。

localsdkには、例えば以下のような関数があります

このあたりの動作は、シリアルコンソールのログにちょろっと出ています。

OSD表示のために、フレームが生成されると呼び出されるコールバックを設定できるようです。左下のロゴや、日時表示の設定を行っています。

 

この顔文字、日本ではあまり使われないですねｗ

さて、ここで見てわかるように、OSDの乗せられた画像はエンコーダに突っ込まれているようです。
ATOMCamのアプリからローカル録画をONにすれば、毎分ごとのmp4を取得することはできますが、これはあくまで動画であり、結構きつい圧縮がかかっているため、きれいな静止画を取得することはできません。

はてはて困ったな、と思っていると、アプリのバイナリと同じところに"impdbg"という怪しい実行ファイルを見つけました。

ファイル名から推測すると、"IMage Processor DeBuGger"では？？

ためらわずに実行してみます。

[root@Ingenic:bin]# ./impdbg
usage: ./impdbg --option [args]
--enc_info get encoder info
--enc_rc_s chn:offset:size:data set encoder rc
--fs_info get frame source info
--save_pic [path] save pic data
--pic_type [RAW/NV12/YUYV422/UYVY422/RGB565BE] save pic type
--system_info get system info
[root@Ingenic:bin]
 

 おやおや？？save_picコマンドがありますぞよ？

それぞれのコマンドを実行してみます。

[root@Ingenic:bin]# ./impdbg --system_info
info: func_dispatch,170func mid:fid:name= 3:2:misc_system_info
tree item: 3
Framesource-0 update_cnt=26980(qframecnt=26983, dqframecnt=26980, sem_msg_cnt=16, sem_cnt=0)
OSD-0 update_cnt=26980(sem_msg_cnt=16, sem_cnt=0)
Encoder-0 update_cnt=26980(sem_msg_cnt=16, sem_cnt=0)
---Framesource-0-----OSD-0-------------Encoder-0
tree item: 3
Framesource-1 update_cnt=26980(qframecnt=26983, dqframecnt=26980, sem_msg_cnt=16, sem_cnt=0)
OSD-1 update_cnt=26980(sem_msg_cnt=16, sem_cnt=0)
Encoder-1 update_cnt=26980(sem_msg_cnt=16, sem_cnt=0)
---Framesource-1-----OSD-1-------------Encoder-1
tree item: 1
Framesource-2 update_cnt=0(qframecnt=0, dqframecnt=0, sem_msg_cnt=16, sem_cnt=0)
---Framesource-2

ふむふむ

[root@Ingenic:bin]# ./impdbg --fs_info
info: func_dispatch,170func mid:fid:name= 1:0:fs_info
CHANNEL(0)
INFO 1920x 1080 RUN 20/ 1(fps) NV12
CROP DIS left(0) top(0) width(1920) height(1080)
SCALER EN width(1920) height(1080)
CHANNEL(1)
INFO 640x 360 RUN 20/ 1(fps) NV12
CROP DIS left(0) top(0) width(640) height(360)
SCALER EN width(640) height(360)
CHANNEL(2)
INFO 1280x 720 OPEN 20/ 1(fps) NV12
CROP DIS left(0) top(0) width(1280) height(720)
SCALER EN width(1280) height(720)

ふむふむ。

どうやら、３ストリームがあるように見えます。
適当にいろいろ試してみたところ、なんと以下のコマンドで画像らしきものが保存できました。

[root@Ingenic:bin]# ./impdbg --save_pic /tmp/test.bin --pic_type NV12
info: func_dispatch,170func mid:fid:name= 3:0:misc_save_pic
info: save pic file name : /tmp/test.bin type : 1
info: func_dispatch,219 size = 0
[root@Ingenic:bin]# ls /tmp/test.bin -la
-rw-r--r-- 1 root root 3110400 May 31 09:15 /tmp/test.bin

これをmicroSDに入れてバイナリビューアで見てみます。

確かに画像っぽい！

というわけで、どうやら内部コマンドをちょっと突っついてやるとイメージセンサから取得したばっかりの画像が撮れそうです。

しかし、これは"NV12"というYUV形式の画像のため、ちょっと変換してやらないといけません。（内部でmp4のエンコーダに突っ込まれているため。mp4では色空間はRGBではなくYUVなのです（雑に説明））

変換のため、VisualStudioでプログラムを書きます（なんかツールありそうな気がするんだけど…）

すると

……

…………

おおおおおおおお！画像出た！

1920x1080の綺麗な静止画です。

あとはこれを何らかのストリーマに食わせてやれば、自力で綺麗な静止画が取得できそうですね。

…っていうめんどくさい手順を取らなくていいように、

是非！ONVIF対応を！！！！！！

（それが対応されれば、普通に外部から画が取れるので）