日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

<< 過去

スタンドアロンPCへのインストール

今日はスタンドアロンのPCにWindows 10をインストールしていた。

Windows 7 PCを買ってWindows 10を入れる


届いたDVDを入れて、既存のパーティションを消してインストール。

インストール完了後には、ドライバーのインストール。

と、ここまでは普通なのだが。


ここで、スタンドアロンでのライセンス認証を行う必要がある。

入手したMAK認証用のキーを入力すると、Webで認証をしようとするが、ネットワークにつながっていないのでエラーになる。

ここで電話認証が提案されるかと思ったのだが、どうもそうなっていない。

[Windows 10] Windows のライセンス認証を電話で行う方法  (Windows 展開技術大全)

電話をかけたら、対象の製品はどれかとか、アップグレードが完了したかとか、エラーが出てるかとか聞かれて、

なんとか乗り越えたら確認IDをプッシュボタンで入力するんだけど、

これが数回に1回しくじって、入力し直しになったりで、けっこう時間がかかった。


最終的にはスタンドアロンにするにしても、ネットワークにつないで認証した方がよっぽど効率がよいと思ったが、

社内ネットワークにつなぐには相応のセキュリティ対策が必要で、それをしていないからね。

もっともWindowsライセンス認証をする段階では、各種のセキュリティ対策をする前だろうから、どっちでも一緒な気がするけど。

特にこれはWindows 7の業務用PCとして、社内ネットワークに接続する権利は持っているわけだし。

(MACアドレスでフィルタリングをしているので、全く未登録のネットワーク機器は接続が拒否される)


もう1つめんどくさかったのが、Windows 10のパッチ適用である。

社内ネットワークに接続して、WSUSの設定をしてアップデートするのが楽である。

ネットワーク負荷も社内のサーバーでキャッシュされているので軽いし、必要なパッチも自動的に選ばれる。

ところが、スタンドアロンの場合は、Microsoft Updateカタログから、適用すべきパッチを探して、

それをダウンロードしてUSBメモリなどで運んでインストールとしないといけない。

Windows 10の場合、1903とかバージョンごとに違う上に、x86とx64でも違う。あとARMとかもあったな。

さらに今回、指定のWindows 10のバージョンが古かったこともあって、更新プログラムが1GB越えという状況。

基本的には「サービススタック更新プログラム」と「累積更新プログラム」を運んで適用すればOK。

初回なので大量の累積更新プログラムも全部役立つが、

今後定期的に更新する場合、本来は差分だけでよいのに、全部ダウンロードして適用なので無駄が多い。

でも、スタンドアロンの場合、それしか選択肢はないと思われる。どこまで真面目にアップデートするかという話はあるが。


それに比べればまだましだったが、ウイルス対策ソフトのインストールもけっこう時間がかかった。

これもスタンドアロンだと定義ファイルは手動でファイルを運んでの更新になる。

これもどこまで真面目にやるかという話だが、USBメモリなどを介したウイルス感染の可能性があるので、

必ずウイルス対策はやれという指示なので、あまりいい加減なことも言ってられない。


スタンドアロンにしたのは、製品評価のために必要なコンピュータの設定の都合、

社内ネットワーク接続との両立は難しいだろうという判断があったからである。

例え、社内ネットワークにつながるようにしても、長期間切り離されることも想定しないといけない使い方である。

長期間、社内ネットワークから切り離されてしまうのなら、結局はあまり変わらないのだ。

厳密に運用されているかは怪しいが、長期間切り離されたPCは、手動でWindows更新・ウイルス定義ファイル更新をすることになっている。

確かに全く社内ネットワークに繋がないならセキュリティ対策を簡素化できるという考えもあったのだが、そこが重要だったわけではない。

とはいえ、この手間を考えると、スタンドアロンにしたのは正しかったのかと思ってしまうよね。


そんな苦しみはあったが、1日かけてセットアップ全体の8割方終わった。

Windowsとか基本的な部分は全て終わっていて、製品評価に使うソフトのインストールに時間がかかっている。

これだけで1日仕事になることもしばしばなので、Windowsインストールも含めてここまで進んだならいいとこかな。

もう1台作る予定はあるが、そのときはもうちょっとスムーズに行くといいな。


Author : hidemaro
Date : 2019/10/16(Wed) 23:45
コンピュータ・インターネット | Comment | trackback (0)

Windows 7 PCを買ってWindows 10を入れる

最近、製品評価のためのコンピュータの確保に向けて、いろいろ動いていた。

Windows 7の頃は、業務用PCを製品評価専用に用意して、そこにソフトウェアをインストールすれば済んでいた。

コンピュータの設定もいろいろ変えないといけないので、製品評価専用にしないといけないんだけど。

ところがWindows 7のサポートも終わることだし、次のプロジェクトからはWindows 10にしないとねと言っていた。


Windows 10への移行にあたって、他の部署に聞いてくれた人がいて、

その情報によれば、カスタムされたWindows 10のコンピュータへのインストールはできないらしい。

確かに説明書にも、プリインストールのOSを消して、Windowsのインストールからすることを推奨すると書かれている。

これ自体はWindows 7のときもそうだったのかもしれないが、なおさら問題のようだ。

