2019-03-02 13:46:06

I think the problem is that there are two different methodologies at work here. Ethin, when he decrypts BGT data, is taking advantage of flaws in BGT itself. Let me say right out of the gate that I don't know how to do this, and if I did I wouldn't share details. Would I like to know how to decrypt BGT stuff? Well sure, who wouldn't.

Rastislav Kiss, on the other hand, is using what we might call a somewhat modified version of the brute force attack. That is, try every possible key until you get the right one. In a true brute force attack, you don't even worry about having a memory dump of the application, you just try all possible keys of length 1, then all possible keys of length 2, and so on, until you find the right one. Naturally, a brute force attack *WILL* succeed at some point, but it might take hours, weeks, or centuries. By using a memory dump, you can, at least in theory, eliminate those possible keys that aren't in the memory dump from the brute force process. However, you're counting on the fact that you know or can guess the length of the key, and that the developer hasn't done something to either hide the key in plain sight so you'll never find it no matter how many billions of keys you try, or destroy it when they're done with it, presumably before you get your memory dump.

Thumbs up

2019-03-02 21:51:10

@26, the issues with the second methodology are the flaws you stated: time, and impracticality.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

2019-03-04 11:47:50 (edited by Jayde 2019-03-05 10:14:11)

@26: no, it isn't a brute force attack. The correct name is a dictionary based attack, where you build up a dictionary out of the memory dump and then try each key contained in it. In hacking, the dictionary based attack has a great advantage over brute force attack in time. As you say, brute force attack can take centuries because there is enormously big amount of possible password combinations. On the other hand, dictionary based attack goes just until it processes all contained keys. So it's much faster. Problem normally is, that you don't know what the password is, so you must build too broad dictionary and there is still a great chance that you'll miss the key.
But in BGT this isn't a big deal, because we can build a dictionary out of memory dump and we know that our key will be somewhere in it.
Someone may find it unbelievable, I have too when I was trying it for first time. But it really works, that's a fact.
Here is a small example of Samtupycracker version 2 in action. Please ignore the stupid title and unoptimized code, it's pretty old. big_smile
(Link removed by moderator)
Run samtupycracker2.bgt, set the sound you want to break and dictionary program.dmp.log. The dictionary are strings extracted from the dump file using sysinternals strings program.

In this concrete case on my computer, the program is able to find the password in about 30 seconds.

@Ethin: noone is forcing you to use or do anything. You have just asked for a prove, so here it is. smile

Best regards

Rastislav

Thumbs up

2019-03-04 15:02:36

admins, please remove post 28 and take  relevant action. His method might be extremely extremely tedious, and I'm not at the keyboard this very second to verify whether or not it actually works as expected, but I have no reason to believe otherwise. Horribly inefficient and stopable it might be... But this could indirectly harm quite a few of our developers  regardless of the time factor

Thumbs up

2019-03-04 15:33:37

You could at least have used a sample bgt program to test this thing on, but yeah. strings, a program that basically prints all printable strings contained in a file + the bgt decriptor will decript all bgt stuff provided that the call to string encrypt is a string between quotes, not for example a string generated by some function like stringToUppercase or stringReverse, if I've got the names correct. Then again this does show off how easy it is to decript, and although we might not want this on the forum, keeping it strictly off-forum will give bgt a false sence of security and will move it underground.

Roel
golfing in the kitchen

Thumbs up

2019-03-04 15:46:19 (edited by Ethin 2019-03-04 16:24:17)

