honeylab's blog

各種ハードウェアの改造、主にファミコンミニなどをやってます(ました)

ATOM CamのWebカメラ化とUSB A-Aケーブルの錬成

honeylab.hatenablog.jp

 

先日クラウドファンディングで受け取ったネットワークカメラ、
ファームアップWebカメラ化が予定されていましたが、
そのファームウェアが公開されました
(正直もっと後になるかと思ってました)

www.atomtech.co.jp

やり方は上記リンクの通りなのですが、
microSDカードを使ったファームウェアアップデートに加え、
本体委側にあるUSB-A端子とPCを
「USB AtoAケーブル」で接続しなければなりません。

このUSB-AtoAケーブル、USBの規格上は通常使用しないケーブルです。

(上流がA,下流がBと決まっている)

しかし、一部の機器やサービスマン用として、ごくわずかですが市販のケーブルとして流通しています。

が、その辺の電気屋、ではあまり売っていないと思います
必要だと思ったら、
このご時世ですから店頭を探し回ったりせず、

アマゾンとかでこの辺をポチったほうが早いと思います。

 

サンワサプライ 両面挿せるUSBケーブル(A-Aタイプ) 1m ブラック KU-RAA1
 

 さて、私は一般人ではないので、机の周りにこのようなA-Aケーブルが転がっていたはずなのですが…昨日まであったんですが…

見当たらないので、錬成することにします。

 

つくりかた

A-Aケーブルは無くても、一般的な、使い古したA-BやA-miniB,A-microBなどのケーブルは少し位転がっているのではないでしょうか。

f:id:honeylab:20200514152739p:plain

このケーブルを二本準備して、必要な長さに切り

f:id:honeylab:20200514152902p:plain

同じ色の線同士をはんだ付けします。余裕があればシールドも処理しましょう。
まぁ1m程度ならたぶんヘーキヘーキ。

これが難しい、ちゃんとした製品が欲しい場合はぽちっと買っちゃいましょう。

 

上記のリンクに従ってファームウェアをアップデートし、
このケーブルを使ってPCに接続すると「HD USB Camera」として認識されます。

こっちのケーブルでPCと接続している間はmicroUSBコネクタでの電源供給は不要のようです。

 

f:id:honeylab:20200514153320p:plain

f:id:honeylab:20200514153706p:plain

Windows付属のカメラアプリ、VLCなどで使用できることを確認しました。
ATOMCam自体、画質はそこそこ良いという評判だった画質も、そのまま反映されているようです。

 

仕組み的には、linuxのg_webcamを使用しているようです。
UVCデバイスですので、WindowsMACLinuxではドライバ不要です。

Linuxで使わないか…

 

ATOM Cam解析準備

※こちらは初代ATOM Camに関する記事になります。
技術的に共通する部分も多いですが、ATOM Cam2に関する記事は
↓こちらに記載していますのでこちらもどうぞ

 

 

 

---------------------------- 

激安防犯カメラ「ATOM Cam」

一部界隈で話題になった、クラウドファンディング形式で発売することが報じられ、一時期は達成は全然無理かと思われた「ATOM Cam」ですが

 

internet.watch.impress.co.jp

 

最終的には十分な投資を集めて無事発売、にこぎつけたようです。

そして、こちらの製品をリターンとして受け取りました。

 

Image

なんとマスクがおまけでついていました!

 

なんで安いの?セキュリティは?

防犯カメラとしてはかなり安価に設定されているため、当然一から自社開発しているとは考えにくいです。そのため、どこかのメーカのOEM製品に、自社開発のアプリを乗せたものとして発売されると予想していました
(し、そのように商品ページにも掲載されていました)

 

 

 この「Atom Cam」の売りとしては、自社・国内生産によるアプリ・自社サーバを利用した安全性のようです。実際に投資した人のコメントを見ると「中国製のは信用ならん」とか「国内ソフトなら安心」とかいうのがたくさんありました。

 

 …このご時世、別に国内だから、中国だから安心・危険、っていうことはないです。
それぞれの単体製品ごとにセキュリティホールがあったり、バックドアがあったり、ポンコツだったりして安全・危険が決まるわけです。
国内メーカがやったからって、安全になるわけではありません。

 

で、どこのOEMだった?

さて、Amazonやらなにやらの画像検索を駆使し、発表直後にOEM元として想定していたカメラ「Wyzecam v2」の外観がこちらです。

Wyze Cam | 1080p HD Smart Home Camera With Free AWS Cloud

 

まんまやんけ。

それならば事前にこいつを買ってしまえ、と米アマゾンでポチって見たのですが、
うっかりクレカの設定をミスってキャンセルされていましたw

 

あーあ、と思っていた先日、公式のアナウンスで内部基板が変更になったということが報告されました。

 

なんと、ここにきて基板変更??
よくよく見てみると、CPUの変更や小物変更というレベルではなく、
まったく別の基盤になっているという状態です。
これは、OEM元の製品が切り替わった、ということでしょう。
しかし、基板に記載されているロット日付は2020。
すでに出来合いの大量生産品ではない可能性があります。
これはどういうことでしょう。

さらに調べていくと、「iSC5C1」という文字列を見つけました。
どうやらこの文字列、先ほどのWyzeCamのさらにOEM元、
iSecurityなんとかいう会社で製造しているiCameraベースの製品コードのようです。
しかし、WyzeCamの新製品が出ているという様子はありません。