レンタルで業務用PCを確保して、これをクリーンインストールするという方法で対応しているそうだ。


でも、クリーンインストールする時点で、業務用PCである必然性がないような気がした。

業務用PCをレンタルする意義は、社内でサポートを受けられること。故障時も代替機が早期に用意できる。

でも、既存のOSを消してしまうと、社内のサポート対象外になる。そりゃそうだ。

もう1つ問題があって、それが業務用PCの新規レンタルが逼迫していること。

レンタル業者から週ごとに納入される最大台数は決まってるようなんだけど、

Windows 10への移行という特需のため、今申し込んでも、納入がかなり先になってしまう。


この問題を解決する方法が、Windows 7の業務用PCをレンタル業者から購入するという方法だった。

現在、Windows 7が入っているPCは、ハードウェア的にはWindows 10にも対応できる。そんなに古くない。

購入費用はかかるだろうが、レンタル業者にとってみればメーカーサポートの切れたPCはそこまで大きな価値はないだろう。

どれぐらいか知らないけど、それなりに安く買えるんじゃないか。

購入後はサポートは得られないが、月々のレンタル料もかからなくなる。

さらに、この方法ならば、早期に製品評価用のコンピュータが確保できる。

評価計画を立てる人にとってはそっちの方が魅力的に映ったようだ。


それにしても、どうやってWindows 10ってインストールするの?

調べたら、どうも勤務先ではMicrosoftとEnterprise Agreement(EA)という包括契約を結んでいて、

ユーザー数に応じた費用を支払っているので、社内で使う限りにおいては自由にインストール出来るようだ。

ただし、現実的な問題として、Windows 10 Enterpriseのインストールメディアを借りる手続きは必要なのだが。


でも、Windowsってライセンス認証しないといけないよね?

調べたところ、基本的にはKMS認証という方式でライセンス認証をするらしい。

これは社内ネットワークにつないでさえいれば自動的に認証される仕組みだという。

インストール後30日、認証後180日経過すると、認証切れで制限がかかるよう。

なるほど、と思ったが、今回の評価用コンピュータは社内ネットワークから切り離して使う予定であること。

設定の都合、社内ネットワークとの接続を両立するのは難しいだろう(可能ではある)という判断である。


こういう場合どうするのかと調べてみると、MAK認証という方法があるらしい。

一般的にEAライセンスの配布方法には、KMS認証とMAK認証のいずれか、あるいは2つ併用できるそう。

とはいえ、コンピュータの数量が多い場合、ネットワークにつなぐだけで認証されるKMS認証のメリットは大きい。

KMSサーバーを立てる必要があるが、管理上も便利なので、勤務先も基本的にはKMS認証でと言っている。

一方のMAK認証はPC1台ごとにライセンスキーを入力して認証するという方式。

認証後は恒久的にライセンスが有効となる。これは家庭用のライセンスに似ている。

台数が少なければMAK認証しか選択肢はないし、そうでなくてもKMSサーバー不要なのはメリットがある。

この2つの方式は併用できるので、勤務先でもネットワークから切り離して使う場合は、一件審議の上でMAK認証用のキーを発行するとあった。

申請すると、無事にMAK認証用のキーが付与された。やったね。


他にも必要なセキュリティ対策や、関連ソフトウェアのインストール方法など、調査すべきことは多かったが、

まぁなんとかいけるかなぁというところまでやってきた。

うちの部署ではなかなかノウハウがなくて困ったが、今後は避けられなさそうだし。


ところで、部内の他の課では、レンタルPC以外にもけっこうな数のPCを持ってたりする。

現役で使っているものはまだよいのだが、もう長らく通電すらされていないものも数多く並んでいる。

実は、かつてこの部署で開発していた製品で使っていたものらしいのだが、

今はその製品がなくなり、開発者もほぼ残っていない状況で、古い製品とともに残されているようだ。

ふと気になって見てみると「Pentium 4」「Windows XP」なんてシールが貼られている。

もう使えないのでは? と思っているんだけど、捨てる決断をできる人ももういないのだろうか。


実はここはレンタルPCを購入することのリスクでもある。

レンタルだったら、一定期間経過するとレンタル業者が引き取って、適切に処分してくれる。

ところが買い取ってしまうと、最終的にはそれを処分するところまで責任を持たなければならなくなる。

そういうところで陳腐化したので捨てますという決断ができるかということである。

まさに今、Windows 7世代の部署所有の製品評価用のコンピュータが、そういう決断を迫られてるんじゃないかなと。

スタンドアローンで使うなら残せなくもないが、基本的にはサポートの切れたOSは使うものではないでしょう。

果たしてここから部署所有PCの大粛清になるかどうか。

そのために代替機が必要なら、今回の方法に準じて購入するか、あるいはレンタルPCで代替するか。条件次第かな。


Author : hidemaro
Date : 2019/10/08(Tue) 23:26
コンピュータ・インターネット | Comment | trackback (0)

まさかフィンガープリントが一致しただけ?

先日、会社の業務用PCに新しいマルウェア対策ソフトを入れた。

至急インストールせよという指示だったので、その通りにやった。

それで今日、自作のVBAマクロを組み込んだExcelワークシートを開くと「不審なマクロを検出しました」と出てきて開けない。

