Writeup : 2020年に修正されたとある脆弱性について

どうもみむらです。

年末です。後数時間で年が変わります。
私はといえば、「千葉県少年少女オーケストラとアキラさんの大発見コンサート2020」の放送を見ながら、この記事を書き終えたらソバをと最後の力をふりしぼっているところです。

宮川彬良さんのアルバム、時々仕事中にも聞いておりますが
音楽の中に遊びというか楽しみポイントが多数含まれているのもあって、すごい人だなと思うわけです。

・・・いや、今回はそういうことを書きたいわけではなくて。


今年、9月頃にとある一つの脆脆弱性が修正されました。

私が報告者になっているもので古いバージョンの製品に含まれていたものではありますが、
色々なベンダーさんでもやってしまいそうな知見が多々ありましたので
軽くご紹介できたらな、と。

なお、仕事柄脆弱性診断は行っておりますが、
趣味の範囲での発見で既に修正されているものになります。

またこの記事は特定の製品やブランドを貶めることは一切目的としておりません
自社の製品に対して「こういう脆弱性あるかも知れない」という気づきとして使って頂くことを目的としておりますので、ご理解ください。


今回の脆弱性では
「ソフトウェアアップデート」の処理において下記のような問題点がありました。

  • ソフトウェアアップデートのファイルの検証に不備があり
    任意のファイルを挿入できた。
  • ソフトウェアアップデートのファイルの処理に不備があり
    高権限で任意のコードを実行できた。

1.ソフトウェアアップデートのファイル検証

今回のソフトウェアではアップデートの方式が下記のような仕組みになっていました:

  1. サーバからアップデートのメタ情報を取得する
  2. メタ情報に手元のソフトウェアより新しいソフトウェアがあればダウンロードする
  3. アップデートに際し追加の処理が必要な場合は実行する

今回一つ目の問題点だったのは
「ソフトウェアアップデートのファイル検証」が不十分だったことでした。

ダウンロードしたファイルに付属しているメタデータは下記のような構造でした。
(実際にはもっと多くの情報などがあり、このように簡易な形にはなっていません)

ここにおいてのファイルチェックの方法に下記の不備がありました。
(繰り返しではありますが既に修正済みです)

  • “file” 要素で記述されているファイルのみチェックされる
    記述されていないファイルはチェックされない
  • “file” 要素で書かれている内容が MD5 や SHA1によるファイルのハッシュのみだった。
    → ファイルの整合性は検証できるが、
     「信頼出来るところからのものか」を検証できない

今回のケースでは、その先の処理でファイルの信頼性の検証は行われていましたが
ソフトウェアアップデートの処理を作成する際に上記のような項目のテストは
抜けがちになるのではないかと感じています。

対策としては下記のような追加の検証処理の追加や、
テストコードの追加が出来るとよいかと思います。

  1. MD5 や SHA1 などの整合性チェックに加えて
    電子署名を用いたアップデートファイルの信頼性の検証を付加する
  2. アップデートファイルが zip や tar といった一般的なアーカイブファイルを併用している場合などは、メタ情報などに記述されていないファイルが入っていた場合に検証を失敗させるなどする。

1に関しては例えば OpenSSL を用いて下記のような処理で実現できます:

# ベンダーが持つ秘密鍵で電子署名を作成する
$ openssl dgst -sha256 -sign private-key.pem patch.zip > patch.sig

# 受け取り側では公開鍵と提供された署名 (patch.sig) を用いて検証する
$ openssl dgst -sha256 -verify public-key.pem -signature patch.sig patch.zip

C# ですと “RSAPKCS1SignatureDeformatter.VerifySignature” などを用いて
実現するのも良いと思います。