さらに調べていくと、Xiaomiからも似たようなカメラが出ていることがわかりました。

kazuhiro-geek.com

 

このように、何種類かのカメラがこのiSC5Cベースの製品として製造されています。
その中で、今回ATOM Camが採用した2020-02-26ロットの製品は、おそらく最新版で
まだほかのメーカから発売されていないように見えます。

とりあえず分解しよう

せっかくなのでちゃんとした分解写真を載せたいところですが、
もうすでに何人か分解されているようなので、ここではリンク先をご覧いただくことでお茶を濁してみたいと思います。
うちでは、うちでしかわからないことを調べます。

 

まず、シリアルコンソールを接続します。

ずらずらとブートログが現れます。
そして、ログインプロンプトが表れますが、パスワードがわかりません。
製品をそのままにしてハッキングを頑張る方法もありますが、
ここではあっさりとシステムの入っているFlashを取り外し、
ROMリーダで吸い出してしまい、Linuxファイルシステムとして中身を覗いてみます。
このような方法は、機器が実際に手元にある時には非常に手っ取り早いです。

Image

搭載されているのは128Mbit(16MByte)のフラッシュです。

吸い出したイメージは16MBになります。

これをLiunxマシンにもっていって、とりあえずbinwalk -eします。

f:id:honeylab:20200501113203p:plain



すると、フラッシュ内に含まれたsquashfs内のrootファイルシステムがファイルとして抽出されます。

/etc/passwdを見てみると、root:x: ですので、shadowを見てみます。

 

f:id:honeylab:20200501113258p:plain

 

f:id:honeylab:20200501113414p:plain

ありました。
最近いじったshadowパスワードは、新しい形式である$1$などで始まるものだったので知らなかったのですが、この形式のものは非常に古いとされるDESアルゴリズムによるもので、現在はあまり使われない形式らしいです。

 

さて、このパスワード文字列をhashcatという解析ツールに食わせます。

 

f:id:honeylab:20200501092426p:plain

約20分ほどでパスワードが解析できました。

このパスワードを使うと、このカメラのシリアルコンソールに直にログインできます。

 

f:id:honeylab:20200501092643p:plain

netstatを見てみます。
アプリの実行中は、ローカルホスト内でプロセス内通信をしているものと、
おそらくカメラサーバと思われるamazon awsサーバへの通信が確立しているだけで
不用意にtelnetポートが開いて居たりはしません。

f:id:honeylab:20200501105321p:plain

この状態であれば、いきなりカメラ映像をのぞき込まれたりはしなそうです。
このあたりについて、これから追って解析していきたいと思います。

いよいよ楽しいOSSの時間です

例によって、このカメラはLinuxベースの製品ですから、当然Linuxソースコードが存在し、GPLに従って要請に基づき提供される必要があります。

もし、この製品のLinuxの部分が完全にwyzecamなどと同じであれば、それと寸分たがわぬものでしょうからリンクなどを示すことでもいいかもしれません。
しかし、新しいハードウェアを使用していますし、全く同じということではなさそうです。また、u-bootも同様にGPLと思われます。

ブートログを見る限り、ファームウェア更新の仕組みなど多くの手が入っていますから、これも同様に提供される必要があります。

Linuxのバージョン表記は

Linux version 3.10.14__isvp_swan_1.0__ (xuxuequan@ubuntu) (gcc version 4.7.2 (In
genic r2.3.3 2016.12) ) #17 PREEMPT Mon Dec 23 09:43:27 CST 2019」

となっています。

u-bootのビルド情報は

「U-Boot 2013.07 (Mar 04 2020 - 15:05:06) Board: ISVP (Ingenic XBurst T31 SoC)」

です。

 

ドン・キホーテの「スマモッチャー」では、アプリ本体のバイナリにGPLソフトがスタティックリンクされているように見えながら、ソースコードを公開しないなどアレげなところもありましたが、本品の類似製品ではわりとライブラリ周りが整理されていたので、本品にはそういう部分は無いのかもしれません。

ソースコードの提供は、Webサイトなどでユーザがダウンロードできる形式にする、などの方法がありますが、今のところ、発売元のWebサイトには無いようです。
後ほど、提供方法についてお問い合わせフォームから問い合わせてみたいと思います。

尚、この情勢で発送が遅れたり、発送業者が変わったりしてすったもんだして大変そうなので、ちょっとぐらいは待ちますw(が、本当は本体提供と同時なのよ…?)

 

アプリの安全性は?

先述したように、例えば国産だから安心、とかそういうことはもはやありません。
ちなみに、アプリ自体の根幹部分などはほぼ全部チップ・ハードウェアメーカ及びOEM生産元から提供を受けているものでしょうから、純国産ソフトはあり得ません。
実際には、サーバの設定やローカライズだけをやっているものと考えられます。
通信自体はきちんとSSLですし、カメラ自体の認証も行っているように見えるので、
全然知らないユーザに覗き見られることはなさそうです。
映像送受信の仕組み自体はもともとの生産元と思われる「hualai」のサーバアプリの仕様に基づいているようです。
スマモッチャーではそのOEM元の提供するycc365のようなアプリから相互接続できるような、ある意味便利な機能がありましたが、ATOM Camでは 販売元のサーバによるカメラ認証を行っているため、そのようなことはなさそうです。
デバッグ出力に、[curlpost:152]dbg: (curl_post) url:[https://api.atomtech.co.jp:443/device/v1/p2p
id/get] のように、メーカのAPIサーバと通信している部分が見つかります。)

 