なんだこりゃ。


対策ソフトのメーカーのWebサイトを見ると、Microsoft Officeのマクロに対する検査機能を備えているようだが、

一律にマクロを禁止しているというわけではなく、何らかの解析を行って危険かどうか判定しているようだ。

以前、これと似たような操作を行うマクロを作ったことがあって、それはどうだと開いて見ると問題はない。

なんとなく説明を読む限り、一定のフィンガープリントを持っているものを弾いているように見えた。

そこで、Excelワークシートのファイルにちょっと細工をしてみると、無事に開けた。

それでとりあえず回避できたが、Excelで開くと「ファイルが壊れています」という警告が表示される。

警告が表示されるだけでやりたいことはできるので問題ないが、改めて恒久対策をしないと。


今のところは、自作のマクロのフィンガープリントがマルウェアのものと一致したのか、そんな理由で弾かれたように見える。

プログラムの内容に対して評価が入って弾かれたのではなさそうに見えるので、

プログラムの動作に影響がないところでソースコードを変更すると回避出来そうに見える。

そんなんで回避出来ていいの? って思うけど、マルウェアの性質なども考慮してのことか。


本当にフィンガープリントの一致だけが原因だとすると、よくそんなの引き当てたなと思うけど。

どういうアルゴリズムを使ってるか知らないけど、SHA-1ハッシュだとすると80bitだから、

偶然一致する確率は1.2×1024回に1回、照合対象のフィンガープリントはいくつもあると思うが、

例え100万個のいずれかと一致するとしたところで、121京回に1回とかそんなレベルですからね。

ちょっと疑わしい数字だけど、少し変更するだけで回避できるってのはそういうことなんじゃないのかな。


パッと見た感じでは、この対策ソフトを無効化することはできなかった。

一般的な対策ソフトだと、一時的にオフにする機能があったりするけど、

オフにしたまま使われ続けては危険なので、一般ユーザーには封じているのかもしれない。

今回は細工をすることで回避出来たが、どうしても回避出来ない場合はどうするんだろうね。

危うく業務が止まってしまうところだっただけに心配になった。


Author : hidemaro
Date : 2019/10/03(Thu) 23:31
コンピュータ・インターネット | Comment | trackback (0)

USBの誤接続対策

今日は休暇を取っていた。

思いのほか昨日の帰宅が遅くなったので、休暇にしておいてよかったと思った。


先日、こんな話を書いた。

ルール上、USB Type-Cオス は他の形状のコネクタへの変換ができないので、Type-Cがない機器では使えない

(USB Type-Cにイヤホンをつなぎたい)

これってどういうことかと思った人もいるかもしれない。

USBのコネクタ形状はいろいろルールがあるのだ。


当初のUSBには平べったいA端子と、四角いB端子の2種類があって、

ホスト側(通常はPC)はA端子、デバイス側はB端子を使うということで、誤接続防止をしていた。

なんで同じUSBなのにわざわざ形状を変えてるんだろうと不思議に思っていた人もいると思う。

でも、一方がA端子(オス)、もう一方がB端子(オス)というケーブルしか流通しないようにすれば、

それだけでホスト同士とかデバイス同士を繋がれることは防げる。

まぁ世の中には不届き者もいて、規格外のA端子同士のケーブルも付属品として流通してたりするのだが。


それが少し変わり始めたのが miniB端子、microB端子 の登場である。

単に小さくしただけだと思っていたかも知れないが、実はピンが1つ(IDピン)増えている。

この1ピンはUSB On-The-Go(OTG)という機能に使っていたのだが、

スマートフォン・タブレットのようにデバイスにもホストにもなれる機器のためのものだったと。

従来は、A→B/miniB/microB という繋ぎ方しかあり得なかったが、

OTG対応であれば、miniB/microB→A(メス)に変換して、各種USBデバイスをつなげるようになった。

このような接続を行うケーブルは、ホスト側のminiB/microBのIDピンをGNDと短絡しているそうだ。

なお、厳密にはminiA/microAというのもあるが、あまり使われていなかったそうだ。

microA/B兼用コネクタなんてのもあったように、あえて使い分けるほどの理由はなかったのだろう。

ホストにしかなれない機器でminiA/microAを採用するものが皆無だったというのもあるんだろうが。


そして決定的に変わったのだがType-Cの登場である。

Type-Cはホストとデバイスで同じコネクタを使うようになった。

そんなこともあってUSB Type-CではCCという端子が追加され、これを使って相手を認識する仕組みができた。

Type-C同士のケーブルにはUSB 2.0のみ対応のタイプでもCC端子同士が結線されている。

このCC端子を使った通信で、USB Power Deliveryをコントロールしたりしているわけ。

一方で、相手がUSB Type-Cではない場合は、それなりに区別しなければならない。


なので、変換アダプタ・ケーブル内で、CC端子をプルアップまたはプルダウンしているようだ。

A端子(オス)→Type-C(オス)、microB(メス)→Type-C(オス)のような変換を行うアダプタが、

Type-C側がデバイスになるので、デバイスを表すCC端子プルアップのケーブルを使う。

Type-C(オス)→A端子(メス)のようにType-C側がホストになる場合は、CC端子をプルダウンのケーブルを使う。

