Talk:Obfuscation (software)

There's a long list of "recreational" examples that are not cited in any way. They may also have POV, given use of some words without a source ("unintelligible", "famous", "extremely difficult"...). Also, the last example is way too long to illustrate a minor (?) section of the article.Otus (talk) 13:57, 12 June 2008 (UTC)Reply

Given there were no objections, I went ahead and made some changes. I removed the NPOV tag as well as the citation tag. MLetterle (talk) 17:34, 4 April 2008 (UTC)Reply

Full Disclosure: I work for PreEmptive Solutions, creator of Dotfuscator. That being said, I notice that the article has a nice long section on the "Disadvantages of Obfuscation", would there be any resistance to adding a section called "Advantages of Obfuscation" (and perhaps add the word "Perceived" to both?) MLetterle (talk) 12:19, 27 March 2008 (UTC)Reply

Maze program compilation section rewritten to point out that -fwritable-strings is not available anymore as of gcc 4.0. I also added a link (right after the Perl example) to obfuscated Python examples found in the official FAQ.
Tekkaman 13:12, 5 April 2007 (UTC)Reply

#include <stdio.h>
main(t,_,a)char *a;{return!0<t?t<3?main(-79,-13,a+main(-87,1-_,
main(-86,0,a+1)+a)):1,t<_?main(t+1,_,a):3,main(-94,-27+t,a)&&t==2?_<13?
main(2,_+1,"%s %d %d\n"):9:16:t<0?t<-72?main(_,t,
"@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l,+,/n{n+,/+#n+,/#\
;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l \
q#'+d'K#!/+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# \
){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#n'wk nw' \
iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c \
;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'{n' ')# \
}'+}##(!!/")
:t<-50?_==*a?putchar(31[a]):main(-65,_,a+1):main((*a=='/')+t,_,a+1)
  :0<t?main(2,2,"%s"):*a=='/'||main(0,main(-61,*a,
"!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry"),a+1);}

this example did not compile in Borland for some reason

Am I the only one who thinks this article has a few inaccuracies? Obfuscation of the source code makes no difference to the output of a decompiler. Variable names in the source code of any compiled language is reduced to addresses in the final object code. These addresses take the same space regardless of how long the variable name was in the first place.

I'm hacking this article until its not wrong!

You are absolutely wrong. Your model is too simplistic, and will even be more so after the C++ committe meets in a few years. Your claims only hold true for a very few languages, like C.

I wrote these parts of the article from a position of experience, while your claims are from a position of theory. Therefore your theory does not consider enough variables. One phrase: Symbol tables. These tables are important for many forms of dynamic programming (such as Reflection) and are stored with the bytecode/executable/interpreted script in a great number of languages.

And furthermore, there is more to obfuscation than just simple renaming. I've heard that Microsoft in its early days inserted instructions that confused and broke common debuggers, to resist analysis of their programs. Obfuscation also covers the realm of destroying all structure that would lend a program to human-readability.

If you look at sourcecode, it is well-structured. It is decomposited into functions for Structured Programming, objects of OOP, etc. Compilers tend to propagate this structure into compiled code. Obfuscators erase as much of this as possible. -- forgotten gentleman

This sentence doesn't make sense as it is or is mal-formed, should be corrected: "Obviously this limitation does not apply to intermediate language (Java, C#, etc.) obfuscators, which generally work on compiled assemblies rather than on source code."

"Microsoft recommends using the Script Encoder to obfuscate the ASP files" - as far as I know, Microsoft encloses and recommends Dotfuscator in current versions of .Net

That is two articles of mine that have been deleted, out of three. One of them having been my user page. This is extremely frustrating. I am just deleting my entire entry until I have time to revert it with deeper explanations. -- forgotten gentleman

The following sections of this article were removed (by "forgotten gentleman"); I'm putting them on this /Talk page for future reference.

== Uses for obfuscation == There is generally little point in plain obsfuscation of source code although some cases include:

• Attempting to "protect" the IP of something that has to provided in

source form (for platform portability)

• Some code-generators (e.g. SDL) generate hard to read

code, on the basis that you should tweak the design not the code. When dealing with interpreted languages it could be argued that smaller (but less undestandable) variable names will keep code size down. However this is a false economy OK that wasn't NPOV

==Can't obfuscation also be useful for opromization? Especially with interpreted languages?

