Microsoft Research Detours Package
oil
Our great sponsors
Microsoft Research Detours Package | oil | |
---|---|---|
17 | 234 | |
4,871 | 2,720 | |
2.1% | 1.6% | |
2.7 | 9.9 | |
30 days ago | 6 days ago | |
C++ | Python | |
MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Microsoft Research Detours Package
-
AMD's Anti-Lag feature is getting gamers banned from Counter-Strike 2
Nit: AFAIU there is no literal modification of machine code going on—instead the import address table (IAT, the Windows counterpart of Linux’s GOT) is patched (the Windows tradition calls this “detoured”, from the quite popular Microsoft hack[1] that does it).
[1] https://github.com/microsoft/Detours
-
Any sufficiently advanced uninstaller is indistinguishable from malware
You essentially replace a function with your own. The project is at https://github.com/microsoft/Detours.
I’ve created a PowerShell module that wraps this library to make it easier to hook functions on the fly for testing https://github.com/jborean93/PSDetour. For example I used it to capture TLS session data for decryption https://gist.github.com/jborean93/6c1f1b3130f2675f1618da5663... as well as create an strace like functionality for various Win32 APIs (still expanding as I find more use cases) https://github.com/jborean93/PSDetour-Hooks
-
#rescuerift
But the client is much different now, and most of that won't work anymore. The client is heavily obfuscated and you can't use a packet sniffer, the communications are encrypted, you CAN however use things like Microsoft Detours to peek at communications
-
Hooking 🪝
If you mean is there an API to perform hooking, then I think the answer is no. There are libraries for doing this, including the official MS one: https://github.com/microsoft/Detours
-
It looks like League of Legends' source code has leaked and is up for sale online
That's how things like steam or Nvidia overlays work, or fraps or OBS hook the output buffer; you can use official packages published by Microsoft for that, such as Detours.
-
Having too many (1,000+) Microsoft Edge tabs open can break File Explorer in Windows 10
Inject a DLL into the process. The DLL hooks two API functions, RoGetActivationFactory() and RoActivateInstance(), using Detours library. When a WinRT class ID is passed in, compare it with WindowsUdk.UI.Shell.WindowTabManager, and if equal, return an error code.
-
Is it possible to edit the XAML of the Win11 Taskbar?
3. Manual hooking (Not recommended): It's possible to use some hooking library like Microsoft Detours to hook the functions responsible for creating the UI layout. I highly unrecommend this method as it's the most method prone to be broken by any change Microsoft does.
-
Is there a tool that you can attach to a game EXE file directly and it ll show you incoming and outgoing traffic for only that file?
Reference: https://github.com/microsoft/Detours
- Debugging C with Cosmopolitan Libc
-
Using Landlock to Sandbox GNU Make
> With regards to chroot, I stand corrected. I knew it was a tree of symlinks, but I thought it was also more than that because symlinks alone don't seem like a sandbox. Honestly, Cosmopolitan's system appears to be more of a sandbox than that.
To be totally clear: the tree of symlinks thing is a fallback, used only when lacking platform support or when sandboxing is explicitly turned off [0]. On Linux, the normal sandboxing strategy is to use namespaces, like most container runtimes. On Mac it apparently uses sandbox-exec (some opaque Apple tool), as was mentioned above. Chroot, being both non-POSIX, requiring root access on many systems, and not providing the necessary facilities is not really a great fit -- which I assume is why it's not used.
There was experimental Windows sandbox support at one point [1] based on how MS does it for BuildXL (their own build tool for giant monorepos) [2]. Unfortunately it doesn't seem to be maintained, and under the hood it's kinda ugly -- it actively rewrites code in-memory to intercept calls to the Win32 APIs [3], which was apparently the cleanest/best way MS could come up with. However, from Bazel's POV it works in a roughly similar way -- you spawn subprocesses under a supervisor, which is in charge of spinning up whatever the target process is with restrictions on time/memory usage/file access.
On the "sandbox in the interpreter" thing: what kind of checks are you envisioning? It seems like putting checks at that level would end up leaving a lot out -- the goal of any build system is to eventually spawn an arbitrary process (Python, gcc, javac, some shell script, etc.) and so even with extensive checks in starlark you'd end up with accidental sandbox breaks all over the place. For pure starlark rules you could e.g. check that there are no inputs from /usr, but even then if gcc does it implicitly, you're SOL. Or am I thinking of the wrong kind of checks?
[0] https://bazel.build/docs/sandboxing#sandboxing-strategies
[1] https://github.com/bazelbuild/bazel/issues/5136#issuecomment...
[2] https://github.com/microsoft/BuildXL/blob/master/Documentati...
[3] https://github.com/microsoft/Detours/wiki
oil
-
Autoconf makes me think we stopped evolving too soon
will prevent almost all of the "silent footguns".
YSH has strict:all and then a bunch of NEW features.
There's been good feedback recently, which has led to many concrete changes. So your experience can definitely influence the language! https://github.com/oilshell/oil/wiki/Where-To-Send-Feedback
-
Basic Things
Regarding writing tools/tests/benchmarks in bash+Python, vs. writing tools in your main language:
I think we might eventually concede that something Debian-like is the “standard development environment” (at least for server side stuff, i.e. not iOS apps)
In this case, bash+Python is a non-issue. It works extremely reliably. That’s actually why I use it! Everything else seems to break, or it’s really slow (node.js is a very common alternative).
- Microsoft conceded this back in ~2017, by building Linux into their kernel with WSL, and providing Ubuntu on top
Yes bash + Python is a disaster on Windows (I have scars from it), but Microsoft agrees that the right place to solve that is in Windows :-)
- Every CI system runs Debian/Ubuntu
- Every hosting provider runs Debian/Ubuntu
- Every online dev env like gitpod.io provides Debian/Ubuntu
This is somewhat related to remote dev envs: https://lobste.rs/s/ucirlx/lapdev_self_hosted_remote_dev
One vision for https://www.oilshell.org/ is that the CI environment is the dev environment is the hosting environment.
Everything is just an equal node in a distributed system. BUT it’s more git like, in that you explicitly sync and work “locally”, wherever that is. You don’t have the network chatter and flakiness of “the cloud”.
Oils has a very large set of monotonically increasing properties too - https://www.oilshell.org/release/0.21.0/quality.html
All that is bash+Python that is run on every commit, and it’s extremely good at catching bugs and perf regressions.
I’m skeptical that any project has that level of quality automation written in pure Rust or Zig. More likely it’s a bunch of cloud services with YAML.
Also a bunch of “hard-coded” toolchains that you can’t script with bespoke code. Like some shell commands in your package.json, which is just a worse way of writing a shell script.
Our quality process is all self-hosted, in the repo, and runs on both Github Actions and sourcehut - https://www.oilshell.org/release/0.21.0/pub/metrics.wwz/line...
bash and Python runs perfectly on Github Actions and sourcehut, with zero change. Containers also do.
(Although we need to unify the CI and release, because the release runs on 2 different real hardware machines, while CI is cloud only.)
Also, a main point Oils is that bash now has another highly compatible, spec-driven implementation – OSH. Having 2 independent implementations is something newer languages don’t have.
(copy of lobste.rs comment)
-
The secret weapon of Bash power users
in your bashrc to enable it. I've used it for probably ~18 years now.
It also works with https://www.oilshell.org/ since we use GNU readline. Just 'set -o vi' in ~/.config/oils/oshrc
-
Pipexec – Handling pipe of commands like a single command
No other shell does that.
But I didn't know it was called MULTIOS until now. (I guess that's read "mult I/O's"? I have a hard time not reading it was multi-OS :) )
It seems a bit niche to be honest, but it's possible to support in Oils.
---
Oils also uses Unix domain sockets already for the headless shell protocol
https://github.com/oilshell/oil/wiki/Headless-Mode
We could do something like dgsh, but so far I haven't seen a lot of uptake / demand. Every time it's mentioned, somebody kinda wants it, and then it kinda peters out again ... still possible though.
I think flat files work fine for a lot of use cases, and once you add streaming, you also want monitoring, more control over backpressure/queue sizes, etc.
-
Show HN: Hancho – A simple and pleasant build system in ~500 lines of Python
which works well. You don't have to clean when rebuilding variants. IMO this is 100% essential for writing C++ these days. You need a bunch of test binaries, and all tests should be run with ASAN and UBSAN.
---
I wrote a mini-bazel on top of Ninja with these features:
https://www.oilshell.org/blog/2022/10/garbage-collector.html...
So it's ~1700 lines, but for that you get the build macros like asdl_library() generating C++ and Python (the same as proto_library(), a schema language that generates code)
And it also correctly finds dependencies of code generators. So if you change a .py file that is imported by another .py file that is used to generated a C++ header, everything will work. That was one of the trickier bits, with Ninja implicit dependencies.
I also use the Bazel-target syntax like //core/process
This build file example mixes low level Ninja n.rule() and n.build() with high level r.cc_library() and so forth. I find this layering really does make it scale better for bigger projects
https://github.com/oilshell/oil/blob/master/asdl/NINJA_subgr...
Some more description - https://lobste.rs/s/qnb7xt/ninja_is_enough_build_system#c_tu...
-
Re2c
This is sort of a category error...
re2c is a lexer generator, and YAML and Python are recursive/nested formats.
You can definitely use re2c to lex them, but it's not the whole solution.
I use it for everything possible in https://www.oilshell.org, and it's amazing. It really reduces the amount of fiddly C code you need to parse languages, and it drops in anywhere.
-
Ask HN: Looking for a project to volunteer on? (February 2024)
SEEKING VOLUNTEERS - https://www.oilshell.org/ - https://github.com/oilshell/oil/
I'm looking for people to help fill out the "standard library" for Oils/YSH. We're implementing a shell for Python and JavaScript programmers who avoid shell!
On the surface, this is writing some very simple functions in typed Python. But I've realized that the hardest parts are specifying, TESTING, and documenting what the functions do.
---
The most recent release announcement also asks for help - https://www.oilshell.org/blog/2024/01/release-0.19.0.html (long)
If you find all those details interesting (if maybe overwhelming), you might have a mind for language design, and could be a good person to help.
Surveying what Python and JavaScript do is very helpful, e.g. for the recent Str.replace() function, which is nontrivial (takes a regex or string, replacement template or string)
But there are also very simple methods to get started, like Dict.values() and List.indexOf(). Other people have already contributed code. Examples:
https://github.com/oilshell/oil/commit/58d847008427dba2e60fe...
https://github.com/oilshell/oil/commit/8f38ee36d01162593e935...
This can also be useful to tell if you'll have fun working on the project - https://github.com/oilshell/oil/wiki/Where-Contributors-Have...
More on #help-wanted on Zulip (requires login) - https://oilshell.zulipchat.com/#narrow/stream/417617-help-wa...
Please send a message on Github or Zulip! Or e-mail me andy at oilshell dot org.
-
The rust project has a burnout problem
This is true, but then the corrolary is that new PRs need to come with this higher and rigorous level of test coverage.
And then that becomes a bit of a barrier to contribution -- that's a harness
I often write entirely new test harnesses for features, e.g. for https://www.oilshell.org, many of them linked here . All of these run in the CI - https://www.oilshell.org/release/latest/quality.html
The good thing is that it definitely helps me accept PRs faster. Current contributors are good at this kind of exhaustive testing, but many PRs aren't
- Unix as IDE: Introduction (2012)
- Oils
What are some alternatives?
Mhook - A Windows API hooking library
nushell - A new type of shell
orbit - C/C++ Performance Profiler
fish-shell - The user-friendly command line shell.
pe-sieve - Scans a given process. Recognizes and dumps a variety of potentially malicious implants (replaced/injected PEs, shellcodes, hooks, in-memory patches).
elvish - Powerful scripting language & Versatile interactive shell
pmaudit - "Poor Man's Audit" (lightweight build-auditing script)
xonsh - :shell: Python-powered, cross-platform, Unix-gazing shell.
samurai - ninja-compatible build tool written in C
PowerShell - PowerShell for every system!
WidescreenFixesPack - Plugins to make or improve widescreen resolutions support in games, add more features and fix bugs.
ShellCheck - ShellCheck, a static analysis tool for shell scripts