このようにType-Cから先のケーブル形状によって、CC端子の処理を変えることで接続の整合性を取っているわけである。


最初に書いた、Type-C(オス) から他の形状に変更できないというのは、

Type-CというのはCC端子を判定しないと、相手がホストかデバイスかわからないので、

少なくともType-Cのメスコネクタを付けている機器は、CC端子の判別ができることという条件を付けているから。

Type-C(オス)の先には、純然たるType-C機器がいるとは限らず、形状変換されたホストがいるかもしれないし、デバイスがいるかもしれない。

それがわからない変換はやってはいけないということである。


こういう都合を考えると、Type-C以外は淘汰されるべきだと思うわけだけど、

やはり歴史的な経緯もあって、PCではA端子が主流で、その状況はなかなか変わるように見えない。

ホスト・デバイス兼用はType-Cになっていると思うが、デバイス側はType-Cが普及してきてるのかな?

でも、この前購入したUSB HDDはUSB 3.0用にmicroB端子だったし、こちらも道半ばですかね。

従来は端子形状だけで回避できるはずだった誤接続が、Type-CになるとCC端子で判別せねばならないというのは1つのハードルかもしれない。


用途を考えるとそれでいいんだけど、USBデバイスから直接Type-C(オス)が出てるってのがイレギュラーだよね。

Type-C(メス)で出していれば、それをType-Cのホストにも、A端子のホストにも接続できたのである。

昔から、USBストレージのように直接A端子のオスになっているようなデバイスはありましたけどね。

ただ、この場合は、必要ならA端子(オス)→A端子(メス)の延長ケーブルが使えたり、

microB(オス・OTG)→A端子(メス)とか、Tupe-C(オス)→A端子(メス)みたいな形状変換と組み合わせられるので全く問題はないのだが。

それと比べると、Type-C(オス)で出す不都合はとても大きいわけだけど、3.5mmミニプラグで接続していたイヤホンの代替という明確な目的がありますから。

だから許されてるんだよってことですよ。


Author : hidemaro
Date : 2019/09/30(Mon) 23:35
コンピュータ・インターネット | Comment | trackback (0)

USB Type-Cにイヤホンをつなぎたい

旅行のお供にタブレット(HUAWEI MediaPad M5)も持って行くわけだけど、

そうすると困るのがイヤホンジャックがないこと。そう、ないんですよ。

普段は家で使ってるので、動画とか見るときはスピーカーから音を出しているのだが、

バスの車内とかで使うわけにもいかないので、仕方なくイヤホンが接続できるスマートフォンで動画を見てた。


一般的なイヤホンは3.5mmミニプラグを接続に使うが、

スマートフォン・タブレットの薄型化の支障になっているという話がある。

そこでUSB Type-Cをイヤホン接続に使うことが行われつつある。

3.5mmミニプラグってそんなに厚みに影響する? って思うけど、USB Type-Cって厚さ2mmですからね。

このあたりはメーカーによっても差がありそうで、SHARPは一貫して3.5mmミニプラグを採用しているが、

SONYのXperiaでは2018年発売のXperia XZ2以降はUSB Type-Cに一本化している。

HUAWEIは? というとスマートフォンではあったりなかったりとまだらなのでちょっとわからない。


一番簡単な解決策は、タブレットに付いてきたイヤホン用の変換器を持ち歩くこと。

ただ、常に接続して使うならともかく、タブレットに接続するとき以外は外すのだからなくしそうで怖い。

そんなわけで、いろいろ調べていたのだが、どうもUSB Type-C接続のイヤホンがあるらしい。

DAC内蔵タイプならば、いずれのスマートフォン・タブレットに接続しても使えるという。

これなら1つのイヤホンで、タブレットもスマートフォンも使えるのでは? と考えた。


USB Type-Cのイヤホン接続に使う場合、アナログ接続とデジタル接続がある。

アナログ接続は変換器は単なる形状変換だが、そのためには本体にアナログ音声出力用の回路を持っている必要がある。

本体に3.5mmミニプラグが付いている場合、通常はそこにイヤホンを接続するだろうから、USB Type-Cにアナログ音声出力回路を付けることは通常ない。

3.5mmミニプラグがない = USB Type-C アナログ音声出力に対応とは言い切れないようだが、多くの場合はそうなっている。

それがあてはまらないのはiPad Proぐらいらしい、

一方のデジタル接続は、単なるUSB機器として接続するもの。

こちらはUSB Type-Cが付いている機器であれば、Android・iOS・Windowsいずれも標準対応とのこと。

ゆえに、3.5mmミニプラグの有無によらず、USB Type-Cの付いたスマートフォン・タブレットなら全て使えると考えて良い。


ところが、USB Type-C接続のイヤホン自体が数少ないし、デジタル接続と断定できるものはなおさら少ない。

Yahoo!ショッピングでいろいろ探して、安くて確実にデジタル接続と確認出来たのがこれ。

極の音域 Type-C Premia (MS Solutions)

ハイレゾ対応を謳っているが、量子化ビットが24bit(通常16bit)なのでハイレゾという話で、サンプリング周波数は48kHzまで。

