rbmm

Location: Odessa, Ukraine

Remote: yes

Timezone: Flexible [UTC-7, UTC+3]

Willing to relocate: no

Technologies: windows low level development, windows internals, win32/NT api, debugging, research, DLLs, Processes, and Threads, IPC, asynchronous I/O, tokens, SD, crypto api, certificats, authentication( credential providers, authentication packages, etc), tpm, WDM, hooking, ..own debugger and tools, some PKI-based windows logon solutions

Resume/CV:

https://stackoverflow.com/users/6401656/rbmm ( https://stackoverflow.com/tags/winapi/topusers - #8 All Time )

https://github.com/rbmm

https://www.youtube.com/@alexshort1643/videos

Email:[email protected]

I don’t know. But how do you explain the fact that this remains almost unknown, even though this system behavior has existed for years? For instance, try asking ChatGPT or Gemini about this —the AI don’t know, which is quite telling.

Sorry for the off-topic post, but since you're from Cisco... is there someone I could speak with regarding the Senior Software Engineer - Windows (Duo) position (ID 2023286: https://careers.cisco.com/global/en/job/2023286/Senior-Softw...)?

I am a low-level Windows developer with extensive knowledge of Windows internals, Win32/NT APIs, debugging, research, etc., and—most importantly—expertise in the Windows logon area, credential providers, and related technologies.

I’m simply looking for a job—nothing more. I posted updates on LinkedIn solely to draw attention to myself, hoping to turn that into a position; writing articles for their own sake doesn't really interest me. In reality, though, it hasn't helped at all. I’m trying to reach out only regarding roles where I possess—in my view—extensive knowledge and experience in the key area. It feels impossible to land these roles without an inside contact, which is why I asked about Duo Security. Then again, to be honest, even that usually doesn't help—but I try to seize even a hypothetical chance.

Location: Odessa, Ukraine

Remote: yes

Willing to relocate: no

Technologies: windows low level development, windows internals, win32/NT api, debugging, research, DLLs, Processes, and Threads, IPC, asynchronous I/O, tokens, SD, crypto api, certificats, authentication( credential providers, authentication packages, etc), tpm, WDM, hooking, ..own debugger and tools, some PKI-based windows logon solutions

Resume/CV:

https://stackoverflow.com/users/6401656/rbmm ( https://stackoverflow.com/tags/winapi/topusers - #8 All Time )

https://github.com/rbmm

https://www.youtube.com/@alexshort1643/videos

Email:[email protected]

Everyone has their own strengths and weaknesses. I’m a developer. I’m good at writing and debugging code. But writing articles isn't my thing—even on my native language, not say already on English (despite the language itself isn't the main issue here). I used to post technical posts on LinkedIn. Not in the style of The Old New Thing, but just about things that were somewhat interesting and not widely known. The posts weren't high-quality, but they did earn me over 2,300 followers there. However, a year ago, LinkedIn deleted my account. So, all of that is gone forever (I didn't back it up anywhere else, and I don't have a personal website). That means my claim about the LinkedIn posts can't be verified anymore. I’ve written a few article-like pieces on my GitHub—for example, https://github.com/rbmm/tbal (or https://github.com/rbmm/StateMachineState). They were nothing special—not top-tier quality. A few years ago, I collaborated with someone, and we wrote some articles together for his site (I provided the technical info, and he did the writing): https://dennisbabkin.com/blog/author/?a=rbmm (We haven't worked together for several years now). To me, it’s nothing remarkable. In any case, my main "creative output" was on LinkedIn. It never even crossed my mind that the platform could delete everything. When your account gets flagged as "restricted," it doesn't just switch to read-only mode where you lose access; it means a total wipe—everything gets deleted: all public posts, all conversations (including the ones with other people). For instance, I wrote about my framework for writing shellcode in C++ simply and efficiently using native code—okay, I think it’s the best implementation of its kind available publicly. I used to write about various other utilities and research projects of mine, amusing PoCs, and little-known techniques. At least there’s still Stack Overflow with its objective reputation (rating) system—though, in reality, it doesn't bring me anything, and the topic I primarily answered questions on (WinAPI) is pretty much dead these days. That leaves GitHub (obviously, I don't make all my projects public) and the occasional YouTube video.

Thanks for the comments.

I watched a few videos—maybe that’s because it’s a very niche topic, and you personally aren't involved in this specific field. Actually, my question had two parts. The first was general—less of a specific question and more of a general observation. I believe the current selection process is deeply flawed for both sides. It’s particularly bad for unconventional candidates (though that’s always been the case). The search for a résumé—which has to follow a specific format rather than just any style—has become an end in itself, even though it’s merely a tool, not the actual goal. And now, it seems like tons of people are using AI to write "perfect" résumés and heavily embellish their knowledge and experience. (Personally, I don't get the point of lying; if they believe you and hire you, that kind of lie—about your actual capabilities—will be exposed immediately. What do you gain in the end other than disgrace?) This breaks the process even further.

The second part was strictly personal. I’m wondering if there’s any way to get in touch with the team handling this position—bypassing the standard process. I say this because I genuinely possess unique knowledge and experience in the key required areas (low-level Windows development, credential providers, debugging all of that) and had some public proof of this—like my Stack Overflow ranking, for instance, which—unlike a résumé—can't be faked (and can look up "rbmm windows"). but, I can't even apply for the position or make myself known. So, I was asking if anyone happens to know people there (despite slim the extremally low, i nothing have to lost).