参考例 / 引用元 : デジタル署名を作成、検証する – .NET Tips (VB.NET,C#…)
https://dobon.net/vb/dotnet/string/digitalsignature.html
( 一部コードの修正などを筆者側で加えています )

using System;
using System.Text;
using System.Security.Cryptography;

/// <summary>
/// デジタル署名を作成する
/// </summary>
/// <param name="message">署名を付けるメッセージ</param>
/// <param name="privateKey">署名に使用する秘密鍵</param>
/// <returns>作成された署名</returns>
public static string CreateDigitalSignature(
    string message, string privateKey)
{
    //メッセージをバイト型配列にして、SHA1ハッシュ値を計算
    var msgData = Encoding.UTF8.GetBytes(message);
    var hashData = (new SHA1Managed()).ComputeHash(msgData);

    //RSACryptoServiceProviderオブジェクトの作成
    var rsa = new RSACryptoServiceProvider();
    //秘密鍵を使って初期化
    rsa.FromXmlString(privateKey);

    //RSAPKCS1SignatureFormatterオブジェクトを作成
    var rsaFormatter = new RSAPKCS1SignatureFormatter(rsa);
    //署名の作成に使用するハッシュアルゴリズムを指定
    rsaFormatter.SetHashAlgorithm("SHA1");

    //署名を作成し、文字列に変換して返す
    return Convert.ToBase64String(rsaFormatter.CreateSignature(hashData));
}

/// <summary>
/// デジタル署名を検証する
/// </summary>
/// <param name="message">署名の付いたメッセージ</param>
/// <param name="signature">署名</param>
/// <param name="publicKey">送信者の公開鍵</param>
/// <returns>認証に成功した時はTrue。失敗した時はFalse。</returns>
public static bool VerifyDigitalSignature(
    string message, string signature, string publicKey)
{
    var msgData = Encoding.UTF8.GetBytes(message);
    var hashData = (new SHA1Managed()).ComputeHash(msgData);

    //RSACryptoServiceProviderオブジェクトの作成
    var rsa = new RSACryptoServiceProvider();
    //公開鍵を使って初期化
    rsa.FromXmlString(publicKey);

    var rsaDeformatter = new RSAPKCS1SignatureDeformatter(rsa);
    //署名の検証に使用するハッシュアルゴリズムを指定
    rsaDeformatter.SetHashAlgorithm("SHA1");

    //署名を検証し、結果を返す
    return rsaDeformatter.VerifySignature(hashData,
        Convert.FromBase64String(signature));
}

余談ですが、今回脆弱性を発見するきっかけになったのは
「メタ情報」に容易にアクセスできたことでした。

今回、ソフトウェアが Windows の Proxy 設定をアップデート時に使用するようになっており、プロキシを挟んだ途端に上記のように通信が確認出来る状態になりました。

Windows では Proxy 設定は、グループポリシ等で制約している場合を除き、

KEY : HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
Element: ProxyServer 
Type : REG_SZ

またこのとき、アップデートの通信に関し HTTPS 通信で行われていましたが、
HTTPS 通信の証明書の検証は行われておらず、改竄した内容がそのまま信頼される状態になっていました。

HTTPS 通信の証明書の検証は、一般的に検証をした方が不必要なリスクから守ることができる場合が多いため行った方が良いです。

ただ今回のような「アップデータ」の場合は、検証に失敗したことによってアップデートが出来なくなるという可能性も考えられますので、どちらのリスクを取るかは検討した方が良いかと思いますし、先述のファイルに対する電子署名を信頼して、HTTPS 通信の証明書の検証はしないという選択もありだと思います。


また、今回の脆弱性を外部から悪用する場合、DNS の変更か Proxy の変更が必要でした。
(その他の方法もありますが割愛します)

世の中を見渡してみますと「インターネットの高速化」などを偽って、ローカルの DNS 設定を書き換えてしまうマルウェア ( 例:ユーザーに気付かれずにひそかにDNS設定を変えてしまう「DNSアンロッカー」 / マルウェア情報局 ) や 脆弱なルータを突いて設定を書き換えてしまう攻撃 (例: ルーターをハッキングし、利用者をフィッシングサイトへリダイレクトする攻撃 / カスペルスキー公式ブログ ) も出ている背景がありますので、
必ずしもかなり難しい攻撃ではないと考えられます。

ですので、DNS や HTTPS の証明書といった経路に対して信頼を付与するのではなく、通信内容(今回の場合はアップデートのファイル)について「エンド-エンド」での信頼を前提として、その上で HTTPS の証明書検証をするといったような形がよいと考えます。


2.ソフトウェアアップデート処理が高権限で走っている

アップデートの処理がコンピュータ内で一番高い権限を持っているプロセスで実行されており、アップデート処理を細工することで任意のプログラムを一番高い権限で実行できるようになっていました。

アップデートファイルの展開処理などが高い権限で実行されている場合
アーカイブファイルの細工 (例 : Zip Slip / ディレクトリトラバーサルが発生する zip ファイルを用いて、意図しないファイルの書き換えを行えてしまう ) をはじめとした色々な要因によってファイルの意図しない変更が発生する可能性があります。

対策としては、ファイルの検証は低い権限で行うなど、不必要に高い権限を与えないように設計するのが良いかと思います。

また、今回の例ではありませんでしたが
アップデートの処理が書かれたプログラム(アップデータ)を配布ファイルに含めている実装もいくつか見られます。

この場合、可能であれば既に稼働中のプログラムに処理を入れ(ファイルの書き換えを稼働中の信頼出来るプログラムによって行うようにし)権限を徐々に与えるという形が良いでしょう。


そばが食べたい一心で書いていましたので、
途中誤字や設計としてそれはオカシイ!という点もあるかも知れません。
指摘等は受け付けておりますので、気兼ねなくメッセージをいただければ幸いです。


余談ではありますが、「脆弱性情報」と聞くとその製品を叩いたり「こんな危険なものは使えない!」と思われる方がいらっしゃると思うのですが、それは違うと思っています。

逆に「実はあるのに、みんな黙っている世界」というのを考えてみたら、そっちの方が怖いかと思いますし、それでしたら「どういうことがあって狙われる、こういう風にすることで修正できる」という話を優しく広げていくことが大事なのではないかなと。

私自身、元々ソフトウェアディベロッパーから、今は情報セキュリティ関係を主軸にしていますが、正直「情報セキュリティの人たちすごく怖いな・・」というのはかつてありまして、今も時々感じることはあります。

「これが分かってて当然」「これが出来ないのはオカシイ」という話がよく出てくる世の中ではありますが、失敗しても治していくことができればそれでいいんじゃないかな、とかつての経験とかを振り返りながら思う今日この頃です。
(何かありましたら気兼ねなく聞いてもらえればと!)

それでは、よいお年をお迎えください!

VAIO SX12 ( 2020年10月モデル ) も SSD 換装が可能。

どうもみむらです。
新しい PC を買ったら何をするか、それは分解に決まっています [要出典]

今回、最新の VAIO SX12 (2020年10月モデル) を SSD 換装前提で購入しましたので
例のごとくバラしてみます。

バラしてみる


結論としてはこの画像を見れば一目瞭然です。
(画像を撮り忘れたので SSD は換装済みのものです)

SX12 の場合、裏のネジを外すと、キーボードトップ側が外れるようになっています。
(ですので、VAIO Pro 13 の頃のような、USB 端子の部分を広げながら外したり・・等々がありません。楽ちん!)

今回は M.2 (SATA) 接続モデルを購入し、 M.2 (PCI-e) に換装しましたが、
キチンと PCI-e として認識してくれます。

もちろん、換装するためにバラしたりすることによって、
保証がなくなったり故障したりしたとしても私としては保証出来ません(自己責任)が
安くPCを買いたい方や、ある程度のスキルがあるかたには是非お勧めです!

取り急ぎメモまで・・・。

PrimoCache を使って Intel の最新チップセットでも HDD を SSD を使って高速化する

どうもみむらです。
先日 PC が故障しまして第9世代の Intel CPU (i7-9700) を用いて組み直していました。

故障する数日前からビープ音(長音)の連続で起動に失敗したりしていたので
なんか気持ち悪いなとは思っていたのですが。。

テレワークが推奨されており、お仕事に甚大な影響が出ることもありましたので
ツクモ電機さんのレジの横にあるリーダーにクレジットカードをシャコシャコッと何度も差し入れしてきました。。来月の引き落としに今から震えています。

ただ今回買い換えを行ってみて
Intel Smart Response Technology (iSRT, HDD を SSD キャッシュで高速化するやつ) が
Intel Optane Memory との組み合わせ専用かつ、RAID 不可に変更
されており
iSRT を使って RAID-5 を高速化していた身としてはかなりショックでした。。

では iSRT の代替としていいものは無いのかと探していたところ
PrimoCacheという良さそうなものを見つけたので試してみました。


PrimoCacheとは

HDD を SSD でキャッシュして高速化するソフトです。
まさしく Intel の Smart Response Technology で実現していたものを実現してくれます。

ほかにも FuzeDrive (AMD 環境では StoreMI という名前で提供されています) というソフトなどもありますが、いくつか試してみたところ PrimoCache がよさそうな感じでした。

PrimoCache は Romex Software 社の製品で、1つ当たり $29.95 の製品になっています。
https://www.romexsoftware.com/en-us/primo-cache/

なお私自身はメーカーさんから
今回の記事に関して何か支援を受けてはいませんのであしからず。。

PrimoCache の設定をする

左上のボタンを押してドライブを追加します。

図3 : ドライブの追加ボタン

次の画面で「高速化したいドライブ」を選択します。

図4: 高速化したいドライブを設定。今回は Intel RAID 1 ドライブ。

次にキャッシュの方法についての設定です。
Level-1 Cache が “DRAM 上” のキャッシュ、 Level-2 Cache がストレージとなります。

またキャッシュについては文字通り Level1, Level2 の階層構造になっています。

今回の場合は SSD キャッシュのみを有効にするため、
Level-1 Cache は 0MB に設定します。

図5: Level-1 Cache を 0MBに設定する

次に Level-2 Cache を設定するために、画面中央の小さなボタンを押下します。

図6: Level-2 Cache の設定ボタン

ボタンを押下すると次のような画面が表示され
キャッシュ用のドライブを選択する画面になります。

今回は Intel Optane Memory を使うため
INTEL MEMPEK.. で始まるドライブを選択します。

注:もちろん Intel Optane Memory を使わずに通常の SSD でも利用可能です。
注2:認識されている容量が小さい場合は何らかのパーティションを作ってから再試行してみてください。

図7: キャッシュ用ドライブを設定している図¥

設定後、 “Size” を “MAX” に変更し、その横にあるボタンを押下します。

図8: キャッシュ設定を行う

特に何もなければ
“Individual Read/Write Cache Space” のチェックを無効にします。

これが ON の時はそれぞれのキャッシュが設定した割合で行われますが
無効の場合は割合を気にせずに Read / Write キャッシュを行うようになります。

図9: Read/Write Cache の割振設定を無効にする。

最後にお好みで Defer-Write (遅延書き込み) の設定を行います。

遅延書き込みを有効にすると応答速度が速くなりますが、
ディスクへの書き込み(キャッシュ内容の反映)が遅くなります。

図10: 設定がほぼ完了した図

設定が完了したら “Start” を押下します。

画面UI について

稼働を始めると下記のようにキャッシュ率などが表示されます。

図11: 稼働が開始した画面

ある程度動きはじめたら、画面を閉じて仕事に戻りましょう。


冒頭のとおり PC の故障で買い替えたところ
Intel RAID 構成に対する SSD キャッシュが使えなくなって呆然としていたところ
こういうソフトを見つけることができてよかったです。。!

また前回の構成では Intel RAID の RAID-5 だったのですが
iSRT が有効な環境だと最新のマザーボードや mdadm ではマウントできず焦りましたが
dmraid を使うことでマウントができました。

PrimoCache の場合は Intel RAID と SSD Cache が別の機構なため
同じようにマウントできなくなることは(きっと)ないと思いますし安心です・・!

ではでは、素敵なテレワークライフを!

Ubuntu 19.10 で Hyper-V の Enhanced Mode を有効にする (Enable the Enhanced Mode with Ubuntu 19.10)

どうもみむらです。

Ubuntu を Hyper-V で使用していると、
起動時に高確率で GUI 起動待ちになって何も操作できなくなったり
( Ctrl + Alt + Function Key での切り替えしてもログイン画面が出てこない )
そもそも Enhanced Mode が使えなくて色々と不便でしたので、
有効にするスクリプトを作成しました。


Hi I’m Mimura.

I make a script to enable the “Enhanced Mode” on Hyper-V with “Ubuntu 19.10”.
Also, it fix an issue that to fail to start X.


Script:

下記からダウンロードできます。 / you can download from this link:
https://gist.github.com/mimura1133/a6aebf4945b6688d1a5aedffdfa9368c


How does it works / どういう仕組みか:

このスクリプトは、
Microsoft が提供している Enhanced Mode を有効にするスクリプトを元に
作成されています。

https://github.com/microsoft/linux-vm-tools/tree/master/ubuntu/18.04

最近の Ubuntu では Wayland を最初に使用しようと試みます。

上記のスクリプトでは、 Xorg を使うようにできているため、
Wayland を利用しないようにする処理を追加し、
Enhanced Mode を Xorg 経由で使えるようにしました。

# Stop to use wayland.
sed -i_orig -e 's/#WaylandEnable=false/WaylandEnable=false/g' /etc/gdm3/custom.conf

また、どうやら Ubuntu に入っている Wayland と Hyper-V が相性が悪いらしく
時々起動に失敗する(コンソール経由のログインも受け付けない状態になる)のですが
Wayland を無効にすることで、確実に起動できるようにもなります。

(Arch Linux に入れたときには上手く動いていたので、 Ubuntu の問題だと個人的には思ってます..)


this script based on Microsoft’s.
https://github.com/microsoft/linux-vm-tools/tree/master/ubuntu/18.04

Recent versions of ubuntu are try to use a Wayland before using Xorg.
So, I added a code to disable to use Wayland.

# Stop to use wayland.
sed -i_orig -e 's/#WaylandEnable=false/WaylandEnable=false/g' /etc/gdm3/custom.conf

In addition, the Wayland and Hyper-V seem to be incompatible, sometimes fail to boot,
but the issue is fixed at the same time by disabling wayland.


Ubuntu の最新版が Enhanced Mode でサクサク動いて、コピペも出来るようになりますし、
同じように Kal Linux でも Enhanced Mode が使えるようにするものも公開していますので
Linux を Hyper-V で使っている方は、是非お試しくださいませー。

I have also released another versions for Kali Linux.
Please feel free to use the script if you’re using Linux on Hyper-V.

Git Repository (Forked from Microsoft):
https://github.com/mimura1133/linux-vm-tools

SECCON 2019 Final Write-up (Mimura)

みむらです。
先日 SECCON CTF が行われ、司会業しながら問題もひとつ出題させて頂きました。

当日朝来たら「問題名は mimura ね!」となっていました。

みなさんがもしかしたら持たれていたかもしれない、
「なんだよ、自己主張強すぎだろ・・」みたいな認識は誤りです。。(苦笑)

当人も年末に心臓にリアップ(育毛剤)を掛けられた感じで、
それはそれはよい毛が生えた気がします。冗談はこの辺にして。。


Hi, This is Mimura is author of “Mimura” challenge had provided on SECCON 2019 final.

I would have named to my challenge if I knew it will called as my name.
but in fact, I got a strong heart in exchange for the result.

okay, enough with jokes. I’ll start explaing how to solve it:


問題のストーリー / Overview:

パスワードロックされている USB ドングルが渡されるので
上手くパスワードロックを解除して中からフラグ文字列を探すことが目的です。

そのための手としては下記のようなものが考えられます。 (解くために必要な訳ではないです):
・USB ケーブルを接続する
・デバッガに接続する。
・ファームウェアを取り出して解析する。
・改造して書き戻す
・半田ごてで回路を変更する etc…


We provide a usb-key which seems protected by password.
you should find a password and find a flag on this device.

You can.. ( of course, you don’t have to do everything.) :
・Connect to Debugger (Hardware Emulator)
・Connect to PC
・Dumping and Analyse a firmware.
・Rewrite a modified firmware.
・Modify the circuit with soldering iron etc..


どうしてこういう問題を作ろうと思ったか。 / What influenced:

ハードウェアに関する問題を作ろうと思っていて、
ハードウェアロック付きの USB メモリを問題にしたら面白そうと思ったのがきっかけです。

また最近は業務でもハードウェア機器を触ったり色々としていますので
自分の中で作問を通してちょっと無理(学習)をしてみようという気持ちで
マスストレージに挑戦してみようと思いました。


I was influenced by Security USB-Key.

My main job is security researcher and developer, and I have recently been investigating of hardware device.
So, I thought to try to make mass storage device without an OS and growth up my skills.


ステップ1:ハードウェアを繋ごう
Step1 : Let’s connect the device to your machine.

ハードウェアを繋ぐと上記のような2つのデバイスが認識されます。
You will find these devices on your machine when connect the device.


また、マスストレージの方は、それっぽいファイルが保存されているのですが、
“<THIS SECTOR AREA IS PROTECTED BY HARDWARE PROTECTION>” と表示されていて、
内容が読めません。

You can find deleted file that seems would contain a flag data, but it seems protected.


COMのほうはというと、繋ぐとパスワードを要求され、
3回失敗すると、パスワードの受付を一切してくれなくなります。

Let’s check the com port. It looks like we need to input correct password via COM port.
And if you input wrong password three times, the device going to freeze.


ステップ2:デバッガを繋ごう
Step2 : Let’s connect emulator (debugger) to device.

USBポートの真逆の位置に、SWD ポート(デバッガを接続するためのポート)が生えています。
ここに問題と一緒に配布していたケーブルを接続し、デバッガ (STLink) と接続します。

You can find a SWD port that uses for hardware debugging on the other side of USB port.
You need insert a cable which we provided at beginning of the game and connect to the emulator (STLink).


ただそのままでは接続できません。

世の中に売られているハードウェアにおいても、
こういうデバッグポートは何らかの手によって接続できないように作られています。

今回の問題では、本体のプログラムコードの冒頭で SWD ポートを無効にするように
コードを入れておきました。

But… you may can’t connect the device via emulator if just connect.
Most devices disable the debug port (such as SWD, JTAG ICE and so on..) to protect “Intellectual Property” or prevent from illegal use.

Also on this device, I insert a code to disable the SWD port at the beginning of the main program code.


Description of Boot Mode selection (from ST.com, en.CD00164185.pdf)

今回のボードですと、上にジャンパスイッチがありました。

ここをの上のピン (BOOT0) を “0” 以外にすることで、メインファーム(今回の問題のプログラム)以外でシステムが立ち上がるようになるため、
プログラムによって SWD の無効化が行われず、接続可能となりました。

その他の方法としては、上の “RST” と書かれたボタン(リセットボタン)を押し続け
プログラム自体が起動しない状態にして接続するという方法もあります。


You can control the boot mode by Jumper switch.
If you change the BOOT0 pins ( upper pin ) to 1 (such like the photo), you can connect SWD port because the hardware will not run the challenge binary.

In other way, you can connect it with push and hold the RST button until connect the emulator successfully.


Description of Boot Mode selection (from ST.com, en.CD00225773.pdf)
Description of Boot Mode selection (from ST.com, en.CD00225773.pdf)

接続が無事に完了すれば、メモリをダンプするツールを用いて
フラッシュの内容を抜き出します。

アドレスについては、同じようにチップの仕様書を見ると
“Flash memory” は 0x08000000 から 0x080FFFFF にアドレスが設定されていますので、
この範囲を見ながらダンプを行います。

今回の問題では 64K のメモリが積まれていましたので、
Sector 0 から Sector 3 (0x0800FFFF) までがアクセス可能になっているかと思います。

上記の例では STM32 ST-Link Utility を使用しましたが、
その他に使い慣れたプログラマやデバッガをお持ちであればそれを利用したりして
抽出すれば良いと思います。

例えばSTM32 を J-Link 化したあと OpenOCD で接続して、
mdw コマンドで “mdw 0x8000000” として取り出したり
dump_image コマンドで “dump_image dump.bin 0x8000000 0xFFFF” みたいな感じで
抽出するという方法などもあります。


After connection, you can rip the firmware from hardware with writer tool.

According to the peripheral data sheat, You can find that the main firmware saved on a memory of 0x08000000 (Sector 0) to 0x0800FFFF (Sector 3) area.

I used STM32 ST-Link Utility to rip the challenge program binary on this time.
It’s also possible to rip with OpenOCD or similar tools.

if you try to rip with OpenOCD, you can use “mdw” command (i.g. “mdw 0x8000000” ) or “dump_image” command (i.g. “dump_image dump.bin 0x8000000 0xFFFF”)


ステップ3:ファームウェアを解析しよう
Step 3 : Let’s analyse the firmware!

普段は IDA 使いなのですが、
無料の範囲でバッチリできることを確認するために、 Ghidra でやってみます。

パスワードを入力したあとに “Checking…” と出ますので
その文字列の処理を頼りに探してみると 0x80001a8 付近にパスワードの確認処理が見つかります。

ここの処理を見ると下記のルールが現れます:
・1文字目は “O”
・3文字目、7文字目、11文字目は “e”
・9文字目は “a”
・10文字目は “m”

つまり、不明な部分を適当な文字で埋めると “O_e___e_ame!” となります。


Let’s analyse the firmware with Ghidra!

Looking back at the communication via serial port, the string that “checking ..” was appeared after send a password.
At address 0x80001a8, you can find the code.

According the code, you’ll find these rules:
* 1st character is “O”
* 3rd, 7th and 11th character is “e”
* 9th character is “a”
* 10th character is “m”

Therefore, the password will “O_e___e_ame!”. ( I filled unknown character with “_”)


やった!解けました!
Hooray! you did it!!


実は… / It’s hard to say this, but…

・・・ですよね。。すみません。
これなのですが、書き込むリビジョンを間違えてしまいまして、
特定位置の文字列チェックが欠損した版になっていました。
ミスの状態のまま出題を行ってしまい申し訳ありませんんでした。。。

…yes, I know why you’re being wired. It’s a my fail. I’m so sorry.
I had made a mistake that I wrote an another version firmware.
Thus, you would not have found a 2nd, 4th, 5th, 6th and 8th character.

ここで回答を期待していたキーワードは “開け!ゴマ!” です。
アリババと40人の盗賊で登場する話ですが、日本だと「アラジン」とかそういう話でも出てくるので世界一般以上に日本で有名なキーワードなんじゃないかと思います。知りませんけど。。

My expected password is “Open Sesame!”.
This is one of the most famous words from “Alibaba and the Forty Thieves”, I think.


ステップ4:ファイルを取り出そう
Step 4 : Let’s extract the file.

アンロックしてから読み直すと、フラグファイルが見えるようになります。
あとはこれを展開すると、フラグが出てきます。

SECCON{YOU_CAN_ANALYSE_HARDWARE_DEVICE}

After unlocked, let’s try to find a flag file on the storage with Forensics tool.
You can get a flag after by extracting it.

SECCON{YOU_CAN_ANALYSE_HARDWARE_DEVICE}


FAQ / よくある質問

Question:
 試してみたいのですが、評価ボードはもらえますか?
 Can you give me the challenge board?

Answer:
 ごめんなさい。。でももしお会いできる機会があれば、事前にお持ちすることは可能です。
 Sorry. I can’t. but I can show you the board. please feel free to contact me.

Question:
 どうしてパスワードを解除したあとにファイルが表示されないのですか?
 Why didn’t show the file after unlocked?

Answer:
 Windows でテストをした際に、エクスプローラや通常の方法で読み出しに失敗することが何度か確認できており、当該のエラーの解決が間に合わなかったのが理由です。。すみません。。
 I’m sorry again. I found a issue that windows system can’t read FAT12 data correctly, and I couldn’t find a solution before the CTF.


最後に / Summary and digression:

次出すことがあれば、もっとちゃんと自分が納得できる問題を提供したいなと思っており
今回の自分の問題は、ソフトウェアディベロッパとして、ユーザにソフトウェアを提供することのある人間としては、クオリティが低すぎたんじゃないかと自分でも猛省しています。

とはいえ、別件のこともありますし、Twitter で軽く触れたことは自分の意見には間違いないので
機会があれば十分な期間を取った上で、問題のクオリティや出し方(何をすれば良いのかを明瞭にする、問題タイトルをまともなモノにする)を自分の納得できるレベルにして出題してみたいですね。

問題を通してハードウェアに対してちょっとでも興味を向けてもらえる人が増えたなら
(ハードウェアから信頼を築いていく面白さとか、純粋に現実世界と仮想空間が繋がるのたのしい!とか思ってもらえたなら)今回出題して良かったなーと思います。

・・・司会業を当日していながら、色々と申し訳ない気持ちとかがあったのですが、
そういうのはチラ裏で。


I think I could have improved the quality of the challenge If I had more time.
Thus, I need to apologize to the CTF Player.

But fortunately, some CTF players told me the challenge was interesting.
It made me very happy.

so I think I want to create the “CTF challenge” ( the meaning that it meets the criteria for a general CTF challenge) in the hardware genre if next seccon ctf is to be held.


ところで、今回の問題はシンガポールで作っていたのですが、
あの「マリーナベイサンズ銀行」の預金ってどうやったら下ろせるんですかね。

by the way, could you tell me how to withdraw the money at “Marina Bay Sands Bank” if you know.
I think it’s the same way to get points in CTF, but it was very difficult for me….
especially slots….

ではでは! Bye!