Obfuscated code is extremely difficult to debug. Variable names will no longer make sense, and the structure of the code itself will likely be modified into unrecognizability. This fact generally forces developers to maintain two builds: One that can be easily debugged, and another for release. Both builds should be tested to make sure they act identically.

Occasionally an obfuscator may be buggy, in a difficult to reproduce way. There is little one can do except find a newer version or fiddle with any inputs to the obfuscator until it works.

You are absolutely wrong. Your model is too simplistic, and will even be more so after the C++ committe meets in a few years. Your claims only hold true for a very few languages, like C.

Well what may happen in the future is irrelevant to an encyplodedia. My claim holds true from at least all compiled languages I've dealt with. Bytecode I'm less familiar with so I'll have to check my facts on that, although I'm sure its very implentation dependant.

I wrote these parts of the article from a position of experience, while your claims are from a position of theory. Therefore your theory does not consider enough variables. One phrase: Symbol tables. These tables are important for many forms of dynamic programming (such as Reflection) and are stored with the bytecode/executable/interpreted script in a great number of languages.

I'm sorry but symbol tables are an irrelevance from my experience. If you don't want people to know the names of your functions you strip the symbol table. Its only of use to debuggers.

That is two articles of mine that have been deleted, out of three. One of them having been my user page. This is extremely frustrating. I am just deleting my entire entry until I have time to revert it with deeper explanations.

I don't know what other pages have been deleted, I'm just arguing about this one.Welcome to Wikipedia

And furthermore, there is more to obfuscation than just simple renaming. I've heard that Microsoft in its early days inserted instructions that confused and broke common debuggers, to resist analysis of their programs. Obfuscation also covers the realm of destroying all structure that would lend a program to human-readability.

I'm sorry but breaking debuggers is not the issue here. People have written plenty of hairy code to attempt to confuse debuggers (I know I've had to bypass some of them), but thats a whole different ball game (and completly pointless IMHO).

If you look at sourcecode, it is well-structured. It is decomposited into functions for Structured Programming, objects of :OOP, etc. Compilers tend to propagate this structure into compiled code. Obfuscators erase as much of this as possible.

Unless your talking about binary obfiscators your the type your talking about must just wreak code they touch. A linked list looks the same in assembly if its nodes are called wikjn and koip instead of n and p. Anything that fiddles with internal structures will just break stuff. If binaries generated by the source-code and its ofuscated equivilent are not identical then its defeated its own point.

I don't want this to become a "Your Wrong" and "I'm right" argument so I would welcome any other points of view?