さて、とりあえずなんとなく解析の準備が整いました。
ところどころ、いじれそうなところがあるのでこれから試してみたいと思います。

あ、というわけでソースコード請求しなきゃ

 

 

キャッシュレス端末詐欺?と噂の「日本タブレット」のタブレットが”中国製タブレット”だった件wについて

Twitterをうろうろしていたらこんな記事を見かけました。

f:id:honeylab:20200422165742p:plain

 

 

斜め読みすると、キャッシュレス端末をレンタルしてレンタル料を徴収していた会社から一方的に利用停止の通知が来て使用できなくなり、窓口も7月まで閉鎖している、とのことです。

さらに、しばらく前から不払いや機能制限などゴタゴタが続いていたようです。

headlines.yahoo.co.jp

検索してみると、この貸与される端末がなぜかメルカリに出ているらしいので、

Image

さっそく購入してみました。

 

到着したのは箱に封があり、未開封の新品のようでした。

f:id:honeylab:20200422102947p:plain

f:id:honeylab:20200422103100p:plain

Image

予想通り、Androidタブレットでした。

Image

型番は「NT-J1」と記載されていますが、
この型番での情報はネットにはほとんどありませんでした。

 

 

 

Image

裏側上部のふたを開けてみたところ、TF(microSD)スロットと、SIMカードスロットが2つ搭載されていました。

そのうちの1番スロットにはすでにminiSIMが挿入されていました。
おそらく課金等の通信に使用していたようですが、契約はすでに無効になっているようです。

 

f:id:honeylab:20200422103719p:plain

試しに解約済みのsoftbankSIMカードを挿してみたところ、認識はしているようです。もしかしてこれSIMフリー端末なのでは???(未確認)

 

 

Image

端末名で検索しても全く情報がないので、USB経由でADB接続してみます。

Image

プロダクト名として「M8271b」という文字列がありますが、
しかし、これで検索しても何も出ませんでした。

cpuinfoを見てみると

 

Image

なんとなく予想していましたが、MediaTekのMT8735Bと表示されました。
CPU自体は「Lenovo Tab 7」などにも使われているそこそこ良い性能のもので、
OSのUIの動きも割とサクサクで、
その辺で数千円の中華タブレットよりは明らかによい動きをしています。

 

デフォルトで日本タブレットの決済アプリなどが入っている上に、

f:id:honeylab:20200422182718p:plain


NTWDMとかいう端末の位置情報をどっかに送り続けるアプリが入っている(無効化した)、ユーザー登録などが必要で使用できない、っていう問題がある、っていうか

まぁ上の記事にあるように

会社がトンデルっぽいけどwwwww

 

本体カバーは特別な工具なしで外すことができましたが、裏蓋が金属でできていて、
端を指先でこじ開けようとした際にパックリと切ってしまいました!!!!。
きちんと保護し、適切な工具を使用したほうがいいです。

 

f:id:honeylab:20200422110842j:plain f:id:honeylab:20200422111809p:plain

開けてびっくり、本体基板がとても小さいです。いまはみんなこんなもんなんだな。
そして、基板上をよく見てみましたが、
基板上に製品名の手がかりとなる文字列は全く記載されていませんでした。
しかし、SoCであるMTK型番の開発は日本国内で行っている事例はほとんどないため、
プレイステーションクラシックに採用されているため散々調べた)
おそらく中国製だと思うんですが…


設定メニューから技適情報を確認してみました。

f:id:honeylab:20200422114534p:plain

R 204-720179 , 205-170305 の番号が表示されています。

 

1番目、204-720179を検索すると、JENESIS-MT6625-5Gというのが出てきた!
どうやら、「Jenesic Holdings」というのが機器の取り扱い元らしい。

f:id:honeylab:20200422162919p:plain

2番目の205-170305の形式は「PCBA,JENESIS-MT8735-PCBA」と書いてあります。
Sどうやらこれがこのタブレットのようです。

f:id:honeylab:20200422162707p:plain

さて、JENESISホールディングスとやらを見てみましょう。

https://www.jenesis.jp/gaiyo.html

 

f:id:honeylab:20200422164056p:plain

香港発、深圳に子会社、ただし日本企業とたくさん提携、ということで、
会社に関しては日本法人だけど、工場はしっかり中国ねw

プロダクトページにはAndroid端末がたくさん取り扱いがあるので、
そういうOEMっぽいのとか組み込みとかをメインに扱う会社のようです。

f:id:honeylab:20200422164825p:plain

その中で、この端末を製造してニッポンタブレットに納品したんでしょう。

しかし、ニッポンタブレットの営業として、10万台とかを設置したとか言ってるんだけど、ほんとにそんなに作ったのか…

nippon-platform.co.jp

べつにこれ自体は悪いことでも何でもないんだけど、

f:id:honeylab:20200422164825p:plain


ニッポンタブレットタブレットにNIPPON PAYとかいうシステムを入れているタブレットが中国製だった、っていう字面がちょっとおもしろいですよね。

あと、このタブレットを売ってくれた人のアカウントには、二台以上まとめてなら一台500円引き、在庫数はお問い合わせください、って書いてあるけどこの人は何者かねw

 

決済端末としての利用プランはこちらに

https://nippon-tablet.com/plan

