Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please restore our registers when you’re done with them

randomascii.wordpress.com

Post reply on HN
Print view View original

111–120 of 142 posts

Re: Please restore our registers when you’re done with them

#111

Post by astrange »

matthews2 wrote: post #29
323 wrote: post #15

Sounds like there should be an option when you write assembly code to tell the compiler "please save/restore any register that I'm modifying in this asm code according to the target you are compiling for"

Maybe we need some kind of higher level language that gets boiled down into assembly.

C does have official intrinsics for SIMD on Intel platforms, but the people who are good at writing video codecs don't like to use them because Wintel culture has such bad taste at naming functions (thanks to Hungarian notation) that using them is near-unreadable and it's easier to write everything in asm.

Re: Please restore our registers when you’re done with them

#112

Post by AnimalMuppet »

ddingus wrote: post #108
AnimalMuppet wrote: post #72

Earlier quoted context omitted.

Depends on the instruction architecture. 68000 had some ways of burying a small literal operand in the instruction. If I recall correctly, MOVEQ.L would let you move zero to a register without touching memory (other than the instruction fetch), and it wasn't a long instruction.

Yes, that is true. However, moving a zero to a register does take time. Time that would otherwise be used operating with the zero value already present in the zero register. The second best is what moto did. As you point out, there is the instruction fetch, which could be the intended operation, rather than developing the zero itself. On par with that is having enough registers to just hold a zero, and whether that m…

But moving it from the zero register to another register would also take time. If what you want is a zero in a register other than the zero register (say, one that is going to serve as the index of a loop, which the zero register cannot do), then MOVEQ should not take any longer than a MOVE from the zero register to another register.

Re: Please restore our registers when you’re done with them

#113

Post by pajko »

JoshTriplett wrote: post #79
cpeterso wrote: post #51

Earlier quoted context omitted.

Yes. That's pretty common, unfortunately.

I'd love to see Chrome and Firefox and IE working together to detect this kind of thing and put up a malware warning explaining how to uninstall it, and see how quickly it can be eliminated. Seriously, there is zero valid reason to ever inject code into another program, other than as a debugging tool on a system being debugged.

What about AutoHotkey, reWASD, ConEmu, JoyToKey?

Re: Please restore our registers when you’re done with them

#114

Post by JoshTriplett »

ZGDUwpqEWpUZ wrote: post #103
Retric wrote: post #81

Earlier quoted context omitted.

There might be a few more. Invasive Anti cheat software seems necessary for competitive multiplayer games on PC.

DLL injection is also used for in-game overlays by Steam/Discord/etc, and I'm not aware of a better method they could use instead given that they're expected to work for games that were never made with those services in mind.

GL/Vulkan extensions for drawing overlays over the current frame. Compositor/Windows extensions for drawing overlays, the way Android has. You don't need to be running inside the current process to draw on the screen.

Re: Please restore our registers when you’re done with them

#115

Post by JoshTriplett »

pajko wrote: post #113
JoshTriplett wrote: post #79

Earlier quoted context omitted.

I'd love to see Chrome and Firefox and IE working together to detect this kind of thing and put up a malware warning explaining how to uninstall it, and see how quickly it can be eliminated. Seriously, there is zero valid reason to ever inject code into another program, other than as a debugging tool on a system being debugged.

What about AutoHotkey, reWASD, ConEmu, JoyToKey?

Injecting keyboard events does not require running inside the current process. Either emulate a keyboard device or inject events via the APIs for that.

Re: Please restore our registers when you’re done with them

#116

Post by Cloudef »

ZGDUwpqEWpUZ wrote: post #103
Retric wrote: post #81

Earlier quoted context omitted.

There might be a few more. Invasive Anti cheat software seems necessary for competitive multiplayer games on PC.

DLL injection is also used for in-game overlays by Steam/Discord/etc, and I'm not aware of a better method they could use instead given that they're expected to work for games that were never made with those services in mind.

They use wayland compositor (gamescope) under linux (even under X11), in their new SteamOS UI and it's already working a lot better. Plus they can do other awesome stuff with it like completely having control of where and how the game outputs its buffer. So it can fix games with bad multi-monitor behaviour, force game to render in their native aspect ratio / resolution etc... it's just great and makes gaming experience feel more like a console where things (usually) just work.

Gamescope + mangohud + steam overlay working together is very big part of SteamOS and Steam Deck's success, and it does zero runtime modification or hooking into the child process. I can imagine all the trouble you run with the hooking eventually and all the hacks it must have piled up.

Re: Please restore our registers when you’re done with them

#117

Post by saagarjha »

brucedawson wrote: post #16
mkj wrote: post #5

It seems that the chrome developers should be able to perform the same binary analysis on the suspect Mcafee software. I guess it's a bit harder without source code to reference side-by-side though.

That would be possible, but we'd have to install the software, then guess which binary was the culprit, and then have some way of finding the function boundaries. My crude analysis technique required on having symbols for chrome.dll to indicate where functions started, so I'd have to have switched tools to something else that could find those.

Most disassemblers are fairly decent at guessing function boundaries if the code isn't too bad.

Re: Please restore our registers when you’re done with them

#118

Post by account42 »

Cloudef wrote: post #116
ZGDUwpqEWpUZ wrote: post #103

Earlier quoted context omitted.

DLL injection is also used for in-game overlays by Steam/Discord/etc, and I'm not aware of a better method they could use instead given that they're expected to work for games that were never made with those services in mind.

They use wayland compositor (gamescope) under linux (even under X11), in their new SteamOS UI and it's already working a lot better. Plus they can do other awesome stuff with it like completely having control of where and how the game outputs its buffer. So it can fix games with bad multi-monitor behaviour, force game to render in their native aspect ratio / resolution etc... it's just great and makes gaming experien…

They use gamescope under SteamOS, not Linux in general where you already have another compositor. Running all games under a nested compositor (gamescope) would have some perf impact (even if a small one) as well as an unexpected cursor acceleration profile.

Re: Please restore our registers when you’re done with them

#119

Post by account42 »

JoshTriplett wrote: post #114
ZGDUwpqEWpUZ wrote: post #103

Earlier quoted context omitted.

DLL injection is also used for in-game overlays by Steam/Discord/etc, and I'm not aware of a better method they could use instead given that they're expected to work for games that were never made with those services in mind.

GL/Vulkan extensions for drawing overlays over the current frame. Compositor/Windows extensions for drawing overlays, the way Android has. You don't need to be running inside the current process to draw on the screen.

For the Steam overlay they also need to intercept input (while the overlay is open).

Re: Please restore our registers when you’re done with them

#120

Post by Cloudef »

account42 wrote: post #118
Cloudef wrote: post #116

Earlier quoted context omitted.

They use wayland compositor (gamescope) under linux (even under X11), in their new SteamOS UI and it's already working a lot better. Plus they can do other awesome stuff with it like completely having control of where and how the game outputs its buffer. So it can fix games with bad multi-monitor behaviour, force game to render in their native aspect ratio / resolution etc... it's just great and makes gaming experien…

They use gamescope under SteamOS, not Linux in general where you already have another compositor. Running all games under a nested compositor (gamescope) would have some perf impact (even if a small one) as well as an unexpected cursor acceleration profile.

True. I personally have setup my distro to launch directly into gamescope optionally for SteamOS like experience. On desktop client they still either hook or use vulkan layer (latter often in proton, thanks to dxvk). However I would not be surprised if they started using nested compositor even on desktop.
Post reply on HN