Since neither of you two care to sign your respective statements, I don't know which if yours is which, but I'm sure at least one of you is clearly not helping to write a useful article. The fact is, "obfuscators" are commonly used pieces of commercial software that perform a specific function for specific reasons, and your opinion of their worth is out of place here. This is an encyclopedia, not a chat room. If you think obfuscators are worthless (I happen to agree for different reasons), then don't write one or buy one, but don't interfere with someone trying to write a useful article on the topic. Symbol removal and substitution is one method (if you think symbol tables can just be stripped, then you obviously don't program in a language with reflection), as is code rearrangement, debugger fouling, and others. Commercial software has used these and other methods, and they should be documented here. --LDC

Since neither of you two care to sign your respective statements, I don't know which if yours is which, but I'm sure at least one of you is clearly not helping to write a useful article.

I think we both want a useful article. Hence I've moved the discussion into talk to gain consensus.

The fact is, "obfuscators" are commonly used pieces of commercial software that perform a specific function for specific reasons, and your opinion of their worth is out of place here.

As you may of picked up I don't think obfuscators are worth much at all but agree there should be an article about them. I just don't want it to be inaccurate.

This is an encyclopedia, not a chat room.

I hope its debate rather than chat.

If you think obfuscators are worthless (I happen to agree for different reasons), then don't write one or buy one, but don't interfere with someone trying to write a useful article on the topic.

I'm venturing an opionion as to why I think the article if flawed. I attempted to correct it the Wikipedia way, found the original author disagreed and reverted the change, so I question the assumptions and statements in /Talk. Now we are debating to get a better article.

Symbol removal and substitution is one method (if you think symbol tables can just be stripped, then you obviously don't program in a language with reflection)

The article already states you can't obfuscated code that uses reflection. Where mangling the names is allowed where do you need the symbol table? Answer you don't, therefor can strip it. The renamed functions aren't hiding anything in the underlying code. But the way the article is written thats what is implied. See:

This is wrong on both counts. You can use obfuscators on languages with reflection, and even on code that specifically uses reflection (though you have to account for it). Secondly, renaming variables and methods does hide information. Human-meaningful names are valuable information to a (human) debugger and reverse-engineer. I don't see how you can possibly argue otherwise. Renaming may not hide what the code actually does, but it does hide the programmer's intent, and sometimes that's enough to seriously impede reverse-engineering. --LDC

Compilers tend to propagate this structure into compiled code. The job of a good obfuscator is to destroy as much as possible of this structure that lends a program to being human-readable.

A good obfuscator is one that can generate logically identical source code that creates indentical binaries for textually different source code. Which is the exact opposite to what the article says.

, as is code rearrangement, debugger fouling, and others.Commercial software has used these and other methods, and they should be documented here. --LDC

No. They are different techniques for defeating crackers. They are different from obfuscating source code. Sure document them in Wikipedia but not in this article.

We seem to be disagreeing about the definition here, so let's quare that away first. An "obfuscator" (as the term is used by actual commercial software available today) is a program that makes reverse-engineering difficult. Changing source code into logically indentical source code is one--and only one--method of doing that, and it is indeed the origin of the term. But even the source-only obfuscations are not purely textual, some are algorithmic (i.e., making the algorithm difficult to follow). Another method is changing the actual structure of the code to something functionally equivalent (but not logically indentical). Another is applying transforms on the resulting object code. Have you actually browsed to see what kinds of obfuscators are available and what they actually do, or are you just talking theory from some textbook? --LDC

I accept blame if I've pushed this into a heated argument. I have unfortunately been in a foul mood for the last days, and I know this has seeped through into this article. (I admit, it did not help for you to say that you simply couldn't stay within the NPOV, marring the article right in the middle to say that.) But let's get past that and get to writing good articles. I'll offer my input to a few points raised here.

As you may of picked up I don't think obfuscators are worth much at all but agree there should be an article about them.

I agree that they're white elephants. To keep NPOV, I limited myself to an enumeration of advantages and disadvantages.

However, on a project where code size reduction was absolutely crucial, it worked well. (FYI, this was in Java. The size reduction was definitely nontrivial, even accounting for compression.)

I'm sorry but breaking debuggers is not the issue here. People have written plenty of hairy code to attempt to confuse debuggers (I know I've had to bypass some of them), but thats a whole different ball game (and completly pointless IMHO).

I would suggest what you've encountered was an operation on the code which kept it to spec, but made it more difficult for you to "read and understand." From my perspective, having been on a project where they actually dedicated a programmer to parse obfuscated code to hand off to a fairly untrusted remote team... it fits all reasonable definitions of "obfuscated code" to me. In spirit and to the letter.

If your experience is mainly about the fun obfuscation contests, I can see how you would disagree.

A good obfuscator is one that can generate logically identical source code that creates indentical binaries for textually different source code. Which is the exact opposite to what the article says.

We have different conceptions of obfuscators. I believe you have your conception from the fun contests. In my conception, an obfuscator keeps the translated program conformant to a black-box spec. Since obfuscation has all sorts of side-effects (performance, code size, etc), it is not always possible to use an obfuscator which works well on most other programs.

Where mangling the names is allowed where do you need the symbol table? Answer you don't, therefor can strip it.

I thought about explaining this by referring to lexical scoping, but I thought better of it. Now I wish I had.

Here, I believe you're thinking too quickly. Static languages promote a sense of determinism. Dynamic ones don't, because code from outside the system may happily interact with its internals. So, getting rid of the symbol table is a net loss of information that may have undesirable effects. One bad effect is to destroy the whole point of having a dynamic language.

Tell me quickly how to strip the symbol table for a Java program, using javac. You can't. The symbol table is not merely a debugging aid in dynamic languages; it's the point. However, an obfuscator may do this, fully or partially, depending on how much you need the dynamism.

The article already states you can't obfuscated code that uses reflection.

That's definitely a valid misunderstanding of the article's earlier versions. I was very unclear.

You can configure an obfuscator to leave parts of your code unrenamed.

I wish this article was expanded much more to explain these contests. I want the boring IP aspects to be a smaller section. However, I can't really speak about the contests, since I've never participated. -- forgotten gentleman

