Yabu.log

ITなどの雑記

Jesse Donat氏のCsvToMarkdownTableを日本語(全角文字)対応させたい

以前も紹介しましたが、csvからmarkdownの表を作るツールがあります

https://donatstudios.com/CsvToMarkdownTable

ただしこのツールは文字数をjavascriptのlengthで数えているため 全角・半角関係なく1文字で数えてしまうため、作成した表のplane textがずれてしまいます。

| 番号 | 
|----| 
| 1  | 
| 2  | 
| 3  | 

本当はこうなるべき*1

| 番号 | 
|----  | 
| 1    | 
| 2    | 
| 3    | 

一行目□■■■■□ ←二文字だが全角文字なので表示は4文字分の扱い
二行目□■□□□□ ←半角文字一字分のあとは三文字埋めのスペースが入るべき

markdownのコンセプト、plane text状態でも読みやすい、に反してしまうので、 なんとか日本語でもplane textの状態で表の形を保たせたいのですが。

maxRowLen[ii] = Math.max(maxRowLen[ii], ee.length);

ここのlengthの箇所を半角全角の表示スペースに応じた処理に変えれば動きそう。 だが、少し調べて分かったがjavascriptは半角・全角に応じて文字数を返す処理が標準で存在しないらしいので、半角全角を判定する方法を自分で考えて実装する必要がある。

まぁプロポーショナルフォントを使っている環境ではこんなことやっても意味ないんだけどね。

追記:sublime textの拡張機能でできるらしい。後日検証予定

*1:固定幅フォントじゃないからわかりにくいけど許して。。。

早速webツールっぽいものを作ってみた

昨日日記で書いた

自分も作ってみたいものが2,3ある。 日頃よくやってる置換とかはwebツール化して公開するのも良いかもしれない。

yuyubu.hatenablog.com

のことですが、早速作ってみた。

https://yuyabu.github.io/OrderByWithCaseExpressionGenerator/

github.com

元ネタは以前Qiitaに上げたこれ。

qiita.com

ひとまずはhelloworld的なものを作るつもりだったが、勢いで30分ほどで作ってしまった。 インデントすらされてないし、画面レイアウトの設計に全くカロリーを割いてていないため、使いにくいことこの上ないが、 ひとまず公開してみる。

他人がサービスをつくったとかアプリを作ったみたいな記事を見るたびに憧れるが、 自分が作ると細かいところに時間を使いすぎて、公開はおろか、完成までもたどり着かない。

今だと、TDDで作らなきゃとかCIもやらないとね。とか思って重い腰が更に重くなってしまうため、 ひとまず公開までにこぎつけるまでにカロリーが最小になるように決めて作業をした。 変数名とか全部適当だし、綴のチェックもしていない。 またjavascriptはほとんど書いたことがないため、わからないところは基本googleだよりで作っている。*1

レイアウトやリファクタリングは明日以降ちょっとずつやっていこうと思います。

日記を書いてて思ったけど、order by 対象のカラムがchar型だったら動かないな。。。。

PS. 適当なエディタがなかったので4年前に使い方を忘れたvimで書いた。 保存、終了やdd、pくらいしか覚えていない ビジュアルモードとかいうのがあったような・・・うーん思い出せない。

追記: ひとまず常にシングルクォーテーションで囲むことでchar型に対応した。 oracleの場合、charとnumber型を比較しようとするとchar型の方にtonumber()を適応するので、 この改修でnumber型の場合も一応使える。

