冷知识:Windows XP SP0 可以使用 ExitWindowsEx API 关机但不断电。SP1 改为了只要硬件支持就会断电。
经过搜索得知,Win11 中仍然保留了这个画面,可以在组策略中开启。
经过搜索得知,Win11 中仍然保留了这个画面,可以在组策略中开启。
看到有人在问有没有 Windows 下的 Notch Simulator,于是想到了 Windows 下窗口置顶的问题。
传统的 WS_EX_TOPMOST 还是会被别的 top most 窗口挡住,而且像任务管理器,开始菜单还是能在其之上。
曾经个人调查过背后的原因,是从 Win8 开始引入了 Window Band 的功能,任务管理器或开始菜单把它们自己设置到了更高层次的 Band 上,于是能比 top most 更 top。具体可见这篇文章。
其中一种显示在上层的方法是使用 UIAccess,但是这要求应用程序有签名,且还要放到 Program Files 文件夹中。于是我就想到了上述文章提到的方法。
其中一种方法是使用 CreateWindowInBand,这个函数会检查进程的签名,所以实际实现只能注入DLL进去,在目标进程里面创建窗口。
还有一种方法是 SetWindowBand,不过文章作者的说法是需要注入 explorer,hook SetWindowBand,然后打开开始菜单,会触发 hook SetWindowBand 的函数,此时才可以成功调用 SetWindowBand,还说不知道内部的工作流程。
于是我开始逆向,发现 twinui.pcshell.dll 在调用 SetWindowBand 之前都会调用 EnableIAMAccess,去掉 EnableIAMAccess 后 SetWindowBand 就失败了。EnableIAMAccess 需要传递一个 key 进去,而这个 key 是在之前调用 AcquireIAMKey 获取的,于是尝试注入进 explorer 调用 AcquireIAMKey,发现失败了。
因为 AcquireIAMKey 是直接调用 NtUserAcquireIAMKey system call,百思不得其解之下,我尝试逆向 win32kfull.sys,看看内部的实现逻辑,发现限制了只能获取一次,而且这个 key 是在调用 SetShellWindowEx 的时候才会生成。
也就是说,explorer 启动时先调用了 SetShellWindowEx,然后 twinui.pcshell.dll 调用 AcquireIAMKey 获取到 key,后续就没人能再获取了。而 SetShellWindowEx 在当前 shell 进程还在运行时是不能再次调用的。
所以说要实现随意调用 SetWindowBand,只能结束当前的 explorer 进程,启动新的 explorer 进程并注入 DLL,hook NtUserAcquireIAMKey 获取到 key。
传统的 WS_EX_TOPMOST 还是会被别的 top most 窗口挡住,而且像任务管理器,开始菜单还是能在其之上。
曾经个人调查过背后的原因,是从 Win8 开始引入了 Window Band 的功能,任务管理器或开始菜单把它们自己设置到了更高层次的 Band 上,于是能比 top most 更 top。具体可见这篇文章。
其中一种显示在上层的方法是使用 UIAccess,但是这要求应用程序有签名,且还要放到 Program Files 文件夹中。于是我就想到了上述文章提到的方法。
其中一种方法是使用 CreateWindowInBand,这个函数会检查进程的签名,所以实际实现只能注入DLL进去,在目标进程里面创建窗口。
还有一种方法是 SetWindowBand,不过文章作者的说法是需要注入 explorer,hook SetWindowBand,然后打开开始菜单,会触发 hook SetWindowBand 的函数,此时才可以成功调用 SetWindowBand,还说不知道内部的工作流程。
于是我开始逆向,发现 twinui.pcshell.dll 在调用 SetWindowBand 之前都会调用 EnableIAMAccess,去掉 EnableIAMAccess 后 SetWindowBand 就失败了。EnableIAMAccess 需要传递一个 key 进去,而这个 key 是在之前调用 AcquireIAMKey 获取的,于是尝试注入进 explorer 调用 AcquireIAMKey,发现失败了。
因为 AcquireIAMKey 是直接调用 NtUserAcquireIAMKey system call,百思不得其解之下,我尝试逆向 win32kfull.sys,看看内部的实现逻辑,发现限制了只能获取一次,而且这个 key 是在调用 SetShellWindowEx 的时候才会生成。
也就是说,explorer 启动时先调用了 SetShellWindowEx,然后 twinui.pcshell.dll 调用 AcquireIAMKey 获取到 key,后续就没人能再获取了。而 SetShellWindowEx 在当前 shell 进程还在运行时是不能再次调用的。
所以说要实现随意调用 SetWindowBand,只能结束当前的 explorer 进程,启动新的 explorer 进程并注入 DLL,hook NtUserAcquireIAMKey 获取到 key。
GitHub
GitHub - megabitsenmzq/Notch-Simulator: Pretend you have the latest MacBook Pro!
Pretend you have the latest MacBook Pro! Contribute to megabitsenmzq/Notch-Simulator development by creating an account on GitHub.
Forwarded from 乌鸦观察
#AudioPlaybackConnector with Win11 style 已验证可行。
比较可惜的是连接窗口因为用了系统提供的DevicePicker,在 Win11 中还是 Win10 的风格,所以要完全实现 Win11 风格的话就得自己实现设备选择界面了。
比较可惜的是连接窗口因为用了系统提供的DevicePicker,在 Win11 中还是 Win10 的风格,所以要完全实现 Win11 风格的话就得自己实现设备选择界面了。
SingleExeXamlIsland 已发布。该项目演示了如何实现单 exe 文件调用 XAML Island 及 WinUI 2,详情请看 README。
GitHub
GitHub - ysc3839/SingleExeXamlIsland
Contribute to ysc3839/SingleExeXamlIsland development by creating an account on GitHub.
今天把msys2的shell换成了zsh,安装了Oh My Zsh以及zsh-autosuggestions和zsh-syntax-highlighting这两个插件,主题使用的是powerlevel10k
个人不推荐使用其他主题,因为其他主题读取git信息时是启动新进程获取的,在Windows下很慢。而powerlevel10k是在后台运行gitstatusd进程,速度极快!而且powerlevel10k还有异步加载插件的功能,可以缩短启动到可输入命令的时间。
这套配置在Windows下速度也是挺快的,感觉上比我多年前 (也许现在变快了?但我不用了) 用的Oh My Posh还要快。
个人不推荐使用其他主题,因为其他主题读取git信息时是启动新进程获取的,在Windows下很慢。而powerlevel10k是在后台运行gitstatusd进程,速度极快!而且powerlevel10k还有异步加载插件的功能,可以缩短启动到可输入命令的时间。
这套配置在Windows下速度也是挺快的,感觉上比我多年前 (也许现在变快了?但我不用了) 用的Oh My Posh还要快。
GitHub
GitHub - ohmyzsh/ohmyzsh: 🙃 A delightful community-driven (with 2,500+ contributors) framework for managing your zsh configuration.…
🙃 A delightful community-driven (with 2,500+ contributors) framework for managing your zsh configuration. Includes 300+ optional plugins (rails, git, macOS, hub, docker, homebrew, node, php, pyth...
YSC 的频道
今天把msys2的shell换成了zsh,安装了Oh My Zsh以及zsh-autosuggestions和zsh-syntax-highlighting这两个插件,主题使用的是powerlevel10k 个人不推荐使用其他主题,因为其他主题读取git信息时是启动新进程获取的,在Windows下很慢。而powerlevel10k是在后台运行gitstatusd进程,速度极快!而且powerlevel10k还有异步加载插件的功能,可以缩短启动到可输入命令的时间。 这套配置在Windows下速度也是挺快的,感觉上比我多年前…
顺带一提,刚刚简单试了下最新的Oh My Posh,感觉变快了很多,喜欢PowerShell的朋友也可以试试。
start-ssh-pageant.sh
567 B
刚刚写了个msys2启动ssh-pageant的脚本,主要是因为两个问题:
一是ConEmu会等待当前控制台下所有进程退出了才关闭标签页。因此直接启动的话,在退出shell时因为ssh-pageant没有退出,标签页就不会关闭,只有脱离当前控制台才能实现真正的后台运行。
二是ssh-pageant在sock file存在时会尝试连接,如果此时进程不存在了就要等几秒超时,通过脚本提前检测PID对应的进程是否存在可以缓解此问题。(不能100%解决,因为PID可能被复用了)
使用方法:在
一是ConEmu会等待当前控制台下所有进程退出了才关闭标签页。因此直接启动的话,在退出shell时因为ssh-pageant没有退出,标签页就不会关闭,只有脱离当前控制台才能实现真正的后台运行。
二是ssh-pageant在sock file存在时会尝试连接,如果此时进程不存在了就要等几秒超时,通过脚本提前检测PID对应的进程是否存在可以缓解此问题。(不能100%解决,因为PID可能被复用了)
使用方法:在
~/.bashrc (Bash) 或 ~/.zshrc (Zsh) 中加入 source /path/to/start-ssh-pageant.sh (/path/to为start-ssh-pageant.sh所在位置)在试用了一下Windows Terminal之后,我打算扔掉ConEmu了。
后者在配合msys2/wsl使用时问题很多。按照ConEmu官方推荐的做法,msys2/wsl应该使用其提供的connector,但是使用connector并连接ssh时会出现终端尺寸锁死在80x24(打开nano之类的程序,终端右半部分是黑的,只有左上角80x24有显示东西),滚动条buffer不可用(输出的东西超过屏幕buffer就被截断了,滚动条一直不变长),不支持24bit color,以及性能很差(执行curl --help all等一次性输出很长文本的情况,可以明显地看到它在那滚呀滚,Windows Terminal是瞬间显示完)。
如果不使用connector,情况反而有好转(不过估计是Windows10的控制台有改进,Win7下可能还是得用connector),除了不支持24bit、性能差的问题还在,其他问题都没了,但是在使用tmux等支持鼠标控制的程序时,鼠标进行操作就会卡死。
不过Windows Terminal还是缺少一些细节功能,比如在msys2中粘贴本地路径时自动转换成Unix风格。
后者在配合msys2/wsl使用时问题很多。按照ConEmu官方推荐的做法,msys2/wsl应该使用其提供的connector,但是使用connector并连接ssh时会出现终端尺寸锁死在80x24(打开nano之类的程序,终端右半部分是黑的,只有左上角80x24有显示东西),滚动条buffer不可用(输出的东西超过屏幕buffer就被截断了,滚动条一直不变长),不支持24bit color,以及性能很差(执行curl --help all等一次性输出很长文本的情况,可以明显地看到它在那滚呀滚,Windows Terminal是瞬间显示完)。
如果不使用connector,情况反而有好转(不过估计是Windows10的控制台有改进,Win7下可能还是得用connector),除了不支持24bit、性能差的问题还在,其他问题都没了,但是在使用tmux等支持鼠标控制的程序时,鼠标进行操作就会卡死。
不过Windows Terminal还是缺少一些细节功能,比如在msys2中粘贴本地路径时自动转换成Unix风格。
YSC 的频道
在试用了一下Windows Terminal之后,我打算扔掉ConEmu了。 后者在配合msys2/wsl使用时问题很多。按照ConEmu官方推荐的做法,msys2/wsl应该使用其提供的connector,但是使用connector并连接ssh时会出现终端尺寸锁死在80x24(打开nano之类的程序,终端右半部分是黑的,只有左上角80x24有显示东西),滚动条buffer不可用(输出的东西超过屏幕buffer就被截断了,滚动条一直不变长),不支持24bit color,以及性能很差(执行curl --help…
才夸了没多久,最近又遇到bug了,连接ssh后,按Ctrl+C会停掉ssh进程,而不是传递给目标机器。去搜索了下,似乎除了mintty,其他终端都是走Console Host的,就会遇到许多问题。现在还是先用着mintty吧……
小米平板5底下会显示全面屏手势提示线,然后设置里没有开关关闭。按照网上的方法,可以跟小爱同学说“全面屏”打开另一个全面屏设置页面,然后就有“隐藏手势提示线”的开关了。
然而重启后又会显示出手势提示线,经过测试发现“隐藏手势提示线”开关控制的是 global settings 下的
我的解决方法是加一个 Magisk script,等待 boot completed 然后
具体代码如下:
没有 Magisk 的用户,可以考虑用 Tasker 等工具,开机时修改一下
然而重启后又会显示出手势提示线,经过测试发现“隐藏手势提示线”开关控制的是 global settings 下的
hide_gesture_line,进一步反编译发现系统桌面会在启动时检查一下设备是不是平板,是的话会把 hide_gesture_line 设置成0。我的解决方法是加一个 Magisk script,等待 boot completed 然后
settings put global hide_gesture_line 1 。具体代码如下:
#!/system/bin/sh可以做成模块,也可以直接放到
{
until [[ "$(getprop sys.boot_completed)" == "1" ]]; do
sleep 1
done
settings put global hide_gesture_line 1
}&
/data/adb/service.d,记得加上执行权限。没有 Magisk 的用户,可以考虑用 Tasker 等工具,开机时修改一下
hide_gesture_line。Node.js的QUIC支持有了新的动静
https://github.com/nodejs/node/pull/44325
https://github.com/nodejs/node/pull/44325
GitHub
src: quic by jasnell · Pull Request #44325 · nodejs/node
Updated alternatiive to #38233 ...
Significant changes here. This focuses entirely on the internal API surface and does not expose any public API yet. That is intentional to allow us to work throug...
Significant changes here. This focuses entirely on the internal API surface and does not expose any public API yet. That is intentional to allow us to work throug...
之前搬家了,昨天把联通宽带迁移了过来,又被强制花钱买了个新光猫(联通不给在我有光猫的情况下不买然后减钱),光猫是华为的HG8120C。
光猫背面写着用户名密码是root和admin,但是通过网页登录进去缺少很多选项。按照网上的方法用telnet备份配置文件后得知超级管理员用户名和密码是telecomadmin和admintelecom,也是挺搞笑的。
telnet里的shell是假的,搜索了一圈居然发现有获得root shell的方法!整个过程很精彩,推荐阅读:
https://blog.leexiaolan.tk/pwn-huawei-hg8120c-ont-via-uart-part-1.html
光猫背面写着用户名密码是root和admin,但是通过网页登录进去缺少很多选项。按照网上的方法用telnet备份配置文件后得知超级管理员用户名和密码是telecomadmin和admintelecom,也是挺搞笑的。
telnet里的shell是假的,搜索了一圈居然发现有获得root shell的方法!整个过程很精彩,推荐阅读:
https://blog.leexiaolan.tk/pwn-huawei-hg8120c-ont-via-uart-part-1.html
因为有透明代理的需求,但又不想折腾路由器全局代理,于是调查了一下 sniproxy (C语言实现的那个) 的方案。sniproxy 本身不支持走 SOCKS 代理,需要套一层 proxychains,然后由于 sniproxy 是用 UDP 解析域名,proxychains 又不支持 UDP 代理,于是再加上 https-dns-proxy 走代理使用 DoH 解析 DNS。最终方案是基于Alpine Linux,可以运行在 Docker 或 WSL1 中。WSL2 未测试,建议使用 WSL1,因为可以和主机共享网络。
GitHub 地址 https://github.com/ysc3839/sniproxy-socks
Docker Hub 地址 https://hub.docker.com/r/ysc3839/sniproxy-socks
在 WSL 中使用,需要手动下载 releases 中的 sniproxy-socks-rootfs.tar.gz,然后在 cmd 中执行:
然后执行
启动后在文件管理器中打开
执行
执行
后续会考虑写个脚本自动下载并安装到 WSL 中。(已取消)
要登录时自动运行,可以运行
GitHub 地址 https://github.com/ysc3839/sniproxy-socks
Docker Hub 地址 https://hub.docker.com/r/ysc3839/sniproxy-socks
在 WSL 中使用,需要手动下载 releases 中的 sniproxy-socks-rootfs.tar.gz,然后在 cmd 中执行:
mkdir %localappdata%\wsl\sniproxy-socks其中
wsl --import sniproxy-socks %localappdata%\wsl\sniproxy-socks sniproxy-socks-rootfs.tar.gz
sniproxy-socks 是 WSL 的 distro name (或者叫容器名更加贴切),%localappdata%\wsl\sniproxy-socks 是安装位置,这两个选项都可以随意设置。然后执行
wsl -d sniproxy-socks /entrypoint.sh 会自动在后台运行。启动后在文件管理器中打开
\\wsl$\sniproxy-socks 可修改配置文件。执行
wsl -t sniproxy-socks 停止运行。执行
wsl --unregister sniproxy-socks 卸载。要登录时自动运行,可以运行
shell:startup 打开“启动”文件夹,新建 start-sniproxy.jse 并写入:new ActiveXObject('WScript.Shell').Run('wsl -d sniproxy-socks /entrypoint.sh',0)GitHub
GitHub - dlundquist/sniproxy: Proxies incoming HTTP and TLS connections based on the hostname contained in the initial request…
Proxies incoming HTTP and TLS connections based on the hostname contained in the initial request of the TCP session. - dlundquist/sniproxy
YSC 的频道
因为有透明代理的需求,但又不想折腾路由器全局代理,于是调查了一下 sniproxy (C语言实现的那个) 的方案。sniproxy 本身不支持走 SOCKS 代理,需要套一层 proxychains,然后由于 sniproxy 是用 UDP 解析域名,proxychains 又不支持 UDP 代理,于是再加上 https-dns-proxy 走代理使用 DoH 解析 DNS。最终方案是基于Alpine Linux,可以运行在 Docker 或 WSL1 中。WSL2 未测试,建议使用 WSL1,因为可以和主机共享网络。…
朋友推荐了一个 Golang 实现的 sniproxy,直接支持 SOCKS,就不需要这么麻烦了,也能原生支持 Windows。
https://github.com/NiceLabs/go-sniproxy
我的项目在补全剩下的脚本及说明后可能就不继续维护了,就当多一个选择吧。
https://github.com/NiceLabs/go-sniproxy
我的项目在补全剩下的脚本及说明后可能就不继续维护了,就当多一个选择吧。
GitHub
GitHub - NiceLabs/go-sniproxy: Proxies incoming HTTP and TLS connections based on the hostname contained in the initial request…
Proxies incoming HTTP and TLS connections based on the hostname contained in the initial request of the TCP session. - NiceLabs/go-sniproxy
YSC 的频道
因为有透明代理的需求,但又不想折腾路由器全局代理,于是调查了一下 sniproxy (C语言实现的那个) 的方案。sniproxy 本身不支持走 SOCKS 代理,需要套一层 proxychains,然后由于 sniproxy 是用 UDP 解析域名,proxychains 又不支持 UDP 代理,于是再加上 https-dns-proxy 走代理使用 DoH 解析 DNS。最终方案是基于Alpine Linux,可以运行在 Docker 或 WSL1 中。WSL2 未测试,建议使用 WSL1,因为可以和主机共享网络。…
GitHub
Release v2 · ysc3839/sniproxy-socks
Contribute to ysc3839/sniproxy-socks development by creating an account on GitHub.