honeylab's blog

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

(汎用) SPIメモリのダンプからパーティションを切り出す

吸い出したメモリダンプからパーティション切り出すために、サイズを確認します。

手がかりとなるのは、Kernelコマンドライン

Kernel command line: console=ttySGK0,115200 mem=36M rootfstype=squashfs root=/dev/mtdblock2 init=linuxrc mtdparts=gk_flash:320K(U),1664K(K),1152K(R),2560K(A),-(H)\

mtdpartsパラメータと起動時の下記の表示です。

f:id:honeylab:20190510083000p:plain

なぜこのようなパラメータが必要なのか。それはSPIメモリは、USBメモリやHDDのような共通的なパーティションテーブルの仕組みを採用していないことが多いからです。
そのため、明示的にこのようなサイズ指定を行ってパーティションを決定してやる必要があります。

16進表記 10進表記 サイズ(K表示)
Start End Start End  
0 50000 0 327680 320
50000 1f0000 327680 2031616 1664
1f0000 310000 2031616 3211264 1152
310000 590000 3211264 5832704 2560
590000 800000 5832704 8388608

2496

さて、実際に吸い出したROMを解析します。
Linuxでよく使われる binwalk というツールを使います。 

binwalk dump.img -y filesystem

 によって、以下の出力が得られます。

DECIMAL HEXADECIMAL DESCRIPTION
---------- ----------------- -----------------------------------------------------
2031616 0x1F0000 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 1058498 bytes, 217 inodes, blocksize: 131072 bytes, created: 2018-08-28 05:24:06
3211264 0x310000 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 2248460 bytes, 4 inodes, blocksize: 131072 bytes, created: 2019-01-14 08:29:23
5832716 0x59000C JFFS2 filesystem, little endian

このパーティションの開始位置は、先程の開始位置と一致します。

しかし、3番めからです。

1番めと2番めはそれぞれ U-boot と Kernelのバイナリイメージがそのまま書き込まれています。パーティション内にファイルシステムを持っていません。

では、それぞれのパーティションをファイル化します。

 dd if=dump.img of=mtd2_Root.img skip=1984 bs=1024 count=1152

 dd if=dump.img of=mtd3_A.img skip=3136 bs=1024 count=2560

 dd if=dump.img of=mtd4_H.img skip=5696 bs=1024 count=2496

 これらのコマンドで後半3つのパーティションが切り出せます。
mtd2とmtd3はhsquashファイルシステム、mtd4はjffs2ファイルシステムのようです。

これをLinuxマシンに持っていって、マウントを試してみます。

マウントポイントを作成します。

sudo mkdir /mnt/mtd2

sudo mkdir /mnt/mtd3

sudo mkdir /mnt/mtd4

 マウントしてみます。

sudo mount mtd3_A.img /mnt/mtd3
sudo mount mtd4_H.img /mnt/mtd4 

 エラーが出なかったようなので、マウントできているようです。

マウントポイントに移動してlsしてみます

 /mnt/mtd2$ ls
bin etc init linuxrc mnt opt proc run sys usr
dev home lib media nfsroot p2pcam root sbin tmp var

 /mnt/mtd3$  ls
ca-bundle-add-closeli.crt cloud.ini p2pcam

 マウントできたようです。

mtd2がLinuxのルートファイルシステムです。また、mtd3はルートファイルシステムの/p2pcamをマウントポイントとしてマウントされます。

p2pcamは前に書いたように、このカメラのメインアプリケーションです。

どうやら、パーティション名の’A' は Application , ’R' は Root file system, 'H' は Homeのようですね。

そして、mtd4をマウントしようとしたところ、jffs2がサポートされていないと言われてしまいました。

jffs2はフラッシュメモリ用のファイルシステムのため、一般的なデスクトップ用のLinuxではドライバが入っていないようです。この辺を後で続けて試してみようと思います。

ドンキWiFIカメラ(6) SPIメモリをダンプする

さて、もういいかげんなんかハックしなきゃと思いつつ、とりあえずSPIメモリのフルダンプを取ります。
この間リーダーを買ったので取り外して読んでもいいですが、