Again, I am being extremely imprecise WRT reflection -- you can obfuscate code with reflection, you just have to make sure everything calls the obfuscated name. I don't know why I didn't mention this; it's always the main source of complexity when doing painfully obfuscated builds.

It just defeats the point, since oftentimes classnames are constructed according to a spec. It's not just a matter of "having a name." -- forgotten gentleman

I've moved a few bits of text around and re-arranged the recreational obfuscation bit and added an example the usenet. I've not touched the second part but I'm still unhappy with statements that refer to messing with the internal structure of the code. Maybe a category like "Protecting code from reverse engineering" would better cover some of these weird and wonderful binary obfuscators.

Does the usenet example really have tremendously long lines, or did a couple of newlines get lost somewhere? --AxelBoldt

Actually, please modify as you wish. I promise to not throw a tantrum again. ;-) I was not myself; dealing with a very volatile person last week, I became irrational too.

I don't quite understand what you don't like about the internal structures part, so I'll just see what your modifications are. If you mean that breaking internal structure doesn't decrease codesize much with current obfuscators, maybe I'd better look more closely to see where the size savings come from.

Funny, I just now looked at the Jax homepage http://www.research.ibm.com/jax/ and they use language similar to this article's. I definitely should have done research, because they are more precise than my off-the-cuff revisions. -- forgotten gentleman

very short and unimportant comment. Is really "atacker" an appropiate name for somebody trying to do reverse engineering? --AN

Hi,