量子化ビットの方がハイレゾの恩恵としては大きいという話はあるけど、なんとなく中途半端な印象を受ける。

ただ、スマートフォン・タブレットの本体のアナログ音声がハイレゾ対応してなくても、ハイレゾ対応できますよっていうのは、

イヤホン内部にADCを内蔵していないと実現できないので、それはデジタル接続であることの証でもある。


それで届いたので接続してみたが、タブレットもスマートフォンもこれで音声を出せた。

自宅にはType-Cの付いたPCがないから確認できてないけど、おそらく職場のWindows PCでもいけるんじゃないか。

(ルール上、USB Type-Cオス は他の形状のコネクタへの変換ができないので、Type-Cがない機器では使えない)

とりあえずこれで目的は達せられた。


ただ、このUSB Type-Cイヤホンにもいくつか難点がある。

1つがスマートフォン・タブレットではよいが、それ以外のオーディオ機器では使えないということ。

最近はこれ以外の機器に接続することは減っているが、3.5mmミニプラグ接続のイヤホンを全廃したわけではないので、状況に応じて選択すれば良い。

スマートフォンまたはタブレットと明確なら1本で両対応できるのがメリットということ。

もう1つの問題が、充電とイヤホンを同時に使えないこと。

この問題に対応して、充電用USBポートと3.5mmミニプラグの二叉ケーブルも売られている。

確かに充電とイヤホンが同時に使えないのは欠点だと思ったが、どうしてもそれが必要になることは多くないからよいと考えた。


ところで、これらの問題を一挙に解決する方法として、無線接続のイヤホンを使うという方法がある。

それもよいかなと思ったのだが、過去にもBluetoothイヤホンを使った経験から言えば、最大の問題は電池である。

他の問題としてタイムラグと、無線ゆえに接続不安定になることがしばしばあること。

Bluetooth接続のオーディオ機器としては、自宅用のBluetoothスピーカーがある。(cf. いまどきは無線で)

これはスマートフォンまたはPCとスピーカーの位置関係の自由度が高いメリットが生きている。

あと比較的大きな機器なので電池も持つし、音楽再生専用だからタイムラグも問題ない。

ただ、移動中に使うイヤホンだと、メリット以上にデメリットが目立つというのが、過去の経験から学んだことである。

ここら辺は理想と現実のギャップかもしれんね。


Author : hidemaro
Date : 2019/09/26(Thu) 23:28
コンピュータ・インターネット | Comment | trackback (0)

スクリーンショット禁止っていうけど

電子書籍を購入するとき、基本的にはBOOK☆WALKERを選んでいるが、

取扱がないときには楽天Koboを選んでいる。そういうこともある。

でも、その両方で取り扱いが無い電子書籍があった。

電子書籍といってもデジタル版しかないもので、商流が限られているのもそのためかなと思う。

普段使っている2ストア両方で取り扱いが無いなら、どこから選んでも一緒だということで、

出版社直販のストアで買ったのだが、噂によればスクリーンショットができないらしい。


そんなわけで試してみた。

まず、Android版、電源+音量ボタンでスクリーンショットを撮ろうとすると「スクリーンショットの取得は許可されていません」と表示が出る。

サードパーティのアプリでキャプチャしようとすると真っ黒になった。

Windows版もあるので、試してみると、まずPrintScreenキーを押しても反応しない。

Windows Vista以降の標準となったスクリーンショット切り取り用ツール、Snipping Toolを起動しようとすると、起動が拒否される。

カハマルカの瞳でキャプチャを取ると、ダミーの画像がキャプチャされる。

というわけで、確かにスクリーンショットは完全にブロックされている。


こうなってくると、仮想マシンぐらいしか方法が思い浮かばないので、AndroidとWindowsそれぞれ試してみた。

AndroidはBlueStacksというエミュレータ、Androidゲームの動画配信に使われているらしいが、これでやってみた。

BlueStacksを起動すると、その中は完全にAndroidなので、Google Playからアプリをダウンロードすればよい。

それでアプリを起動して、電子書籍をダウンロードすると、普通に表示できた。

あとはBlueStacks上のキャプチャボタンを押すと、あっさりキャプチャ出来てしまった。

Windowsだが、Microsoftは開発者用に35日間限定のWindows 10仮想マシンを提供している。

VMWare用をダウンロードして、VMWare Workstation Playerで起動させれば、無料でWindows 10の仮想マシンを作れる。

Windowsは評価目的、VMWareは非営利という条件付きだが、今回の試験はまさにそうでしょうと。

ちょっと試すだけにはなにかと時間がかかってしまったが、これも仮想マシンの外側からスクリーンショットを取ればキャプチャできた。


そもそも、どうしてこの電子書籍ストアはスクリーンショットに厳しいのかという話だが、

おそらく閲覧できる時間を区切って販売されるコンテンツが多いからだろう。

今回購入した電子書籍は恒久的なものなので(サービスが継続する限りは)ずっと読めるから必要性は薄いのだが、

閲覧できる時間を限定したとしても、何も対策しなければ静止画なので簡単にキャプチャできてしまう。

しかも、自己使用のためにキャプチャすること自体は、著作権法で認められている私的複製の範囲にあたる。