honeylab.hatenablog.jp

ここはひとつ、u-bootから読んでみます。

シリアルを接続し、u-bootの起動中にキー入力でコンソールに落ちます。

 

GK7102 # sf probe

で実装されているSPIフラッシュが確認できます。

GK7102 # sf read 0xc1000000 0 0x800000

で、RAM上に SPIフラッシュの 0番地から 8Mぶん(全部)を読み込み、

SDカードを認識させます。

GK7102 # fatinfo mmc 0
[PROCESS_SEPARATORS] fatinfo mmc 0
Interface: MMC
Device 0: Vendor: Man 035344 Snr 173110f7 Rev: 8.0 Prod: SU32G
Type: Removable Hard Disk
Capacity: 30436.5 MB = 29.7 GB (62333952 x 512)
Partition 1: Filesystem: FAT32 "VOLUME1 "

先ほど読み込んだ内容をSDカードに書き込みます。

GK7102 # fatwrite mmc 0:1 0xc1000000 dump.img 0x800000
[PROCESS_SEPARATORS] fatwrite mmc 0:1 0xc1000000 dump.img 0x800000
writing dump.img
8388608 bytes written

 

ちゃんと書かれているか確認します。

GK7102 #
GK7102 # fatls
[PROCESS_SEPARATORS] fatls
usage: fatls <interface> [<dev[:part]>] [directory]
GK7102 # fatls mmc 0
[PROCESS_SEPARATORS] fatls mmc 0
dcim/
system volume information/
lost.dir/
android/
139676 board.pdf
27 info.txt
8388608 dump.img

3 file(s), 4 dir(s)

 SDカードを流用しているので他のファイルも見えますが、正しく書き込めているようです。

これをWindowsに持って行って読んでみます。

 

f:id:honeylab:20190509165721p:plain

読めてるっぽい。

 との結果も同じっぽいのでちゃんと読めてるっぽいな。

 

ドンキWiFIカメラ(5) じゃぁ何が問題なのか

まだ書くのかよ…という声が聞こえてきそうだけど、自分の勉強のためにも少しまとめておこう。

例のWiFiカメラ、Linuxは入っていないとのことですが、
基板に搭載されたSPIフラッシュの中身及び、電源が入っている状態で以下のソフトウェアが動作しています。

 

パッケージ名

該当バージョン  ライセンス
u-boot U-Boot 2012.10 (Dec 26 2017 - 18:17:43) for GK7102 rb-sc1045-v2.0 (GOKE) GPL
Linux

Linux version 3.4.43-gk (root@localhost.localdomain)

(gcc version 4.6.1 (crosstool-NG 1.18.0) ) #71 PREEMPT Fri Nov 10 15:20:07 CST 2017

GPL
busybox BusyBox v1.22.1 (2018-08-20 14:07:18 CST) multi-call binary. GPL
     
p2pcamに 以下のライブラリが静的リンクされている模様  
mkdosfs mkfsdos 2.11由来のリソースが多数検出 (2.11 (12 Mar 2005)) GPL
Wireless-Tools  Wireless-Tools 由来のリソースが多数検出 GPL
Zbar QRコード読み取りに使用 LGPL

 

そもそも、本体のプログラムとしてGPLのものを使っている場合(バイナリが当然配布されますので)、GPLに基づく著作権表記をしなければなりません。

例えば、これはe-mobileのPocketWiFiの説明書にある表示です。

f:id:honeylab:20190508001345p:plain

最近のルータ等、ネットワークでちょっと難しいことをするような製品にはたいていLinuxをはじめとするGPLのモジュールが含まれることがほとんどです。

しかし、ドンキのWiFi見守りカメラのどこを見てもこのような表示は見当たりません。
つまり、GPLの要求する著作権表示条件を満たしていないことになります。

まぁ、Linuxが入っていないと思っているんだから仕方ないかもしれません
その他、上の表に入っているモジュールが確認されていますので、それぞれの著作権表記と、ソースコードの公開が必要です。
p2pcamというクラウドサーバと通信するこのカメラのキモのアプリですら、GPLLGPLの制限により同様の処置が必要です。
設定用のQRコードを読み取るっていう重要そうな処理にZBarを使っているのですが、静的リンクにしてればちょっと状況は違ったかもしれませんが、ほかにもGPLが入っているので結局駄目ですね。

 