OK... so this is a dictionary attack. Of a kind. But it has two problems:
* its ridiculously inefficient. He pretty much reads all bytes, skipps \ns (which isn't probably the wisest idea, especially on windows...) and tries each byte sequence as he goes.
* The program relies on the user having far too much information. The user must have the sound as well as the dictionary. The dictionary is retrievable, but what about someone not knowing the sound they want to extract? What if they have a pack fileand just want to pull it out? The time the program takes to decrypt (if it actually can) exponentially grows as you ad more files you want to pull out. Let's assume that it averages to about 150 seconds to decrypt a single sound. A single sound from Manamon, for example. Manamon has 218 sounds, approx. So the amount of time you'd be waiting would be about 32,700 seconds, or 9 hours and 5 minutes. By that point I'd just give up and fall back to the disassembly method: its faster, less efficient and can be done in under 3 hours.
* A string in BGT is only printable if it has three or more characters. And, of course, it has to have printable characters. What if I have a string as a key that's full of non-printable characters? Something like:b'\xc2\x96\x03\xc2\xbe\xc3\xb7\xc2\x86\xc2\x9f\xc2\x9a\xc3\x85\xc3\xb1\xc3\x88\xc3\xa6\xc2\x8a\xc4\x80\xc2\x86\xc2\xb7\xc2\x95\xc3\xbb\t\x00\xc3\xb5\r\xc3\x9d\xc3\x98\xc3\x86\x13\x01\xc2\x97\xc2\x93\xc2\x8d\xc2\x89\xc3\xb1\xc3\xb3\xc2\x88\xc3\xae\x01\xc2\x91\xc3\x94\xc3\xbd\xc2\x83\xc3\xb5\xc3\x94\xc3\x86\x05\xc2\x95\xc2\xb6\xc2\x98\xc3\x84\x17\xc3\x85\xc3\xa0\xc2\xbf\x0c\xc2\x9e\xc2\xa5\xc3\xb3\x0e\xc3\x93\xc2\xac\xc3\x91\xc3\x93\x07\xc2\x9d\xc3\xb1\x1f\xc2\xba\x03\xc2\x9d\x1f\xc2\x94\xc2\xbd\xc2\xbb\xc2\xbc\x1c\xc2\x84\xc3\xbc\xc2\x98\x00\xc2\xaa\xc2\x88\t\xc2\xa2\xc2\x87\xc3\xa5\xc3\x8c\xc3\x8d'
Rendered as numbers, this key becomes:
[194, 150, 3, 194, 190, 195, 183, 194, 134, 194, 159, 194, 154, 195, 133, 195, 177, 195, 136, 195, 166, 194, 138, 196, 128, 194, 134, 194, 183, 194, 149, 195, 187, 9, 0, 195, 181, 13, 195, 157, 195, 152, 195, 134, 19, 1, 194, 151, 194, 147, 194, 141, 194, 137, 195, 177, 195, 179, 194, 136, 195, 174, 1, 194, 145, 195, 148, 195, 189, 194, 131, 195, 181, 195, 148, 195, 134, 5, 194, 149, 194, 182, 194, 152, 195, 132, 23, 195, 133, 195, 160, 194, 191, 12, 194, 158, 194, 165, 195, 179, 14, 195, 147, 194, 172, 195, 145, 195, 147, 7, 194, 157, 195, 177, 31, 194, 186, 3, 194, 157, 31, 194, 148, 194, 189, 194, 187, 194, 188, 28, 194, 132, 195, 188, 194, 152, 0, 194, 170, 194, 136, 9, 194, 162, 194, 135, 195, 165, 195, 140, 195, 141]
By that logic (unless there's some other way of fixing this issue and making BGT except the extended ASCII set), this string would be entirely ignored by BGT. And I generated this key with the following algorithm in Python:

key=""
for char in range(0, 128):
 randchar=random.randint(0, 256)
 if randchar in [f for f in range(32, 127)]:
  continue
 key+=chr(randchar)

This algorithm could be simplified, but it proves my point nicely. This algorithm will completely ignore ASCII codes 32-126. So it will completely ignore non-printable characters, by the non-extended ASCII standard's knowledge, anyway. The key above, rendered as numbers, is 3/4 invalid, by that standard.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up +1

2019-03-04 16:37:57

30:
I see what your saying, but must personally disagree. Whether he happens to test with a sample program, which he does unless package.zip was updated, doesn't matter. This method could be used to break the encryption of dozens of current audiogames. Although I admire new conversations and methods revolving around decryption/disassembly, I would like to think of this as a pretty welcoming community. Better keep such a program in the underground than openly distribute it on the largest open forum for audiogame discussion. After all, what brings us all together? These very games, often created with little to no compensation. the disadvantages to providing a publicly obtainable copy of something to such a magnitude far outweigh the one advantage.

Thumbs up

2019-03-04 16:46:48

@32 I've not looked at the program, but if it works the way  I think it does it reads strings seperated by a newline from a textfile and tries them as decription keys, so it's literally 10 lines or so. I do agree with you, however that decription attempts on specific games should be kept off-forum, just general techniques. But having an actual example instead of just shouting "security! but we won't tell you how" isn't so helpful either.

Roel
golfing in the kitchen

Thumbs up

2019-03-04 16:59:20

I do have to agree with Cartertemm. While I honestly doubt many will use this method due to the flaws that I pointed out (along with Cartertemm) it should not be on this particular forum. He could've PM'ed one of us or both of us, instead of posting it publicly. Mods, please remove post 28 -- or edit the link out -- before your favorite search engine, or archive.org, capture this page in their cache.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

2019-03-04 20:28:38

@30: exactly what I wanted to point out.
BGT's security is very weak in some points. Regarding my example, I will keep this up. If some moderator thinks it would be better to delete it, feel free to do so, I am not here to judge those decisions.
I just want to point out another thing. What guys do you think really happens, if someone decrypt sounds of a random BGT audiogame?
Well, if I think about it, I can't find any real harm of this. What wrong can happen to developer, if someone decrypt his sounds by this small really trivial utility? I think we are overrating this. Just look on our biggest audiogames - Swamp, Trtr, Eurofly, Sound RTS, Top speed, which game from them encrypts its sounds? NHL, Counter strike, GTA, biggest mainstream games in the world don't use encrypted sounds at all.
I personally think decryption of sounds is not dangerous. And it really good points out what's risky on BGT and what to remember when coding. because, guys, this isn't only thing my small utility can do. I have another, similar, but much more powerful and dangerous. And you can be sure that releasing it would make REAL harm to our games.
Sounds decryption is just a warning: "Hey, think more about what's happening in the background."
thus this small utility should be kept imo as an example for developers what they can expect and how to prevent it.
But it's on moderators. Anyway, leteckaposta is a service, which deletes all uploads after fixed period of time. In this case it's around 30 days. So after a month, this will be deleted anyway.

Regarding wrapping into a function like string_lower_case, this really helps. Sadly only in case of sound decryption, because it protects memory where it saves the password. But everything that you handle in BGT code is easyly visible in memory, if you don't make something special to hide it. that's important and many devs forget it.

@Ethin: using non-printable characters will really slow down the process. In that case, third version of Samtupycracker, which allows for raw dump search is required. Of course disassembling is still the most reliable way to go around, but there are just few people in our gaming community able to use it, while there are many others who may potentially discover these much easier paths and use them to much worse things than sound decryption. That's why I wanted to prove that it works, not only to you or someone other, but to everyone.

Best regards

Rastislav

Thumbs up

2019-03-04 20:56:49

Both sides of this discussion are correct. I also think decryption of sounds is nothing. there are bigger things to be worrying in application development.
I would suspect this psudo dictionary attack to work most of the time. I would suspect that most BGT devs don't have a formal education in computer science let alone cyber security/cryptography. They read, "You can encrypt your sounds from being stolen." They think to themselves this is something I want to do, I want to protect my hard work from hackers. They aren't aware of the reality. They probably either pick a stupidly simple phrase or mash on the keyboard which isn't that hard to crack. they would never make the phrase a bunch of non-printable chars.
I proper education in computer science hopefully will give someone the understanding of BGTs shortcomings.
This kind of research has to be done in public. Not in secret. Maybe, it might give an incentive for an BGT update. but i am not holding my breath.
Admins should not delete any posts. Unless they are endangering people's safety.

I don’t believe in fighting unnecessarily.  But if something is worth fighting for, then its always a fight worth winning.
check me out on Twitter and on GitHub

2019-03-04 23:25:35 (edited by cartertemm 2019-03-04 23:39:08)

As a prerequisite, I enjoy hacking/reverse engineering as much as the next guy. Give me a game and a code puzzle and I'll choose the code puzzle any day of the week without fail. Most every challenge comes with new knowledge to be had and that's what I live for.

Yet I think you might be looking at this from the wrong point of view. I personally don't really care if people get my sounds, if they do well good for them, congrats have a cookie. but others mind. It's my belief that since we're such a tight knit community we should do our best to respect the wishes of those who pump out content, in many cases without compensation. I suppose I'm not really a shiny portrayal of my own ideology, since I often find myself hyperfocused on pulling games apart, but I do my best to respect the license if such a thing exists. It just so happens, the majority of audiogames do not. Yet I never, never, under any circumstances, in any way shape or form, deliberately give myself an upper hand. Never once have I ripped unauthorized code or sounds or assets out of a project, going on to use them without consent. Yet were I 11 again and finding such a tool at my fingertips you can bet I probably would have. The only thing stopping me was determination and a crucial understanding of debugging.

As of the last uh, maybe 3 years or so, I've noticed a steady increase in people who really wouldn't bat an eyelash at the prospect of disrespecting our work. By this I mean circumventing encryption, difficulty or lack there of aside, and pulling content for use in their own projects. I know this after examining sounds and finding the exact SHA256 file hashes of custom made sounds. when confronted, I got no more than utter denial. I doubt I need to go over the virtually undeniable odds here. Suffice it to say, there are a host of forum members that couldn't care less. It could potentially be a minority or select age group, but regardless these types make themselves heard over everybody else. I have no sympathy for these guys, age included. This is the internet, and it's natural to find ourselves recognizing people for actions and actions alone. I had a small period of time when I was just like this. I was frowned upon with contempt, however, so began to take a look at what I had been doing.

I genuinely believe the majority of people here couldn't care less as long as they have games to play. I'm for helping people out, all anyone has to do is ask and I'll do what I can, but that comes at a cost. You just, don't, take advantage of my kindness and time by taking shit for yourself without a backward glance. that's reprehensible, dickish, slimy, whatever creative words you'd like to use. I wish I didn't see it so much, no not just on this forum either. Imagine the world we could create if people weren't so willing to take the easy way out at the cost of others? Wishful thinking I know.

So what I'm really meaning to say here, there's a point when a simple PoC turns into happy catering for every less talented scriptkitty on the block, and that's how I see this mindset, unfortunately. In addition to snagging sounds, just took about 3 or so minutes, give or take, turning his script and logic into something more deadly by far. Suffice it to say, I can now get more than sound decryption keys but that's all I'll offer up. Everyone is well aware that BGT can be cracked wide open in other days, this being little more than an alternative. As Kyle pointed out, there are most certainly bigger aspects of the development process. But does that mean we allow the forum to be a medium through which tools are hosted that could give unauthorized access to assets? I quite frankly couldn't care less if you decide to keep these findings to yourself. Letting the world know it's possible with a brief explanation, food for thought so future BGT developers know what they might be getting into, fine as well. But outright posting a one-click solution? I'm surprised there's nothing directly prohibiting such in the rules but I can't remember seeing anything like this in the past.

Thumbs up

2019-03-05 01:24:16 (edited by Rastislav Kiss 2019-03-05 01:30:35)

Just one thing I've forgotten, of course you need to crack just one sound. Samtupycracker v2 as well as v3 will print out used password, which you can then apply to all other sounds, so number of them doesn't increase time needed to find the password.

@Cartertemm: I see your view of point. I am developer as well. Although I am rather mathematician, enjoying applying my crazy ideas through programming, I have worked and still work on audiogames from time to time. So I understant what you're saying, I am exactly on field of ag a developer, who hasn't its own sound base and is too honest to steal sounds from other games.

I don't want to convince you about my opinion, you has your own along with reasons and I have also stated mine as well as why I have published this and what's worth attention on it.
I just want to remind one thing, I don't remember if I already said it or not. But that thing is, that even if there are kiddies stealing sounds, they have never produced something nice with them. Because Someone who isn't able to get sounds by other way than stealing them will most likely not be able to produce anything serious. Just another stealing, as you can see on tons of clons we have encountered in last period.
Heh, now it may look this applies also for me, because I'm unable to get sounds for my games. big_smile
but while in my case this is because of my time, which I invest in things I'm personally considering as more interesting, these fake developers normally do it, because they can't do it in other way.
I was talking with some of them and was pretty disgusted by some of their techniques, but that's completely different topic far from thisone.
On the other hand it's true, that this can't be applied for everyone. Programmers are lazy, what is good, because they make things in such a way where they're as easy as possible, but also can lead to practices, where they take something already prepared. However when we take also good programmers, in sense of those with high skills, then a description would be enough to help them decrypting, excepting fact they should be able to think out this or another approach themselves. So we would must to be quiet, what would on the other hand give to new programmers a sense of BGT being safe.
What can be true, but only in case you use BGT tools in smart way and know, where it is most vulnerable.
What I think I have described enough, if someone really thinks about mine previous posts where I was explayining what made the dictionary based attack possible (two facts - informations from memory and known security algorithm), he / she can understand according risks without my explanations about more destructive uses and also prevent them.

So it's a hard discussion anyway. As Kyleman already stated, there are pros and cons on both sides.
I think the best way is a good licence, that's something I often miss in projects of beginners and I can't understand why they don't include at least some basic eula. When I was beginning with programming, all of my first audiogames contained licence terms. It's true that their most often sounded like: "These licence terms aren't worth reading, please, continue in installation," or "I know you won't read my licence, so why to include it here?" but it was there. big_smile

Anyway, this discussion is starting to be interesting. tongue

Best regards

Rastislav

Thumbs up

2019-03-05 06:57:21

I'm really not here to attempt to convince you that my opinion is the right or only way, indeed I can clearly see both sides. I'm merely wishing to protect and respect the work of our comparatively few developers.
Normally, these matters are better dealt with by a community, a community with many members and contributors who are able to effectively pose solutions. A community with the majority wishing for a positive result. Here, however, I feel we are the minority, with the vast majority standing around in slight aw meanwhile rapidly awaiting new snippets so they can go home and show their less talented brothers how to easily break away from standard forms of protection.

I just, fail to see why an easy-to-use application is in the least bit helpful, and I'm honestly saddened to see how long the download has survived without admin intervention. Your not proving anything everyone doesn't already know. All one must do is read the weekly, what language should I choose, topics. When someone undoubtedly brings up BGT and it's countless simplistic benefits, others are most likely around to remind the newbie of antivirus flagging, security risks, and functional limitations. Most everyone is aware of what can be done and has been for a while now. What are you doing by providing a complete application with everything already included? Trying to prove just how easy it can be which has already been known. Trying to provide yet more incentive to switch languages? Either way, the way I happen to see it, during these trying times the risks far outweigh the benefits no matter how you look at it. Armed with only posts before 28, I'd imagine a basic program could be created to mimic your algorithm anyway.

As I said above, we're no longer only dealing with sounds, as was proven by myself in no substantial amount of time. Your only making stealing, for lack of a better term, protected assets a trivial matter. Sure public consumption was a certain eventuality, but at least if we were talking underground distribution the net wouldn't have had the chance to be cast over so large an audience. I hadn't felt the need to report your post since admins were supposedly watching over our topic here, but I'm starting to grow concerned since it's been nearly 24 hours.
I don't necessarily agree about sound stealers being unable to make anything, good. As you say yourself, coding, game design, and sound design are entirely different ball games. Take the void, which had ripped out and used a good amount of manamon content without permission. Yet people played it. The blood reign, ripped more custom sounds from SBYW or SBP or have your pick of the scrolling battles* games, again without permission. these are only two and I'd be happy to provide more examples if necessary. Most people have heard of and enjoyed at least one out of these two titles.

I to would find this conversation intriguing if not for the insane risk factor. It's certainly interesting to talk about code or puzzles we've managed to solve, just as long as there is no chance at harming the reason why we're here in the process.

Thumbs up

2019-03-05 07:23:33

Again, I say remove the damn link before archive.org takes another snapshot of the site and manages to pull this topic in with i and capture that link for evermore. I have no doubt that google has already cached it.
Edit: Oh fuck, it pretty much has. https://www.mail-archive.com/audiogames … 48272.html

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

2019-03-05 08:29:51

amusing

Ivan

2019-03-05 10:12:48

Moderation:

I'm removing the link, but am not issuing any punishment beyond that. There is no intent to harm, or none that I can see at any rate, and it appears that this discussion is remaining fairly theoretical.
I agree with the standpoint that it's okay to talk theory but not okay to post examples that the less scrupulous among us can tweak in order to deconstruct things that developers want left alone.

As such, I'm just going to ask that we not trade this link around here on the forums anymore. Please don't repost it, as I will have to take punitive action if that occurs.

Check out my Manamon text walkthrough at the following link:
https://www.dropbox.com/s/z8ls3rc3f4mkb … n.txt?dl=1

Thumbs up

2019-03-05 13:20:10

the link is already goin to die in 29 days,

Thumbs up

2019-03-05 15:26:04

This discussion is painful to read because it sounds like the things Ethin is saying are trivially disproven by the existence of, for example, my SoR2 program. Am I misunderstanding the argument here completely? Because, like, it really does sound trivial. Like, if BGT programs worked on Win9x, people would be finding keys within an hour of a game's release. People have mapped the entirety of RAM for old games, using techniques that are not at all difficult with BGT and a RAM dump. What am I missing?
I did my own encryption in Java—not particularly advanced, easily broken if someone identified the algorithm and the key. In BGT, that's more cumbersome, due to how strings are handled (you can literally say 'a'+1 in Java, C, etc, to get 'b', whereas going from chars to bytes in BGT is either not properly documented, or requires converting to hex, then from hex to ints). So string_encrypt is simpler. I mostly only use it for saved data (lol who believes I have sounds worth encrypting?), mostly to make cheating require more effort than just opening a file and changing a 5 to a 6, but still go into it expecting someone to break it in the unlikely event the game succeeds.
The real issue is that you need to use the built-in encryption in BGT for sounds. It's not impossible to work around this, although that creates an even bigger vulnerability if I describe it at all. But why even bother, at this point?

Some of my games
Keep up to date by following @Jeqofire on twitter!
Ear Ninja?

Thumbs up

2019-03-05 16:56:54

@44, mapping memory with memory dumps only works to a point. There are ways like this and this to prevent exactly that. For example, most good crypto libraries do not call memset() to zero out memory because the compiler can optimize it away and make that call have no effect or be called sometime later, endangering the security of the program. Instead, a crypto library might call Monociphers' crypto_wipe() function, which securely erases the memory, and cannot be just 'optimized away'. In order to then get anything sensitive like crypto keys, you'd then need to figure out:
* The address of the function doing the cryptography
* the address of each function called in that function
* the exact time, down to the smallest unit of measurement possible, when the cryptography has just started and the keys and other sensitive data is in memory
This is much harder than just "mapping memory" with a memory dump.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

2019-03-05 19:18:30

Does BGT do those things?

Some of my games
Keep up to date by following @Jeqofire on twitter!
Ear Ninja?

Thumbs up

2019-03-05 20:17:11

@46, I have no idea if it does or doesn't. However, if we are able to pull keys out of it via debugging, the chances are low that it does do those things.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

2019-03-06 00:34:52

It doesn't say in the docs so you have to assume it does not actively erase or zero secure memory after it runs out of scope. likewise, you can not assume it actively protects keys in ram.

writing secure C++ is tough even in the best of circumstances. Writing secure C++ while trying to erase memory behind you and not letting anything leak  is near impossible. I would assume the majority of bgt is in angel script, only dipping into C++ where needed. I would be highly surprised if angel script had the capability to securely manage and protect memory. only the basics of encrypt, decrypt, and hash are offered. Do we even know the algorithms used?

Again I reiterate, The sounds to your game being stolen is not the end of the world. why not leave them open and put that effort into a modding system. There are much more important things to protect, like your source-code, or your activation system.

I don’t believe in fighting unnecessarily.  But if something is worth fighting for, then its always a fight worth winning.
check me out on Twitter and on GitHub

2019-03-06 01:00:45

I can imagine a token attempt at encryption to abide by license agreements might sometimes be necessary. It could be argued that not encrypting sounds would be the equivalent of redistributing them.

Some of my games
Keep up to date by following @Jeqofire on twitter!
Ear Ninja?

Thumbs up

2019-03-06 16:01:11

Nah, Angelscript has no such ability and nor does BGT bother to wipe memory. Or if it did the implementation was so bad I haven't been able to track it down which is very likely. I'd imagine the number one goal was bringing simplicity to the development process which it apparently did all too well. As a little exercise, write and build a c++ program that passes around arbitrary pieces of unwanted information, dummy passwords for instance. See what all your able to grab. Then rewrite the program. Ethin is exactly right about compiler optimisations performed on memset. I've heard VS is immune unlike clang and g++, but who would want to take such a risk?

C++11 and later includes a function, memset_s, that should hopefully work for all but extremely paranoid cases as far as I know. In the end your only stopping a certain variety of attacks. I highly doubt attaching a debugger would fail to give an attacker the desired result as well but don't get me started on that losing battle.
Additionally, quite a few crypto apps/libs go the route of simply overrighting rather than clearing, creating an entire class for this purpose.

Thumbs up