あと、タブレットのレンタル規約とかがこの辺に…

https://nippon-tablet.com/apply/pdf/rental.pdf

 

さて、例によってGPLソースコードはどこにあるのかな…
ニッポンタブレット(現NIPPON Platform)は7月まで窓口が止まっているようだけど…
JENESISは技適の申請元なだけでこの端末を頒布した人には当たらないしなぁ…

 

あっ、メルカリで売ってくれた人か!(やめときます)

 

PCエンジンminiのファイルシステムとコピープロテクト

honeylab.hatenablog.jp

 

前回に引き続き、システムをすこし紹介します。

PCEMiniでは内蔵ストレージはeMMCが使われています。
これは、SDカードの前身であったMMCの拡張のようなもので、
シリアルもしくは少数のパラレルI/Oでアクセスし、
LinuxからはMMCカードと同じように見えます。

また、u-bootのMMCサブシステムからも認識されています。 

 

Partition Map for MMC device 2  --   Partition Type: DOS

Partition     Start Sector     Num Sectors     Type
    1              6287360         1396736       b
    2                73728           16384       6
    3                    1         6197248       5 Extd
    5                90112            4096      83
    6                94208           16384      83
    7               110592          204800      83
    8               315392         1376256      83
    9              1691648         4587520      83
   10              6279168            8192      83

このうち、p6はvfatパーティションで、LinuxのKernelイメージであるuImageファイルが保存されています。p7はrootファイルシステム、p8はエミュレータから一時的に展開されるゲームイメージ置き場、p9には圧縮・暗号化されたゲームイメージの保存場所です。

 

ところで、このようにファイルが普通に見えているので、コピーも簡単にできてしまいそうです。それはメーカとしては困ったものですね。

そのため、いくつかのコピー防止機能があるようです。

前の記事にも書きましたが、ゲームデータはすべて一つのファイルとインデックスにまとめて保存して暗号化され、一般人には解読できないようになっています。
これにより、個別の吸い出したゲームデータが流通しにくいようにしてあるのだと思います(が、m2engageは長らくWiiなどのバーチャルコンソールに使われてきたエンジンであるため、このフォーマットは解析され、展開するツールがじつは存在しています。そして、複合化キーはm2engageの中に納まってしまっています…)

 

また、個別のゲームデータに加え、ミニ系ゲームマシンではゲームセレクトのUIなども重要な知的財産権です。そのため、全体のROMをコピーされて別プラットフォームで動かされることも困ります。

調べてみたところ、CPUの特定のレジスタに書かれたZ7213専用のデータを読み込むことで、ほかの互換SoC,例えばR16やA33では動かないようにしてあることがわかりました。

 


現在、このZ7213はPCエンジンミニ、メガドライブミニにしか使用されていません。

また、まえのブログの記事で「不明」としていた6ピンのチップ、これは特定のバイト列に対して演算結果を返す、いわゆるセキュリティチップの働きをしていることがわかりました。

 


このセキュリティチェックが通らなければブートローダすら動作しないことが確認できました。

 

上記のように、いくつかのコピーガードのようなものが設けてあることが確認されました。しかし、本当に一般ユーザが読みだせない領域を使ったり、高度な認証を行ったりするようなものではありません。
メールの本文と別に、パスワードを送る程度のセキュリティです。

(君とこの会社の話してるのよ。君だよ君。びくっとするんじゃないよ。)

 

それでも、メーカとしては「コピー防止策を行った」という事実による体制のアピールと、著作権者への許諾に対する姿勢、お偉いさんへの承諾など、それなりに重要なことなのだと思います。

 

 

PCエンジンmini 分解 まず初報

3/19に発売されたPCエンジンmini

過去に挑んだ

ニンテンドークラシック ファミコンミニスーパーファミコンミニ」

メガドライブミニ」

NEOGEO Arcade Stick Pro」

に続くゲーム内蔵コンソールの分解解析です。

pcwatchですでに分解され、さらっと内部構造は説明されていますので、

pc.watch.impress.co.jp


それよりも詳しい部分の解析をしていきます。

まずはサクッと基板の内部写真を。

f:id:honeylab:20200321212659p:plain

先述の記事にも出ていますが、かなり多くの部分がメガドライブミニと共通しています。
ちなみにこちらがメガドライブミニの基板です。

f:id:honeylab:20200321214650p:plain

 

ZUIK製のZ7213というSoC。これはAllwinnerのSocをベースにカスタムされたチップ、ということですが、A33R16といったチップとピンアサイン、内部ブロックは同じと考えられ、全く同じファームウェアが動作し、ユーティリティでSoCの内部IDを問い合わせるとA33と返答されます。私はカスタムではなくリマーク・リブランドだと思っているのですが…。


メガドライブミニは内部ストレージがTSOPのNAND Flashだったのですが、
その部品が実装できるパターンがそのまま残され
さらに追加でeMMCのパターンを設けて実装されています(IC4付近)
USB HUBチップであるMA8601の使用や、HDMI周りのI/F回路、PCBのレイアウトやアートワークもほとんど共通化されています。

メガドライブミニで行ったような内部USBメモリの増設なども同じように行えます(カーネルの書き換えが必要)

 一点大きな違いとして、6ピンの謎のi2cっぽいチップのパターンがメガドライブミニでは実装されていなかったところ、本機では実装され(IC7)、実際に通信していることが確認されました。残念ながら未解析で何のためのチップかはわかっていません。