以下、お詫びして訂正します。出てきたわ。

 

でも、ソースコード絶対出ないよ。出すわけないもん。

 

なんでかっていうとまぁ結構みんな指摘している通り、このカメラは中華のどっかのメーカが作っているOEM製品なわけですよ。

例えばこれ

https://hkhongmei.en.alibaba.com/product/60861646443-805849863/YCC365_Plus_APP_auto_tracking_HD_720P_indoor_Fixed_WiFi_IP_Camera.html

https://ja.aliexpress.com/item/Wdskivi-1080-1080P-IP-WiFi-Cctv/32967060735.html

https://store.shopping.yahoo.co.jp/ekou/288zd-1080.html

こんなの。

見てわかるように、なんだかよくわからない販売店が売っているような製品です。
このメーカたちにコード請求しても絶対出さないよ。
国内のメーカーですら出さないところあるし。

 

そんな製品を、国内のあるメーカが開発元としてドンキに納品して、こうやって私のお手元に届いたわけ。
これ、ドンキみたいな販売店が手を出しちゃいけなかった製品なんだよ。

正直、ドンキには同情します。本当に知らなかったんじゃないかと。
しかしまぁ、開発元としてやってるところはこれほんとは知ってるだろ。
扱ってる商品がAndroidタブレットだったりナビだったり、OEMやってたり。

 

そんなわけで、セキュリティがポンコツうえにGPL違反でアレげな製品ですが、カメラと無線LAN(RTL8188)とSDカードスロットとマイクとスピーカー(単純なADCとDACっぽくてLinuxから見えないけど)がついて、実際に使える上に3980円となかなかお値打ちな製品なんで、そういうものを自作する代わりに買う、という用途にはおすすめです。

 

GPL関係で何か間違ってたら教えてください。ライセンス周りは素人なので。

 

ドンキWiFiカメラハック(4) セキュリティ上の問題と、Linuxは使用されていなかった!

【追記】改めて確認したところ、製造元及びドンキホーテLinuxの使用を確認し、ソースコードの開示をはじめました。

 

ここまでの調査の結果、以下のような問題がわかりました。

 

このカメラ、とにかくWiFiにつないでクラウド経由で画像を表示することが目的で、ローカルのセキュリティはポンコツです。
アプリからはメールアドレスとパスワードで紐付けられたユーザしか利用できませんが、
telnetやRTSPはローカルに流れたままのため、このカメラが接続されたネットワーク環境内からは画像が自由に見れることになります。また、パスワードを設定することは不可能です。
そのため、このカメラを設置したネットワーク環境では、WiFiのパスワード管理を行ったり、知らない人にLANポートを貸したりしないようにしたほうがいいです。

f:id:honeylab:20190507132346p:plain



先述の通り、telnet経由で自由にスクリプトを仕込むことができます。
定期間隔で、自分の専用サーバに画像を送ったり、動画を見続けることも可能になってしまう可能性があります。(実行した本人が法に触れる可能性があります。)

ただし、これはこの製品特有のものではなく、いわゆる中華カメラ製品にはよく見られるものです。それなのにそのまま、まるで日本の市販製品のようなガワをつけて販売しているのは問題ではないかと思いますが、あんまり追い詰めるとこんなにおもしろいデバイスが安く買えなくなってしまいますのでそっとしておきましょう(遅い)。

 

以下は、最初の対応ですが、その後Linuxが使われていることを確認してくれました。

また、ここまでの調査で、本体内にはu-bootやLinuxカーネルbusyboxのバイナリがあることがわかっていました。そのため、発売元であるドン・キホーテソースコードの開示を請求したところ、きちんと開発会社に確認を取り、

Linuxを使用していないので開示できるソースコードはない」

と返答をしてくれました。

 

なんと!Linuxは使用されていないとのことでした!
販売元を通じた回答なのでこれが正式な回答なのでしょう。

