カテゴリー：PC・ネットワークの記事一覧

本物そっくりの詐欺メールがたくさん届くようになってきました。ふつうは、これらの詐欺メールは、プロバイダの電子メールシステムの選別機能(フィルタ)が働いて「迷惑メールフォルダ」に届くようになっているはずですが、なかには、巧妙にフィルタをすり抜けて、通常の「受信箱」に届くものがあります。

 

いったいこれらの詐欺メールはどこからやってくるのでしょうか？

 

ここでは、当方あてに通常の「受信箱」に届いたこれらの詐欺メールを、メールヘッダーから解析して、アドレスやサーバーなどのWHOIS情報を参考に、分類してみたので、その結果を記述します。

 

対象のメールは、2021年1月1日から5月27日までのおよそ5か月の期間に、本来「迷惑メールフォルダ」行きのはずであるが何らかの理由で通常の「受信箱」に届いた詐欺メール167件です。(実際の「迷惑メールフォルダ」に届いた詐欺メールは、この十倍から数十倍以上はあります。その一部が漏れて「受信箱」に入ってしまったと考えています。)

 

なお、ここでは、詐欺メールの見分け方の詳細や、騙されないためにどのような対策をするべきかについては触れていません。(これらについては、ネット上に優れた記事がたくさんあります。)

 

1. 詐欺メールの内訳

 

届いた詐欺メールには、アカウントとカード情報を抜き取るもの、カード情報を抜き取るもの、サイトへのログイン情報を抜き取るもの、出会い系サイトへ誘導するもの、脅しをかけて不正に送金を要求するもの、があります。

 

これらの件数の内訳と割合は次のとおりです。

 

【詐欺メールの内訳】

 

【詐欺メールの内訳】

 

アカウントとカード情報を抜き取るもの、カード情報を抜き取るものをあわせて全体の3分の2の113件に達していることがわかります。

 

その他は、出会い系サイトへ誘導するもの、脅しをかけて不正にBitcoinの送金を要求するものなどでした。この記事では、出会い系サイト誘導と送金要求については割愛します。

 

2. 詐欺の対象物

 

このアカウントとカード情報を抜き取る113件について、どのアカウント情報、どのクレジットカード情報を詐欺の対象としているかについて分類してみると、次のようになります。

 

【主な詐欺の対象物】

 

【カード対象物の内訳】

 

圧倒的に、Amazonに関するものが過半数、次いで、楽天に関するものとなっています。また、主要なクレジットカード会社に関するものが見られます。

 

3. どこの国からこの詐欺メールはでている？

 

これらの実際のメールには、メール本文の中にクリックする箇所が必ずあります。

そのURLのドメイン情報を調べました。

また、メールヘッダーと呼ばれる部分に、発信者の情報、発信元メールサーバーの情報、メールソフトの情報、日本語文字コードの情報などが記述されています。

 

【メールヘッダーの例 (1)】

 

【メールヘッダーの例 (2)】

 

まともな普通のメールであれば、送信者のメールアドレスからわかる国名、発信元メールサーバーがある国名、本文中のサイトのURLがあらわす国名は、一致することが多いとおもわれます。

 

ところが、ここで取り上げた詐欺メールは、これらが一致しないことが多いのです。

 

4. どこの国からこの詐欺メールはでている？

 

メールヘッダーに記載されている発信者のIPアドレス、発信元メールサーバーのURL、本文中にあるクリック誘導のURLのドメイン、それぞれをWHOIS情報をもとに、国名を調査した結果を次に示します。

 

【国別リスト】

 

【送信者メールアドレス(国別)】

 

【発信メールサーバー(国別)】

 

【情報入力先URL(国別)】

 

 

これらを見る限り、非常に偏っていることがわかります。もちろん調査しても不明なところはありましたので、精度はやや低いですが、それでもおおよその傾向はわかります。

 

詐欺メールの送信者は、不明を除くと、日本、次いで中国の順です。しかし、本文中の情報を入力させるためのURLは、不明を除くと、中国が圧倒的に一番となっています。

また、どの国のメールサーバーから発信されているかを見ると、日本、シンガポール、米国、ロシア、香港などばらばらです。

 

この結果をひとことでいうと、これらのアカウント・カード情報を詐取するのは主に中国のサイトですが、メール自体は日本から正規に発信されたように見せかけて、シンガポール、米国、ロシア、香港などの第三国のサーバーを経由して追跡しにくくしている、というように見えます。

 

このアカウントとカード情報を抜き取る113件の詐欺メールのメーラーソフトは、大半がMicrosoftのものですが、一部、中国製のFoxmailが使われていました。

 

【詐欺メールのメールソフト】

 

また、メール本文の日本語文字コードは、大半がUTF-8でしたが、中国のGB2312も一部にありました。

 

【詐欺メールの文字コード】

 

これ以上の追跡はしていませんが、やはり中国のまたは中国に関係した詐欺グループが多いと見るのはそれほど外れていないようです。Silent invasion がここにもと考えるのは考え過ぎでしょうか。

 

5. 終わりに

 

ここでは、詐欺メールの見分け方の詳細や、騙されないためにどのような対策をするべきかについては触れていませんが、怪しいメールにはじゅうぶん注意しましょう。

 

怪しいとおもったら、発信者情報(メールアドレス、メールヘッダーに記載してあるメールサーバーのアドレス、発信者のIPアドレスなど)を調べて、本物か偽物の判断をしましょう。

 

(2021-6-2)

 

 

なお、本調査で使用した元のデータと図表のまとめ資料については、以下をごらんください。(PWについてはサイト管理者までお問い合わせ下さい。)  phishingemail .

 

