「パス指定してLoadLibraryすれば、DLLプリロード攻撃は避けられる」、という認識は間違いで、WinAPI等を呼ぶだけでDLLプリロード攻撃が成功するパターンがありますよ、という話を書きました。
Windows開発されている方は、ご一読して頂くと良いかもしれません。
Chrome拡張用Twitter自動画像拡大フィルタをFirefoxアドオン化しました。
下記のURLからどうぞ。(なお、mozillaの公式サイトでの配布は、現在審査中)
https://ipmsg.org/tools/tw_filter.html>
ただ、chrome拡張と違い、オプション画面が出ません。(chrome拡張とはもろもろ違うらしい…)
Chrome拡張用Twitter自動画像拡大フィルタを作ってみました。
twitterの(クリック時の)縦画像は縮小されすぎと思う方にどうぞ。(ついでにプロモーション表示削減も)
Chromeウェブストア内: Twitter自動画像拡大フィルタ
追記(2016/11/29): 比較サンプル画像などを追加してみる。
Win10では、TrayNotifyでのバルーン表示がToastAPI(WinRT)によるトーストに(シェル内で)自動変換される。
それはいいのだが変換が不十分で、IPMsgではあちこちアラが見えてしまう。
具体的には メッセージ通知/挙動も互換性のない変化をして少し困ったのだが、一番困ったのが表示中トーストをプログラム的に消去出来なくなった点。(唯一、TrayNotifyでトレイアイコンを消去すると消えるのだが…)
特に、
1.新たな着信や開封時、表示中トースト(があれば)消去&直ちに新しいトーストを表示したいが、後続トーストはキューイングされる。
2.(トーストクリック以外に)トレイアイコンのクリックでもトーストを即座に消したいが、TrayNotifyではトーストは消えてくれない。
あたりで、やむを得ずv4.0以降ではToast用APIを直接操作でToast表示&消去を行うことに(*1)。
さてそのための専用DLLを作りtoastAPI(WinRT/COM)を使うことで、トーストオブジェクトを直接操作が可能となり、自由に表示/消去ができるようになった…のだが、Win10 Anniv.の一部環境で「トースト表示で固まります」という報告が届くように。
詳細ログが取れるバージョンを使ってもらいログを解析すると、IToastNotifier::Hide()の21回目の呼び出しから、毎回綺麗/正確に120秒固まるようになっていた。
少し調べると、MSDNでも同様の報告があり、Win10 Anniv.側の問題であることはほぼ間違いなさそうだが、誰も回答を付けていない状態。
手元で発生しないので、IPMsg掲示板に報告して頂いた方に何度も実験して頂いて感謝だったのだが、おおよそ判ったことは、
STAアパート用のCOMの同期機構で固まっている可能性あり。(自前環境ではないのためあくまで挙動からの推測)
マルチスレッド化&COM MTA利用で、1トースト毎に1スレッド&関連ファクトリ&トースト生成する以外に回避は難しそう。
(ただしマルチスレッド+STAは試していないので、試す価値はあるかも)
MTAの場合、OS/API側が内部で作ったと思われるスレッド(≠トースト作成したユーザ側スレッド)がコールバックを呼んでくるので、それに配慮する必要あり。
といった点で、これらに対処してマルチスレッド&MTA化することで一応解決した様子。
ともあれMSさん、こういう(TrayNotify->Toastのような)不完全なエミュレーションで強制移行させたり、使わせたいはずのToastAPIもupdateでデグレしたまま放置なのはご勘弁(笑)
(*1) Toast用APIはWinRT/COMであり、Win7以前では使えないだけでなく、さらにビルドのターゲットバージョンの問題から、Win7以前でも動かすためには IPMsg本体のターゲットはXP用とした上で、トースト操作専用dllをこしらえ、そちらだけWin8以降用としてWinRT対応させる形にせざるを得なかったのだが、この部分は何らかの hack で1ビルド対応可能かも。何かご存じの方がいましたらご連絡下さい。
Categories
Android |
CeSleep |
comp_misc |
comp_tips |
fastcopy |
ipmsg |
mailman |
misc |
npop |
ScheEdit |
sigsleep |
tdiary |
thinkpad