[RARE AND HARD TO REPRODUCE] Byondhook can generate NEGATIVE Computer IDs about byondhook HOT 23 CLOSED

If I have to guess, the crashes may be from some form of function byond calls when updating windows/tabs, especially prompts (as for some reason starting/finishing any form of input prompt has a far higher chance to crash you).

Unsure why this is happening now but it may be due to serverside byond changes.

from byondhook.

I remember this happening on the first versions of ByondHook, I'm not very "robust" with BYOND code so the way I was checking for changes to my CID was checking my computer_id variable from a local goonstation fork, I assumed this was normal behaviour.
The number set on the config file is NOT supposed to be your computer ID result - it is the ID of the storage volume used to produce the computer id after a set of calculations.

How do you check for your computer id?
By multiple instances of BH, what do you mean? Connected multiple times on the same server? Or a different server? With the same ckey? Or you mean the multiple windows "bug"? What version of BH are you running, did you compile the latest one from 12 days ago or are you using the release build?

from byondhook.

For some reason this only occurs in VERY specific circumstances (such as multiple instances of byondhook + dreamdaemon launching), but I've seen byondhook generate and spoof itself to use negative computer ID values, despite the set one being different.

If I had to guess, it's something involving the 'multibyond' tab issue.

Also it seems crashes are getting more common despite being on the exact same version of byond, possible attempt at a security fix server-side?

Said crashes have essentially zero pattern and instantly close-out the game.

Random crashes are most likely solely because of how poorly coded BYONDHook is
Serversided computer_id being negative should be impossible because it's unsigned iirc
HDD serial is a DWORD so I dunno how you're getting negative values in any scenario

Multiple BYOND windows open because dreamseeker opens a new process for each winset:// and then never terminates them for some reason (LOL)

from byondhook.

For some reason this only occurs in VERY specific circumstances (such as multiple instances of byondhook + dreamdaemon launching), but I've seen byondhook generate and spoof itself to use negative computer ID values, despite the set one being different.
If I had to guess, it's something involving the 'multibyond' tab issue.
Also it seems crashes are getting more common despite being on the exact same version of byond, possible attempt at a security fix server-side?
Said crashes have essentially zero pattern and instantly close-out the game.

Random crashes are most likely solely because of how poorly coded BYONDHook is Serversided computer_id being negative should be impossible because it's unsigned iirc HDD serial is a DWORD so I dunno how you're getting negative values in any scenario

Multiple BYOND windows open because dreamseeker opens a new process for each winset:// and then never terminates them for some reason (LOL)

ONCE AGAIN, if you have any improvement feel free to submit a pull request but I doubt we'll need that as I haven't ran in a single crash for the past month.
Plus your only public repo is a roblox mumble plugin which you didn't even write yourself

from byondhook.

ONCE AGAIN, if you have any improvement feel free to submit a pull request but I doubt we'll need that as I haven't ran in a single crash for the past month. Plus your only public repo is a roblox mumble plugin which you didn't even write yourself

unfortunately my non-shitcode non UC pasted byond cheat is private repository.. you cannot have it..
i wrote the mumble plugin what the fuck do you mean lol that's an ancient project from when I started learning C++

i am not going to make a pull request rewriting your entire shit codebase

from byondhook.

ONCE AGAIN, if you have any improvement feel free to submit a pull request but I doubt we'll need that as I haven't ran in a single crash for the past month. Plus your only public repo is a roblox mumble plugin which you didn't even write yourself

unfortunately my non-shitcode non UC pasted byond cheat is private.. you cannot have it.. i wrote the mumble plugin what the fuck do you mean lol that's an ancient project from when I started learning C++

where in UC did I paste this from considering I'm the one who posted it over UC
I've been a staff member and resigned from UC half a decade before you signed up

"dang dude you didn't make a separate header for ur hooks? shit code..... copy pasta funny code"

from byondhook.

grandpa uses inline assembly in every call

from byondhook.

grandpa uses inline assembly in every call

After you understand it's purpose, feel free to push a pull request with your workaround

from byondhook.

grandpa retrieves edx from assembly despite it being in parameters

from byondhook.

grandpa hooks a function and then gets a parameter from a calling function with inline asm

from byondhook.

grandpa puts padding in sigscanning pattern

from byondhook.

grandpa sigscans for exported functions

from byondhook.

oh god awful and terrible coding practices which totally impact performance and execution, how about you read the code better and learn about the ternary operator before making clueless assumptions

from byondhook.

grandpa uses createthread instead of beginthread

from byondhook.

grandpa uses createthread instead of beginthread

call beginthread and analyze the stack, it will call CreateThread. I'm done answering, you're a certified retard

from byondhook.

grandpa uses createthread instead of beginthread

call beginthread and analyze the stack, it will call CreateThread. I'm done answering, you're a certified retard

yes but this is like saying "i use write instead of printf because printf calls write anyways". it's a low level api you're not meant to call it unless you're not linking to the stdlib

from byondhook.

grandpa uses createthread instead of beginthread

call beginthread and analyze the stack, it will call CreateThread. I'm done answering, you're a certified retard

