Does PureBasic insert an identifier in your executables?

[Bonne_den_kule]

6. Java bytecode is interpreted.

YES! (or better: it's executed by the java vm, it's code but not of a real existing architecture)

False, it uses a JIT compiler on most systems. Same applies to .NET's CIL.

[luis]

6. Java bytecode is interpreted.

YES! (or better: it's executed by the java vm, it's code but not of a real existing architecture)

False, it uses a JIT compiler on most systems. Same applies to .NET's CIL.

False is a word in the same category of "never", "always", "the best" and the like.

The "or better" was indeed better IMHO. Java is not *exactly* interpreted, and it's sometime (and originally it was exclusively) executed by a VM, executing the code of a not existing real architecture. Obviously, like any VM born to give architecture independency, the implementation on a particular platform can be translated in the local architecture's machine code through JIT compilation. So, you are right too (and I forgot to mention that additional case), but *it's not a rule*.

"The JVM runtime executes .class or .jar files, emulating the JVM instruction set by interpreting it, or using a just-in-time compiler (JIT) such as Sun's HotSpot. JIT compiling, not interpreting, is used in most JVMs today to achieve greater speed."

http://en.wikipedia.org/wiki/Java_Virtual_Machine

.NET is JIT in the Microsoft implementation, but it can be created obviously (and it has been) a compiler for C# (for example), who can directly generate machine code instead of CLI instructions.

That's the reason why I wrote "As often happen there is no simply black and white only".

Let's say almost all the absolute statements made by toledo requires a preamble specifying a context, or are simply debatable when not just very far from the thruth. He really believes his thruth it's the only one (should be clear by now), and I know there are a lot of people who believe the same. One thruth, one "best", "always", no questions.

[tempest]

Meh..I'm a noob in the reversing scene and I can unpack PE protectors way harder than the smartest person here can code..so good luck with renaming those symbols. Reversers use call stacks and tracing..obfusc doesn't even stop noobs. I can do AES encrypted binaries with a fob based loader..and I'm not nearly as talented as most..

Use SecuRom, TheMida, or a hardware fob, and hope like hell nobody takes much interest. No protector anyone cares to mention can prevent anything. Everything including .NET, JVM, Flash WITH protectors is activly being reversed. PB is a PE builder/compiler...

SecuRom is the most sophisticated PE protector outside some hardware fobs, and you see how much good it does, all it's assets are pirated. That protects assets worth hundreds of millions..

My method: encrypt content that gets decrypted with a hash loader over SSL connection, and still hope nobody takes interest..good luck

Also people who think C++ is cool and lambast high-level languages are the same people who praise Linux and Mac and have no idea how they work..just pathetic consumers...to piss them off ask to see their work.

I seen this thread before going to bed and registered to post this, I also use PB but can code in both RISC and CISC. PB is productive, if you don't like it go develop your vaporware and write your C++ that is probably loaded with buffer overflows and memory leaks..

[Kaeru Gaman]

@tempest

why the heck worry? PureBasic compiles into optimized ASM.
it's almost impossible to re-construct the Basic sourcecode, and with the ASM-source with unnamed variables you can win NUFFIN.

... and if the heck you invented something that was really really really worth the protection efford,
you should rather open it's source and get the bloody Nobel price for it.

[tempest]

@tempest

why the heck worry? PureBasic compiles into optimized ASM.
it's almost impossible to re-construct the Basic sourcecode, and with the ASM-source with unnamed variables you can win NUFFIN.

... and if the heck you invented something that was really really really worth the protection efford,
you should rather open it's source and get the bloody Nobel price for it.

The actual instructions mean nothing, even mediocre release teams can build a PE/COFF file from scratch with dumped PE. PE uses sections as does ELF(Linux and Mac). They have import tables and some other sections. DRM encrypts strings and imports, redirects imports, replaces bytes, moves region offsets, uses native api from a stub to detect debuggers, and in the case of the harder protectors uses hardware dongles with isolation keygen, byte translation, or decryption routines. Also the latest trend is inline VMs. SecuRom and StarForce have a different VM and crypto for every protected asset, ISO release teams do these in a night.

Most vendors pay for product development, it's meant to be an investment. You can't fund a company off just product support despite popular belief with OSS. A software engineer expects at least 50k a year..

Code complexity is the best DRM. Functional algorithms make things hard, some stuff keygenners and seasoned reversers can't even do, but these aren't on populer software. Also server checks that sign used content with subscriber specific hashes are extremely effective. As it stands no Java or Flash protector is undefeated, there exists some PE stuff, but one of 3 of those is x64 only.


Another note on Java, it's extremely easy to decompile to high level syntax. Even JVM protectors decompile it and wrap it with a runtime decoder stub then turn it back to structured byte code. PB and C/C++ do compile to x86 instructions, and reversers can even write it. Sometime cracks even have inline patches which is custom written ASM in a spare space in the PE.

[Thorium]

tempest is absolutly right.
On my experience the problem is that most people trying to protect there software don't know how cracking works. And that a encryption don't protects at all. The key must be inside the executable otherwise it could not decrypt it self. But as a reverser you don't have to find the key you even don't have to understand the encryption and you don't have to decrypt. Why not? Because thats all included in the executable. Let it decrypt itself. Thats how it's done. Encryption means nothing. The clever protections damaging the actual code of the software and implement a exception handler that repairs the code if execution reaches it. That should protect against removing of the protection code because the exeption handler is part of it. But again, the reverser just have to find it and execute it so it will do the work for him.

Thats how it work. A cracker let the software crack itself. Keep this allways in mind if you think about protection.

[tempest]

If you really wanted to you could obfuscate strings with peek and poke functions from entry point without even using ASM, and make do some anti-debug with native API.

If I thought there was a market for it I'd make a static library that has a RISC VM. Have something like startvm() and stopvm(), these would provide pointers the ladder would use to start a VM thread, this would only work though if the compiler supported directives, if not the only thing you could do from static is anti-debug, or crypto that would be vulnerable to static analysis and unpacking.

The other would be a PE rebuilder like most are, and put a lot of work into something that has already been done. I'd either do a dongle or like StarForce has recently and do crypto server stuff.

The weakness with most dongles is they bring routines and/or keys into readable memory, or the chip ROM gets dumped. You can also glitch chips to cause memory leakage or the chip to execute adresses that can be injected.

[Blue Steel]

anything you can do to protect or hide your work people can and will get around it if they want.. after all it is software and by that very nature can be probed reverse enginered (just like anything else really) just like doors locks secutity screens only keep out the honest people. If they really want in they'll find a way.

Software by its nature stores elements or headers or reference material so that the computers running it knows what its looking at and how to decipher the following code.

all that being said, Theres never any real reason to hide what language you've used (because no matter what you do people will get around it). you just make it as secure as you can. those looking to see what language something is written in are usually after 2 things .. 1. to reverse engineer (you should feel flattered that someone thinks your software is wirth going to all that hastle) 2. to learn what language made that software .. which means that they are interested in what languiage you used so that they can probably use it too. Either way its a credit to you and that language you've used that you have people interested in looking at your code. Not a negative..

[Rescator]

Anything that is intended to run on end user hardware can have it's protection bypassed,
but "cloud computing" will never be the solution either, latency and load will always be issues there, and the ones running the cloud suddenly have much more data backup responsibility than normal software. If you forget to back up on your system, then that is your issue not the software maker. But with cloud they have to guarantee safe backups. (or loose you to the competition). And the subscription model is always more expensive than singular purchase anyway.
It's going to be interesting the next decade, but I'll probably still be programming with PureBasic then as well