しかし、同じ瑞起製、SoCとしてR16を搭載していた「電車でGo! PnP」の基板にも同じパターンが存在し、部品が実装されていたことが確認されています。

(こちらのサイトで分解検証されています)

mazu-bunkai.com

電車でGo!PnPと本機との共通点、メガドライブミニでの差異ブート・内蔵ストレージがeMMCであるか、NAND Flashであるか、という点があります。
もしかしたら、eMMCに対応するための特別なbootROMか何かが書かれているのでは?と今推測しているところです。

基板の裏側です。いくつかのFETとテストパッドがあります。

f:id:honeylab:20200321233344p:plain

これに加えて、お行儀よく内部に使用されているu-bootやLinuxカーネルソースが公開されていますので、ダウンロードしておきます。

 

www.konami.com

基板上のRXD,TXDをUSBシリアルケーブルなどで接続し、シリアルターミナルで開くことでより深い解析が行えます。

 

f:id:honeylab:20200321234005p:plain

 

起動直後にシリアルターミナルから's'の文字を入力し続けるとu-bootのシェルに入ることができます。

 

ここではいくつかのデバッグ・テストコマンドの実行や、起動にかかる環境変数の変更ができます。

ここで、拙著「メガドライブミニのひみつ」などで紹介している環境変数変更の手法によって/etc/shadowをのぞき見し、rootパスワードを取得します。

※※※ メガドライブミニのひみつ BOOTH にて頒布中 ※※※

honeylab.booth.pm

 

これにより、Linuxのコンソールにログインすることができるようになり、もっと詳しい解析を行っていくことができます。

 

起動しているプロセスの一覧なんかも見れます。

f:id:honeylab:20200321234546p:plain

ここから先は、Linuxの知識があればあれやこれやそれができていきます。

 

さて、ダウンロードしたOSSソースを確認してみます。

 


兄弟機・同じ開発元であるメガドライブミニのソースコードとdiffをとってみたところ、純正のコントローラや対応コントローラが全く違うことに対応した、という程度の差分で、ほとんど同じソースコードであることがわかりました。

メガドライブミニ」では、カーネルソース内、対応SPECIALデバイスとしてパッドのVID,PIDを設定することで、専用製品のみに対応するように設計されていました。
これと同様、本機でも付属、および開発元であるHORIのいくつかのパッドのみ使用できるようになっているようです。

 
これが対応しているデバイスのVID,PIDです。

hub.c: { SPECIAL_USB_DEVICE(0x14cd, 0x8601) }, // 内蔵USBハブ、およびマルチタップ?
hub.c: { SPECIAL_USB_DEVICE(0x0F0D, 0x138) }, // 付属パッド
hub.c: { SPECIAL_USB_DEVICE(0x0F0D, 0xC1) }, // HORI Pad Switch
hub.c: { SPECIAL_USB_DEVICE(0x0F0D, 0xAA) }, // 不明?
hub.c: { SPECIAL_USB_DEVICE(0x0F0D, 0xF1) }, // 不明?
hub.c: { SPECIAL_USB_DEVICE(0x0F0D, 0x139) }, // 海外版付属パッド?
hub.c: { SPECIAL_USB_DEVICE(0x0F0D, 0xEE) }, // HORIPAD mini4

 

不明な製品が多いですが、もしかしたらこのPIDの製品を持っている方は使用できる可能性があります。
USBハブのID ma8601はメガドライブミニと同じですので、使いまわせる可能性もありますね。

 

また、付属の純正パッドですが、分解してみたところ連射スイッチのパッドが残されていました。

もしかしてと思ってパターンにスイッチをつけてみると…

 

見事連射モードが作動していました。

もしかしたら連射スイッチはただのボタン扱いで内蔵エミュレータによるハンドリングになるのかなと思っていましたが、パッド側で対応していたようです。

 

さて、まずはこんなところ。これからもうすこしいろいろ書いていきたいのですが…

そうそう、内蔵エミュレータですが、公式の情報通りM2が作成したもののようです。
内蔵ゲームのROMは一つのバイナリファイルとして圧縮・暗号化されていて、基本的にはエミュレータ"m2engage"からしか参照できないようになっています。

 

これは同様にM2が作成した"m2engage”が使用されている「メガドライブミニ」と全く同じ方式です。

ちなみにファミコンミニでは、一般的なNES/SNES用のROMがパーティション内にファイルとして納められ、パーティション自体をLinuxの暗号化ファイルシステムとしてマウントするようになっていました。(そのため、吸い出してもそのままでは使用しにくいですが、本体内に複合キーが納められていたり、Linuxの起動中には普通にファイルとして参照できるため、逆に全く暗号化されていないのと同じ状態になっていました)

 

さて、ちょっとTwitterで見かけたのですが、購入直後から診断モードに入ってしまって
ゲームにたどり着けない状態になっている方がいらっしゃったようです。

 

起動スクリプトを解析してみたところ、どうやら2回通るはずのハード診断ルーチンを一回しか通さずに出荷されてしまっているようで…

対応しているパッドを2本接続してテストを通してしまえば通常通り使えると思うのですが、初期セットにはパッドが一個しかない…つらみ

うっかり私みたいにガツガツ解析してればファイルを修正することで修正が可能なんですがね…

さて、とりあえず初報はこんな感じ。今後もうちょっと解析するか、本にまとめるか、どうしようかなぁ…

 