I stumbled accross this entry and added a link to my own paper on the topic (or more accurately, to an essay I once wrote explaining that paper: http://www.cs.princeton.edu/~boaz/Papers/obf_informal.html).

I normally wouldn't do that but the entry seemed to lack any of the security-wise criticism of obfuscation. I thought the least I could do is "confess" to the self-citation.

Boaz Barak

What I am missing on the page is the distiction between source code transformation steps that leave the machine code/binary (almost) intact (as mentioned before in this discussion!), and those that (try to) obfuscate the binary as well. Examples of the latter are control obfuscations and data obfuscations as discribed in this document: http://www.cs.arizona.edu/~collberg/Research/Publications/CollbergThomborson2000a/index.html

Maybe give some examples of code transformations.

Michiel Visser

re: "Code Morphing"

I am not a Wikipedian, but I must point out that the "Code Morphing" section reads like a sales spiel for a specific commercial product. The section contains a lot of text copied from the website of "Strongbit", the vendor selling "EXECryptor." It is not clear that this text conforms to the standards of scholarship one would expect of a reasonably good-quality encyclopedia. To someone fairly knowledgable about this topic, assertions such as "code restoration is an NP-hard problem" especially cry out for a summnary of or reference to an actual proof.

The "Code Morphing" section in isolation suffers severely from ignorance of, or refusal to mention relationships to, other related techniques of code manipulation.

In other words, this junk should be removed, or replaced with text better befitting an encyclopedia.

Code Morphing is one of the approaches to protect software applications from reverse engineering, analysis, modifications, and cracking used in EXECryptor obfuscating software. This technology protects the code on the CPU-command level. It is known the x86 processors command system is redundant and allows the execution of the same ‘code’ using various different system commands. It breaks up the protected code into several processor commands or small command snippets and replace them by others, while maintaining the same end result. Thus the protector obfuscates the code not on the source level but on the level of the CPU commands.

The Code Morphing is multilevel technology containing hundreds of unique code transformation patterns. In addition this technology includes the special layer that transforms some commands into Virtual Machine commands (like P-Code). Code Morphing turns binary code into an undecipherable mess that is not similar to normal compiled code, and completely hides execution logic of the protected code.

Unlike other code protectors, there is no concept of code decryption with this system. Protected code blocks are always in the executable state, and they are executed as a transformed code. The original code is completely lost and code restoration is an NP-hard problem.

Using secondary-switch, or hashing methods for ensuring that all pointers get mashed and processed using acual algebra (such as

main(){ char G = 61; char f = *G; char p = qp = 4; char G = !p; char *c = 32 | (*p + *qp) | (*p) + (*G(f)) }

makes the problem NP-complete, since it is possible to arrange the code to effectively require all combinations of the above to calculate the original input strings. The EXECrypor method is reversible in polynomial time, and is technically an NP problem but has not been proved to be NP-hard. On the other hand, all meta information such as variable names, comments, function names, namespaces, classes etc are destroyed during EXECryptor or any other obfuscation program worth it's salt. (no pun intended).

It has been suggested that Code morphing be merged into this article or section. (Discuss)

I agree. I think "Code Morphing" has been claimed as a trademark by Transmeta and I must say that I've not come across it in the context of obfuscation/shrouding. MarkMLl (talk) 20:57, 21 September 2009 (UTC)Reply

Why don't we just merge Wikipedia and text? —Preceding unsigned comment added by 207.138.32.33 (talk) 09:27, 17 October 2008 (UTC)Reply

I can't understand a thing about how that Twelve days of Christmas program works. Neither, I take it, can almost anyone else. Its creator must have had a twisted mind. Has anyone tried to analyse how it works?

• Thomas Ball from MSR has done it [1], Sliwers 19:29, 23 May 2007 (UTC)Reply

Intermediate compiled code such as Java and .NET is often obfuscated professionally. Professional obfuscation of intermediate compiled programs helps protect against reverse engineering while making applications smaller and more efficient. Professional obfuscation may be regarded by some as an example of security through obscurity.

I know of NO instances where binary obfuscation has resulted in faster code while not reducing portability; Obfuscation almost invariably works by taking simple methods such as @call writeln and converting them to their goto.. syntax, which actually takes longer than just letting the OS do the call itself.

With all due respect, simply considering yourself to be an expert on a subject does not qualify you to make undocumented or unverified claims on Wikipedia. This page needs a complete rework, too much redundant information and ego inflating, in my opinion.

I would not consider myself an expert on the matter, so somebody please step up and mercilessly cut the fat from this article. I will correct some of the grammatical and punctuation errors.

Spragc 14:40, 6 February 2007 (UTC)Reply

Reading this article in entirety I found it to be badly organized, thus I changed the headings and removed redundant sections whilst trying to pay as much respect as possible to the original author. Please understand that my goal is to make this a useful article for others (such as myself) with a limited knowledge of obfuscation. I'm guessing from reading the previous discussion that this wiki has suffered a great deal of hacking, so my changes are primarily cosmetic, mostly changing language and removing redundant information.

Here, briefly, are the changes:

-- Improper header importance was given to a set of articles halfway through, it appeared as though somebody has simply pasted another wiki directly into the center of this one.

-- I removed the redundant information which included a general description of obfuscation, and it's use in reverse engineering.

-- A section on defective obfuscators was removed as the defective nature of these programs should be questioned, if these programs are defective by nature, and not "buggy", this should be stated and links to proof or original research cited, please.

-- Grammatical changes were made to the debugging section under disadvantages. These changes were intended not to modify the nature of the article but to increase it's readability.

-- Concealment of evidence title changed to "Uses in malicious software". I believe this to be a much more appropriate header, considering the content beneath this header. Spragc 15:09, 6 February 2007 (UTC)Reply

Would anyone be willing to compile a list or comparison of obfuscators, so that external links can be cleaned up. For the moment I think most of the external links are valid because they are usefull, but it would be even more usefull to give them a page of there own. Martijn Hoekstra 13:42, 9 February 2007 (UTC)Reply

There is reference to a very short list of obfuscators and one is explicitly mentioned. There is a matrix here http://en.wikipedia.org/wiki/User:Scatophaga/Comparison_of_.NET_obfuscators which is more objective and a similar format to other wikipedia articles of this nature. Kallax (talk) 23:16, 18 December 2012 (UTC)Reply

The article focuses mostly on code obfuscation, but data can be obfuscated too.

For example, this occurs with some digital audio players that do not allow normal MP3 files to be played but allow obfuscated MP3 files to be played (The Sony Network Walkman NW-S23[2] uses a substitution cipher). The reason for this is not exactly clear, but Vendor lock-in seems the most probable. I'd be the first to agree that the boundary between obfuscation and encryption seems a bit vague. Anyway just thought I'd mention it to help make the article more rounded. Pgr94 00:26, 13 February 2007 (UTC)Reply

How come this page doesn't mention "HTML encryption"? There are companies selling products for it. It is noteworthy that it is totally useless because any decent DOM analysis tool (i.e. Firebug) would be able to regenerate the real source from the DOM structure. In fact you can regenerate it using a bookmarklet. --Voidvector (talk) 10:25, 18 October 2008 (UTC)Reply

It's "Obfuscated code" and HTML isn't code. MarkMLl (talk) 20:57, 21 September 2009 (UTC)Reply

This article contains way too much source code. It isn't necessary to have more than one or two small examples (the C maze program from the IOCCC is a great one!), nor is it useful to the average reader to show several steps of obfuscating the prime-number generator. This information could be presented more densely, and with more English and less C, by simply describing the obfuscations without necessarily illustrating each one with a full copy of the source code. Thoughts? --FOo (talk) 17:10, 24 December 2008 (UTC)Reply

I have made lots of edits, added links, and in particular split the main example into a separate section (and added a couple of notes). I am not 100% happy with it, but I think it's better than it was. Sorry if I am jumping in with two left feet, but usually I get no sodding responses on the discussion pages so I just go ahead and edit-- then you do! SimonTrew (talk) 13:37, 9 March 2009 (UTC)Reply

This page uses words like "intellectual property" that are incorrect and it consider this usage as advantage. It is not advantage. NPOV shoul consider it as form of usage only. —Preceding unsigned comment added by 81.18.126.50 (talk) 17:52, 14 April 2009 (UTC)Reply

I compiled and ran the code

void primes(int cap) {

 int i, j, composite;
 for(i = 2; i < cap; ++i) {
   composite = 0;
   for(j = 2; j * j < i; ++j) 
     composite += !(i % j);
   if(!composite)
     printf("%d\t", i);
 }

}

and it works fine, but the obsfuscated code

_(__,___,____,_____){___/__<=_____?_(__,___+_____,____,_____):!(___%__)?_(__,___+_____,___%__,_____):___%__==___/ __&&!____?(printf("%d\t",___/__),_(__,___+_____,____,_____)):___%__>1&&___%__<___/__?_(__,_____+ ___,____+!(___/__%(___%__),_____)):___<__*__?_(__,___+_____,____,_____):0;}main(){_(100,0,0,1);}

for this program doesn't do what it's supposed to, and what is worst it ends up with a segmentation fault. —Preceding unsigned comment added by Tyomero (talk • contribs) 23:27, 18 May 2009 (UTC)Reply

however, no one uses such a method of obfuscation because it's not supported by all compilers IDE's —Preceding unsigned comment added by 213.210.194.114 (talk) 07:38, 4 February 2010 (UTC)Reply

the winner "Hou Qiming scientific calculator doc" search using google returns no scientific calculator to download or to study for its documentation. it seems the "best self documentating calculator" is not available.188.25.53.154 (talk) 04:47, 1 March 2012 (UTC)Reply

Hello fellow Wikipedians,

I have just added archive links to one external link on Obfuscation (software). Please take a moment to review my edit. You may add {{cbignore}} after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether, but should be used as a last resort. I made the following changes:

• Attempted to fix sourcing for http://www.devx.com/microsoftISV/Article/11351

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 03:55, 31 March 2016 (UTC)Reply

Hello fellow Wikipedians,

I have just modified 2 external links on Obfuscation (software). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20050308231232/http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html to http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html
• Corrected formatting/usage for http://research.microsoft.com/~tball/papers/XmasGift/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 19:45, 1 December 2017 (UTC)Reply

One of the listed benefits is "shrinking the executable." Likewise, one of the disadvantages is "it may trigger antivirus even if the developer just did it to reduce code size"

This seems to conflate obfuscation with minification and similar optimizations. While source code minification (the removal of comments, whitespace, and sometimes line breaks, and perhaps switching to shorter, less descriptive variable names) could be considered to obfuscate the code somewhat, this is often done simply to reduce bandwidth use and accelerate parsing (e.g. in Javascripts for web) without intent to obfuscate. Similarly, symbol stripping could be considered to both obfuscate a binary executable and reduce its size, but that is usually seen primarily as a size reduction measure, while something speficially designated as an automatic obfuscator would take further measures beyond this. Similarly, machine code produced by a compiler invoked with aggressive optimization flags could be seen as somewhat obfuscated in terms of being less easy to decompile/reverse engineer than non-optimized code, but again this is incidental, and not really seen as within the domain of obfuscation.

I would think that any deliberate obfuscation outside of these measures (which are not strictly obfuscation techniques, even if they can have that effect to some extent) would tend to increase code size and complexity rather than reduce it, by doing things in a more complicated and roundabout way than necessary. Nlburgin (talk) 17:16, 7 March 2019 (UTC)Reply

I have tagged both offending statements with Template:How Nlburgin (talk) 17:51, 7 March 2019 (UTC)Reply