yes but this is like saying "i use write instead of printf because printf calls write anyways". it's a low level api you're not meant to call it unless you're not linking to the stdlib

cant care less about two butt buddies such as mennui and rshoe having a mental breakdown over the fact someone finally released something useful for BYOND.

you are talking shit about my code but you are doing the same exact thing in calamari/seraph etc.
imagine hooking every export of wsock32 and stuffing inline assembly in every function

too bad the "sigscanning for exported functions" im doing (which is a ternary operator fallback if GetProcAddress fails) actually keep ByondHook working no matter what update is released, instead of ur shitty hack that broke down a couple hundreds versions ago.

from byondhook.

grandpa uses createthread instead of beginthread

call beginthread and analyze the stack, it will call CreateThread. I'm done answering, you're a certified retard

yes but this is like saying "i use write instead of printf because printf calls write anyways". it's a low level api you're not meant to call it unless you're not linking to the stdlib

cant care less about two butt buddies such as mennui and rshoe having a mental breakdown over the fact someone finally released something useful for BYOND.

you are talking shit about my code but you are doing the same exact thing in calamari/seraph etc. imagine hooking every export of wsock32 and stuffing inline assembly in every function

too bad the "sigscanning for exported functions" im doing (which is a ternary operator fallback if GetProcAddress fails) actually keep ByondHook working no matter what update is released, instead of ur shitty hack that broke down a couple hundreds versions ago.

gramps... calamari is ancient, i didn't write seraph, and your "hack" (you mean cheat) doesn't do anything aside spoof when you have full paste available. your sig scanning has fucking padding in it and will break the moment the compiler rearranges functions

from byondhook.

grandpa uses createthread instead of beginthread

call beginthread and analyze the stack, it will call CreateThread. I'm done answering, you're a certified retard

yes but this is like saying "i use write instead of printf because printf calls write anyways". it's a low level api you're not meant to call it unless you're not linking to the stdlib

cant care less about two butt buddies such as mennui and rshoe having a mental breakdown over the fact someone finally released something useful for BYOND.
you are talking shit about my code but you are doing the same exact thing in calamari/seraph etc. imagine hooking every export of wsock32 and stuffing inline assembly in every function
too bad the "sigscanning for exported functions" im doing (which is a ternary operator fallback if GetProcAddress fails) actually keep ByondHook working no matter what update is released, instead of ur shitty hack that broke down a couple hundreds versions ago.

gramps... calamari is ancient, i didn't write seraph, and your "hack" (you mean cheat) doesn't do anything aside spoof when you have full paste available. your sig scanning has fucking padding in it and will break the moment the compiler rearranges functions

grandpa hooking seventy-fucking-four (or should i say soixante plus fucking quatorze?) wsock32 functions when you could just hook two kernelbase functions and get the same job done.

dont know which obscure open-source compiler you're using but MSBuild compiles fine and sigscanning has been tested and reported working, idk what you're on about

from byondhook.

too bad the "sigscanning for exported functions" im doing (which is a ternary operator fallback if GetProcAddress fails) actually keep ByondHook working no matter what update is released, instead of ur shitty hack that broke down a couple hundreds versions ago.

grandpa... top secret info... no exported function signatures that byondhook uses have changed in literally any 514 version.. so you don't need to do the stupid sigscanning shit

grandpa hooking seventy-fucking-four (or should i say soixante plus fucking quatorze?) wsock32 functions when you could just hook two kernelbase functions and get the same job done.

gramps is still on about a 5 year old cheat no one uses anymore?? why is he speaking french?? i think grandpa has alzheimers

from byondhook.

dont know which obscure open-source compiler you're using but MSBuild compiles fine and sigscanning has been tested and reported working, idk what you're on about

I am talking about when Lummox changes a function in BYONDCore which changes the padding and has a knock on effect, and because you sigged padding for some reason your sig is weaker than a twig

from byondhook.

grandpa... top secret info... BYONDHook used to retrieve exported functions by ordinals rather than by mangled export name, ordinals did change and every addition on top of that (switching to mangled names and sigscanning fallback) was to try to make BYONDhook as lasting as possible.

your code is trash, you're saying i'm copy pasting but you're just slapping kierohook on top of a 20 years old game, adding VMProtect (LOL????) and using it to encrypt strings LMAO this isn't 2005 anymore you're making a cheat for BYOND not counter strike source, good job virtualizing all your functions then injecting a DLL onto a process which on runtime will break the very same container you've created and leak pockets of live code onto memory.

All those virtualizations and your cheat is still literally the only one detected by BYOND

VMP_BEGIN("Calamari::Hooks::Byond32");
    /*if (a3 == 32)
    {
        int* a = (int*)a2;
        *a = 1864845531;
        printf("overriding\n");
        return 1864845531;
    }*/

top quality code. I'm closing because I'm done talking to french people with funny voices, if the author still has a problem with negative computer IDs (which I believe is normal behaviour) he can reopen the issue or email me, other people can go back to making very funny videos on youtube kaka breakthrough ahaha im troller on 1990s game...

from byondhook.

vmprotect was so mso couldn't crack it open lol

from byondhook.