Re: decrypting bgt stuff?
2019-03-08
Thread
AudioGames . net Forum — Developers room : gabriel-schuck via Audiogames-reflector
Re: decrypting bgt stuff? The topic is interesting and, as already mentioned, there are those who do not want the sounds of their game to be used, especially when there is work involved that justifies this.I did not get the code that attempts to decrypt sounds, but for programmers who care about it, it's a good way to test and handle some decryption.Anyway, there will always be someone trying to hack something and that is a responsibility of each one.I have already done some tests here, opening the dump file manually in a notepad and managed to locate the key of my game.when it was customary to put it straight into a string.What I do now is as follows:1. I create a function that returns the key encoded in base64.2. At the time of calling the set_sound_decryption_key () function, I decode the base64 string that wasreturned by my function.I'm not saying it's an infallible solution, I'm just proposing a way to make it difficult. Do your tests. Here I did a search and could not locate, whether it is encoded or decoded. URL: https://forum.audiogames.net/post/417086/#p417086 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @53, yeah, I get ya. init_pton() can be ported ridiculously easily. I can post the code here if you like -- I managed to port it with almost no changes to it. And yeah, I don't get why the *_s functions are not enabled for most compilers. It doesn't make sense but it is what it is, and C11 is different from C++ and no C++ standard will be compatible with C11 (strange as that is). I so wish you could compile with two or more standards, but that would ridiculously overcomplicate things. URL: https://forum.audiogames.net/post/416972/#p416972 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? Thanks for the information on memset_s. that's gotta be one of my biggest gripes on c++ and it's compilers. Among other things, I found myself coding a raw implementation of inet_pton because mingw doesn't know what it means. I've often wondered why the hell this is, why I'm able to throw something together but the smart guys who make the compilers can't. Or at least provide some derivative so as I'm not forced to do the same.IsDebuggerPresent is extremely unreliable, so keep that in mind. It can easily be broken just as is the case with most if not all windows API functions. The function was created not for security, but printing additional mesages/giving other info or generally behaving differently if in the context of a debugger. URL: https://forum.audiogames.net/post/416850/#p416850 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @50, memset_s (and its friends) are C11-specific and none of the compilers I use implement them. Cppreference.com says: "As with all bounds-checked functions, memset_s is only guaranteed to be available if __STDC_LIB_EXT1__ is defined by the implementation and if the user defines __STDC_WANT_LIB_EXT1__ to the integer constant 1 before including string.h." MSVC breaks this tradition (and compatibility) by making you define a completely different macro. Not sure what it is off the top of my head though. And yeah, one of the stages of clearing memory is zeroing it out.On Windows you can determine (though it doesn't always work) whether a debugger is attached to your program with IsDebuggerPresent. I haven't found a cross-platform solution though. URL: https://forum.audiogames.net/post/416679/#p416679 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @50, memset_s (and its friends) are C11-specific and none of the compilers I use implement them. Cppreference.com says: "As with all bounds-checked functions, memset_s is only guaranteed to be available if __STDC_LIB_EXT1__ is defined by the implementation and if the user defines __STDC_WANT_LIB_EXT1__ to the integer constant 1 before including string.h." MSVC breaks this tradition (and compatibility) by making you define a completely different macro. Not sure what it is off the top of my head though. And yeah, one of the stages of clearing memory is zeroing it out. URL: https://forum.audiogames.net/post/416679/#p416679 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? The thing is, every design is useless if it's used too much and therefore cracked. Look at mainstream devs, every game gets cracked (except multiplayer of course, accounts and such) but people don't use them because risk of viruses and steam is easy enough. Every minute spent on security is a minute not spent on features. I wonder how much effect improved obfescation boosts game sales, but with audiogames this will be hard to track. URL: https://forum.audiogames.net/post/416602/#p416602 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/416588/#p416588 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/416519/#p416519 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/416515/#p416515 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @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. URL: https://forum.audiogames.net/post/416465/#p416465 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? Does BGT do those things? URL: https://forum.audiogames.net/post/416450/#p416450 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @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 memoryThis is much harder than just "mapping memory" with a memory dump. URL: https://forum.audiogames.net/post/416429/#p416429 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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? URL: https://forum.audiogames.net/post/416421/#p416421 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? the link is already goin to die in 29 days, URL: https://forum.audiogames.net/post/416412/#p416412 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/416396/#p416396 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? amusing URL: https://forum.audiogames.net/post/416390/#p416390 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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 URL: https://forum.audiogames.net/post/416384/#p416384 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/416382/#p416382 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
2019-03-04
Thread
AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
Re: decrypting bgt stuff? 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. 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. Anyway, this discussion is starting to be interesting. Best regardsRastislav URL: https://forum.audiogames.net/post/416331/#p416331 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
2019-03-04
Thread
AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
Re: decrypting bgt stuff? 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. 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. Anyway, this discussion is starting to be interesting. Best regardsRastislav URL: https://forum.audiogames.net/post/416331/#p416331 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/416310/#p416310 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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, have a cookie. but some do. 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 tallanted 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. URL: https://forum.audiogames.net/post/416310/#p416310 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/416279/#p416279 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
2019-03-04
Thread
AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
Re: decrypting bgt stuff? @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 regardsRastislav URL: https://forum.audiogames.net/post/416274/#p416274 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/416209/#p416209 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @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. URL: https://forum.audiogames.net/post/416203/#p416203 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/416198/#p416198 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/416189/#p416189 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/416189/#p416189 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/416189/#p416189 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @28, OK... so you get a list of strings... which may or may not be in the millions for a count of them. And your program just brute-forces it. Which is exactly what this is. You use an internal dictionary but yoru still brute-forcing the issue. The method people like Carter and I use has not only proven to work *all the time* but it has also proven to be much faster than using a dictionary of strings. We don't brute-force, we get in, retrieve what we need and get out. No dictionary is needed. URL: https://forum.audiogames.net/post/416189/#p416189 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @28, I don't consider that link proof -- it linked me to a foreign site that was in a different language -- but I have nothing to say. The method people like Carter and I use has not only proven to work *all the time* but it has also proven to be much faster than using a dictionary of strings (which an application might have millions of). URL: https://forum.audiogames.net/post/416189/#p416189 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/416184/#p416184 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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 URL: https://forum.audiogames.net/post/416177/#p416177 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? admins, please remove post 28 and take URL: https://forum.audiogames.net/post/416175/#p416175 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
2019-03-04
Thread
AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
Re: decrypting bgt stuff? @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. http://leteckaposta.co/file/249637651.1 … 0e14854/csRun 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. Best regardsRastislav URL: https://forum.audiogames.net/post/416147/#p416147 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @26, the issues with the second methodology are the flaws you stated: time, and impracticality. URL: https://forum.audiogames.net/post/415759/#p415759 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? 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. URL: https://forum.audiogames.net/post/415652/#p415652 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? ok, @rasti i did what you said to test, didn't plan to abuse it. I made a thing that reads the dmp files and tries to set every single line as decryption key, then trys to play a sound, an if that checks if the sound is playing and if it is copy the key. It don't works. What do i do wrong, just asking? I don't plan to do any sound leaks or so. URL: https://forum.audiogames.net/post/415651/#p415651 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @23, again, your missing the point. This technique doesn't work and if it did it would be horribly inefficient and makes far too may assumptions about the password. What if the password isn't a password within the ASCII table. What if its raw bytes. Again, I'll stick with the tried and proven method and not some phantom method someone's willing to just make up without evidence. URL: https://forum.audiogames.net/post/415512/#p415512 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
2019-03-01
Thread
AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
Re: decrypting bgt stuff? Memory dumps of BGT programs normally haven't 500mb. From 100 to 200, in special cases more, but it isn't very frequent.Also I apologize for my mistake in calculation, in 1 bytes there are 9980 possible 20 byte sequences, not 500. Still not much, but if we want to be exact, it's good to claim.Also about the example sequence, one byte is enough to call password not printable, if we are supposing the password has been written on the keyboard without using characters generation. Or it may be more exact calling it not writable?Not important anyway.Your assuming that the key can be easily determined by picking random offsets in the core dump and just scanning from there. Sorry, buddy, not how that works.Who's talking about picking random offsets? Let's describe the technique by offsets, okay. Then you pick starting offset 0, and increase it by 1 till you don't have enough bytes to get from that position to form a password.This basically works, it doesn't matter how much you don't want to believe it.But I know that some people aren't familiar with theoretical proves. While you can prove this practically yourself just by following what I said, I can save your time by sending you my code and a practical example of program where it works.There are two versions. One takes a list of strings extracted from the memory dump by external program. it is fast, it can find the password in few minutes.Secondone works directly with memory dump and doesn't use any filtering, trying every possible sequence in given range. How fast it finds the password depends on your initial setup. if password is long enough, it will take more than few minutes, but it will find it.Which version would you like to try out? Best regardsRastislav URL: https://forum.audiogames.net/post/415509/#p415509 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
2019-03-01
Thread
AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
Re: decrypting bgt stuff? Memory dumps of BGT programs normally haven't 500mb. From 100 to 200, in special cases more, but it isn't very frequent.Also I apologize for my mistake in calculation, in 1 bytes there are 9980 possible 20 byte sequences, not 500. Still not much, but if we want to be exact, it's good to claim.Also about the example sequence, one byte is enough to call password not printable, if we are supposing the password has been written on the keyboard without using characters generation. Or it may be more exact calling it not writable?Not important anyway.Your assuming that the key can be easily determined by picking random offsets in the core dump and just scanning from there. Sorry, buddy, not how that works.Who's talking about picking random offsets? Let's describe the technique by offsets, okay. Then you pick starting offset 0, and increase it by 1 till you don't have enough bytes to get from that position to form a password.This basically works, it doesn't matter how much you don't want to believe it.But I know that some people aren't familiar with theoretical proves. Wwhile you can prove this practically yourself just by following what I said, I can save your time by sending you my code and a practical example of program where it works.There are two versions. One takes a list of strings extracted from the memory dump by external program. it is fast, it can find the password in few minutes.Secondone works directly with memory dump and doesn't use any filtering, trying every possible sequence in given range. How fast it finds the password depends on your initial setup. if password is long enough, it will take more than few minutes, but it will find it.Which version would you like to try out? Best regardsRastislav URL: https://forum.audiogames.net/post/415509/#p415509 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
2019-03-01
Thread
AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
Re: decrypting bgt stuff? Memory dumps of BGT programs normally haven't 500mb. From 100 to 200, in special cases more, but it isn't very frequent.Also I apologize for my mistake in calculation, in 1 bytes there are 9980 possible 20 byte sequences, not 500. Still not much, but if we want to be exact, it's good to claim.Also about the example sequence, one byte is enough to call password not printable, if we are supposing the password has been written on the keyboard without using characters generation. Or it may be more exact calling it not writable?Not important anyway.Your assuming that the key can be easily determined by picking random offsets in the core dump and just scanning from there. Sorry, buddy, not how that works.Who's talking about picking random offsets? Let's describe the technique by offsets, okay. Then you pick starting offset 0, and increase it by 1 till you haven't enough bytes to get from that position to form a password.This basically works, it doesn't matter how much you don't want to believe it.But I know that some people aren't familiar with theoretical proves. Wwhile you can prove this practically yourself just by following what I said, I can save your time by sending you my code and a practical example of program where it works.There are two versions. One takes a list of strings extracted from the memory dump by external program. it is fast, it can find the password in few minutes.Secondone works directly with memory dump and doesn't use any filtering, trying every possible sequence in given range. How fast it finds the password depends on your initial setup. if password is long enough, it will take more than few minutes, but it will find it.Which version would you like to try out? Best regardsRastislav URL: https://forum.audiogames.net/post/415509/#p415509 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @21, first, your not proving anything and making very wild assumptions about a lot of things. Your assuming that the key can be easily determined by picking random offsets in the core dump and just scanning from there. Sorry, buddy, not how that works. Your also making assumptions about key lengths.Really, your just making claims that are very difficult to believe. Your making a claim that if I load a 500 MB file that's a BGT program, sounds and all, that I can just locate the decryption key in about a minute or so. That is not feasible. In a 500 MB program, there are 524288000 offsets. Let's assume that the base address is our starting offset. The base address is 0x40. That would mean offsets 0x40 to 0x1f80. Since the game is loaded in RAM by the time you generate the dump, you can't exclude anything. I'm sorry but unless you actually provide code and provide a working PoC, I find your claim impossible to believe. I'll stick with the tried and true method of debugging the application to cut sounds and other pack data out of a BGT executable, which has been proven to work time and time again. It doesn't help your case when you make false assertions that the character sequence "1, 205, 51, 105" is not printable. Only byte 1 (SOH) is a non-printable character; that's an aSCII control character. Bytes 205, 51, and 105 is printable if your going with the extended ASCII table; otherwise byte 205 is not a valid byte. If your processing the dump in unicode/UTF-8, then the above assertion is still valid; only byte 0x1 is non-printable. 0xCD is Í; 0x33 is 3; and 0x69 is i. URL: https://forum.audiogames.net/post/415494/#p415494 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @21, first, your not proving anything and making very wild assumptions about a lot of things. Your assuming that the key can be easily determined by picking random offsets in the core dump and just scanning from there. Sorry, buddy, not how that works. Your also making assumptions about key lengths.Really, your just making claims that are very difficult to believe. Your making a claim that if I load a 500 MB file that's a BGT program, sounds and all, that I can just locate the decryption key in about a minute or so. That is not feasible. In a 500 MB program, there are 524288000 offsets. Let's assume that the base address is our starting offset. The base address is 0x40. That would mean offsets 0x40 to 0x1f80. Since the game is loaded in RAM by the time you generate the dump, you can't exclude anything. I'm sorry but unless you actually provide code and provide a working PoC, I find your claim impossible to believe. I'll stick with the tried and true method of debugging the application to cut sounds and other pack data out of a BGT executable, which has been proven to work time and time again. URL: https://forum.audiogames.net/post/415494/#p415494 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @21, first, your not proving anything and making very wild assumptions about a lot of things. Your assuming that the key can be easily determined by picking random offsets in the core dump and just scanning from there. Sorry, buddy, not how that works. Your also making assumptions about key lengths.Really, your just making claims that are very difficult to believe. Your making a claim that if I load a 500 MB file that's a BGT program, sounds and all, that I can just locate the decryption key in about a minute or so. That is not feasible. In a 500 MB program, there are 524288000 offsets. Let's assume that the base address is our starting offset. The base address is 0x40. That would mean offsets 0x40 to 0x1f80. Since the game is loaded in RAM by the time you generate the dump, you can't exclude anything. Yo ucan't exclude the sounds (because you can't exactly figure out what's a sound and what isn't unless you can find a way to do lots of comparisons on every single byte sequence you come across to figure out if its a header, a set of PCM samples, and so on). I'm sorry but unless you actually provide code and provide a working PoC, I find your claim impossible to believe. URL: https://forum.audiogames.net/post/415494/#p415494 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
2019-03-01
Thread
AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
Re: decrypting bgt stuff? Hi,that's exactly why I marked BGT security as very vulnerable. To be able to decrypt german messages during world war II, allies needed to have working enigma machine first, so they could make a decryption machine based on it.In BGT, you have everything to find out, if any key you are able to think out is correct or not.And you have a dump file, which as you know contains the key, what is one continuous sequence of bytes.And you know that it will probably contain upto 20 characters, possibly more like in case of Redspot.So, how many continuous 20 bytes sequences can you get out of 1 bytes long dump file?Yes, it's 500 possible sequences.It may look many for a human, but this is actually nothing for a computer. Fast C++ program would do this in few seconds.Another good thing is, that passwords with more characters have longer sequences, so there is even lower amount of possible passwords.But BGT is generally very slow when you want to perform many operations involving use of strings. Searching the key in this way can take hours, if it's long enough. Of course, even hours is perfectly short time, when we want to decrypt something. But now, it's far from our C++ ideal right?So, how to speed this up?One approach is through a basic question. Why the decryption takes so much time?Answer: because it's trying many sequences, which are obviously not our password.For example, ascii values 1, 205, 51, 105 are even not printable, so it probably isn't what we want.Of course, this isn't an absolute claim. If one uses password generator, it can involve such characters as well. It is rather psychological assumption. Why would one use a password generator, if he / she can easily write a password to quotes and it will work?Based on this conclusion, we can easyly reduce size of the memory dump by filtering out all non-printable characters. We can go even deeper and start thinking, what characters has programmer probably used based on his language.First option we have is to get all groups of printable characters out of the file and try, if our password wasn't surrounded by non printable characters. Because BGT has functions to get ascii code of a byte, it is capable of doing such filtering. or you can do some preprocessing on the file, there are programs to extract string out of binary files.This method worked for all BGT games I have cracked, except myone.If this don't work, then the password is probably surrounded by other printable characters.So you can connect everything together and search with sequences selecting method.If this doesn't work as well, then a password generator was probably used and thus you need to iterate through all bytes.Length of this operation depends on the length of used password. From encryptions I broke, this is very unpredictable. For example, Samtupy used about 170 characters long password to protect sounds of Redspot, but only 4 characters longone to protect sounds of Sammycenter.I saw games using about 10 character long password, few using 60 characters, so there are various approaches.But they are crackable in general, and the most easy way is through the encryption tool, through BGT.If you don't believe, try it out. it is that easy like this.I personally have also nothing against publishing my source code here, but I think some people won't agree with that. It is bit embarrassing for me revealing it here as some super secret, when it is just a set of ideas, which you probably would invent easily yourself as well if you think about it a bit. But here it is, you have everything to successfully recover passwords of sounds from the most of BGT games. Trivial approach when compared to debuggers, disassemblers and so on, but it basically works and requires less technical skills and time.For developers, as I said, there are ways to go around this. Not all of BGT games are crackable in this way, one of them is STW and I still don't know why. I would like to see its password to check, what happened in memory so my program isn't able to detect it. One my theory is, that Samtupy loaded everything to memory first and then erased the password, but I can't think out the reason why he would to do so.But that's not important anyway. There are more important and more enjoyable parts of coding, which are more worth of your attention.Best regardsRastislav URL: https://forum.audiogames.net/post/415492/#p415492 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @19, that was generally what I was saying. You can encrypt and decrypt with BGT, but you can't just find a cryptographic key in a few minutes like Rastislav Kiss was claiming, with BGT. You can't "analyze memory dumps" with it, either -- not unless you know windows internalsvery, very well, and I really doubt the memory dump format was ever standardized, let alone written down in a specification. So unless evidence can be provided that you can suddenly find keys in BGT using BGT in less than 5 minutes, or whatever a "few minutes" is, I can't just accept that. URL: https://forum.audiogames.net/post/415312/#p415312 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? I think what Ethan was arguing is that you can't do it with bgt. He wasn't arguing the difficulty of decryption, he was simply saying that you can't decrypt BGT with BGT and asking for evidence. URL: https://forum.audiogames.net/post/415284/#p415284 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
2019-02-28
Thread
AudioGames . net Forum — Developers room : oussamabengatrane via Audiogames-reflector
Re: decrypting bgt stuff? at Ethin, in my case i have a lot of was to look for the key, and i will say it again, bgt stuff can be easy unpacked in a way or an other URL: https://forum.audiogames.net/post/415215/#p415215 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? well, i didn't with bgt. I red the dump with npp, and was able to find my key. But i was not able to deteckt any keys, exept i know exactly how they go. Because there is nothing like key=deckey or so, so it's almost impossible to find it using that way. URL: https://forum.audiogames.net/post/415155/#p415155 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? And again, I doubt this. Significantly. The header of an embedded pack file is known by practically everyone who's invested time into it. But using BGT itself to analyze memory dumps to discover keys... you know my opinion already. Please provide some actual evidence, either privately or publicly, instead of giving vague theories and information that doesn't prove anything. URL: https://forum.audiogames.net/post/415119/#p415119 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? And again, I doubt this. Significantly. The header of an embedded pack file is known by practically everyone who's invested time into it. But using BGT itself to analyze memory dumps to discover keys... you know my opinion already. Please provide some actual evidence, either privately or publicly. URL: https://forum.audiogames.net/post/415119/#p415119 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? ok, just for fun i tried this on my own game. I was in fact able to find my key in the ram dump, but this only works if it is your own game i think, because you don't know what is key and what not, so to efectively find it you need to know it before. Or is there a methot to find it directly in that file? URL: https://forum.audiogames.net/post/415072/#p415072 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @13, yeah... OK then... whatever you say. URL: https://forum.audiogames.net/post/415038/#p415038 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @13, yeah... right... I totally believe -- without evidence at all -- that BGT is capable of analyzing memory dumps. That's totally possible in BGT and the version of angelscript it uses. URL: https://forum.audiogames.net/post/415038/#p415038 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
2019-02-27
Thread
AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
Re: decrypting bgt stuff? It is completely in BGT. I just give it a memory dump of target process and the rest is analysis. I have here a collection of decription keys to sounds of various BGT games, including popular titles like Redspot (did you know its key has about 170 characters?), The killer or Sbyw. None of them was revealed by debugger or disassembler, all I needed was memory dump of each game, which you can optain by few clicks in task manager.Best regardsRastislav URL: https://forum.audiogames.net/post/415037/#p415037 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @11, and again, I doubt your claim. BGT does not have the ability to read raw memory. I find it very hard to believe that you could easily figure out the key for any BGT game or pack file with BGT alone. If BGT had the ability to read and write raw memory I think someone like cartertemm would've figured that out long ago and we wouldn't need to delve into debuggers to figure out the decryption key for sounds. URL: https://forum.audiogames.net/post/415033/#p415033 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
2019-02-27
Thread
AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
Re: decrypting bgt stuff? @Ethin: I didn't said cryptography is bad at all. Cryptographic algorithms themselves like AEs Rijndael or Serpent are fine. If you encrypt a string with bgt and store it somewhere, with good key it is impossible to decrypt it.However problems appear when a program which is fully under your control works with encrypted data. I have played around with Hero's call some time ago trying to get its sounds. And I wasn't successful at this, because I didn't know the format in which they were saved.Of course, if I invested more time to it, I might use disassembler to look how data are processed, which functions are called, etc. But it could take days, weeks, or even years of work if algorithm in c++ was complicated enough for me to find out what's happening.That's a lot when compared with BGT, where all implementation details are known and you have tools to reproduce loading, you need just to find right key.And if this key lies unprotected in memory of program, which you can easily access, then it is trivial even for a program in BGT to find it.Of course this is not the case of modern good written apps, you can't even use this technique to get to macbooks anymore, after Apple's fix, but in BGT...The key can be found in minutes, without guessing or disassembling.Regarding packages yes, that's just one layer of 'protection' and you still need to get encryption key to be able to get playable sounds. That's the reason why I wrote exact steps how to do this. Even if some kid reproduces them, he / she will most likely to get just encrypted files. And it is still a good preview what are the risks of BGT's security. If I received an executable in C++ with packed sounds, I would need to use debugger to see how they are stored and how can I get them. If I received a program in BGT, I would already know, what to do. Best regardsRastislav URL: https://forum.audiogames.net/post/415028/#p415028 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @8 and 9, this is definitely untrue.8: cryptographic keys are stored in the compiled bytecode of the executable, not in the encrypted pack file. If the keys were stored in the pack file, decryption would not be possible without opening the file, figuring out the key offset and reading from there.9: Just because someone knows what algorithm to use for cryptography does in no way mean that cryptography is bad. It does in no way mean that an attacker can easily extract the key from the code of the application. Every good cryptography library has special functions that are used to securely generate, store, utilize, and wipe memory. The only reason people are able to extract keys from BGT so easily is because of one major problem with the way BGT works: the base address is always the same. There is no use of ASLR involved. Since ASLR is not used, it is ridiculously easy to figure out just where each function offset is and put a BP on it. If ASLR were used this would be far more difficult, as even disassemblers would not yield results that could be trusted. I also find it very hard to believe that you have written a program in BGT that is capable of figuring out the cryptographic key used to encrypt data without some kind of disassembler involved. That kind of technology is far beyond BGT's capabilities. Here's my reason why I doubt you: whenever a byte is added to a sequence of bytes, the amount of possible byte sequences grows exponentially. As an example, let's go with the ASCII table since that will be easy to understand. The ASCII has 128 characters, the NULL byte included. For this example, we won't assume that the NULL byte means the end of a character sequence as it does in C, because we don't know if Phillip may have found a way around that. Let's say your sequence of bytes currently is of size 1. That's 128 possibilities. Not hard to iterate through, eh? Let's add some bytes and I shall demonstrate the exponential growth:2 bytes: 256-16,384 possibilities3 bytes: 384-2,097,152 possibilities18 bytes: 2,304-85 undecillion possibilitiesNow, lets bring in the Python unicode table (0x0-0x11). Now we start to get ridiculously large amounts of possibilities. For one byte of an unicode string we have 1,114,112 possibilities right there. Make that sequence 32 bytes long and you've got yourself approximately between 35,651,584 to over 3.1748503857632414... × 10^193 possibilities.Granted, hackers do not guess keys like this -- the time, as you can see, would be astronomically unfeasible. However, hackers usually have debuggers, hex editors and other tools available to them to aid in the task of breaking encryption. BGT does not however provide such tools. I am perhaps over-complicating the problem, but unless you can provide proof to back up your claim, I certainly will not take you seriously. I doubt that if I gave you a pack file encrypted with a 1024-byte key your little program could crack it in a few minutes.As for the pack file thing, yes, the pack file has a "known" header. However, remember that its possible to add encrypted sounds to pack files and then decrypt them when you need them and still include them in an executable. I have a program that can extract pack files but I still have to get the key(s) first, which does solicit a debugger. Perhaps I'm wong on what I've said, but I still have my doubts about your 'program'. URL: https://forum.audiogames.net/post/415001/#p415001 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @8 and 9, this is definitely untrue.8: cryptographic keys are stored in the compiled bytecode of the executable, not in the encrypted pack file. If the keys were stored in the pack file, decryption would not be possible without opening the file, figuring out the key offset and reading from there.9: Just because someone knows what algorithm to use for cryptography does in no way mean that cryptography is bad. It does in no way mean that an attacker can easily extract the key from the code of the application. Every good cryptography library has special functions that are used to securely generate, store, utilize, and wipe memory. The only reason people are able to extract keys from BGT so easily is because of one major problem with the way BGT works: the base address is always the same. There is no use of ASLR involved. Since ASLR is not used, it is ridiculously easy to figure out just where each function offset is and put a BP on it. If ASLR were used this would be far more difficult, as even disassemblers would not yield results that could be trusted. I also find it very hard to believe that you have written a program in BGT that is capable of figuring out the cryptographic key used to encrypt data without some kind of disassembler involved. That kind of technology is far beyond BGT's capabilities. Here's my reason why I doubt you: whenever a byte is added to a sequence of bytes, the amount of possible byte sequences grows exponentially. As an example, let's go with the ASCII table since that will be easy to understand. The ASCII has 128 characters, the NULL byte included. For this example, we won't assume that the NULL byte means the end of a character sequence as it does in C, because we don't know if Phillip may have found a way around that. Let's say your sequence of bytes currently is of size 1. That's 128 possibilities. Not hard to iterate through, eh? Let's add some bytes and I shall demonstrate the exponential growth:2 bytes: 256-16,384 possibilities3 bytes: 384-2,097,152 possibilities18 bytes: 2,304-85 undecillion possibilitiesNow, lets bring in the Python unicode table (0x0-0x11). Now we start to get ridiculously large amounts of possibilities. For one byte of an unicode string we have 1,114,112 possibilities right there. Make that sequence 32 bytes long and you've got yourself approximately between 35,651,584 to over 3.1748503857632414... × 10^193 possibilities.Granted, hackers do not guess keys like this -- the time, as you can see, would be astronomically unfeasible. However, hackers usually have debuggers, hex editors and other tools available to them to aid in the task of breaking encryption. BGT does not however provide such tools. I am perhaps over-complicating the problem, but unless you can provide proof to back up your claim, I certainly will not take you seriously. I doubt that if I gave you a pack file encrypted with a 1024-byte key your little program could crack it in a few minutes.As for the pack file thing, yes, the pack file has a "known" header. However, remember that its possible to add encrypted sounds to pack files and then decrypt them when you need them and still include them in an executable. I have a program that can extract pack files but I still have to get the key(s) first, which does solicit a debugger URL: https://forum.audiogames.net/post/415001/#p415001 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @8 and 9, this is definitely untrue.8: cryptographic keys are stored in the compiled bytecode of the executable, not in the encrypted pack file. If the keys were stored in the pack file, decryption would not be possible without opening the file, figuring out the key offset and reading from there.9: Just because someone knows what algorithm to use for cryptography does in no way mean that cryptography is bad. It does in no way mean that an attacker can easily extract the key from the code of the application. Every good cryptography library has special functions that are used to securely generate, store, utilize, and wipe memory. The only reason people are able to extract keys from BGT so easily is because of one major problem with the way BGT works: the base address is always the same. There is no use of ASLR involved. Since ASLR is not used, it is ridiculously easy to figure out just where each function offset is and put a BP on it. If ASLR were used this would be far more difficult, as even disassemblers would not yield results that could be trusted. I also find it very hard to believe that you have written a program in BGT that is capable of figuring out the cryptographic key used to encrypt data without some kind of disassembler involved. That kind of technology is far beyond BGT's capabilities. Here's my reason why I doubt you: whenever a byte is added to a sequence of bytes, the amount of possible byte sequences grows exponentially. As an example, let's go with the ASCII table since that will be easy to understand. The ASCII has 128 characters, the NULL byte included. For this example, we won't assume that the NULL byte means the end of a character sequence as it does in C, because we don't know if Phillip may have found a way around that. Let's say your sequence of bytes currently is of size 1. That's 128 possibilities. Not hard to iterate through, eh? Let's add some bytes and I shall demonstrate the exponential growth:2 bytes: 256-16,384 possibilities3 bytes: 384-2,097,152 possibilities18 bytes: 2,304-85 undecillion possibilitiesNow, lets bring in the Python unicode table (0x0-0x11). Now we start to get ridiculously large amounts of possibilities. For one byte of an unicode string we have 1,114,112 possibilities right there. Make that sequence 32 bytes long and you've got yourself approximately between 35,651,584 to over 3.1748503857632414... × 10^193 possibilities.Granted, hackers do not guess keys like this -- the time, as you can see, would be astronomically unfeasible. However, hackers usually have debuggers, hex editors and other tools available to them to aid in the task of breaking encryption. BGT does not however provide such tools. I am perhaps over-complicating the problem, but unless you can provide proof to back up your claim, I certainly will not take you seriously. I doubt that if I gave you a pack file encrypted with a 1024-byte key your little program could crack it in a few minutes.As for the pack file thing, yes, the pack file has a "known" header. However, remember that its possible to add encrypted sounds to pack files and then decrypt them when you need them and still include them in an executable. URL: https://forum.audiogames.net/post/415001/#p415001 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? @8 and 9, this is definitely untrue.8: cryptographic keys are stored in the compiled bytecode of the executable, not in the encrypted pack file. If the keys were stored in the pack file, decryption would not be possible without opening the file, figuring out the key offset and reading from there.9: Just because someone knows what algorithm to use for cryptography does in no way mean that cryptography is bad. It does in no way mean that an attacker can easily extract the key from the code of the application. Every good cryptography library has special functions that are used to securely generate, store, utilize, and wipe memory. The only reason people are able to extract keys from BGT so easily is because of one major problem with the way BGT works: the base address is always the same. There is no use of ASLR involved. Since ASLR is not used, it is ridiculously easy to figure out just where each function offset is and put a BP on it. If ASLR were used this would be far more difficult, as even disassemblers would not yield results that could be trusted. I also find it very hard to believe that you have written a program in BGT that is capable of figuring out the cryptographic key used to encrypt data without some kind of disassembler involved. That kind of technology is far beyond BGT's capabilities. Here's my reason why I doubt you: whenever a byte is added to a sequence of bytes, the amount of possible byte sequences grows exponentially. As an example, let's go with the ASCII table since that will be easy to understand. The ASCII has 128 characters, the NULL byte included. For this example, we won't assume that the NULL byte means the end of a character sequence as it does in C, because we don't know if Phillip may have found a way around that. Let's say your sequence of bytes currently is of size 1. That's 128 possibilities. Not hard to iterate through, eh? Let's add some bytes and I shall demonstrate the exponential growth:2 bytes: 256-16,384 possibilities3 bytes: 384-2,097,152 possibilities18 bytes: 2,304-85 undecillion possibilitiesNow, lets bring in the Python unicode table (0x0-0x11). Now we start to get ridiculously large amounts of possibilities. For one byte of an unicode string we have 1,114,112 possibilities right there. Make that sequence 32 bytes long and you've got yourself approximately between 35,651,584 to over 3.1748503857632414... × 10^193 possibilities.Granted, hackers do not guess keys like this -- the time, as you can see, would be astronomically unfeasible. However, hackers usually have debuggers, hex editors and other tools available to them to aid in the task of breaking encryption. BGT does not however provide such tools. I am perhaps over-complicating the problem, but unless you can provide proof to back up your claim, I certainly will not take you seriously. I doubt that if I gave you a pack file encrypted with a 1024-byte key your little program could crack it in a few minutes. URL: https://forum.audiogames.net/post/415001/#p415001 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
2019-02-27
Thread
AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
Re: decrypting bgt stuff? In case of BGT, this is very easy. General problem is, that algorithms for things like encryption, packages managing, sounds loading etc. are used by everyone, thus attacker exactly knows what to search for.For example, if a game has sounds packaged in it, it is just a package pasted in the executable file. And because there is a high chance that developer used native BGT packages, there will be most likely the same data structure. So all you need to do is to grab a binary editor, or make one yourself, it is very easy with BGT. Check out header used by normal BGT packages and then search for it in executable file. When you find it, cut everything before and save the rest of file. Tada, there is a working BGT package, which you can browse, extract, or do whatever you want with it.I have published this information because I don't consider it so dangerous. I just wanted to point out the biggest problems leading to sounds leaks.I won't publish concrete steps, because I know there are kids waiting just to steal something. But things work very similar if you want to decript sounds. The biggest problems when decripting something are which algorithm was used, how was it implemented and how to know, if decripted result is correct or not, in other words if currently tried key is right or not.When using BGT, all of these questions are answered.So you don't even need a disassembler. I have a program which allows me to decrypt sounds from the most of BGT games just by few keyboard hits.There are ways to go around this. however, as someone already mentioned, don't waste your time with this. Big games like NHL, World of tanks or GTA don't use encryption of sounds at all. Think more about your game structure. That's what makes your game unique, its performance and features. 99% of that kids who are just dealing with leaked sounds and source codes can't do so. So even if they get your sounds, they will be completely unable to use them.Best regardsRastislav URL: https://forum.audiogames.net/post/414990/#p414990 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
2019-02-27
Thread
AudioGames . net Forum — Developers room : oussamabengatrane via Audiogames-reflector
Re: decrypting bgt stuff? bgt/c# stuff can be unpacked using the data libraryes that any dev used to pack that thing, i know some ways around how to unpack that stuff, using tools, or even a code to unpack this data, and if you wonder, i would tell yo the key is incide the dat file or the .something URL: https://forum.audiogames.net/post/414980/#p414980 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? I am also watching this topic as well. URL: https://forum.audiogames.net/post/414936/#p414936 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? I'm keeping an active eye on this topic. I definitely do not want to start seeing specific descriptions of how to break games, as BGT is still a language many devs use and we don't need them feeling as if they're going to be at risk by default. URL: https://forum.audiogames.net/post/414852/#p414852 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? hiI finded the thing called flm or something like that, can anyone tell me how this works? URL: https://forum.audiogames.net/post/414776/#p414776 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? i agreed, please watch this topic, URL: https://forum.audiogames.net/post/414755/#p414755 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? Admins, could you please watch this topic? I feel here lies the potential for a great deal of destructive information getting leaked, the last thing this community needs is the ability to rip assets out of games especially in these times.I'll go ahead and skip to the second portion of your question, as I believe there's enough dishonesty to go around without a publicly easy-to-follow guide for everyone. This is done following standard disassembly. thus, I'd be lying if I said there was a good one fits all protection mechanism.Redfox, sounds.dat can be broken. Serverside sounds are not only an insane usability sacrifice but false sensse of security. Let's not make our games suck because we're spending more time attempting to devise complicated algorithms to prevent someone from getting your sounds. That's what a license is for.The short and generic answer, if someone is smart and determined they'll break your protection no matter what. If the computer is able to read it, so can a well skilled attacker.However, you can make the process significantly more difficult. As someone who considers disassembly a hobby, I can only give a couple rough bits of information. It's then your job to combine them into as tight of a system as possible. If you would like me to give suggestions on a specific implementation, get in contact off forum. I'll try to put it as simply as possible without really getting into technical Intricacies.Builtin functions are a partial issue. Given the ease of determining an address for a function in the BGT standard library, one can simply wait until it is called and get more information. Take string_encrypt for example.The attacker would probably allow your game to execute until he found a call to the address of string_encrypt, obtainable with any decent disassembler. He could then examine the parameters or return values. Mathematical operations can be harder to track down however, since the computer is performing hundreds per second. Basically, try and avoid the call to builtin functions for encryption whenever possible. Stick to your own system. I personally recommend doing a bit of research into bitwise or ascii. I stress again, math is really helpful here. Try generic byte rotation/shifting. That way your in effect creating multiple layers to sort through. If the attacker gets the parameters to string_encrypt, they'll be encoded by your own method as well so he can't just throw the key into a 20 line extractor. As I'm sure you can tell, I'm being vague and purposely so. Most of the time it's really more trouble than it's worth and I hope people would eventually grow to understand that. URL: https://forum.audiogames.net/post/414744/#p414744 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? Admins, could you please watch this topic? I feel here lies the potential for a great deal of destructive information getting leaked, the last thing this community needs is the ability to rip assets out of games especially in these times.I'll go ahead and skip to the second portion of your question, as I believe there's enough dishonesty to go around without a publicly easy-to-follow guide for everyone. This is done following standard disassembly. thus, I'd be lying if I said there was a good one fits all protection mechanism.Redfox, sounds.dat can be broken. Serverside sounds are not only an insane usability sacrifice but false sensse of security. Let's not make our games suck because we're spending more time attempting to devise complicated algorithms to prevent someone from getting your sounds. That's what a license is for.The short and generic answer, if someone is smart and determined they'll break your protection no matter what. If the computer is able to read it, so can a well skilled attacker.However, you can make the process significantly more difficult. As someone who considers disassembly a hobby, I can only give a couple rough bits of information. It's then your job to combine them into as tight of a system as possible. If you would like me to give suggestions on a specific implementation, get in contact off forum. I'll try to put it as simply as possible without really getting into technical Intricacies.Builtin functions are a partial issue. Given the ease of determining an address for a function in the BGT standard library, one can simply wait until it is called and get more information. Take string_encrypt for example.The attacker would probably allow your game to execute until he found a call to the address of string_encrypt, obtainable with any decent disassembler. He could then examine the parameters or return values. Mathematical operations can be harder to track down however, since the computer is performing hundreds per second. Basically, try and avoid the call to builtin functions for encryption whenever possible. Stick to your own system. I personally recommend doing a bit of research into bitwise or ascii. I stress again, math is really helpful here. Try generic byte rotation/shifting. That way your in effect creating multiple layers to sort through. If the attacker gets the parameters to string_encrypt, it'll be encoded by your own method as well so he can't just throw the key into a 20 line extractor. As I'm sure you can tell, I'm being vague and purposely so. Most of the time it's really more trouble than it's worth and I hope people would eventually grow to understand that. URL: https://forum.audiogames.net/post/414744/#p414744 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: decrypting bgt stuff?
Re: decrypting bgt stuff? Unfortunately, there's ways to rip sounds and data no matter how you encrypt it, you could package them in a dat file or something, or in the game's exe, it doesn't matter, there's ways around it.I've entertained the idea of completely serverside sounds... URL: https://forum.audiogames.net/post/414733/#p414733 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