→  元のデータ (Excel)

→  図表のまとめ資料 

.

 

Windows10のPCを立ち上げて、左下のスタートボタンから「設定」をクリックし、設定ホーム画面が開いたとき、あなたのPCは、次のA、Bのうち、どちらの画面になっているでしょうか。

 

type - A 

 

 

type - B 

 

 

実は、手元にある2台のPCのうち、1台は「A」、もう1台は「B」と、設定ホーム画面上部のアカウント情報が表示されないPCと、表示されるPCがあったのでした。

 

長いこと不思議でしたが、いろいろ調べたところ、ようやく原因らしきことがわかってきました。

 

この記事は、そのメモになります。

 

 

1. 経緯

 

変化に気づきはじめたのは、Windows10のバージョンを1903から1909にアップデートした直後からでした。

 

バージョンが1903のときは、いずれのPCも「A」の画面が表示されていました。それ以前と同じなので特に違和感はありませんでした。

 

バージョンを1909にアップデートしたところ、1台は「A」、もう1台は「B」と、異なる画面が表示されるようになったのでした。それ以降に何回かWindows Updateがありましたが、設定ホーム画面上部のアカウント情報の表示については変化がありませんでした。

 

調べた結果、「A」から「B」の画面に移行しようとしていて、一部のPCのみに先行して「B」の画面を試験的に適用しているらしいことがわかりました。ですから、まだ全部のPCに適用されているわけではないようです。

 

ただ、ずくにも適用することはできるようで、その方法が次の記事にありました。

 