基板に乗っているSPIFlashにu-bootやLinuxKernelのバイナリが入っていますが、使用していないなら仕方ありま…

(しかし、使用されていなくてもバイナリが渡ってたらソースもいるんじゃなかったっけ…)せん!

いや、ぶっちゃけそのモノ自体には興味がなく、販売元と製造元がどんな対応をするのか、ということ自体に興味があったので、その結果が得られて満足です。

 

さてさて、まぁLinux入ってるんで、まだまだいろいろ遊んでみますかね。

改めて言うけど、パスワード設定できないんで、ローカルLAN内でのセキュリティに気をつけてね!!

ドンキWiFiカメラハック(3)

前回までの記事はこちら

honeylab.hatenablog.jp

honeylab.hatenablog.jp

 

追加してきたのでもう安心。

Image

 

さてと、このカメラ、AndroidiOSにターゲットを絞り、クラウドに誘導することで日銭を稼ぐシステムの片棒を担がされている気がするので、その辺を外していきます。

ドンキはこれいくらで仕入れてきてるんだろう?

開いてるポート番号を調べてみます。外からツールを使うのではなくて、netstatで調べます。

# netstat -a -p
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 localhost:9008 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:www 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:telnet 0.0.0.0:* LISTEN 204/telnetd
tcp 0 0 0.0.0.0:5050 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:7101 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:7103 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:8001 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:3201 0.0.0.0:* LISTEN 159/tees
tcp 0 0 0.0.0.0:554 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:843 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:6670 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 157 192.168.200.1:telnet 192.168.200.100:5388 ESTABLISHED 204/telnetd
udp 0 0 0.0.0.0:7998 0.0.0.0:* 187/p2pcam
udp 0 0 0.0.0.0:8001 0.0.0.0:* 187/p2pcam
udp 0 0 0.0.0.0:8002 0.0.0.0:* 187/p2pcam
udp 0 0 0.0.0.0:bootps 0.0.0.0:* 269/udhcpd
udp 0 0 0.0.0.0:8888 0.0.0.0:* 187/p2pcam
udp 0 0 0.0.0.0:20188 0.0.0.0:* 187/p2pcam
udp 0 0 0.0.0.0:9999 0.0.0.0:* 187/p2pcam
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 259 185/rsyscall.goke /tmp/systemcall.sock
unix 2 [ ACC ] STREAM LISTENING 282 187/p2pcam /tmp/aaa
unix 2 [ ] DGRAM 547 264/hostapd /var/run/hostapd/wlan0
unix 3 [ ] DGRAM 231 159/tees /var/run/tees.sock
unix 2 [ ] STREAM CONNECTED 327 264/hostapd /tmp/systemcall.sock
unix 2 [ ] DGRAM 299 187/p2pcam 

見にくい。Excelで整形しよう。

9008 187/p2pcam
www 187/p2pcam
telnet 204/telnetd
5050 187/p2pcam
7101 187/p2pcam
7103 187/p2pcam
8001 187/p2pcam
3201 159/tees
554 187/p2pcam
843 187/p2pcam
6670

187/p2pcam

 telnetdはbusyboxで、そのほかのサービスは内蔵のカメラアプリが開いて要るっぽい。
専用サーバアプリじゃないのでURLが分かりにくい…

使えそうなポートを確認してみる。554はRTSPだ。

VLC Media Playerを開き、rtsp://192.168.200.1:554/ を開く。

f:id:honeylab:20190507050737p:plain

うん。簡単に再生できた。ローカル内で監視するならこういった簡単な操作が望まれる。

f:id:honeylab:20190507051003p:plain

(上記画像は、暗いところなので暗視白黒になっている)

これで遠隔からptzを制御できれば完璧なのだが、どうやら今のところ独自プロトコルらしく、独自に解析されたこちらのツールを使うのがいいようだ。

https://github.com/ant-thomas/zsgx1hacks

wwwもあるのだが、どうも該当ファイルが置いていないか無効化されていて何もできないっぽい。上のハックツールではそれを利用しているようにも見える。

 