利用規約でも、ウォーターマークを消すことなどは禁止しているが、私的複製までは禁止していない。

スクリーンショットを回避する手段を埋め込んでおきながら、私的複製を禁止しないのは理屈に合わない気がするが、

著作権法の例外規定を公然と否定するのは難しいと考えているのだろう。


Androidについて言えば、外部画面出力ができたとしてもHDCPによってコピー禁止がかかる仕組みになっている。

すなわち、本来はAndroidの画面を外部からキャプチャすることはできないということ。

一方で、Androidは特に禁止されていない限りにおいてはスクリーンショットを撮影することができる。

今回の電子書籍アプリは設定によりスクリーンショットを禁止しているということである。

これが守られていれば、どこにも穴はないはずなのだが、BlueStacksはAndroidの外部(Windows)から画面全体をキャプチャできてしまう。

BlueStacks自体はAndroidのゲームをWindowsでプレイする手段として、大手企業にも広く認知されたツールなのだが……


Windowsについて言えば、このアプリはHDCPを強制していないので、そこが穴になっている。

それはHDCPに対応していないVMWare内のWindowsでアプリが起動できたことからもわかる。

なので、Windows PCの外側からキャプチャすることは、真っ当にやろうと思えばできてしまう。

ただ、WindowsでHDCPを強制させるのは、現実的ではない事情もある。

全てのPCのディスプレイがHDCP対応しているとは限らないから。そもそもアナログ出力だとどうしようもありませんからね。

Blu-ray動画などどうしてもHDCPが必須のものは仕方ないが、たかが電子書籍でHDCP強制はあり得ない。


どうしても汎用PCでコンテンツを保護しようとしても、どこかに穴が出来てしまうんだよね。

家電製品、例えばBlu-rayプレイヤーなら、出力先にHDCPを強制するのは簡単だし、内部をハックするのも難しい。

HDCPで出力されたものを回避して複製する行為は禁止されている。

Androidはコンテンツ保護にはかなり気を遣っているとは思ったのだが、オープンなOSなのでBlueStacksのようなエミュレータは作れる。

BlueStacks自体は悪いものではないが、コンテンツ保護という観点では不十分な点があるのは否定できない。


スクリーンショット禁止というのも難しいもんだなと思った。

その昔、ふと気になってAndroidのBOOK☆WALKERのアプリ上でスクリーンショット操作をしたら、

あっさりキャプチャできて、そういうもんなの? と思ったもんだけど、一般的にはそれで済ませてるんだよね。

違法な複製の温床にもなりかねないのだが、そもそも紙の本なら普通にスキャンできるし、完全に禁止する難しさも知っているのかもしれない。

電子書籍アプリを開けば、恒久的に読めるものを、あえてキャプチャする必要性も乏しいので、

スクリーンショットを撮影されることを必要以上に恐れても仕方ないという考えも成り立つ。


でも、この電子書籍ストアは、閲覧できる期間を区切って販売しているので、スクリーンショットされることはまさに脅威。

動画配信でも似たような売り方があって、似たような問題はあると思うけど、動画をキャプチャするのはそれなりに手間がかかる。

なんとしても回避したいところで、けっこう頑張っているのだが、穴はあるんだよね。

けど、これだけ困難なら、容易には回避出来ないと言ってもよいでしょう。

仮想マシンの外側からキャプチャするなんて、技術的には可能だとしても、普通はやらないことだから。

実験的にやってみたけど、実用上はこれはどうかと思うしね。BlueStacksはそこまで大変ではないけど。


Author : hidemaro
Date : 2019/09/15(Sun) 23:00
コンピュータ・インターネット | Comment | trackback (0)

受信エラーに直接気づけない!?

1つ前の世代で使っているマイコンのシリアル通信機能について、いろいろ深掘りしてたんだけど、

エラー時の処理を調べてみると、ちょっと奇妙なことに気づいた。


マイコンによって違いはあるだろうけど、通信ペリフェラルとDMAを組み合わせて使用することはよくある。

DMA(Direct Memory Access)は、あらかじめ設定しておけばCPUを使わずにデータ転送できる仕組み。

DMAはプログラムから駆動することもできるが、割り込み要求信号から駆動することもできる。

通信ペリフェラルに受信ごとに割り込みを発生させる設定をしておいて、

DMAコントローラに受信割り込み要求ごとに、受信レジスタからメモリにデータ転送すると設定しておくと、

あとはCPUは手放しで受信データが順番にメモリに格納されていくわけである。

指定数のデータの転送が完了したら、DMA転送完了割り込みを発生することもできる。


ところでシリアル通信の受信時には、フレーミングエラーとか、パリティエラーとかが発生することがある。

普通に使っていればこういうエラーが発生することはないと思うのだが、もしエラーが発生したらどうなるんだろう。

その結果、次のような動作になることがわかった。

  1. 受信エラー割り込みはDMA転送のトリガにならない
  2. 受信エラーが発生すると、エラーフラグが消えるまでは新たな受信を停止する
  3. ゆえに1回でも受信エラーが発生すると、DMA転送は永遠に完了しない

通信ペリフェラルは受信エラー発生時に割り込みを発生させることができるのだが、

このマイコンでは、DMA転送と併用するときは、受信エラー割り込みを使うことが出来ない。