すごいgdgdな分解している様子を映しているかもしれないYoutube動画はこちらです

youtu.be

docomo dTV01 / unext-tv (HUAWEI M220)をroot化しようとしたけどうまくいっていない話

ハードオフで見つけてたので、勉強がてらいじっていました。

この2つ、基板が全く同じでソフトだけ違うもののようでした。

 

シリアル端子は出ていたけど、 bootloader中にも何のキー入力も受け付けず、
起動してからはconsoleはcloseされるようでシリアルからのアクセスはできませんでした。

 

シリアルから触れなくても、ビルド番号x7クリックで開発者モードにして、
ネットワーク経由でadbできるので大体のことはできるのですが、
あくまでも大体のことしかできないのです。

そのため、どうにかしてroot化できないかといろいろやっていたのですが、今のところできていないのでここまでの流れをメモしておきます。

 

シリアル接続~Linux起動まで

System startup

Reg Version:  v1.1.0
Reg Time:     2014/6/1619:25:50
Reg Name:     hi3719cdmo1b_hi3719cv100_ddr3_2gbyte_8bitx4_4layers_emmc.reg

Compressed-boot v1.0.0
Uncompress....................Ok


System startup

Reg Version:  v1.1.0
Reg Time:     2014/6/1619:25:50
Reg Name:     hi3719cdmo1b_hi3719cv100_ddr3_2gbyte_8bitx4_4layers_emmc.reg

Fastboot 3.3.0 (panli@ottm620-Tecal-RH2288-V2-12) (Jul 14 2015 - 23:34:35)

Fastboot:      Version 3.3.0
Build Date:    Jul 14 2015, 23:35:12
CPU:           Hi3719Cv100
Boot Media:    eMMC
DDR Size:      1GB

Checking DDR config ... OK
Check nand flash controller v610. found
Special NAND id table Version 1.36
Nand ID: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
No NAND device found!!!

Check spi flash controller v350. found
Can't find a valid spi flash chip.
Can't find a valid spi flash chip.

MMC/SD controller initialization.
MMC/SD Card:
    MID:         0x45
    Read Block:  512 Bytes
    Write Block: 512 Bytes
    Chip Size:   3776M Bytes (High Capacity)
    Name:        "SEM04"
    Chip Type:   MMC
    Version:     4.0
    Speed:       25000000Hz
    Bus Width:   8bit
    Boot Addr:   0 Bytes

Boot Env on eMMC
    Env Offset:          0x00100000
    Env Size:            0x00010000
    Env Range:           0x00010000


SDK Version: HiSTBAndroidV500R001C00CP0008_v2014120116

start led blink
ir_led_blink_proc start led blink
ir_led_blink_proc start led blink
ir_led_blink_proc start led blink
ir_led_blink_proc start led blink
ir_led_blink_proc start led blink
ir_led_blink_proc start led blink
ir_led_blink_proc start led blink
ir_led_blink_proc start led blink
ir_led_blink_proc start led blink
ir_led_blink_proc start led blink
mac:04:02:1f:19:ce:21
1 blocks read: OK

Reserve Memory
    Start Addr:          0x35FFF000
    Bound Addr:          0x3E1F000
    Free  Addr:          0x34E89000
    Alloc Block:  Addr        Size
                  0x34E89000       8192
                  0x34E8C000       3133440
                  0x3518A000       3686400
                  0x3550F000       1658880
                  0x356A5000       8294400
                  0x35E8F000       12288
                  0x35E93000       1048576
                  0x35F94000       212992
                  0x35FC9000       8192
                  0x35FCC000       204800

32768 blocks read: OK
## Starting Secure OS at 0x36000000 ...
## Secure OS Image:
   Header Size: 0x400 (1 KB)
   Kernel Load Addresss: 0x38001000
   Kernel Size: 0xadbd4 (694 KB)
   Task Number: 7
   Task Total Size: 0x141BF0 (1286 KB)
