there's always going to be a way to reverse enginere files, nothing you can do to stop that, but you can make it hella difficult, don't know the good ways to do it though.

how to extract and make it dificault

think whatever you want: one of my frends extracted some game sounds, I'd like to know how is it, how to stop people to do it

At least I am not the only one thinking along these lines. I have reservations about giving answers, not that I even know how but still.

at7, I want to know how to stop people

true enough, like making an antivirus, you would have to have made viruses first.

If you're using BGT, it is very easy for someone with a hex editor to separate the baked pack file from the executable, and as far as I know, you can do absolutely nothing to prevent this. It is also very easy for anyone who has or can write a pack extracter script to extract the contents of the pack file once separated, and again, there's nothing you can do about this.

This only gets you part way there, though. Assuming the sounds are encrypted, you need to decrypt them. BGT's encryption functions have shown themselves time and time again to be easy to break with a debugger and/or other methods, which cracks your encrypted sounds wide open, no matter what key you use. I do not know how to crack BGT encryption, and even if I did I would not post details here, so please don't ask me how to do it. As far as I know, there's nothing you can do about this, short of possibly writing all sorts of custom functions unique to your game.

The short answer is, if you want true security, don't use BGT! Use a mainstream programming language like Python, etc. Better yet, write custom functions unique to your game for handling decryption, etc. That way it will be harder to crack, and cracking your security wide open won't help crack anyone else's security wide open.

Bottom line: There is absolutely no way to insure that absolutely nobody in the world will ever crack your security. If the program has the ability to play your sounds, which it must in order for the game to work properly, then it necessarily has the ability to decrypt those sounds, and since it does, there is always the possibility that someone will be able to figure out how it's done and crack it, and there is absolutely nothing anyone can do about this.

Well, imagine you encrypt sound assets files. You load them when your program starts. Then, if you have to decrypt that encrypted data every time you want to play a sound, then it's gonna take time and CPU to decrypt it. If you have multiple assets with a CPU intensive game, this is just not possible. So what if you load the encrypted files and decrypt them before storing them in RAM? Sure it's gonna be fast, but someone can just dump the process memory and find the assets from there very easily.

Encrypting your assets is pointless. There's no way to do it securely and really most mainstream games just don't do it either. The only thing they have is custom file formats and compression. That's it. Don't destroy your game's performance just to try to prevent someone doing something you can do nothing against. The only games that use encryption are online games or games that talk to a server.

Wait! You had an idea, what if you made a server for your game to talk to and do the decryption server-side? No, doesn't work, because the server will have to send the decrypted data back to the client anyways. Don't do that, but the server could send mixed audio to prevent clients from having individual assets.

It's a losing battle, the best you can do is try to fingerprint your audio to detect when someone uses it, not really effective for short assets, better suited for soundtrack. Or you can digitally sign the files so if someone uses them without ripping the signature you can prove they were your assets.

People are using Cython to compile the classes and stuff as moduels, and then only having a main script which links them. Then they bundle that configuration up with PyInstall so there's multiple layers there. I don't know how effective Cython is, I'm not a computer scientist and have not studied such things.

I would highly not recommend people *ever* right custom cryptographic functions. Not unless your an expert in cryptology and even then I'd be hesitant to trust you unless you can prove that your work is cryptographically secure. If you want to encrypt or decrypt data, use libraries like OpenSSL, Pycryptodome, and so on. Don't write the routines yourself -- you'll most likely get them wrong. As an example, I'd use Botan, Monocypher, etc., for cryptography rather than manually doing it myself.
@16, I don't believe the overall goal for encrypting game assets is necessarily to stop anyone but the appropriate people from reading the data, though that does factor into things. The goal, nowadays anyway, I think, is to stop -- or do our best to stop -- the casual debugger guy from picking out the data with relative ease.

But if the sound is decrypted to be played, a debugger guy will get them in the decrypt function... Nothing you can do really unless you make it hard to reverse engineer, but that's another process.

@23, there are various other reasons why we are able to obtain the key from BGT games in particular. For one, its base offset is not randomized (its base offset is the offset that the app is loaded into memory at). It doesn't allow for address-space layout randomization, which allows the OS to put it wherever it pleases, so we always know where to start looking. But I digress. Hiding the key is impossible. The only way to hide it is to use an external service like Amazon key management service (AWS KMS), which allows you to generate a key whenever you want to do crypto, and that may not even be effective. The idea with that is that you retrieve the key from AWS KMS, do encryption with the returned plaintext key (in secured memory), and store the nonce, encrypted key, and encrypted data together. Then you load the nonce, load the encrypted key and send the encrypted key off to AWS for decryption. You get back the plaintext key and use that for decryption, then wipe the key from memory. This has a major advantage because the key is not actually stored in a decrypted form on disk, and its only stored in a decrypted form in memory for a short while. But even this is useless against a determined attacker.
The point is, its possible to obscure the key. Never hardcode the key in source code, obviously, is one rule that BGT simply does not allow you to safely address. Hash it, encode it all you like, the attacker will still find it by looking for string_encrypt or file_encrypt, because the parameters passed to that function will, ultimately, be the final key, no matter what you do with it. The functions are always a constant with BGT, so its ridiculously easy to break it because we always know what to look for. Take an application that's written in C++, and that can use any crypto library out there for cryptography, and you've got yourself a lot of difficul and hard work because you need to figure out the crypto functions that get the key, and with name mangling that most definitely won't be easy. Even if you obfuscate your code, a determined attacker will still be able to figure out your program no matter what you do. You can make it a hell of a lot harder though by following common sense. don't store the key in the source code; store it elsewhere, or generate it when you need it and store it in an encrypted form using an external service. In BGT that's not practical, unfortunately. However, this in no way means you shouldn't use encryption or obfuscation; make it as hard as you can for an attacker to get at your data. But don't try to address problems that are impossible to address. But secure your dat anywhere; just because the most determined attacker can get at your data doesn't mean that any attacker can get at your data. If you do it right, you can put off most people who want at your key, because most of them will only spend a few hours to a few days at most hacking at it before giving up. You store the key in a service and its impractical to get at it because you'd need to somehow figure out how to stop the world right before the key is wiped and replaced with all zeros.