その代わり、エラーをきっかけにデータ転送が進むことは無いし、

プログラムがエラーを認識してエラーフラグを消すまでは、一切の受信が停止するというおまけ付きである。


ところがこれってDMA併用時は割り込みでエラーに気づくことができないってことなんだよね。

そんなのでエラー処理大丈夫なの? と思った。

実際のシステムでは、定周期処理でDMA転送の状態をポーリングしている。

正常に全データを受信できたら割り込みを発生させることが出来るが、

受信中にエラーが発生した場合もそうだし、データが届かなかった場合も割り込みが発生しない。

そのため、一定時間待ってもデータが届かなかった場合は、タイムアウトでエラーにする処理を組み込んでいる。

タイムアウトを検出するのはほぼ必須だからこれでいいのか。


最新世代のシステムで使っているマイコンはどうなっているのか、気になって再確認してみた。

すると、DMA併用時に受信エラーが発生したときは、DMAを強制停止して、DMA転送完了割り込みを発生させる。

DMA転送完了割り込みでは、正常終了かフラグを確認することになっているので、

異常終了だった場合は、何らかのエラーがあったことが検出できるってわけ。こっちの方が素直ですね。

もっとも、このマイコンでもタイムアウトの検出は別途行う必要はあるのだけど。


あと、このマイコンは通信ペリフェラル内にFIFOを備えているので、

FIFOサイズ以下であれば、DMAを併用せずともCPU手放しでデータの送受信が出来る。

特に受信の場合、DMA併用よりもFIFOで受信する方がずっとシンプルに作れるようになっている。

この場合、FIFOに指定数格納された時 と 受信エラー発生時 に割り込みを発生させることができる。

エラーフラグが消されるまではFIFOへの格納を停止するので、その点でもDMAの異常終了と似ている。

同じマイコンの類似した機能なので合わせてるんだろうけど。


受信エラーが発生したら割り込みで通知できるのは当たり前だと思ってたけど、

DMA併用時だと必ずしもそうともいかないというのは想定外だった。

受信エラーを無視して、受信し続けるということはしないなど考えられている部分もあり、

割り込みが発生せずとも、それで問題ないように作ること自体はそんなに難しいことではないのだけど。

どうせタイムアウト処理は作らないと使い物にならないわけだし。


Author : hidemaro
Date : 2019/08/22(Thu) 23:11
コンピュータ・インターネット | Comment | trackback (0)

リセットって割り込み?

マイコンの重要な機能が割り込みである。

割り込みというのは、条件を満たしたとき、実行中のプログラムを中断して、指定したプログラムを実行させるもので、

マイコンではタイマや通信などをきっかけにして、割り込みを発生させることが多い。

PCも裏ではいろんな割り込みが動いてるんだけどね。それを意識するかはともかく。


割り込みの種類を書き上げたリストの筆頭に「パワーオンリセット」と書いていたら、

それは割り込みではないのでは? と指摘された。

僕の認識ではリセットは優先度最高の割り込みという認識だったのだが、

確かにリセットって一般的な割り込みとは全く違う概念のものだよね。


マイコンのマニュアルにはどう書かれているのか。

ARM Cortex-Mシリーズ と ルネサスRXシリーズ のマニュアルを見てみたのだが、どちらも書き方はほぼ同じだった。

僕が割り込みと思っていたものは「例外」という言葉で書かれていた。

Cortex-Mでは例外は リセット、ノンマスカブル割り込み(NMI)、各種フォルト、スーパーバイザコール、システムタイマ、外部割り込み から構成されているとある。

RXでは例外は リセット、NMI、割り込み、未定義命令例外、特権命令例外、無条件トラップ から構成されるとあった。

すなわち、例外の中に「割り込み」という概念があるということらしい。


一般的に割り込みというのは、ユーザーが有効・無効や優先度を決めることが出来る。

ARMだと数字が小さいほど優先度が高く、RXだと数字が大きいほど優先度が高い。

もっとも同じルネサスでも旧NECから継承したRL78(旧78K0)は数字が小さい方が優先度が高いようだが。

それはさておき、Cortex-M ではリセットの優先度は -3、NMIは優先度-2、ハードフォルトは優先度-1に固定されている。

ユーザーが設定できる優先度は0~255なので、リセットは最優先、それに次いでNMI、ハードフォルトというのは不変ということである。

リセットとNMIが最優先かつ無効化できないというのは、どんなマイコンも共通なんじゃないか。


Cortex-MにしてもRXにしても、例外の中に狭義の「割り込み」があって、

狭義の割り込み以外の例外として、少なくともリセットとNMIがあるということである。

リセットは明らかに特殊だけど、NMIもリセットを除いて最優先で無効化できないという点では特殊である。

NMIはその性質からエラー処理に使われることが普通である。

とあるシステムでは、外部のロジックICの異常信号をNMI入力に接続してあった。

ロジックICが異常を検出したら、マイコンにNMIを発生させて処理を停止させるようになっていたはず。

RXマイコンではNMI発生後は元のプログラムに復帰出来ないと書かれていたぐらいなので、そういう用途でしか使っちゃダメだよということだね。


リセットは割り込みなのか? と問われると、ちょっと困ってしまうところはあるのだが、