Loading Secure OS ...
================task_addr:0x36000000
uwSCR = 0x600001d3
Set all interrupts to be non-secure
gic_int_num:160
address:f8a01080,value:00000000
address:f8a01080,value:f800ffff
address:f8a01084,value:ffffffff
address:f8a01088,value:ffffffff
address:f8a0108c,value:ffffffff
address:f8a01090,value:ffffffff
GICC_PRIMASK primask 000000f8
GIC_ID_PHY_BASE value 00000000
GIC_IC_PHY_BASE value 00000000
SCU Init
CodeStart = 0x38001000, CodeEnd = 0x38276c00
map_section_entry 2 times l1_index:0x00000382
===map UART Shareable device start==== === === = !!!
===map UART Shareable device ==== === === = !!!
===map Timer Shareable device ==== addr[f8a81000] === === = !!!
===map GIC Shareable device ==== addr[0xFC000000] === === = !!!
===map TZPC Shareable device ==== addr[0xFCA00000] === === = !!!
===map L2 cache registers ==== addr[0xFC100000] === === = !!!
===map suspend registers 1 ==== addr[0xFCC00000] === === = !!!
===map suspend registers 2 ==== addr[0xFCD00000] === === = !!!
intRestore OK 3!
attension please : excute from osTaskInit!!!!!!
osMemSystemInit default pt done 0x00080000
attension please : osSysInit OK!!!!!!
attension please : osHwTmrInit OK!!!!!!
attension please : osSwiInit OK!!!!!!
attension please : osTskInit OK!!!!!!
attension please : osHuntInit OK!!!!!!
attension please : osMsgInit OK!!!!!!
attension please : osSemInit OK!!!!!!
System Security Config... OK!
map_section_entry 2 times l1_index:0x00000f8a
TrustZone enabled...  OK!
map_section_entry 2 times l1_index:0x00000f8a
map_section_entry 2 times l1_index:0x00000f8a
map_section_entry 2 times l1_index:0x00000f8c
map_section_entry 2 times l1_index:0x00000f8c
Create secure mem zone... OK!
Create non-secure mem zone... OK!
Init Cipher driver... OK!
<<<OTP DBG>>> OTP_DRV_ModInit 373: OTP init success!
attension please : before task_func OK!!!!!!
global_task_base=0x36200000
osTaskInit done
os initialization successfully
uwMMUCtrl = 0x00c5187f
have defined OS_STB_HiS40V200
RTOSck start to schedule date: 06-26 Change-Id: IB790
init_map_loader:TASK_ADDRESS=0x36400000 order=0x00000002
internal task[0] load success, task name:task_demo1
init_map_loader:TASK_ADDRESS=0x36800000 order=0x00000002
internal task[1] load success, task name:task_demo2
init_map_loader:TASK_ADDRESS=0x36300000 order=0x00000000
internal task[2] load success, task name:task_demo3
init_map_loader:TASK_ADDRESS=0x36c00000 order=0x00000001
internal task[3] load success, task name:dxwidevine
init_map_loader:TASK_ADDRESS=0x37000000 order=0x00000003
internal task[4] load success, task name:task_QA_TZService
init_map_loader:TASK_ADDRESS=0x37800000 order=0x00000002
internal task[5] load success, task name:task_dxhdcp2
Back to boot
## Succeed to load Secure OS
32768 blocks read: OK
## Booting kernel from Legacy Image at 01ffffc0 ...
   Image Name:   Linux-3.4.67_s40
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    7518304 Bytes = 7.2 MiB
   Load Address: 02000000
   Entry Point:  02000000
   Verifying Checksum ... OK
   XIP Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
===TrustedCore hisik3_init_cache started===
===TrustedCore l2x0_init ok===
<<<CIPHER INFO>>> Cipher_Init 166: Cipher init success!
<<<CIPHER INFO>>> HAL_Cipher_HDCPTxReadEnable 1227: tx_read = 1
<<<CIPHER INFO>>> Cipher_DeInit 173: Do nothing, cipher deinit success!
<<<OTP DBG>>> OTP_Init 395: Do nothing, OTP init success!
<<<CIPHER INFO>>> Cipher_Init 166: Cipher init success!
<<<OTP DBG>>> OTP_DeInit 403: Do nothing, OTP deinit success!
<<<CIPHER INFO>>> Cipher_DeInit 173: Do nothing, cipher deinit success!
<<<OTP DBG>>> OTP_Init 395: Do nothing, OTP init success!
<<<CIPHER INFO>>> Cipher_Init 166: Cipher init success!
<<<OTP DBG>>> OTP_DeInit 403: Do nothing, OTP deinit success!
<<<CIPHER INFO>>> Cipher_DeInit 173: Do nothing, cipher deinit success!

Kernelの起動メッセージは普通に出ていますが、その前のブートローダはARM系でよくあるu-bootではありません。
また、Kernelの前にどうやらTrusted Secure OSというようなものが起動しているようです。
この間、いろいろキーを打ち込んでみたけど反応がありませんでした。

adbから接続した状態では生パーティションの状態を取得することができません。
そのため、以前PSCなどの吸出しで用いたeMMC配線乗っ取り法で別PCからeMMCのデータを読み込んでみることにしました。

そうしたところ、eMMCの内容が参照できましたが、見たところRAWパーティションが鎮座しているだけでした。
いろいろ調べた結果、どうやらeMMC内に普通のパーティションを切っているのではなく、bootargsのパラメータでLinuxから認識されているようです。
blkdevparts=mmcblk0:1M(fastboot),1M(bootargs),2M(reserve1),16M(trustedcore),4M(reserver2),16M(recovery),2M(deviceinfo),8M(baseparam),8M(pqparam),20M(logo),40M(fastplay),16M(kernel),4M(misc),512M(system),16M(drmsfs),512M(cust),256M(cache),-(userdata)

この値を参照して作成したのが以下のパーティションリストです。
1k offset offset(byte) size MB
0 fastboot 0 0 1
1 bootargs 1024 1048576 1
2 reserve1 2048 2097152 2  ( zero filled)
3 trustedcore 4096 4194304 16
4 reserve2 20480 20971520 4 ( zero filled)
5 recovery 24576 25165824 16
6 deviceinfo 40960 41943040 2
7 baseparam 43008 44040192 8
8 pqparam 51200 52428800 8 ( zero filled)
9 logo 59392 60817408 20
10 fastplay 79872 81788928 40
11 kernel 120832 123731968 16
12 misc 137216 140509184 4 ( zero filled)
13 system 141312 144703488 512
14 drmsfs 665600 681574400 16
15 cust 681984 698351616 256
16 cache 1206272 1235222528 256
17 userdata 1468416 1503657984 last