How to enable Settings header design on Windows 10 version 1903
(  https://pureinfotech.com/enable-settings-header-windows-10/  )

 

この記事をみると、Windowsのバージョンが1809から1903にアップされたころから始まったようです。

 

 

2. 設定ホーム画面上部のアカウント情報を表示させる方法

 

いずれは新しい「B」の画面に移行されると思われますが、いまだに「A」の画面の場合は、「B」の画面にすぐに移行させる方法があります。

 

(1) Githubのサイトから最新のmach2という圧縮zipファイルをダウンロードする。

 

この記事を書いている時点では、サイトは

https://github.com/riverar/mach2/releases

ダウンロードすべきファイルは
　　　　mach2_0.3.0.0_x64.zip      ←     (64ビットPCの場合)

です。

 

(2) ダウンロードしたzipファイルを任意のフォルダに移動し、そこで展開します。

例えば、以下の例では、フォルダとして、C:\Users\user01 に移動して展開しています。

 

(3) 左下のスタートボタンから「Windowsシステムツール」-「コマンドプロンプト」を選び、右クリックし、管理者モードで実行します。

 

 

(4) cdコマンドで、さきほど展開したフォルダに入ります。

 

 

(5) 次のコマンドをタイプし、実行します。
　　　　mach2 enable 18299130

 

 

(6) これで、「コマンドプロンプト」は閉じてかまいません。いったん、設定ホーム画面を閉じて、再び左下から「設定」をクリックし、設定ホーム画面を開くと、設定ホーム画面上部のアカウント情報が表示された「B」の画面になっているはずです。

 

 

3, 注意事項

 

注意事項として、このアプリケーションはサードパーティから提供されていますが、保証はされていない、また、ウィルス対策ソフトで悪意のあるアプリとして誤認識されてしまうかもしれない、ということです。もし、この方法を試みる場合は自己責任で実施して下さるようお願いします。

 

(2020-5-6)

 

 

4, 追記 - Windows10 に May 2020 Update を適用したらこうなった .......

 

Windows10のアップデートを実施しました。Versionは2004 になりました。

 

それで、このアカウント情報の表示部分がどうなったかというと、元にもどりました。すなわち、type-A の画面にもどってしまいました。

 

おそらく、これがデフォルトなのでしょう。これから変わるかもしれませんが、.......。

 

ということで、再度、type-Bの画面を上記の方法で設定してみることにしました。

 

左下のスタートボタンから「Windowsシステムツール」-「コマンドプロンプト」を選び、右クリックし、管理者モードで実行することになります。

 

 

これで、再度、設定ホーム画面を閉じて、再び左下から「設定」をクリックし、設定ホーム画面を開いたところ、次の type-C の画面になりました。

 

type-C

 

以前の type-B にあった「リワード」の項目はなくなりました。また、ユーザーの画像を設定しているのですが、これが消えてしまいました。

 

というわけで、Windows10 の May 2020 Update を適用すると、また変化しますよ、という報告でした。

 

(2020-5-31 追記)

 

 

 

 

ある日のこと、このサイトの問い合わせ欄に届いたひとつの依頼、それは、「データ復元ソフトを試していただけませんか？」というものでした。

 

ふだん、パソコンで写真の整理をしたり、文章や表を作成したり、という時に誤ってファイルを削除してしまった場合、役立つかも、というもの。

 

その製品のサイトを見ると、Windows用とMac用がありました。(残念ながらLinux用はありませんでした。)

 

 

MACの場合はよく知らないのですが、Windowsは、ひとまず削除してもそのファイルは「ごみ箱」に入るので、当初あまり有用性は感じませんでした。

しかし、間違って「ごみ箱」を空にしてしまったらどうなるだろうか、と考えて、ひとまずこのソフトを試してみることにしました。

 

これは、そのときの試用メモになります。

 

 

1. 無料版のデータ復元ソフト

 

このデータ復元ソフトは、イーザスソフトウェアから提供されている「EaseUS Data Recovery Wizard」というもので、無料版がサイトにありました。

 

https://jp.easeus.com/data-recovery-software/drw-free.html

 

無料版の制限は「最大2GBまでデータ復元可能」とあるのですが、実際にはファイルサイズの合計が500MBまでらしいです。( 後述の追記のように、SNSでシェアすると2GBまで可能なようです。)

ただし、よほど大量のファイルや大きなサイズのファイルでなければ、試すことはできるだろうと思い、手元にあった以前使用していて今は使っていないUSBメモリで、このソフトの無料版を使って、試してみることとしました。

 

結論からいうと、無料版でもある程度は使えます。使い方も簡単でした。

ただ、復元の候補のファイルリストは表示されるのですが、実際に復元できるファイルは500MBまででした。
また、削除してから時間の経過したファイルは、リストに出てこない場合があるようでした。

 

以下に、試した手順を追って記述していきます。

 

 

2. 試してみた環境

 

使用した環境は、

・PC:  Dynabook Satelite PB552FEA127A51 (Toshiba)

・CPU:  Core i5 (Intel) 、実装メモリ: 10GB

・OS:  Windows10 ver.1909、 64-bit

です。

 

ソフトのインストールは、
https://jp.easeus.com/data-recovery-software/drw-free.html
から、「無料版」(Free)を選択して、普通にインストールしました。

 

 

3. 事例 1 ( 16MBのUSBメモリ )

 

最初に試したのは、16MBのUSBメモリです。以前(もう十年以上前)になにかソフトが入っていたのを削除して空の状態にしてあったのを思い出し、どの程度復元できるかを見ようとしました。

 

 

復元した結果は、ファイルが見つからない、ということでした。

 

そこで、このUSBメモリに音楽ファイルを2個コピーし、エクスプローラでファイルの存在を確認してから、また削除しました。

そして、このデータ復元ソフトで、どの程度復元できるかを試してみました。

 

 

 

 

復元した結果は、当初のファイルサイズの約2倍のサイズになりますが、復元の候補のファイルが表示されました。ただ、これをリカバリーするのに、同じ媒体(USBメモリ)にはできないようなので、パソコン本体のデスクトップ領域にリカバリーファイルを置くこととしました。

 

 

リカバリーを起動させるとほんの数秒で修了しました。

得られたファイル名はかなり違っていました(後述)が、きちんと復元できました。音楽ファイルなので実際に動作させてみるとちゃんと音が出ました。

 

 

ファイル名は、そのファイル名の中に空白が混ざっていると、その前後でフォルダ名とファイル名というように認識されるらしく、余計なフォルダができてしまいました。ファイル名に空白を含まないようにすれば、この問題は回避できると思われます。

 

 

4. 事例 2 ( 4GBのUSBメモリ )

 

次に、4GBのUSBメモリで試してみました。このUSBメモリも以前、データを入れていたのを全て削除して空の状態にして保管していたものです。

 

 

エクスプローラでファイルが存在しないことを確認してから、このデータ復元ソフトで、どの程度復元できるかを試してみました。

 

 

結果は、忘れていたいろいろなファイルが出てきました。

4GBのUSBメモリですが、表示された復元候補ファイルのサイズの合計は約8GBでした。
おそらく二重に表示されているとおもわれました。

 

 

次に、やはりパソコン本体のデスクトップ領域にリカバリーファイルを置くこととしいくつかのファイル(全部ではありませんが)にチェックを入れ、リカバリーを試みました。

すると、途中で停止してしまいました。画面には、アップグレードを推奨する表示があらわれたのです。

 

 

デスクトップ領域の復元されたファイルを見ると、合計で480MBとなっており、そのファイル自体はきちんと開くことができました。

 

 

途中停止した理由は、無料版ではファイルサイズの合計が500MBまでという制限があるためと理解しました。( ただし、後述の追記のように、SNSでシェアすると2GBまで可能なようです。)

 

 

5. まとめ

 

ここで、今回のお試しの要点をまとめると、

 

1. Windows版、Mac版はあるが、Linux版はない。

2. Windows版の無料版を試用。500MBまでのファイルの復元には使える。

3. ファイル名には空白を含めないようにして保存しておくのが良い。

4. 削除してからあまりに時間が経過したものは復元ができない場合がある。

5. 復元したファイルの置き場として、パソコン本体のデスクトップ領域を使用するので、本体のハードディスク容量は大きいほうが良い。

6. 復元されるファイルのサイズは、予想の約2倍のサイズに表示される。つまり、同じファイルが複数できるようである。

 

他の同種のソフトもあるようですが、実際に使ったことがないので、比較などはできないことをご理解下さい。

 

「EaseUS Data Recovery Wizard」についていえば、特に困った問題は発生しませんでした。
もしも、500MB以上のファイルを復元しなければならないときは、ライセンスを購入するということになるでしょう。
ただ、Windowsをお使いであれば、無料版はとりあえずインストールしておいて、万が一のときに備えるというのが良いとおもいます。

 

(2020-1-18)

 

 

 

6. 追  記

 

以上が実際にやってみた結果ですが、いろいろ調べてみると、どうも、「無料版の復元サイズ(2GB)については、最初では確かに500MBですが、SNSシェアすると、1.5GBが追加される。合計2GBとなる。」ということのようでした。
ただ、この情報は、探しましたが、上記のサイトではexplicitには記述されていませんでした。

そこで、「EaseUS Data Recovery Wizard」を動作させた状態で、いろいろマウスのカーソルを動かしていると、こんな表示が、突然あらわれたのです。

 

 

試してみる価値はありそうです。

 

(2020-1-24)

 

 

1. はじめに

 

2013年11月に交換(設置)したUSBハードディスク(USB-HDD)は、37型の液晶テレビ(東芝レグザREGZA)の録画用として、我が家の居間で動作していました。が、このところ、どうも録画に飛びが発生したり、予約した番組がきちんと録画されていなかったりと、怪しい動きをしていたのです。

 

このUSBハードディスクの機種に交換(設置)してから5年半が経過したため、そろそろ寿命かな？と考えていた矢先に、突然、「ハードディスクを認識しない」という現象が発生しました。

 

取説(取扱説明書)を見ながら、テレビ側の設定をいろいろ調べてみたのですが、どうもうまくいきません。

 

しかし、このまま放っておくわけにもいかず、しかたなく、新しいUSBハードディスク(USB-HDD)を買いに、近くの家電量販店まで足を伸ばしたのでありました。

 

☆　☆　☆

 

さて、取り外したUSBハードディスクは、ひとまず、そのままにしておいたのですが、以前、同じように故障した録画用のUSBハードディスクを、PCに接続して、その状態を確認したこと [1] を思い出し、今回も、「ダメ元」で、同じ手順で状態を確認したときに、どうなるかを実際に確認してみることとしました。

 

その結果、運良くというか、ハードディスクのファイルを修復し、USBハードディスクをテレビに接続して再び録画・再生をすることができました。

 

この記事では、テレビ録画用に接続した外付けUSBハードディスク(USB-HDD)の修復・復旧について試みた方法と手順を簡単なメモ書きですが、紹介します。

 

(ただし、必ずしもうまくいくとは限らないので、その点はご了解下さい。このような修復・復旧作業を実施される場合は、自己責任で実施されるようお願いします。)

 

2. 確認手順の概略

 

(1) Linuxパソコン(PC)を準備する

(2) USB-HDDをマウントし、マウントボイントを確認する

(3) USB-HDDをアンマウントし、ディスクチェックを行なう

(4) USB-HDDのディスクファイルの修復を行なう

(5) USB-HDDを再度マウントしてファイルのリストを確認する

(6) 再度アンマウントしてディスクチェックを行なう

 

これだけですが、(4)の作業でエラーになるか、ならないかがひとつの鍵になります。ちなみに、以前に書いた記事[1]の場合は、ここでNG(修復不能)と判断しました。

 

3. パソコン(PC)で外付けUSBハードディスク(USB-HDD)の状態を確認する

 

準備するものは、Linuxを起動できるパソコン(PC)と故障した(？)外付けUSBハードディスク(USB-HDD)とUSB接続ケーブルです。

 

液晶テレビ(東芝レグザREGZA)に接続されるUSBハードディスクのファイルフォーマットは
xfs形式になります。一般に使用されているWindowsパソコンでは、このxfsフォーマットのドライブやファイルを認識できません。したがって、Linuxを起動できるパソコン(PC)が必要なのです。

 

必ずしもPC本体にLinuxがインストールされていなくても、CD-ROMドライブなどから起動用CDなどでLinuxを起動できるのであれば問題ないとおもわれます。
(私自身のPCは、WindowsとLinuxのデュアルブートに設定してあるので、Linuxで起動しています。)

 

CDからLinuxを起動する方法は、ここでは触れませんが、[2]などを参考にして、起動用CDの作成、パソコン(PC)のCD-ROMドライブからの起動を行なって下さい。

 

以下、私の環境では、パソコン(PC)は東芝dynabook(PB552FEA127A51)、OSはLinuxでFedora29(64bit)、を使用しています。

 

まず、パソコンに外付けUSBハードディスク(USB-HDD)を接続します。

 

この状態で、外付けUSBハードディスクが認識されているかどうかを確認します。
デスクトップ上に、該当するハードディスクのアイコンが表示されれば、認識され、
マウントされている状態になっています。

そうなっていない場合は、アプリケーションのシステムツールで、ディスク使用量アナライザを起動し、該当のハードディスクが存在するかを確認します。

 

次に、どのデバイスファイルにマウントされているかという、マウントポイントを確認します。例えば、/dev/sdb1 などになります。

 

以下はコマンド操作になりますので、コマンドライン端末(ターミナル)ウィンドウを開いて、管理者権限でコマンドを打ち込みます。

 

次に、いったんアンマウント(マウントを解除)して、ハードディスクの状態チェックを行います。使用するコマンドは、

umount /dev/sdb1

xfs_repair -n /dev/sdb1　　( または　xfs_check /dev/sdb1 )

です。

すると、次のような表示がでてきました。

 

[root@localhost user01]# umount /dev/sdb1

[root@localhost user01]# xfs_repair -n /dev/sdb1

Phase 1 - find and verify superblock...

- reporting progress in intervals of 15 minutes

Phase 2 - using internal log

- zero log...

- scan filesystem freespace and inode maps...
bad magic # 0x6e93bf6a in inobt block 16/3

expected level 0 got 36345 in inobt block 16/3

dubious inode btree block header 16/3

bad starting inode # (7860674304 (0x10 0xd4885f00)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 8172778468)

bad starting inode # (8172778468 (0x10 0xe722b3e4)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6410804566)

bad starting inode # (6410804566 (0x10 0x7e1d1d56)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 7195546658)

--- (途中、省略) ---

bad starting inode # (4750678384 (0x10 0x1b299970)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4502697197)

ir_freecount/free mismatch, inode chunk 16/207729901, freecount 1704223958 nfree 33

badly aligned inobt rec (starting inode = 5277979757)

bad starting inode # (5277979757 (0x10 0x3a97946d)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6257491054)

--- (途中、省略) ---

bad starting inode # (4976999758 (0x10 0x28a6fd4e)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4315432406)

ir_freecount/free mismatch, inode chunk 16/20465110, freecount 107526891 nfree 34

badly aligned inobt rec (starting inode = 6034583137)

bad starting inode # (6034583137 (0x10 0x67b06e61)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 5675287099)

--- (途中、省略) ---

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4294967296)

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