Thanks for the whoishiring link. My expertise is in a very narrow, specialized field. There are incredibly few job openings that actually suit me (I don't just "apply" (not in direct sense) for everything; I only target roles where I truly have specialized knowledge and experience). There are literally only a handful of them. However, it has now become absolutely impossible to reach them (following the loss of LinkedIn)—though I suspect there are very few people with deep expertise in such fields too.

For the specific position I mentioned, I don't think there are thousands—or even dozens—of truly good candidates. I’ve outlined my reasons based on general factors (such as my Stack Overflow rating) and specific expertise in the field of credential providers—for instance, I am the only one who has published a list of interfaces like this one: https://github.com/rbmm/StateMachineState/blob/main/ni.h. There are even YouTube examples demonstrating the use of some of those elements (https://www.youtube.com/watch?v=5SpEfFGE5N8), along with many other things directly relevant to the role. If I were just one of dozens of candidates, I wouldn't be asking this question (I wouldn't have the standing to do so).

the question isn't how to find a job opening, but rather how to effectively apply for one (assuming you have the relevant knowledge and experience).

yes. after any thread request exclusive access to lock, the sequential shared acquire request will block. this iswell known fact, i hope. this is example when shared request will be blocked, despite shared owner(s) now inside lock

also look my 2 comments on reddit: https://www.reddit.com/r/cpp/comments/1b55686/comment/ktfhjs... and https://www.reddit.com/r/cpp/comments/1b55686/comment/ktfggu...

if say true - i here in very strange position. i am by self under debugger research exacly what happens in concrete case and create repro code. i think that implementation of the RtlReleaseSRWLockExclusive is not the best and may be really containing "bug" as i in more details describe in comment on reddit. but from another side, if you want pure formal c++ rules - can you explain - in what exactly was bug in concre case ? what rule/guarantee is violated ? why demo code decide that ALL shared waiters can at once acquire the lock. formal documentation not state this. this intuitive must be true, because no exclusive request more. but.. i really dont know. and i also for fun create own implementation of SRW lock ( if someone interested to look -https://github.com/rbmm/PushLock ) which free from this roblem - i always ( hope) do only single atomic change to lock state during api call. and finally - sorry for my english and too long answer

of course - SRW lock allow shared access only if no waiters ( request to exclusive access) on lock. so even if lock in shared mode, new shared request can block, if was waiter(exclusive) already. in case OP no exactly this, but anyway - i be say that shared access is only hint to system, that it can optimize access - and allow multiple shared threads inside lock. but this was not always

"other threads can share-acquire the same lock without waiting." can but not always and mandatory. you really allow to system enter another shared requestor. but only allow,not demand. system not let shared requestor enter to lock, if before it the exclusive request will be. after first exclusive request - all next shared request will block, util this exclusive request not acquire and then release lock. can be and some another reason, in the end - this is only optimization - you only *allow* multiple shared enter at once. so i be not say that this is implementation bug

what is shared mode ? this is by fact optimization for speed, if we need read-only access to data, we allow to system let another thread into the section that requests shared access also

allow but NOT DEMAND this. If one thread has acquired the shared lock , other thread can acquire the shared lock too. but only CAN. in some case system not let another thread enter to lock, despite it also request share access. one case: if another rthread request exclusive acess - he begin wait and after this - any thread which acquire even shared access to lock - also begin wait

If lock_shared is called by a thread that already owns the mutex in any mode (exclusive or shared), the behavior is undefined.

and

Shared mode SRW locks should not be acquired recursively as this can lead to deadlocks when combined with exclusive acquisition.

why is this ? because if between 2 calls to lock_shared ( AcquireSRWLockShared ) another thread call AcquireSRWLockExclusive - the second call is block.

the code in example make assumption that ALL threads can enter to lock at once. that if one thread enter to lock in shared mode, another thread also ALWAYS can enter to lock in shared mode (if no exclusive requests). but i not view clear formalization of such requirement. and we must not based on this.

i be will add next rule:

thread inside lock must not wait on another thread to enter this lock

this is obvivius for exlusive access, but not obvivous to shared. but must be cleare stated along with the recursive rule ( should not be acquired recursively as this can lead to deadlocks, even in shared mode)

yes, this is i (that "rbmm"), #opentowork

https://github.com/rbmm/SRW-2 - possible better repro code . where i guarantee repro this without hundreds loops. i be say that "question" in RtlReleaseSRWLockExclusive implementation. it first remove Lock bit from SRW (and after this any thread can enter to lock) and then call RtlpWakeSRWLock. but this 2 operations not atomic. if in the middle (after Lock Bit removed and before RtlpWakeSRWLock executed) another thread acquire shared access - it got exclusive. and RtlpWakeSRWLock also "fail" after this - not wake any waiters. but when shared/exlusive owner then release lock..RtlpWakeSRWLock will be called again and self job. i be of course use bit another implementation, link to which i paste in another comment here

several years ago i do own implementation of SRW/PushLocks - of course based on original NeillC code.. https://github.com/rbmm/SRW_ALT/tree/main/PushLock-ALT

they have slightly worse performance compared to MS, when high contention, but in test with this OP case - work well. in my test i not found bugs in implementation, but of course can not be sure that they not exist, very complex logic really. nobody test this, however very simply replace SRW calls to my implementation, by macros in h file