kernel内にはuImage形式のKernel (+cpio.gz initramfs)が入っていました。
ちょっと頑張ってcpio.gzの中身を書き換えて書き戻したところ、Kernelの読み込みメッセージが表示される前に、bootloaderからresetされてしまいました。
また、bootargsの中、bootcmd=mmc read 0 0x36000000 0x2000 0x8000; loadsos 0x36000000; mmc read 0 0x1FFFFC0 0x3B000 0x8000; bootm 0x1FFFFC0
の部分を潰してしまえばbootloaderのコンソールか何かに残れるのではないかと試してみましたが、
この部分がまったく参照されていないような動きをしました。(何を書いておいてもsosの読み込み、起動後に kernelが起動される)
しかし、このパーティションの先頭4バイトがチェックサムなのですが、それが合わないとやはりresetされます。
また、bootcmdを書き換えても動作は変わりませんでしたが、パーティションの識別文字列を書き換えたらやはりresetされました。
どうやら、なにか書き換え防止の仕組みがあるようです。

adbで入って
shell@android:/proc $ cat partitions
major minor #blocks name

179 0 3866624 mmcblk0
179 1 1024 mmcblk0p1
179 2 1024 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 16384 mmcblk0p4
179 5 4096 mmcblk0p5
179 6 16384 mmcblk0p6
179 7 2048 mmcblk0p7
259 0 8192 mmcblk0p8
259 1 8192 mmcblk0p9
259 2 20480 mmcblk0p10
259 3 40960 mmcblk0p11
259 4 16384 mmcblk0p12
259 5 4096 mmcblk0p13
259 6 524288 mmcblk0p14
259 7 16384 mmcblk0p15
259 8 524288 mmcblk0p16
259 9 262144 mmcblk0p17
259 10 2398208 mmcblk0p18
179 16 2048 mmcblk0boot1
179 8 2048 mmcblk0boot0
これだと、eMMC->USBリーダ接続だと認識できないboot0とboot1が表示されますが、

shell@android:/proc $ cat /dev/block/mmcblk0boot0
/system/bin/sh: cat: /dev/block/mmcblk0boot0: Permission denied
この中身は表示できません。
そのため、BeagleBoneBlack等、生のMMC接続を持つ何らかの機器に接続してこのパーティションを覗いてみたいと思います。

まあ、root化したところでそんなに面白いことができるわけではないと思うんですが…

FUSO デジタルCo2/O2チェッカー CD-2IRを分解する

ちょっと業務で使う必要があったのでこいつを調達。

「FUSOデジタルCO2・O2チェッカーCD-2IR」

 ほんとはデジタル出力が出るものがほしかったんだけど、
1プローブでCo2,O2が測れてデジタル出力のあるものが見当たらなかったので
次点でアナログ出力のあるこいつに。

Co2はNDIR,O2はガルバニ電池。
O2のレンジは5%~30%、Co2は0.04~5%。
学校の酸素・二酸化炭素の実験なんかで使うためにウチダのカタログに載ってるような商品で、呼気のレベル(2%~)が計測出来ます。

 

その辺で買える室内環境用のCo2センサは3000ppmとか5000ppmとかまでで、
このレンジのものはあまり売ってないのです。
 

ある程度正確性を要する案件なので、単センサは選定できず。
使う前に構造を知っておきたいのと、今後できればセンサ単体でシステムを作りたいので確認のために分解します。

f:id:honeylab:20200221112133j:plain

 

本体裏表

f:id:honeylab:20200221112253j:plain f:id:honeylab:20200221112302j:plain

 

単三電池4本のほか、AC/DCアダプタで動作可能。
左から電源、アナログ出力、センサプローブ端子

f:id:honeylab:20200221112311j:plain

 

f:id:honeylab:20200221112451j:plain

裏蓋をあけたところ

f:id:honeylab:20200221112556j:plain

内部マイコンボードを外したところ。

f:id:honeylab:20200221112724j:plain

メインマイコンボード。CPUはTOSHIBAのTMP86FM29LUG。

f:id:honeylab:20200221112236j:plain

Co2/O2一体型プローブ。開けてみる。

f:id:honeylab:20200221114150j:plain

f:id:honeylab:20200221114159j:plain

f:id:honeylab:20200221114159j:plain

O2センサは SK-25F アナログ電圧が出力されるタイプ

www.figaro.co.jp

 

Co2センサはsenair.comのもので、型番が読めないけどおそらく5%maxのこいつかな。

senseair.com

こっちはmodbusらしい。

f:id:honeylab:20200221114244j:plain

プローブ基板と本体はVCC/GND/緑/白の4芯でつながってるのでi2cあたりに変換してるのかな?
プローブ基板の裏、写真左側のゲジゲジがたぶんそのマイコン

真ん中のはO2センサの出力(0-10mV)のアンプかと。

 

電源を入れると60秒のウォームアップが。バブルシステムではない。

f:id:honeylab:20200221115018j:plain

ウォームアップ後、そこを外気とみなして21% O2に校正してしまうので、
そうでない環境で電源をON/OFFできないのがちょっとあれ。

Co2は明示的に校正ボタンで400ppm。

 

f:id:honeylab:20200221115154j:plain

 

軽く息を吹きかけてみたところ。約1% Co2。

センサの動作環境としてRH 80%までという要求があるので、
測定空気を盤用除湿器に通したところで測定する、という構造を作ってみる予定。

アナログ出力専用ケーブルを発注し忘れてた…作れるけど、仕事なので買う…