agi_count 0, counted 16320 in ag 16

agi_freecount 0, counted 2400232718 in ag 16

sb_icount 1408, counted 17728

sb_ifree 250, counted 19580102152
sb_fdblocks 52700857, counted 52709049

- 21:34:45: scanning filesystem freespace - 32 of 32 allocation groups done

- found root inode chunk

Phase 3 - for each AG...

- scan (but don't clear) agi unlinked lists...

found inodes not in the inode allocation tree

- 21:34:45: scanning agi unlinked lists - 32 of 32 allocation groups done

- process known inodes and perform inode discovery...

- agno = 30

- agno = 0

- agno = 15

--- (途中、省略) ---

- agno = 13

- agno = 14

- 21:34:53: process known inodes and inode discovery - 1408 of 1408 inodes done

- process newly discovered inodes...

- 21:34:53: process newly discovered inodes - 32 of 32 allocation groups done

Phase 4 - check for duplicate blocks...

- setting up duplicate extent list...

- 21:34:53: setting up duplicate extent list - 32 of 32 allocation groups done

- check for inodes claiming duplicate blocks...

- agno = 0

- agno = 1

--- (途中、省略) ---

- agno = 30

- agno = 31

- 21:34:53: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done

No modify flag set, skipping phase 5

Inode allocation btrees are too corrupted, skipping phases 6 and 7

No modify flag set, skipping filesystem flush and exiting.

[root@localhost user01]#

 

これで、一応、ハードディスクの状態確認ができたことになります。最後のほうに、「iノード割り当てBツリーが破損しているため、フェーズ6と7をスキップします。変更フラグを設定せず、ファイルシステムのフラッシュをスキップして終了します。」のメッセージで終わってしまいましたが、これは、ファイルの一部が破損していることを示しています。

 

4. 外付けUSBハードディスク(USB-HDD)のディスクファイルの修復を行なう

 

次に、修復できるかどうかをやってみました。使用するコマンドは、

xfs_repair -Lv /dev/sdb1

です。

 

ここで、以前経験したような fatal error が出現したら、物理的な故障なので、
どうしようもありません。

 

今回は、次のような表示がでてきました。

 

[root@localhost user01]# xfs_repair -Lv /dev/sdb1

Phase 1 - find and verify superblock...

- reporting progress in intervals of 15 minutes

- block cache size set to 332184 entries

Phase 2 - using internal log

- zero log...

zero_log: head block 199805 tail block 199805

- scan filesystem freespace and inode maps...

bad magic # 0x6e93bf6a in inobt block 16/3
expected level 0 got 36345 in inobt block 16/3

dubious inode btree block header 16/3
bad starting inode # (7860674304 (0x10 0xd4885f00)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 8172778468)

bad starting inode # (8172778468 (0x10 0xe722b3e4)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6410804566)

--- (途中、省略) ---

ir_freecount/free mismatch, inode chunk 16/73979246, freecount 889473186 nfree 31

badly aligned inobt rec (starting inode = 7924286411)

bad starting inode # (7924286411 (0x10 0xd85303cb)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6393507745)

--- (途中、省略) ---

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

agi_count 0, counted 16320 in ag 16

agi_freecount 0, counted 2400232718 in ag 16

sb_icount 1408, counted 17728

sb_ifree 250, counted 19580102152

sb_fdblocks 52700857, counted 52709049

- 21:37:17: scanning filesystem freespace - 32 of 32 allocation groups done

- found root inode chunk

Phase 3 - for each AG...

- scan and clear agi unlinked lists...

found inodes not in the inode allocation tree

- 21:37:17: scanning agi unlinked lists - 32 of 32 allocation groups done

- process known inodes and perform inode discovery...

- agno = 0

- agno = 15

--- (途中、省略) ---

- agno = 14

- 21:37:25: process known inodes and inode discovery - 1408 of 1408 inodes done

- process newly discovered inodes...

- 21:37:25: process newly discovered inodes - 32 of 32 allocation groups done

Phase 4 - check for duplicate blocks...

- setting up duplicate extent list...

- 21:37:25: setting up duplicate extent list - 32 of 32 allocation groups done

- check for inodes claiming duplicate blocks...

- agno = 0

- agno = 1

--- (途中、省略) ---

- agno = 26

- 21:37:25: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done

Phase 5 - rebuild AG headers and trees...

- agno = 0

- agno = 1

--- (途中、省略) ---

- agno = 31

- 21:37:25: rebuild AG headers and trees - 32 of 32 allocation groups done

- reset superblock...

Phase 6 - check inode connectivity...

- resetting contents of realtime bitmap and summary inodes

- traversing filesystem ...

- agno = 0

--- (途中、省略) ---

- agno = 31

- traversal finished ...

- moving disconnected inodes to lost+found ...

Phase 7 - verify and correct link counts...

- 21:37:25: verify and correct link counts - 32 of 32 allocation groups done

XFS_REPAIR Summary Tue Apr 30 21:37:25 2019

Phase Start End Duration

Phase 1: 04/30 21:37:06 04/30 21:37:06

Phase 2: 04/30 21:37:06 04/30 21:37:17 11 seconds

Phase 3: 04/30 21:37:17 04/30 21:37:25 8 seconds

Phase 4: 04/30 21:37:25 04/30 21:37:25

Phase 5: 04/30 21:37:25 04/30 21:37:25

Phase 6: 04/30 21:37:25 04/30 21:37:25

Phase 7: 04/30 21:37:25 04/30 21:37:25

Total run time: 19 seconds

done

[root@localhost user01]#

 

今回は、Phase1、Phase2、・・・、Phase7　と進んでいき、終了した(「done」)との表示でした。

 

もしも、この操作の実行中に、

 

Phase 1 – find and verify superblock…

superblock read failed, offset 0, size 524288, ag 0, rval -1

.

fatal error — 入力/出力エラーです

 

のような表示が出た場合は、それはハードディスクの物理的な故障なので、どうしようもありません。

 

5. 外付けUSBハードディスク(USB-HDD)のファイルリストの確認と再度のディスクチェックを行なう

 

さて、これで修復されたとのことなので、ファイルの存在と状態を確認してみました。いったん、再度マウントを行ないます。

デスクトップ上に、該当するハードディスクのアイコンが表示されれば、マウントされている状態になっていますが、そうなっていない場合は、アプリケーションのシステムツールで、ディスク使用量アナライザを起動し、該当のハードディスクを確認します。(クリックすればマウントされます。)

 

今回の場合、
/dev/sdb1
のマウントポイントは、
/run/media/user01/e4f007b8-c779-4d7a-a2db-34c15c363213
でした。

そのディレクトリまで進み、ファイルの存在状態を確認しました。

 

[root@localhost user01]# cd /run/media/user01

[root@localhost user01]# ls

e4f007b8-c779-4d7a-a2db-34c15c363213

[root@localhost user01]# cd e4f007b8-c779-4d7a-a2db-34c15c363213

 

コマンドは「ls -al」です。

 

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]# ls -al

