PureBasic Forums - English

The reason I asked if PureBasic inserts an identifier is because people who reverse engineer software first find out what compiler was used to build the program. Then they write functions to extrapolate which source code would produce the compiled code. Without identifiers, it's much harder to reverse engineer your software and most people won't even try.

since purebasic first creates optimized ASM-code and then compiles this, it would be a helluvamess to try to reverse-engineer any code.

... anyhow, I would not be too afraid of reverse engeneering.
only in very few very special cases you'll get anything useful from it.

greyhoundcode wrote:UserOfPure, Nituvious, shall we have a group hug?

I like hugs...

toledo wrote:The reason I asked if PureBasic inserts an identifier is because people who reverse engineer software first find out what compiler was used to build the program. Then they write functions to extrapolate which source code would produce the compiled code. Without identifiers, it's much harder to reverse engineer your software and most people won't even try.

Actualy decompilation is not much used for reverse engineering to machine code compiled programs. It's only used for easy to decompile applications, like Java and dotNET.

I reverse engineered a bit to write tools for games and even made unofficial patches that fixed bugs and i never ever decompiled anything. As i started with reverse engineering i tied it but it just did not work out. I even don't find a working decompiler. Yes there are some that produce recompilable code, but it's just 99% inline assembly. ^^

Reverse engineering is done with assembly level debuggers like OllyDbg or Softice or any other.

Just do a search/replace of all "pb_" bytes in the executable then. The exe will still run (I just tried) and there won't be any obvious references to PureBasic.

UserOfPure wrote:Just do a search/replace of all "pb_" bytes in the executable then. The exe will still run (I just tried) and there won't be any obvious references to PureBasic.

Thankyou very much. That exactly what I'm going to do. Does that also work with words like "Gadget"?

Try it! :roll:

toledo wrote:

UserOfPure wrote:Just do a search/replace of all "pb_" bytes in the executable then. The exe will still run (I just tried) and there won't be any obvious references to PureBasic.

Thankyou very much. That exactly what I'm going to do.

Is it worth the effort? I don't see any sense in doing this.

c4s wrote:Is it worth the effort? I don't see any sense in doing this.

Imho some people are afraid to admit they are using basic, c++ is so much cooler and looks more professional, especially if the exe is big with a lot of DLLs and .NET dependency.

why don't you practice programming?
FIRST grow your skills to a level where any of your products become WORTH being reverse engineered, THEN worry about it.

Even without the strings, it's very easy to detect if it's a PB executable, as we are linking to custom libraries which can be easy identified.

toledo wrote:people who reverse engineer software first find out what compiler was used to build the program. Then they write functions to extrapolate which source code would produce the compiled code. Without identifiers, it's much harder to reverse engineer your software and most people won't even try.

I hope you are not talking about decompilation here (an entriely different matter), but instead about some tool that knowing the compiler used the generate the code, and knowing its code generation patterns can try to rebuild some high level constructs from this.

But in my opinion to reverse eng. a software you just need a disassembler, years of experience and a extremely good knowledge of both machine code and os calls. If you change some compiler/linker generated strings inside the exe this will not stop a person like the above mentioned, so it's quite useless. You are better off trying to wrap your code in some way (just to slow him down or to make this not worthy, not to stop him).

A tool like the one you mentioned would be really lame, because it's extremely easy to disrupt this ideal situation the tool is expecting, and it cannot be reliable at all in many cases. Would be a lot lot lot harder to write something like this than the compiler.

gnozal wrote:c++ is so much cooler and looks more professional, especially if the exe is big with a lot of DLLs and .NET dependency.

True. Fred, can we add a BLOATWARE option? It should quadruple the file size (at least) and make it run 10 times slower!

Nope, to simulate large .Net apps PB apps would need to be at least 25% slower, be capable of crashing the entire system at the most inconvenient moment possible and only after the User has created an hour's worth of work and is less than two milliseconds away from saving it

Frankly, the people that use your application do not care what tools you used to craft it, they only care about how well it works, how reliable it is and how easy it is to use.

Foz wrote:10 times slower!

IdeasVacuum wrote:Nope [...] at least 25% slower

Well, "10 times" is 40 times more than "25%".