Re: Proof that Windows is bloatware
Posted: Mon Oct 10, 2011 6:45 pm
The new version of +1 ?Blood wrote: This!
http://www.purebasic.com
https://www.purebasic.fr/english/
The new version of +1 ?Blood wrote: This!
Isn't Mono deprecated now though? I thought I read Novell had been bought out and the company that took them over had laid off developers and pulled the plug on any further Mono development.Foz wrote:Then they started giving it away to bring over the stragglers, and now many MANY developers use .net. Even in the Linux camp they use it (heck, Ubuntu has Mono integrated in it for many of it's applications!)
Try to keep up, it.s the .net version!The new version of +1 ?
Best reply so far!Ramihyn_ wrote:Maybe Microsoft is trickier then we thought and the 30 mb download is part of the compatibility test. Because if you think 30 mb is a waste and too much, then you DEFINATELY dont want to upgrade to vista or Win7
Codewall Assembly Encryption or Spoon studio might be want you want.Danilo wrote:Just would be nice to know another trick to precompile full .EXE's. I couldn't get this to work here with .EXE's,
just with .DLL's. Thanks in advance!
Sounds like marketing hype to me. EXE's were reverse engineered all day long before .net and CIL came out. Heck, some of the guys even had some informal contests to reverse engineer code on this forum! Reversing a .net exe just requires a different tool (or set of tools) from the built-in microsoft tools.Foz wrote:... a .net exe *cannot* be reverse engineered. At all.
No X86/x64 cpu can run encrypted code. So there will be a loader which decrypts the code before execution. Software has done that for decades and it is just one method to make reverse engineering more difficult.Foz wrote:Go ahead and decrypt AES-256 encrypted executable code.
Or, more accurately, it is as difficult as converting native executables back to C/C++ code.
IF all the program does is encrypt the code, then it likely does less than an obfuscator. In order to run, IF it's just encrypted CIL code that needs decrypting to run, then the decryption algorithm is built in, and that encryption is pointless to anyone with a machine-code disassembler and five minutes. Heck, I once had to reverse engineer a "32-bit only" hardware driver that had encryption built in, and it was as easy as opening a hex editor that would show asm op-codes. Now I have a driver that works with "any cpu"...but the point is that code encryption is a very tiny hurdle to jump over in terms of code security. In this day and age, you can do little more than slow the determined. Sometimes you can spend hours, days, or big bucks to make the inevitable only delayed by a few seconds.Foz wrote:Go ahead and decrypt AES-256 encrypted executable code.