合計 1742544948

drwxr-xr-x. 3 root root 53248 4月 30 12:30 .

drwxr-x---+ 3 root root 60 4月 30 21:46 ..

-rw-r--r--. 1 root root 82344 4月 30 12:30 .toshiba_dir_info_e89d874cd80a

-rw-r--r--. 1 root root 4760 4月 30 11:59 .toshiba_serieslist_e89d874cd80a

-rw-r--r--. 1 root root 268 4月 30 12:30 .toshiba_size_info_e89d874cd80a

drwxr-xr-x. 7 root root 109 11月 6 2014 .toshibazze89d874cd80a

--wsr-sr-t. 1 root root 7052292288 11月 14 2013 M000020131114195750e89d874cd80a.dtv

-rw-r--r--. 1 root root 1760 4月 27 15:20 M000020131114195750e89d874cd80a.dtv.meta

-rw-r--r--. 1 root root 80778 11月 14 2013 M000020131114195750e89d874cd80a.dtv.rat

--wsr-sr-t. 1 root root 5232187584 11月 27 2013 M000020131127195950e89d874cd80a.dtv

-rw-r--r--. 1 root root 1760 2月 24 14:52 M000020131127195950e89d874cd80a.dtv.meta

-rw-r--r--. 1 root root 65826 11月 27 2013 M000020131127195950e89d874cd80a.dtv.rat