そして、ここの解析にもある通り、このWebカメラ、起動時にmicroSDスロットに特定のファイル名でシェルスクリプトを置いておくと実行してくれる超便利な機能があるっぽい。

f:id:honeylab:20190507052835p:plain


うーん、便利!

このカメラ、なんとスピーカーが付いていて起動後何も設定されていなかったりすると「QRコードを読み込んでなんたらかんたら」って怪しいイントネーションの日本語でしゃべったりするんですよね。

この音声ファイルはFLASHに圧縮されて書き込まれていて、起動時にRAMに展開されています。

FLASHを上書きするのはちょっとめんどいので、RAM上のこのファイルを上書きすると好きな音声でしゃべらせられるようになると思います。

f:id:honeylab:20190507053507p:plain

あと、一部の音声は英語のままなので出ないと思いますし、怪しくないイントネーションの日本語もあるので、オリジナルの日本語対応の後、クラウド化による日本語追加が行われている気がします。

alarm.wavはひゅーんっていう効果音で、何か警告音を鳴らせるのでしょうか。

これが謎の音声とかにできれば不審者にいいトラウマを植え付けられますね(駄目です)
うーん、単独で音声ファイルを再生できるツールがあれば任意のタイミングでならせる気がするが、これp2pcamバイナリでしかできないのかな…(Linuxサウンドバイスとしては見えてない)

 

その他のポートが何なのか今のとこわかっていないが、RTSPでストリームを見れるだけで結構便利だと思います。
ネットワークに詳しいならクラウド使わなくてもこれだけ転送すれば行けるでしょ

(セキュリティに気を付けてね!)

 

<追記>

普通にONVIFカメラとしてストリーム再生、PTZ操作できました…

f:id:honeylab:20190507073821p:plain

 

ドンキの見守りWiFiカメラ「スマモッチャ-」を発売直後に分解してハックし始める(シリアル、telnetログイン)

もう一台買おうと思っていたのにGWで実家に帰っているうちに地元店舗から在庫が消えているぞ…

 

さて、実際にハックし始めます。
背面のmicroUSB端子は物理的に電源ピンしか配線されていませんので通信等の機能はありません。

調べてあったUART端子にUSB-TTL変換ケーブルを接続し、シリアルログインを試みます。

 

しかし、rootのパスワードがわかりません。

が、実はこのボードの共通パスワードがデフォルトのままセットされているためそれが使えてしまいました。
ここに直接書くとアレげですが、前の記事にあるキーワードでググり続けると見つかると思います。

f:id:honeylab:20190506003041p:plain

さっくりそのパスワードでログインできました。

しかし、なんだかデバッグメッセージが表示されてて作業しにくいです。
dmesg -n 1でも消えないプログラムからの表示がシリアルに流れているようです。

で、psを見てみると。

f:id:honeylab:20190506003203p:plain

telnetdが動いているようなので、接続にトライします。

ifconfigを見てみます。

f:id:honeylab:20190506003252p:plain

起動直後、何も設定していない状態では、こいつがAPになった状態になっていますので、PCからそのアクセスポイントにつないでやります。
SSIDはCLOUDCAM_(MACADDRESS)になっています。

f:id:honeylab:20190506003408p:plain

これにつなぐと、192.168.200.xのIPがもらえるので、192.168.200.1にtelnetしてみます。

f:id:honeylab:20190506003458p:plain

f:id:honeylab:20190506003722p:plain

 

つながっちゃった。
これで変なメッセージも出ないし、複数ターミナル開けたりで便利です。

あとは、wwwが立ち上がってるんだけど、デフォルトで変なパスに飛ばされちゃうな…

 続きはこちら

honeylab.hatenablog.jp

ドンキの見守りWiFiカメラ「スマモッチャ-」を発売直後に分解してハックする(準備)

はい、スルーする予定だったんだけど、誰かがTwitter

なんのSoC入ってるんだろう、って言ったのを見ていてもたってもいられなくなって

発売直後に買ってきて(正確には勢い余って前日深夜に確認しに行って、翌朝発売であることを確認した)

www.gizmodo.jp

 

