Obfuscated code

[balzer]

Here is offuscated code sample, it obfuscated binary, seems

%b=Array(c(077),c(090),c(144),c(000),c(003),c(000),c(000),c(000),c(004),c(000),c(000):
..this line is 275413 characters long::c(000),c(000),c(000),c(000 ),"")

which encoding method is used to obfuscate binary? This is not base64.

thanks.

 

[Thomas 'PointedEars' Lahn]

Here is offuscated code sample, it obfuscated binary, seems

%b=Array(c(077),c(090),c(144),c(000),c(003),c(000),c(000),c(000),c(004),c(000),c(000):
.this line is 275413 characters long::c(000),c(000),c(000),c(000 ),"")

which encoding method is used to obfuscate binary?
c()

This is not base64.

You don't say.


PointedEars

 

[Lasse Reichstein Nielsen]

Here is offuscated code sample, it obfuscated binary, seems

%b=Array(c(077),c(090),c(144),c(000),c(003),c(000),c(000),c(000),c(004),c(000),c(000):
.this line is 275413 characters long::c(000),c(000),c(000),c(000 ),"")

which encoding method is used to obfuscate binary? This is not base64.

It'll be a shot in the blind without access to the definition of "c", and
the code doesn't even seem to be JavaScript ("%b" isn't a valid identifier).
A link to the the source would make it much easier to investigate it.

However, a qualified guess is that the numbers are simply the byte
values of the binary file (which seems to be a DOS or Windows
executable).

/L

 

[Richard Cornford]

Here is offuscated code sample, it obfuscated binary,
seems

%b=Array(c(077),c(090),c(144),c(000),c(003),c(000),c(000)
,c(000),c(004),c(000),c(000):
.this line is 275413 characters long::c(000),c(000),c(000)
,c(000 ),"")

which encoding method is used to obfuscate binary? This
is not base64.

Somewhere in association with this is a function named 'c' or some
code that creates a function named 'c' (most likely the latter as this
style of obfuscation usually includes an attempt to conceal the
decoding function). Finding that function definition, or using the
code that creates to extract the function definition, will show how
these numbers are being handled, and so probably expose how they are
'encoded'.

However, things may not be quite as simple as they may appear as the
input numbers literal are not simply related to the numbers they
represent. Javascript has provision for octal number literals, which
commence with a zero. So 077 is (or may be, as octal literals are not
required by ECMA 262 3rd Ed.) an octal literal, and so is (or may be)
- ((7*8)+7) -, or 63, while 144 is a decimal numeric literal. But
ECMAScript does not allow a zero as the first character in a decimal
numeric literal unless it is the only character in the literal,
immediately followed by a decimal point or immediately followed by an
"ExponentIndicator" (one of 'e' or 'E'), and octal literals may not
contain the digits 8 and 9, so values such as 090 are ECMAScript
syntax errors that, if they 'work' at all, are relying on a non-
standard extension to the language where, presumably, they are
interpreted as decimal.

Richard.

 

[7String]

However, a qualified guess is that the numbers are simply the byte
values of the binary file (which seems to be a DOS or Windows
executable).

 

[Lasse Reichstein Nielsen]

yes, most likely its a byte values of the binary file
(executable). How an executable been converted into this strings in
order to be restored in an original form?

That's impossible to say without seeing the code.
/L

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Thu, 6 May 2010 18:32:27, balzer <[email protected]
september.org> posted:

Here is offuscated code sample, it obfuscated binary, seems

%b=Array(c(077),c(090),c(144),c(000),c(003),c(000),c(000),c(000),c(004)
,c(000),c(000): .this line is 275413 characters long::c(000),c(000),c(0
00),c(000 ),"")

which encoding method is used to obfuscate binary? This is not base64.

I doubt whether that is JavaScript as much as I doubt that your native
language is English. Therefore, there is no reason to consider leading
zero as indicating octal.

Taken as decimal representations of 'ASCII', the first two characters
are MZ, the third is hex 90. That pattern, followed by sparse numbers,
is characteristic of MSDOS/Windows executables.

For examples, see sig, use >mtr -h \windows\*.exe or similar.

So the coding seems trivial, well short of crypto; but malware detectors
may not decode it.