This is sort of an odd-ball question, but have any of you ever encountered a commercial program (heck, *any* kind of program) that uses fibers? I.e. ConvertThreadToFiber, SwitchToFiber, etc.

I have no practical reason for asking this; it's just a passing curiosity. I was thumbing through Windows Internals and came across these critters in their introduction to processes and threads. I've never seen any program make use of any of those APIs. The more I thought about it, the weirder the entire concept seemed. About the only case I could make for doing your own user-mode threading would be if you were doing a ton of thread switching and didn't want to generate a ton of context switches for performance reasons. But then, why use the fiber APIs? I haven't traced through them to see where they lead, but I'd be surprised if they didn't wind up generating a context switch from user to kernel, and back again. That can't be any better than suspending one thread, popping to kernel mode, and resuming another.

Anyway, I haven't seen exactly what happens to the flow of execution when you switch to a different fiber, but it seems like there might be an opportunity here for a protection system. I guess I'll have to write a program sometime to play around with these, but it seems like you might be able to use these to help obfuscate and mangle your code's execution.

Actually I partly take that back.

Going into kernel mode and back to user mode again would not be an actual context switch, per se, just a mode switch. I guess there's slightly less overhead since you aren't having to muck with additional process/thread environment blocks. So maybe using fibers instead of threads would be somewhat more efficient *if* you wrote a better thread manager than the built-in windows scheduler.

Two words: cooperative multitasking.

Commercial, no.
*any*, yes.

I have seen a couple of viruses which use fibers in an attempt to avoid AV engines (see 29A e-zines). Well, this simply compells AntiVirus to emulate a couple of APIs more.

Sorry for the following vague explanation, but it's a lot of time since i last checked fibers:

A fiber is like a piece of your thread's CPU time that you decide to spend on a particular task. Fibers are not scheduled by the OS. Instead, you decide when you want to run them, but this happens in a totally deterministic way. In other words, fibers do NOT run in parallel.

First, you need to inform windows that THIS thread, the current one, is going to be handled as the parent fiber. A "parent" fiber can create new child fibers and switch to them when it wants. Analogously, child fibers can create their own sub-fibers, etc. Declaring fibers reserves storage for saving the context.

Now, you can SWITCH to any of the child fibers. This is done by means of the API SwitchToFiber.

Let's move to what happens when you debug a fiber:

When you switch to a new fiber you can for example set a bpx at its entry point.Next, you debug until you return from the fiber (the fiber is just a procedure). However, and this is important, if you debug into kernel32.dll, when you return you will see that you simply restore the context and go back after the point where you called SwitchToFiber. More exactly, something looking like:

; last instructions at the fiber

xor eax, eax
ret

; this is in kernel32.dll

push ebp
mov ebp,esp
...
mov eax, [context.eax]
mov ebx, [context.ebx]
...
ret ; return to parent fiber


So, answering the question: are fibers good for anti-debug?. In my opinion not at all. Because they are just a shortcut to save / restore the context before to call a given procedure. They don't have much to be with multi-threading.

Hope the explanation is readable,
Havok.

[EDIT] historical note: if i recall, fibers were implemented in windows for compatibility with the *nix.