--- (途中、省略) ---

--wsr-sr-t. 1 root root 2524987584 4月 30 12:00 M000020190430115950e89d874cd80a.dtv

-rw-r--r--. 1 root root 1760 4月 30 12:00 M000020190430115950e89d874cd80a.dtv.meta

-rw-r--r--. 1 root root 41046 4月 30 12:30 M000020190430115950e89d874cd80a.dtv.rat

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]#

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]# cd .toshibazze89d874cd80a

[root@localhost .toshibazze89d874cd80a]# ls -al

合計 108

drwxr-xr-x. 7 root root 109 11月 6 2014 .

drwxr-xr-x. 3 root root 53248 4月 30 12:30 ..

drwxr-xr-x. 2 root root 8192 4月 29 16:00 aeef0000000

drwxr-xr-x. 2 root root 8192 4月 30 12:30 aeef0000001

drwxr-xr-x. 2 root root 4096 4月 27 15:22 aeef0000002

drwxr-xr-x. 2 root root 4096 4月 30 12:30 alkf

-rw-r--r--. 1 root root 12 11月 4 2013 bid.bin

-rw-r--r--. 1 root root 80 11月 4 2013 did.bin

drwxr-xr-x. 2 root root 97 4月 22 10:59 log

[root@localhost .toshibazze89d874cd80a]#

[root@localhost .toshibazze89d874cd80a]# cd log

[root@localhost log]# ls -al

合計 188

drwxr-xr-x. 2 root root 97 4月 22 10:59 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 51200 3月 17 22:59 00000064.dat

-rw-r--r--. 1 root root 51200 4月 6 10:33 00000065.dat

-rw-r--r--. 1 root root 51200 4月 22 10:59 00000066.dat

-rw-r--r--. 1 root root 27008 4月 30 12:30 00000067.dat

-rw-r--r--. 1 root root 11 4月 22 10:59 info.dat

[root@localhost log]#

[root@localhost log]# cd ..

[root@localhost .toshibazze89d874cd80a]# cd alkf

[root@localhost alkf]# ls -al

合計 60

drwxr-xr-x. 2 root root 4096 4月 30 12:30 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r-----. 1 root root 4144 4月 29 16:00 alc0000000.bin

-rw-r-----. 1 root root 4144 4月 29 16:00 alc0000000.buc

-rw-r-----. 1 root root 4144 4月 30 12:30 alc0000001.bin

-rw-r-----. 1 root root 4144 4月 30 12:30 alc0000001.buc

-rw-r-----. 1 root root 4144 4月 27 15:22 alc0000002.bin