特定の条件によって、プログラムカウンタを指定した値にセットするという点では割り込みなんじゃないか。

ただし、リセットというのはその性質上、内部状態をご破算にするので、元のプログラムに戻ることは当然出来ない。

その点では、一般的な割り込みの特徴に合わない気がするんだけど、元のプログラムに戻らない用途で使う割り込みというのはけっこうあるんだよね。

例えば、ウォッチドックタイマー割り込みとか。死に際でログを取ったりするための割り込みだから、通常は元のプログラムに戻らない。

元のプログラムに戻らないのと、戻れないのは違うと言われればそうかもしれないが。


もっとも、リセットは割り込みではないのでは? という指摘はマイコン内部の機能ブロックを意識しての話だったようだけど。

そのマイコンでは、リセット以外の例外をコントロールする機能ブロックがあるらしい。

NMIも、各種フォルトも、狭義の「割り込み」も同じ枠組みでコントロールされているようだが、

唯一、リセットだけは別のブロックによりコントロールされているようである。

リセットは他の割り込みとは実現方法が違うだろうなぁ、というのはだいたい想像できることだけど、実際そうだよというだけの話。


Author : hidemaro
Date : 2019/08/09(Fri) 23:50
コンピュータ・インターネット | Comment | trackback (0)

ROMデータの作り直し

工場で使ってる ROMライターの都合で、ROMデータを作り直す必要があって、

いくつかのROMデータをチマチマと作り直している。

実はもともと開発ツールから生成される、ちょっと特殊なデータ形式をそのまま書き込ませていたのだが、

汎用性に欠く方式でいろいろ不都合があったのも実情である。


この問題を回避するためには、汎用的なROMデータに変換すればよい。

同種のものでも、過去に1つだけ汎用的なROMデータを生成して、書き込む方法を取っているものがあった。

その方法に準じて汎用的なROMデータに変換することにした。

ヘッダ・フッタを切り取って、ROMのサイズに満たない分を0xFFでデータを埋めて、とあるルールでバイナリを変換すればよい。

作業自体は慣れれば大したことではないが、従来より手間は増える。


ROMデータの登録が完了すれば、とりあえずの目的は達せられたのだが、

そういえば新しいROMデータの生成方法を残してなかったなと思い、

ROMデータの生成方法を文書化して、文書管理システムに登録する作業をやっていた。

過去の同種の記載を参考に、実態に即して書き換えを進めた。

登録しておけば、後にROMデータの変更が必要になったときに役立つはず。


ROMデータの生成ってけっこういろいろ手順があるんだよね。

しかも、普段はJTAGとかで書き込むから、ROMライター用のデータを作る必要性もない。

一応、職場にもROMライターがあるので、そのROMデータで妥当かどうか確認する手段はあるのだが、

ROMデータ改訂のたびに毎度そういうことをやるかというと、そうとも言えない。

手順通り作れば大丈夫なはずなんだけど、工場でしくじっては面倒だ。


Author : hidemaro
Date : 2019/07/26(Fri) 23:20
コンピュータ・インターネット | Comment | trackback (0)

パラレルバスのFlashはこうやって書き換える

古いマイコンでパラレルバスのFlash ROMを外付けしてるんだけど、

どうやって書き込むんだろうなぁとおぼろげには思ってたが、

フラッシュ書き込み用のプログラムの改造が必要になったので、

書き込み用のプログラムのソースコードを入手して中身を見てみた。


操作内容を見てみると、Flash ROMに対してマジックワードを書き込みしているように見える。

これは一体何なんだ? と思って、Flash ROMのデータシートを見てみた。

すると、ソースコードに書いてある通りの操作手順が書いてあった。

ソフテックだより/マイコンによるNOR型フラッシュメモリ制御 (ソフテック)

JEDEC標準型コマンドという方式に従っているようだ。

アドレスを変えながらマジックワードを書き込む操作を数回繰り返すとイレースとかライトとかの操作ができると。


偶然、マジックワードを書き込む操作をしてしまったら、Flash ROMが消えたり書き換わったりするのでは?

と思ったけど、Flash ROMにライトアクセスをすること自体が異常な操作だもんな。

間違えてライトアクセスをしたとしても、アドレスを変えながらマジックワードを書き込まないと何も起きないからね。

やってること自体は簡単そうだが、意図的にやらないと起きないことは間違いないようだ。


マイコンの内蔵Flashだと、専用のレジスタをあれこれ操作して書き換え操作をやるものだけど、

外部に接続されたFlash ROMの場合、マイコンの機能は関係なくて、Flash ROM自体の機能で書き換えるというのは、

言われて見れば当たり前のことだけど、操作感があまりに違うものだから、

「えっ、こんな操作で書き換えられちゃうの!?」と初見では思ったよね。

冷静に考えれば全く問題なかったですね。

特定のアドレスにマジックワードを書き込んで書き換えをするのは、マイコン内蔵のFlashでも同じことだし。

そのアドレス空間がROM空間か、ペリフェラルレジスタかという違いでしかない。


Author : hidemaro
Date : 2019/07/17(Wed) 23:16
コンピュータ・インターネット | Comment | trackback (0)

Tools