ウソです(ヨ(* ´∀`)E)

case式では暗黙の型変換が発動しないようです。

単純CASE式では、exprおよびすべてのcomparison_expr値は、同じデータ型(CHAR、VARCHAR2、NCHAR、NVARCHAR2、NUMBER、BINARY_FLOATまたはBINARY_DOUBLE)であるか、またはすべて数値データ型である必要があります。

CASE式

はぁ.今日も会社あるのに徹夜でなにやってんだろう。

*1:専門のひとからすれば酷いコードになってしまっているとおもう。

お気に入りの小道具紹介(Webツール)

google翻訳みたいにテキストウィンドウが2つあって [変換]的なアクションのあるボタンがついているサイトで気に入っているものを紹介。

sqlフォーマッター

www-atl.blog.so-net.ne.jp

辞書や設計書から正規表現悪用活用してグッチャグチャのSQL作った挙句、 インデントが出来ないので困っていた。 こちらのツールでお手軽に整形できる。感謝。

EXCEL表テキスト化ツール

www-atl3.blog.so-net.ne.jp

一つ上と同じ作者様のツール。 tsvを上手く表に表現してくれるメールクライアントとかあるけど プレーンなテキストが必要とされるところでどうしても表が欲しい時に便利。 何?プロポーショナルフォント?知らんな。

CSV→INSERT文変換

CSV→INSERT文変換

ちょっとしたEXCELに残したバックアップとかからinsert文を生成できて便利。 まぁ最初はsakura editorで数回の置換で作っていたが、どうせ作っている人がいるだろうと思い 検索したら見つかった。感謝。

CSV→<table>変換

CSV→<table>変換

一つ上と同じ作者様のツール。 これで煩わしいtableタグともおさらば。 何?素敵なtableタグでデコレーションされたhtmlを読め?知らんな。

CSV To Markdown Table Generator

CSV to Markdown Table Generator — Donat Studios

Jesse Donat氏のツール。感謝。 この方のように、よく使うちょっとした小道具はさくっと作ってgithubで公開できるとカッコイイ。 私もやりたいが、javascriptは普段書かないから重い腰がなかなか上がらない。

difff

difff《デュフフ》

diffが入ってない貧弱な環境でかつ大人の事情でソフトを入れるのが面倒な時に重宝。感謝。 このツールのみサーバー側にpostをしているので気になる方は非推奨。 画面から受け取った文章のdiff結果を返しているだけでは?と思うかもしれませんが、 表示する際に結構凝ったことをされている。

ポートチェック

www.cman.jp

自分のグローバルIPとポートを指定することでパケットが通るかどうか確認することができる。

Exif確認くん

exif-check.org

ネットにアップロードされた画像からExif情報が確認できるツール。 うっかりSNSにアップロードした画像に自宅の位置情報が入ってて住所特定されるとか無いように確認しましょう。*1

最後に

自分も作ってみたいものが2,3ある。 日頃よくやってる置換とかはwebツール化して公開するのも良いかもしれない。

PS.ブログタイトルを変えました。また変えるかも。

*1:昔はこういうのよく聞いたけど最近聞きませんね。

iPhoneによるアクセスポイントの脆弱性の警告?

久々に帰省して、自宅のWifiに接続してみたところ、iPhoneの設定画面が警告的なものを出してきた

安全性の低いセキュリティWPAは安全性が低いとされています。WPA2パーソナル(AES)セキュリティをこのネットワークに使用するようにルーターを構成してください。

ちょっと気になったので調べてみた。

そもそもWPAとは?

過去に無線LANがそもそも利用していたWEP(Wired Equivalent Privacy)に脆弱性が発覚したため、代替として用意されたのがWAP(Wi-Fi Protected Access)というセキュリティプロトコル

WPAが利用しているTKIPが脆弱

TKIP(Temporal Key Integrity Protocol)はWPAで利用可能な暗号プロトコル。 WEPの代替として2002年に華やかにデビューした暗号プロトコルだが、2008年に攻撃方法が論文で発表されて6年の短い生涯に幕を閉じた。

TKIPの代替としてCCMP(Counter mode with Cipher-block chaining Message authentication code Protocol)*1というAESベースの暗号プロトコルを使う手もある。

対策:でどうすんの?

  • WPAのままCCMPを使う
  • WPA2を使う

私の実家では複数チャンネルの通信に対応しているらしく、その一つがセキュリティに問題があるWPAとのことだったので、 ひとまず、WPAを使っているチャンネルを止めることにした。

ちなみに:iPhoneで利用可能な無線LAN認証プロトコル

以下の5種である。

WEPは危険危険、といろいろなところで聞くのに、まだ使えるようになっているのが不思議。つーかWPA2もサポート切れよ。。。と思ったがそんな簡単な問題でもないんだろうか。セキュリティリスクが発覚したものなんか、どんどん使えなくすればいいとおもうんだけど、警告出しつつ使えるようにしているのが不思議。そういうもんなの?

*1:正式名称長過ぎ。暗号化ブロック連鎖を伴うカウンタモードメッセージ認証コードプロトコルってなんだよ

LINEのパケットを見てみた

以下の方法でLINEのパケットを調べてみた。

  • 起動後何もせず1分ほど待つ
    • (起動時などはネットワーク制御系のパケットやら、アップデートやらの邪魔なパケットが飛び交いまくるので暫く待つ)
  • WireSharkで使用中のネットワークインターフェースを指定する。
  • すぐにLINEを立ち上げる(やることは3種類)
    • 普通のメッセージを送る
    • カスタムスタンプを送る
    • 送り先で既読をつける(既読の戻りパケットが欲しい)

f:id:yuyubu:20170814001029p:plain

  • WireSharkを止め、TCPのアクセスのあるIPからLINEっぽいものをピックアップ

LINEっぽいホストをピックアップ

  • 13.32.194.153 Amazon EC2(LINEのCDN)*1
  • 203.104.142.52 LINE
  • 203.104.150.2 LINE
  • 23.45.140.69 アカマイ(LINEのCDN)

一番上は違うかも ちなみに、色分けルールもIP別に作成して解析しやすくした。 f:id:yuyubu:20170814013340p:plain

フィルタを使って通信を調べる

まずは全てのIPが含まれるフィルタ

ip.addr == 13.32.194.153 || ip.addr == 203.104.142.52 || ip.addr == 203.104.150.2 ||ip.addr ==23.45.140.69

通信の流れとしては

  • No1: 最初に23.45.140.69と一回きりの通信(後は音沙汰なし)
  • No2: 203.104.142.52と203.104.150.2を織り交ぜてチャットを実現?
  • No3: 通信の後半に13.32.194.153から大きなデータを一方的に送りつけられている

という内容。(3の終了後に2のパケットのやり取りが何度かあった)*2

23.45.140.69 アカマイ

最初に通信をしていたのがこのホスト。

TLSを使って何かを送信している

f:id:yuyubu:20170814004830p:plain

最後の行がEncrypted Alertと表示されているが、下記サイトによると、

d.hatena.ne.jp

セッションの途中やキャッシュが残っている状態でキャプチャを開始して、前述の共通鍵が入手できず通信の中身が分からないときです。さて、SSLでは通信切断時はAlertプロコトルのClose Notifyで通知します。つまりタネあかしをすると、先ほどの謎のAlertは、単なるClose Notifyのパケットです。

とのことですが、それだと自分のキャプチャ結果のClose Notifyのパケットはサーバー側から出ているように思える。(Close Notifyはサーバー側、クライアント側どちらが出しても問題ないのかな?)

通信内容としては、一通りTLSのやり取りを行った後、ホスト・クライアント双方で400バイトくらいのデータを交換している。

個人的に思った感想としては明らかにアプリケーションが送付するデータよりTLSの制御パケットの方が圧倒的に多いこと。

TLSはまだ勉強不足なのでこのへんで・・・ ※またこれ以後のサーバーも全てTLSを使っていますが、TLSに関する説明は略します。

このサーバーとの通信は、最初にちょろっとTLS経由でデータ交換をした後、音沙汰なしのため最初に必要なアクションであるログイン認証をこのサーバーを使ってやっていると予測してみる

203.104.142.52

アカマイCDNとの通信が終わった後は、LINEのサーバーとの通信が始まる。 こちらは 203.104.150.2より先に通信が始まっている。 多分これはメッセージを送付する前に送られてきた情報、つまりLINEのアプリの状態自体(受信メッセージなどはあるか)などの情報を取りに行っている処理ではないだろうか?

203.104.150.2

こちらは203.104.142.52より後に通信が始まる。 また一部接続済みのコネクションで203.104.142.52から始まるパケットのまとまりもあるので(これは既読確認のパケット?)これはメッセージのためのサーバーなのではないか?

13.32.194.153 (LIneのCDN)

13.32.194.153側からこちらのクライアント側はTLSTCPのメッセージしか送っていないが、 サーバー側から大量のパケットを受信している。 これは多分スタンプの画像データのダウンロードじゃないかな?と邪推してみる。

まとめ

完全に妄想の域を出ないけど、大体、以下のような動きになっているのではないか。

  • 13.32.194.153 Amazon(LINEのCDN)はスタンプ配布のために利用
  • 203.104.142.52 (LINEサーバー)はメッセージ送受信のために利用
  • 203.104.150.2 (LINEサーバ)はアプリケーションの情報更新のために利用
  • 23.45.140.69 アカマイ(LINEのCDN)はユーザーログインの認証のために利用

課題

やってる途中に思ったが、以下のことを試せばよかったと後悔。

  • 通知
  • 相手側からのメッセージの受信

多分もうやらないとおもうけど・・・*3

今日の収穫

  • TLSのパケットを初めてちゃんとみた。
  • Wiresharkのフィルタを覚えた
  • 色設定のやり方を覚えた(これはかなり強力だと思う)

*1:アマゾンもCDN事業やってたのか。知らなかった

*2:これは既読確認のパケットなのかな?

*3:過去史上最大に?が多いいい加減な記事になってしまった。。。

久々にパケットキャプチャをやってみた

初めてパケットキャプチャをしたのは大学2年の時で、ソケット通信のプログラムを作る課題が出た時、 自主課題としてパケットの解析結果的なのを載せるためにやった気がする。

その時はtcpdumpを使ったけど、今回はwiresharkを使う。

初日の成果でも書いてみる。

アカマイすげー

やはり前とやった時と同じく、何もやってない状態でもアカマイ、アマゾン、アップルとの通信は頻繁にやってる。

アップルはアカマイの顧客だけど、アップル以外っぽいエッジサーバーとも通信しているパケットも何度か見かけた。(LINEもアカマイを使っているというのを何処かで見た覚えがある)

TCPのハンドシェイクの確認ができた

TCPの開始・終了時のハンドシェィクは確認できた。 ちょっと意外だったのが、終了時のFIN,ACKパケットをクライアント側からではなく、サーバー側から投げられたこと。

HTMLのリクエストのための接続でしたが、サーバー側が一通りデータを送り終わった後、 「もう終わったから接続切りますね〜」的な切断をサーバー側から始めたのだろうか?通常解説書などでは、常にクライアント側からFIN,ACKパケットを送るような図になっていると思うのだが。。。

まだこの辺は知識が薄いので何が起こっているか不明。

動画サイトはUDP通信を利用していない?

  • youtube
  • youtube live
  • ニコニコ
  • twitch などとのパケットをキャプチャしてみたが、 UDPは使われていなかった。

動画サイトとの通信は基本UDPでやっていると思っていたのでちょっと驚き。 ネットで調べてみたら、パケットキャプチャ初心者が通る通過儀礼的なものらしいw (このことに関する質問などが山のように見つかる。)

stackoverflow.com

stackoverflow.com

teratail.com

ちなみに手元のアプリケーションでUDPが確認できたのはFaceTime(ビデオチャット)のみでした。

流れる情報が多すぎる。

リアルタイムのパケットを眺めているとオメーはツイッターの人気タグかよ。ってくらいの勢いでパケットが流れる。 まぁTCPのハンドシェィクだけで7回もパケット流れるわけですし。 プロトコルTCPだけでなく多種多様なものが流れている。(NBNS,SSDP,DBなんとかは初見)

またIPv6の通信が結構行われている。ただしHTMLとの通信は確認できる範囲では全てipv4だった。 確かipv6でHTTP通信をするには、クライアント側にしかるべき設定をしてからipv6ように用意されたサイトにアクセスする必要があったような気がする。

ipv6を使ったhttp通信のキャプチャも今後挑戦してみたい。

まぁわからないことだらけだけど、初日はこんなもん、ということで。

便利なサイト一覧

キャプチャ中に頼りになったサイトでも貼っておく

MACアドレスのベンダーアドレスを調べる

mac.uic.jp

基数変換

2進数、8進数、10進数、16進数相互変換ツール

今後の課題

  • 送付データの詳細の確認
  • Window制御
  • ipv6のHTTP通信
  • フィルタを工夫してLINE等特定アプリケーションのキャプチャ
  • バカハブどプロミスキャスモードを利用した他ディバイスへのパケットのキャプチャ

最近は資格対策本も電子書籍

ネットワークスペシャリストの参考書を買った。

ネスペの基礎力 ?プラス20点の午後対策

ネスペの基礎力 ?プラス20点の午後対策

驚くべきは、電子書籍として出版されているだけでなく、きちんとリフロー版になっていること。 部数の少なさそうな雑誌などは、明らかに自炊をしたような跡がある状態で電子書籍として売っているが、 リフロー版で売っている点に驚いた。

PDFやスキャナーで取り込んだ形式の本が多いが、Amazonや出版社にはリフロー版の出版を頑張って欲しい。