-rw-r-----. 1 root root 4144 4月 27 15:22 alc0000002.buc

-rw-r--r--. 1 root root 32 11月 4 2013 ald.bin

-rw-r-----. 1 root root 32 11月 4 2013 alk.bin

[root@localhost alkf]#

[root@localhost alkf]# cd ..

[root@localhost .toshibazze89d874cd80a]# ls -al

合計 108

drwxr-xr-x. 7 root root 109 11月 6 2014 .

drwxr-xr-x. 3 root root 53248 4月 30 12:30 ..

drwxr-xr-x. 2 root root 8192 4月 29 16:00 aeef0000000

drwxr-xr-x. 2 root root 8192 4月 30 12:30 aeef0000001

drwxr-xr-x. 2 root root 4096 4月 27 15:22 aeef0000002

drwxr-xr-x. 2 root root 4096 4月 30 12:30 alkf

-rw-r--r--. 1 root root 12 11月 4 2013 bid.bin

-rw-r--r--. 1 root root 80 11月 4 2013 did.bin

drwxr-xr-x. 2 root root 97 4月 22 10:59 log

[root@localhost .toshibazze89d874cd80a]# cd aeef0000000

[root@localhost aeef0000000]# ls -al

合計 520

drwxr-xr-x. 2 root root 8192 4月 29 16:00 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 80 8月 28 2018 aee00000000.bin

-rw-r--r--. 1 root root 80 3月 7 2017 aee00000001.bin

-rw-r--r--. 1 root root 80 6月 25 2014 aee00000002.bin

--- (途中、省略) ---

-rw-r--r--. 1 root root 80 2月 15 2017 aee0000007e.bin

-rw-r--r--. 1 root root 80 3月 1 2017 aee0000007f.bin

[root@localhost aeef0000000]#

[root@localhost aeef0000000]# cd ../aeef0000001

[root@localhost aeef0000001]# ls -al

合計 500

drwxr-xr-x. 2 root root 8192 4月 30 12:30 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 80 12月 5 20:15 aee00000080.bin

-rw-r--r--. 1 root root 80 8月 5 2015 aee00000081.bin

--- (途中、省略) ---

-rw-r--r--. 1 root root 80 12月 3 2017 aee000000ff.bin

[root@localhost aeef0000001]#

[root@localhost aeef0000001]# cd ../aeef0000002

[root@localhost aeef0000002]# ls -al

合計 140

drwxr-xr-x. 2 root root 4096 4月 27 15:22 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 80 2月 27 20:15 aee00000101.bin

-rw-r--r--. 1 root root 80 3月 3 23:25 aee00000103.bin

--- (途中、省略) ---

-rw-r--r--. 1 root root 80 5月 14 2018 aee00000137.bin

[root@localhost aeef0000002]#

 

以上のように、修復されたファイルの状態を確認することができました。

 

最後に、もう一度、アンマウント(マウントを解除)して、ハードディスクの状態チェックを実施しました。使用するコマンドは、

umount /dev/sdb1

xfs_repair -n /dev/sdb1

です。

 

[root@localhost ~]# umount /dev/sdb1

[root@localhost ~]# xfs_repair -n /dev/sdb1

Phase 1 - find and verify superblock...

- reporting progress in intervals of 15 minutes

Phase 2 - using internal log

- zero log...

- scan filesystem freespace and inode maps...

sb_fdblocks 52700857, counted 52709049

- 22:13:57: scanning filesystem freespace - 32 of 32 allocation groups done

- found root inode chunk

Phase 3 - for each AG...