その直後に駐車場で分解して納得して、

色々調べた後ようやくシリアルコンソールログを確認したところです。 

メイン基板の裏表

f:id:honeylab:20190503233144p:plain f:id:honeylab:20190503233217p:plain

 

各部の説明はこんな感じ

 

f:id:honeylab:20190506001410p:plain f:id:honeylab:20190504231327p:plain

 

 SoCはGOKEとかいうところのGK7102っていうやつ。

ARM系。なのでu-bootが入っていると期待される。

 FLASHはSPI接続のGD25Q128。8MByte。

 さっそくu-bootのログ

https://bitbucket.org/!api/2.0/snippets/bakueikozo/7eGyeK/2e406a886913a2b21f17ccbc673ab64101233b5e/files/u-boot%E3%83%86%E3%82%B9%E3%83%88

 

Linuxの起動ログ

https://bitbucket.org/!api/2.0/snippets/bakueikozo/7eGyeK/2e406a886913a2b21f17ccbc673ab64101233b5e/files/%E9%80%9A%E5%B8%B8%E8%B5%B7%E5%8B%95

電源投入後、u-boot実行イメージがSPI FLASHから読み込まれ、
続いて、 Linuxカーネルを読み込んで実行する。

u-bootのコマンドラインはこれ

bootargs=console=ttySGK0,115200 mem=36M rootfstype=squashfs root=/dev/mtdblock2 init=linuxrc mtdparts=gk_flash:320K(U),1664K(K),1152K(R),2560K(A),-(H)
bootcmd=sf probe;sf read 0xc1000000 0x50000 0x1A0000;bootm 0xc1000000;

 

CPU情報はこれ。

[ 0.000000] Booting Linux on physical CPU 0
[ 0.000000] Linux version 3.4.43-gk (root@localhost.localdomain) (gcc version 4.6.1 (crosstool-NG 1.18.0) ) #71 PREEMPT Fri Nov 10 15:20:07 CST 2017
[ 0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[ 0.000000] CPU: VIPT aliasing data cache, VIPT aliasing instruction cache

 

[ 0.020000] Calibrating delay loop... 597.60 BogoMIPS (lpj=2988032)

 

u-boot、Linuxが起動して、p2pcamっていうアプリがクラウドとの通信を行う。

基板上に載ってるRTL8188のWiFi基板はSoCとUSBで接続されてる。

[ 8.550000] usbcore: registered new interface driver rtl8188fu

u-bootの時点でSPI FlashもMMCも生きてるのでMMCから起動とかもできそう。
SPI剥がさなきゃかな?とか思ってたけど全然そんな必要ないわ。

 

######Get Hardware Info: model:CloudCam, firmware-ident:eyeplus_ipc_gk_005

っていうのがベースのハードウェアなのかな。

イメージセンサは GC2033

[ 0.170000] [GPIO CFG] IR CUT1 (44)
[ 0.170000] [GPIO CFG] IR CUT2 (39)

IRカットって電子制御なの?昼間切っとけば透けるんじゃね?(何が)

 

https://www.gcoreinc.com/product/showproduct.php?lang=cn&id=107

Flashパーティション分け

[ 0.610000] gk_flash gk_flash.0: GD25Q64C (8192 Kbytes)
[ 0.620000] 5 cmdlinepart partitions found on MTD device gk_flash
[ 0.620000] Creating 5 MTD partitions on "gk_flash":
[ 0.630000] 0x000000000000-0x000000050000 : "U"
[ 0.640000] 0x000000050000-0x0000001f0000 : "K"
[ 0.640000] 0x0000001f0000-0x000000310000 : "R"
[ 0.650000] 0x000000310000-0x000000590000 : "A"
[ 0.660000] 0x000000590000-0x000000800000 : "H"

U-boot,Kernel,あとはなんだろ。

 

っていうか、このSoC使われまくっててすごい解析・ハックされてるわ。
このカスタムイメージ書くだけで色々できそう。

さて、続きはGW開けてからです…とりあえず最速分解は達成できたかな…

 

続きはこちら

honeylab.hatenablog.jp