- scan (but don't clear) agi unlinked lists...

- 22:13:57: scanning agi unlinked lists - 32 of 32 allocation groups done

- process known inodes and perform inode discovery...

- agno = 0

- agno = 15

--- (途中、省略) ---

- agno = 14

- 22:14:05: process known inodes and inode discovery - 1408 of 1408 inodes done

- process newly discovered inodes...

- 22:14:05: process newly discovered inodes - 32 of 32 allocation groups done

Phase 4 - check for duplicate blocks...

- setting up duplicate extent list...

- 22:14:05: setting up duplicate extent list - 32 of 32 allocation groups done

- check for inodes claiming duplicate blocks...

- agno = 0

- agno = 2

--- (途中、省略) ---

- agno = 31

- agno = 1

- 22:14:05: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done

No modify flag set, skipping phase 5

Phase 6 - check inode connectivity...

- traversing filesystem ...

- traversal finished ...

- moving disconnected inodes to lost+found ...

Phase 7 - verify link counts...

- 22:14:05: verify and correct link counts - 32 of 32 allocation groups done

No modify flag set, skipping filesystem flush and exiting.

[root@localhost ~]#

 

特に、問題はなさそうです。

 

この状態の外付けUSBハードディスク(USB-HDD)を液晶テレビ(東芝レグザREGZA)のUSB録画端子に接続して状態を確認したところ、再び録画・再生をすることができました。

 

6. まとめ

 

以上、テレビ録画用に接続した外付けUSBハードディスク(USB-HDD)の修復・復旧について
試みた方法と手順を簡単なメモ書きですが、紹介しました。

 

(ただし、必ずしもうまくいくとは限らないので、その点はご了解下さい。このような修復・復旧作業を実施される場合は、自己責任で実施されるようお願いします。)

 

------------------------------------------------------------------
References

[1] 液晶テレビに接続したUSBハードディスクの故障と対策 (2013/11/10)

[2] 「HDD認識しない」パソコンでレグザUSBハードディスクを復旧・修復 – レグザREGZA研究 (2014/09/28)
------------------------------------------------------------------

 

(2019-5-2)

 

 

 

あなたに、1時間に20通もの、しつこい迷惑メールが送られてきたら、そして、これらが携帯やスマホに着信していたら、あなたはどうされるでしょうか。

 

パソコンや携帯・スマホでご自分が意図しない迷惑メール、スパムメールを受け取ったという経験をお持ちの方も多いと思われます。

 

私はこれまでに何度も経験があります。
たいていの場合、無視していれば、そのうち止むものもありますが、そうではない場合もありました。

 

ひとつの事例をお話しますと、昨年の秋ごろに、このような迷惑メールの攻撃を受けました。

 

メール自体は長いタイトルと、本文には短い一文とURLが記載されているだけのものです。

しかし、そのメールの頻度はおよそ1時間に20通と常識的に考えても、異常なほどに多く、しつこいものでした。

また、メールの発信者のアドレスもそのたびごとに異なるものでした。

 

記載されているリンク先に関しては、あまり詳しくは触れませんが、海外に住所を有する出会い系サイトのひとつでした。

 

1時間に20通ほどのしつこい迷惑メールですが、もし、これを携帯やスマホで受信時に着信音が鳴るという設定にしていたら、着信する度に(およそ3分に一回)着信音が鳴るということになります。
もちろん、真夜中でも変わらず24時間着信し続けるのですから、人によっては気が狂ってしまうかもしれません。

 

 

どのようなタイトルかというと、

 

・ご注文ありがとうございます。

 

・確認していただけましたか？広川です。【５億】の受け取り許可は既に出ておりますので、【3000円】を追加されれば、いつでもお引き出しして頂けるようになっています。すぐにお引き出しして違反者解除を行なってください。罰金が発生する前にお受け取りされませんと

 

・救済支援会代表・広川美鈴です。私も、そしてこの救済金を寄付してくれた人も、貴方に報われてもらいたいと思っております。これまで、様々なサイトに登録してきたと思うのですが、支援履歴を見させていただき

 

・お急ぎ下さい。今日中には５億の一部でもいいのでお引き出し出来るようにしますからね。用意が出来ていれば今から

 

・広川です。【５億】は今日お引き出しして頂けますでしょうか？【3000円】の追加をされた後に引き出しが出来るようになっております。これを完了すれば違反の取り消しもされますからね。

 

・救済支援会代表・広川美鈴です。５億は既に入金しております。これであなたを違反者から救い出せますからね。救済金は貴方の為に本日、罰金の延期分の手数料も含めて対応をしておきました。私は受け取っていただく為のサポート役でしかありません。貴方が引き出し方が分からない場合であったり

 

・5億貰ってから私は車とマンションを買いました。自由に使ってくれていいって広川さんから言われてたんですけどなんだか本当に

 

・428万円の請求は本日24時まで延長されておりますのでお早めにご対応ください。救済金のお受け取りがされなかった場合、明日請求を開始させて頂きます。

 

・広川です。支援違反者になってしまった方１００名だけに連絡をさせて頂いております。３０００円の手続きだけで確実に受け取りできる人のみに連絡をしていますので

 

あるいは、

 

・「権利喪失」にご注意下さい。賠償金受給には期限が御座います。

 

・賠償金の受取りを辞退した場合についてご説明させて頂きます。大河内 真理子です。

 

・※本人以外、閲覧禁止※重要個人情報につき開封時注意して下さい。

 

・＝＝ATM残高確認依頼＝＝24時間以内に残高確認＋現金一部引き出しをお願いします。

 

・訴追弁護団代表：大河内 真理子です。賠償決定につき12億3000万円の受け渡しを行いますのでご確認下さい。

 

・〓最〓終〓案〓内〓※9名中_8名賠償金受取報告あり※

 

・民法415条・417条・709条によって損害賠償請求を行い勝訴しましたので至急、ご確認下さい。

 

・お知らせ：裁判に伴う重要連絡。弁護士からの連絡をお待ちください

・【寿】賠償金12億3000万円の受領、心からお祝い申し上げます。

 

このような場合、受信する側のメールアドレスを変更してしまうというのが、おそらくいちばん早い対処法なのですが、私の場合、このメルアド自体は普段使っているものなので、変更したくない、という気持ちもありました。そこで、メルアドを変更しないでなんとか解決できないか、と考えました。

 

ここでお伝えする内容は、あくまでも対処法の一例ですので、すべての場合に適用できるとは限りませんが、困っている方々になんらかの参考になればとおもい、記述するものです。

 

手順としては、まず、迷惑メールとおもわれるメール自体を、メールのヘッダー付きで保存しましょう。

 

そして、パソコンやスマホで、次のことを行なっていきます。

 

(1) Whois情報で迷惑メールの発信者のドメイン所有者・管理者を確認します。

(2) 非公開の場合は、ドメイン所有者の情報開示請求をします。

(3-1) 情報開示請求が承認された場合は、ドメイン所有者に配信停止依頼を行ないます。

(3-2) 情報開示請求が非承認の場合は、ドメインのレジストラ登録管理者に「ドメインの一時使用停止もしくは無効化」の要請をします。

 

この方法で、たいていのしつこい迷惑メールは止むとおもわれます。

 

もし、ここまでやってだめなら法的手段に訴えるしかありません。(やったことはありませんが、万が一の時のためにメールのコピーなどの証拠は残すようにしましょう。)

 

より詳しい手順の内容と実例は、

 

→　https://pc.fp46.net/pc01.html

 

に記載しました。必要な方はごらん下さい。

 

以上、なにかのご参考になれば幸いです。

 

(2019-1-27)