Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Program Hides Secret Messages in Executables

timothy posted more than 11 years ago | from the ms-reveals-code-to-piglatinland dept.

Encryption 250

DmuZ writes "My friend Rakan has created a new steganographic tool named Hydan which can embed messages into an executable without altering its size. He recently presented this tool to the public for the first time at codecon. This new technique was intriguing enough to get coverage on SecurityFocus.com. The code is available here."

cancel ×

250 comments

Sorry! There are no comments related to the filter you selected.

meow! (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5418003)

meow!

moron waiting for repLIEs (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5418005)

Outage hits Microsoft's bCentral
Alorie Gilbert, Staff Writer, CNET News.com

A glitch knocked Microsoft's bCentral services offline Friday, leaving thousands of small-business Web sites inaccessible for much of the day.

The outage, which began early Friday and was resolved late in the day, disrupted Web service for 15,000 Microsoft bCentral customers, Microsoft spokesman Rich Adolph said. "bCentral regrets the inconvenience this issue has caused to its customers," he said.
Advertisement

The Web site of Microsoft bCentral itself was unaffected by the outage, which Microsoft blamed on a hardware problem. Among other services, bCentral provides Web hosting to small businesses.

Ron Hall, a bCentral customer, said his e-commerce site, vkrshop.com, was down nearly all day. He said the outage could cost him about 20 percent of his weekly sales because Friday is one of the busiest days for his site, which sells personal fitness equipment.

Hall said the most frustrating aspect was that numerous conversations with bCentral customer service yielded no answers about the nature of the problem or when it would be resolved.

"What's so disturbing is the lack of information from Microsoft," said Hall. "After six or seven hours of no service, customers deserve more than that."

Friday's outage follows a string of gaffes or security glitches affecting users of various Microsoft Internet properties, including the MSN Internet portal, Hotmail e-mail system and Passport online identity authentication system.

Last summer, another bCentral server glitch led America Online to temporarily block e-mail from Microsoft bCentral customers. According to AOL, the bCentral servers did not respond to queries from AOL to determine where the mail was coming from, leading the system to "time out."

more inf. available at trustworthycomputing.com

First Post (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5418006)

First Post!

a usfeul virus! (0)

Anonymous Coward | more than 11 years ago | (#5418008)

any export restriction son this one?

i always thought that the original virus was written along these lines, a neat bit of code that the writer wanted on all his programmes

Excuse me (-1, Flamebait)

Faile (465836) | more than 11 years ago | (#5418009)

But what's so amazing about not changing the size? Last time I looked every executable I ever ran through a hexeditor had more 00's than code.

stenography (4, Insightful)

JohnFluxx (413620) | more than 11 years ago | (#5418011)

> El-Khalil concedes that the method is imperfect -- an application that's been impressed with a secret message has considerably more "negative subtractions" than an unadulterated program, making it easy to pick out through a statistical analysis.

Note that as far as I remember, stenography by definition is supposed to make it imposible to prove that there is data hidden there - one step further than normal encryption. It's not so much as about hiding the data as being able to deny its existance.
One reason for this is if you have encrypted data on your disk, then courts can demand the password for it. Stenography allows you to insist there is no hidden data.

Re:stenography (2, Informative)

gunne (14408) | more than 11 years ago | (#5418028)

Steganography would be more precisely defined as "information hiding". It doesn't require that it is impossible to find the data hidden, but it tries to conceal the existence of the data.
Cryptography on the other hand does not try to try to hide the existence of information, it just tries to hide what message is embedded in that information.
Cryptography != Steganography, but they can be used in conjunction.

Re:stenography (4, Informative)

JohnFluxx (413620) | more than 11 years ago | (#5418042)

er...

Steganography requires that it is impossible to prove that data is being hidden there. (Without reference to other material, etc etc).

From The Free On-line Dictionary of Computing (09 FEB 02):

steganography

Hiding a secret message within a larger one in such a way that others can not discern the presence or contents of the hidden message. For example, a message might be hidden within an image by changing the least significant bits to be the message bits.

Re:stenography (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5418055)

Don't start your messages with "er...", it's retarded.

Re:stenography (1, Troll)

JohnFluxx (413620) | more than 11 years ago | (#5418071)

It's my polite way of saying "you dumb ass".

Re:stenography (3, Insightful)

sql*kitten (1359) | more than 11 years ago | (#5418104)

Hiding a secret message within a larger one in such a way that others can not discern the presence or contents of the hidden message. For example, a message might be hidden within an image by changing the least significant bits to be the message bits

OK, but geeks forget that possible/impossible isn't a binary state, like 1 and 0. It's a about likelihood. Is there a 1% chance that this file contains a hidden message? Or is it more like 90%?

One the police have "reasonable grounds", they can step up to the next level. You can deny it 'til you're blue in the face, but if they get a professor to testify that it's highly probable that there is a message there, and they have evidence that you have corresponded with other suspects ("exactly why did you send Mohammed bin Mohammed a picture of your kitten a day before al-Queda hijacked that airliner?") and suddenly your steganographic sK1Lz aren't worth so much.

Re:stenography (2, Informative)

jaavaaguru (261551) | more than 11 years ago | (#5418213)

Stenography is the art of writing in Shorthand. :-)

Re:stenography (1, Interesting)

Anonymous Coward | more than 11 years ago | (#5418109)

I laugh at your silly techniques! Look how easy it is to outsmart:

$ cp /bin/ls .
$ upx ls
Ultimate Packer for eXecutables
Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002
UPX 1.24 Markus F.X.J. Oberhumer & Laszlo Molnar Nov 7th 2002

File size Ratio Format Name
-------------------- ------ ----------- -----------
69368 -> 32358 46.64% linux/386 ls

Packed 1 file.
$ ./hydan ./ls < msg > ls.stegged
Password:
Host file has no ELF section header
Inconsistency detected by ld.so: dl-fini.c: 66: _dl_fini: Assertion `i == _rtld_local._dl_nloaded' failed!

0wned!

Re:stenography (0)

Anonymous Coward | more than 11 years ago | (#5418136)

All you have to do is pack your executables, and then nobody can hide messages in them?

Something tells me this tools lifespan is going to be pretty short ;)

Re:stenography (1)

Subcarrier (262294) | more than 11 years ago | (#5418137)

El-Khalil concedes that the method is imperfect -- an application that's been impressed with a secret message has considerably more "negative subtractions" than an unadulterated program, making it easy to pick out through a statistical analysis.

It should be easy enough to get around this. The statistical telltale is only due to the fact that El-Khalil consistently uses the same type of instruction to encode a certain bit value. Have Hydan XOR the hidden message with a secret key that produces the right distribution of ones and zeros prior to encoding the message and the problem disappears.

THIS JUST IN (-1)

MAKE IT STOP ARRGGHH (644754) | more than 11 years ago | (#5418012)

As America prepares to use her righteous might to layeth the smacketh down up on Iraq, Slashdot was found to suck. Preliminary reports indicate that it sucks because there are too many whining lefty hippies that are better off dead. More to follow later...

Redundancy? (4, Interesting)

Phroggy (441) | more than 11 years ago | (#5418015)

It exploits redundancy in the i386 instruction set by defining sets of functionally equivalent instructions.

Can someone explain to me exactly what this means? Will all i386 executable binaries have unnecessary redundancy? Could the size of the binary be harmlessly reduced by removing it? If so, then why isn't this done?

If a message is embedded in a binary with this method, can another message be embedded in the resulting binary the same way, or has the required redundancy already been eliminated?

Re:Redundancy? (4, Informative)

brejc8 (223089) | more than 11 years ago | (#5418037)

Some instructions have dont care bits in them.
You could remove these bits in order to compress the file but they occur so rarely its not worth it.
And yes the redundency would have been used up.

Re:Redundancy? (woops) (1)

brejc8 (223089) | more than 11 years ago | (#5418059)

Nope Im wrong (Ive been doing too much ARM and MIPS)
The thing worls as using add and subtract of signed numbers.

The meaning (3, Informative)

Anonymous Coward | more than 11 years ago | (#5418038)

It just means that you can encode certain stuff in equivalent ways (*). Like: mov eax, 0 xor eax, eax sub eax, eax are all equivalent in functionality to zero the eax register.

* = Taking into account flags and instruction size restrictions, etc.

The "redundancy" comes from these facts. So, it's not size redundancy as such, and you can't remove the redundancy. It's more like permutations of the instructions are equivalent (length stays the same).

Re:Redundancy? (4, Informative)

sql*kitten (1359) | more than 11 years ago | (#5418039)

Can someone explain to me exactly what this means? Will all i386 executable binaries have unnecessary redundancy? Could the size of the binary be harmlessly reduced by removing it? If so, then why isn't this done?

It means that if you want to add 50 to a number, you can choose to do (+50) or (-(-50)). They both take up the same amount of space and do the same thing. But if you first process a program to ensure that all additions and subtractions are actually additions, then you can encode data into the list of additions by making some of them into subtractions.

Re:Redundancy? (2, Informative)

Ninja Programmer (145252) | more than 11 years ago | (#5418077)

  • It means that if you want to add 50 to a number, you can choose to do (+50) or (-(-50)).
Actually on the x86, those two are not equivalent. They set the carry flag in opposite directions.

Re:Redundancy? (1)

pldms (136522) | more than 11 years ago | (#5418052)

Can someone explain to me exactly what this means? Will all i386 executable binaries have unnecessary redundancy? Could the size of the binary be harmlessly reduced by removing it? If so, then why isn't this done?

AIUI this system replaces one instruction with a functionally equivalent intruction. The binary doesn't contain redundant instructions (which, as you say, could be removed), rather the i386 instruction set contains redundancies.

Re:Redundancy? (1)

Ninja Programmer (145252) | more than 11 years ago | (#5418068)

  • Can someone explain to me exactly what this means? Will all i386 executable binaries have unnecessary redundancy?


The x86 instruction set has some very convoluted encodings mostly due to the various addressing modes and sometimes assumed registers. Many of the common instructions have more than one way to be encoded. You can get more information at http://www.sandpile.org/

I believe, in fact, that *most* x86 executable streams will expose a lot of this redundancy, and therefore there should be lots of potential for this. Of course it'll drive anti-virus checkers nuts ...

Re:Redundancy? (5, Informative)

BenV666 (620052) | more than 11 years ago | (#5418072)

Can someone explain to me exactly what this means?
It means exactly what it says, there is more than 1 road that leads to Rome.... combining instructions in different ways leads to the same results.
Will all i386 executable binaries have unnecessary redundancy?
Almost everything can be done in several ways. Consider these 2 pieces of asm:
XOR DX,DX
MOV AX,3
MOV BX,4
MUL BX
verses
MOV BX,4
MOV AX,3
XOR DX,DX
MUL BX
Same results, same size, different order :)
Could the size of the binary be harmlessly reduced by removing it? If so, then why isn't this done?
Often the binary can't get much smaller without having effect on efficiency of the code, as far as I trust compilers that is :) (ASM rules!!! :)) I.e.
MOV AX,A000
MOV ES,AX
verses
PUSH A000
POP ES
Same effect while the latter saves 1 byte in code.

Re:Redundancy? (3, Insightful)

Ninja Programmer (145252) | more than 11 years ago | (#5418089)

In your examples, if there is are jump target in there somewhere they won't work. Remember that these are binary recompiler tools -- the source is not necessarily available, and it might not be decompilable to find all jump targets.

The second example has the additional problem of having a different side-effect on AX and possibly stack faulting.

Jump Targets (1)

pommiekiwifruit (570416) | more than 11 years ago | (#5418246)

Yeah, even a simple piece of Z80 code (16 kilobytes) like the Pacman ROMs can take a few days for a human to decode properly getting out all the jump targets (which are cunningly held in various tables; executing the code with a tracer helps tell the difference between code and data but a lot of manual work is required), although compiler-generated code should be more tractable.

If you have control of the linker though, you can on normal systems arrange the object files in n! ways which is enough to get going on (as I said online 15 years ago). That should be safe unless you have a linker bug or a really nasty address releated program bug (I hate those!).

Re:Redundancy? (2, Informative)

erc (38443) | more than 11 years ago | (#5418097)

PUSH/POP is significantly slower than two MOV instructions on an x86, though...

Re:Redundancy? (5, Informative)

etcpasswd (641551) | more than 11 years ago | (#5418078)

From my understanding, it appears that he chooses a complentary pair of instructions: addition-subtraction. Then you designate "1" to addition instruction, and "0" to subtraction. So, if you look at only these instructions, your executable can contain a binary string (addition and subtraction instructions).

Now what the author does is, alter the original binary string to that bit-string data of our interest (of the same length). This process requires flipping of instructions. For example, if some instruction is addition (1), but your data requires it to be (0) bit, you change the instruction to subtraction, and change the operand to a negative of the original value. Same applies to flipping a '0' to '1'.

Addition-subtraction works because there are no overflow issues (atleast with signed ints). Since this is also a very common operation, your executable is likely to be large enough to "hold" sizeable data.

But detection should be easy... (4, Insightful)

rediguana (104664) | more than 11 years ago | (#5418020)

if you are using a relatively common binary. Then you just have to compare the MD5 checksums against a known-good (known-bad in MSFT's case ;P ) to identify a binary that could possibly contain encrypted data. Would it then be too much harder to go back through and disassemble the two and pick out the differences and hence identify the bits?

Novel idea though!

Re:But detection should be easy... (2, Interesting)

brejc8 (223089) | more than 11 years ago | (#5418045)

I think the point here is that you never release the original binary.
And the code looks pretty much like its compiler generated.

Re:But detection should be easy... (0)

Anonymous Coward | more than 11 years ago | (#5418197)

No, it doesn't. It fails vxm's compiler fingerprint checks, which can usually nail the version.

Remember kids - this can't be used for release tagging or watermarking, because the nasty evil cracking groups just get two different copies, notice, and scramble it again.

It's not like polymorphic engines are new, you know. Even commercial snake-oil "copy protection" systems like eLicense and SafeDisc have been using this for years.

Re:But detection should be easy... (3, Interesting)

JohnFluxx (413620) | more than 11 years ago | (#5418054)

True - this is why you should make sure there is no original - i.e. use it on home photos.

This is also why the data should be encrypted before hiding it in the message ;)

Re:But detection should be easy... (1)

wadiwood (601205) | more than 11 years ago | (#5418118)

so hiding your message in something like word or excel is a waste of time because a tool like this veracity [rocksoft.com] will detect the change.

I like scramdisk. A pity they've gone commercial but good they've done it in Europe. [drivecrypt.com]

so anyone else have a favourite (free & opensource?) encryption tool

Re:But detection should be easy... (3, Interesting)

Ninja Programmer (145252) | more than 11 years ago | (#5418130)

You are correct -- detection should be easy so long as you have access to the original unmodified binary. I.e., an original software vendor could embed the message in a product of their own making and you would have no idea.

Furthermore in opensource environments, it may be very difficult to determine if differences are due to different compiler flag settings, or just a different version of the compiler.

Re:But detection should be easy... (1)

// (81289) | more than 11 years ago | (#5418223)

Why bother detecting when you can simple use the same technology to destroy any information which may be present there?

If this encoding technique became popular, then so would the necessary tools to scrabmble the covert channel.

Virus (1, Insightful)

bottlerocket (605232) | more than 11 years ago | (#5418022)

So when can we expect our first virus using this code?

Re:Virus (5, Informative)

KDan (90353) | more than 11 years ago | (#5418088)

Never. The information, though contained in an executable file, is not itself executable (unless you went and took that information out and then executed it separately. The whole point is it does not affect the execution of the program that you hide the information into. So you can put whatever information you want in there (even the code for a virus) and it will still not be a virus, because that information will never get executed unless you actively go in there, extract it, paste it as an executable file somewhere else (eg in memory) and then execute it - so you'd need another virus to do this, basically.

Daniel

Re:Virus (0)

Anonymous Coward | more than 11 years ago | (#5418260)

I guess you could use this for the virus to store information that's invisible to all antivirus programs for later viruses to use. Perhaps even code hidden in files so the viruses that come afterwards find pieces of code to evolve themselves.

Too bad viruses are illegal as such, you could make artificial internet life, that stores information on all hosts, ofcourse they'd have to have a way to move around the net aswell.

You might have gotten hoaxed. (-1, Offtopic)

Sheetrock (152993) | more than 11 years ago | (#5418025)

This is technically impossible, for two reasons.

First, executables are called executables because the computer interprets them. They are made of instructions, and unlike a document you cannot simply tamper with things because it will confuse the computer when it tries to run the executable.

Second, and most importantly, the size of the file is dependent on the size of the bytes within the file. Because the bytes in the file have differing values depending on the instructions they encode, altering the data will alter the size unless you're borrowing from one byte to inflate another -- and in this case, again, you run afoul of the first problem.

I'm surprised the editors didn't review this before approving it for posting. This is really pretty elementary to anyone who understands object code.

Re:You might have gotten hoaxed. (2, Informative)

Ninja Programmer (145252) | more than 11 years ago | (#5418049)

  • This is technically impossible, for two reasons.


Yeah, I know another unchecked perpetual motion machine story from timothy. But no, in this case, the story is not wrong, its just 15 years old (the technique was used 15 year ago, I mean.)

The key point is to exploit x86 instruction set redundancy to find a few bits of entropy here and there strewn throughout the executable code. RISC instructions have the same potential. For example:

add r0, r1, r2
add r0, r2, r1 # not much different

Re:You might have gotten hoaxed. (1)

etcpasswd (641551) | more than 11 years ago | (#5418122)

True. But the proposed method is much more simpler and elegant than this - encoding and decoding is very straight forward. In the method you cite, it sounds really complicated to encode some valuable data.

Re:You might have gotten hoaxed. (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5418128)

oh go fuck yourself.

Re:You might have gotten hoaxed. (4, Insightful)

Ninja Programmer (145252) | more than 11 years ago | (#5418141)

I spoke too soon! Actually now that I've read the article myself and dug deeper in the story I realize there is a bigger issue here. The technique used in "Hydan" actually is broken! The ADD and SUB instruction will set the carry flag in opposite directions meaning simple code sequences like:

A -= 3;
if (A 0) ...

Which might be encoded as:

SUB EAX, 3
JC ...

will cease to function correctly!! The technique I cite (which has been proven and used in the a86 assembler) *DOES* work, since you don't change any of the instruction semantics, but just the instruction encodings.

So in fact, this *IS* yet another bogus story posted by timothy ...

Re:You might have gotten hoaxed. (2, Insightful)

Omnifarious (11933) | more than 11 years ago | (#5418189)

There are cases in which the way the carry flag is set doesn't actually matter. In fact, I suspect that in most cases it doesn't actually matter. But, you're right, unless Hydan carefully analyzes the code to make sure it doesn't matter, it's broken.

RTFA (1)

Hanji (626246) | more than 11 years ago | (#5418057)

Read the f*cking article.
No, you can't randomly tweak bytes in an executable and expect it to still work, but you can replace instructions with functionally equivalent ones, and develop a system to encode data that way (as described in the article).
For example (again, straight from the article), an instruction to add 50 can be replaced with one to subtract -50, and you can (and the program does) encode data that way.

Re:You might have gotten hoaxed. (0, Flamebait)

flux (5274) | more than 11 years ago | (#5418060)

That is one terrific point.. Unless you just go ahead and RTFA, and figure out that it is not that impossible at all.

Re:You might have gotten hoaxed. (0)

Anonymous Coward | more than 11 years ago | (#5418062)

Maybe you should just read the article?

Re:You might have gotten hoaxed. (1)

JohnFluxx (413620) | more than 11 years ago | (#5418064)

er..

I can think of one nice and simple contridiction to your comment. If you replace "add x" with "sub -x". That wouldn't affect anything. (Assuming not self modifying code, the instruction length for add is the same length as sub, etc etc)

Re:You might have gotten hoaxed. (0)

Anonymous Coward | more than 11 years ago | (#5418069)

I want to say R... but I will refrain. The technique is not impossible. The x86 instruction set, indeed any instruction set that contain more then say 4 instructions (indeed one even), is highly redaundant. for example

addi ax 1
subi ax -1

are two instructions that encode the exact same function, these two instruction takes exactly the same amount of space.

Re:You might have gotten hoaxed. (5, Funny)

Michael Dorfman (324722) | more than 11 years ago | (#5418070)

> Second, and most importantly, the size of the file is dependent on the size of the bytes
> within the file.

I don't know about you, but where I come from all bytes are pretty much 8 bits in size.

>Because the bytes in the file have differing values depending on the instructions they
>encode, altering the data will alter the size unless you're borrowing from one byte to inflate
>another -- and in this case, again, you run afoul of the first problem.

Altering the value of a byte changes its size?
Man, I need to get me some of them new magic size-changing bytes! Down with the tyranny of 8-bit bytes!

Re:You might have gotten hoaxed. (4, Insightful)

grahamlee (522375) | more than 11 years ago | (#5418150)

I don't know about you, but where I come from all bytes are pretty much 8 bits in size.

You work with pretty old computers like the IA32 then, and ancient character sets to boot :-P
Where I come from (which is C), the byte is defined as the smallest addressable unit of store (memory, IOW) that can hold one character from the execution character set (i.e. the number of bits in a char). If I'm using ASCII, then the character set is seven bits wide and the smallest addressable unit of store on an i686 is 8 bits, so the byte would be 8 bits. If I'm using EBCDIC on a computer that can address eight-bit-wide units of store, then the byte is still 8 bits.

But now consider a computer that can address eight-bit-wide areas of store, but my OS uses 16-bit Unicode. The byte is now 16 bits, as that's the smallest chunk of memory that can hold a single char. Or a computer that deals in 32-bit-wide chunks only, but I'm (for some Godforsaken reason) using Baudot coding as my execution character set. Now my character set only takes up five bits, but as the minimum addressable unit of store is 32 bits wide, the byte has to be 32 bits.

Man, I need to get me some of them new magic size-changing bytes! Down with the tyranny of 8-bit bytes!

A common misconception is to think that the byte and the octet are interchangable concepts. They aren't. The octet is eight bits, the byte is defined as above (see the ISO C99 standard, for example). It's probable that every system you've used has an 8-bit byte; but don't start thinking that's a universal concept.

Re:You might have gotten hoaxed. (2, Informative)

chrisseaton (573490) | more than 11 years ago | (#5418168)

You're confusing "byte" and "char". "char" is related to character sets, "byte" has nothing to do with them. Just because you're using 16 bit unicode does not change the size of the byte, it simply means that your "char" is two "bytes" (if your bytes are 8 bits). Why would a unicode system half the resolution of memory just because of the character set used? You could have a byte of 8 bits, a character of two bytes, or a byte of 128 bits and a character of 256 bits. No connection between the two.

Re:You might have gotten hoaxed. (1)

KieranElby (315360) | more than 11 years ago | (#5418195)

Obviously the programming language character set does not affect the smallest unit adressable in machine code, as you say, but I think the previous poster was talking about ANSI-C, where a char is defined to always be 1 byte, but not necessarily an octet.

Re:You might have gotten hoaxed. (1)

grahamlee (522375) | more than 11 years ago | (#5418241)

You're failing to read the C standard, in which a byte is defined as the smallest addressable unit of memory in which a single character from the execution character set may reside.

Just because you're using 16 bit unicode does not change the size of the byte, it simply means that your "char" is two "bytes" (if your bytes are 8 bits). Why would a unicode system half the resolution of memory just because of the character set used?

It wouldn't. However it would mean that the byte becomes sixteen bits long, even if the smallest physically addressable unit of store is eight bits long. You're confusing "byte" with "octet". BTW if I used a 16bit Unicode system as my execution character set, then the byte would be two octets long. The computer would still be able to address a snigle octet, I'm not arguing that this somehow magically changes. However the execution platform would have no need for the odd-numbered octet locations as they all lie halfway along units of storage. Think of it like this: I could have a seven-bit character set and an eight-bit byte, but be using a processor that can address four-bit locations (call 'em nybbles). The fact that my char variable is now longer than an addressable unit of store is immaterial; the byte is still an octet even though the computer can address quartets.

You could have a byte of 8 bits, a character of two bytes, or a byte of 128 bits and a character of 256 bits.

No you can't. See above, see the standard, learn, comprehend, become enlightened.

Re:You might have gotten hoaxed. (2, Insightful)

chrisseaton (573490) | more than 11 years ago | (#5418252)

Why is C the authority on what a byte it? Bytes were around a long time before C.

Re:You might have gotten hoaxed. (0)

Anonymous Coward | more than 11 years ago | (#5418177)

Your a dumbass, a byte is always 8 bits.

Your thinking of char.

Re:You might have gotten hoaxed. (0)

Anonymous Coward | more than 11 years ago | (#5418199)

From Jargon File (4.3.0, 30 APR 2001) [jargon]:

byte /bi:t/ n. [techspeak] A unit of memory or data equal to the
amount used to represent one character; on modern architectures this is
usually 8 bits, but may be 9 on 36-bit machines. Some older
architectures used `byte' for quantities of 6 or 7 bits, and the PDP-10
supported `bytes' that were actually bitfields of 1 to 36 bits! These
usages are now obsolete, and even 9-bit bytes have become rare in the
general trend toward power-of-2 word sizes.

Historical note: The term was coined by Werner Buchholz in 1956 during
the early design phase for the IBM Stretch computer; originally it was
described as 1 to 6 bits (typical I/O equipment of the period used 6-bit
chunks of information). The move to an 8-bit byte happened in late 1956,
and this size was later adopted and promulgated as a standard by the
System/360. The word was coined by mutating the word `bite' so it would
not be accidentally misspelled as {bit}. See also {nybble}.

Re:You might have gotten hoaxed. (0)

Anonymous Coward | more than 11 years ago | (#5418255)

Dude, get a life. He was making a joke...

Re:You might have gotten hoaxed. (1)

Thowllly (529311) | more than 11 years ago | (#5418073)

This is absolutely not impossible. The i86 instruction set has some redundancy (Different opcodes that end up doing the exact same thing.) So you can encode bits by toggling between two different opcodes whenever they're encountered. A86 (http://eji.com/a86/) already uses this technique, and has done so for a long time, to 'sign' the executables, so that it can be determined whether some codes has been compiled with the A86 compiler or not.

Re:You might have gotten hoaxed. (3, Informative)

ethnocidal (606830) | more than 11 years ago | (#5418074)

You are both correct and incorrect. While it's obviously not possible to simply go through changing instructions, operators and operands without consideration as to the effect on the program, it is possible to leverage functionally identical instructions to represent a bit.

If you read the article, a trivial example would be subtracting -5, rather than adding +5. The presence of a subtraction operation, rather than an addition operation can signify a binary digit.

Unfortunately, due to the consistent output from compilers, this is not steganography - you can both tell that the executable has been altered, and read the message! His plans for the future (parameter organisation, etc.) may be more relevant, but at the moment this is a proof of concept implementation, not a usable system.

Anyone interested in other forms of steganography could do worse than to read Andrew Tanenbaum's page [cs.vu.nl] on the subject.

Re:You might have gotten hoaxed. (2, Funny)

Openadvocate (573093) | more than 11 years ago | (#5418080)

the size of the file is dependent on the size of the bytes within the file
:D ..... mkaaay.


so a byte containing the value 233 will create a larger file than one containing the value 3? interesting. Maybe you should stick to prgramming in c#.

Re:You might have gotten hoaxed. (1)

Brian Blessed (258910) | more than 11 years ago | (#5418082)

You have to be briefly open minded before you just dismiss things as technically impossible (and then do it).

In this case, I haven't read the article, so I'm wildly speculating, but if you consistently go through the executable replacing groups of instructions with functionally equivalent groups that are the same length then you effectively have an encoded stream of 1's and 0's (or other numbers for more equivalent types).
This wouldn't work for self-modifying code, and each instruction has to be the right length also, but you can see how not blindly dismissing it is interesting.

- Brian.

Re:You might have gotten hoaxed. (3, Informative)

peope (584706) | more than 11 years ago | (#5418093)

This is no hoax

I has the same properties as:
a*b gives the same result as b*a.

You have options on what instructions to use which yields the same results.

Lets say a*b is a 1 and b*a is a 0. You could describe a byte with eight occurancies of the (a*b || b*a) operation.

a*b b*a b*a a*b a*b a*b b*a a*b == 10011101

A common practice with x86 is to use XOR AX, AX instead of MOV AX, 0 to clear the AX register.

However, this is not interchangeable since they do not have the same size. The XOR method is often used because it is faster and have less size IIRC.

Re:You might have gotten hoaxed. (1)

Ninja Programmer (145252) | more than 11 years ago | (#5418158)

You can use SUB AX, AX in place of XOR AX, AX with no issue (both will set the flags equivalently.)

Re:You might have gotten hoaxed. (0)

Anonymous Coward | more than 11 years ago | (#5418239)

Yes, but the compiler fingerprinting of Vexmon - or possibly even IDA or Olly - will flag this as very interesting, indicating a hand-coded section of the file as compilers are always consistent in how they use this - XOR EAX, EAX is theoretically faster as that is the canonical CLR EAX instruction that the pipelines of the P4 are optimised for, so they typically use that. At least one compiler uses SUB EAX, EAX but you'll only very rarely see a mix, and it always makes me suspicious. Some hand-coders use SUB, and I've even seen weirdness like AND EAX,0, and the eternally Hi-I'm-a-beginner-assembly-coder MOV EAX,0 used on occasion. I saw a multiply by 0 once, and that raised a few eyebrows. All clearly indicate hand-coded segments worthy of close attention - sprinklings of these throughout the code indicate the attentions of a polymorphic engine like this one.

Re:You might have gotten hoaxed. (4, Informative)

ZigMonty (524212) | more than 11 years ago | (#5418095)

This is technically impossible, for two reasons.

Did you read the article?

First, executables are called executables because the computer interprets them. They are made of instructions, and unlike a document you cannot simply tamper with things because it will confuse the computer when it tries to run the executable.

Of course you can tamper with executables! As long as your modified version does the same thing, there is no harm done. If you change the addition of a positive number to the subtraction of a negative number, you get the same result if you run it. You run through the binary and if the current bit of data to be hidden is a 0, you don't modify that particular addition instruction and if the data bit is 1 then you *do* modify it. If you compare the modified binary to an original, you can see all the changes and extract the hidden data.

Second, and most importantly, the size of the file is dependent on the size of the bytes within the file. Because the bytes in the file have differing values depending on the instructions they encode, altering the data will alter the size unless you're borrowing from one byte to inflate another -- and in this case, again, you run afoul of the first problem.

This makes no sense to me. The replacement instruction is the same size as the original.

I'm surprised the editors didn't review this before approving it for posting. This is really pretty elementary to anyone who understands object code.

I don't doubt that you understand object code but you don't seem to understand this technique.

Re:You might have gotten hoaxed. (1)

hoggy (10971) | more than 11 years ago | (#5418125)

This is technically impossible, for two reasons.

You, sir, are a moron.

Re:You might have gotten hoaxed. (2, Funny)

TheLink (130905) | more than 11 years ago | (#5418228)

And that's only one reason too ;)

RPN (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5418027)

ALG: (2+(2+(2+(2+(2+2)+2)+2)+2)+2)
28 Keystrokes

RPN: 2 Enter 10 ^
5 Koystrokes

How long... (4, Funny)

ymgve (457563) | more than 11 years ago | (#5418029)

...until somebody embeds "seineeW erA sreenignE epacsteN"?

MOD PARENT UP FUNNY (-1)

Anonymous Coward | more than 11 years ago | (#5418220)

That is actually the funniest thing I've seen all day.

For those who encounter compilation problems... (4, Informative)

Anonymous Coward | more than 11 years ago | (#5418032)

Add -ldl to the LDFLAGS in the Makefile.

First used in a86.com (4, Informative)

Ninja Programmer (145252) | more than 11 years ago | (#5418033)

This is a well known technique that was used in the mid-80s by Eric Isaacson in his product "a86". See here: http://eji.com/a86/

Eric Isaacson used the technique to mark executables, so that he could determine if they were created with an unregistered copy of a86.

Time to go to bed (-1, Offtopic)

fucksl4shd0t (630000) | more than 11 years ago | (#5418036)

Am I the only one that read the headline and wondered how you can embed a massage into an executable?

Re:Time to go to bed (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5418101)

OMG you are so funny!! Do you do stand-up? I must come see one of your shows. Say something else funny!! please! OMG!

Re:Time to go to bed (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5418198)

>Am I the only one that read the headline and wondered how you can embed a massage into an executable?

No... You're just the only one who thought the rest of us may find your comment even remotely interesting.

new compression standard: rm -rf (4, Funny)

more fool you (549433) | more than 11 years ago | (#5418048)

so how do i add my 6MB ogg to the 526K ls?

Re:new compression standard: rm -rf (2, Funny)

more fool you (549433) | more than 11 years ago | (#5418066)

sorry to reply to my own message, it's obviously possible using word.exe

Speaking of which, Ogg Vorbis for Nero (1, Informative)

Anonymous Coward | more than 11 years ago | (#5418129)

The first vorbis [cdfreaks.com] plugin for Nero is out.

One less thing for the mp3-lUsers to complain abou

THIS should be on Slashdot (0)

Anonymous Coward | more than 11 years ago | (#5418285)

Thank you very much kind sir.

moron predicts big boom.. (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5418065)

or bust. deepends on whois soul DOWt/your daddIE.

lookout bullow. run for your options, should you have any?

the daze of Godless phonIE payper liesense hostage ransom scam stock markup FUDgePeddlers(tm), is just more bad ?pr? hysteria, from the ill eagle kingdumb.

whois the real .commIEs?

va lairIE's patentdead PostBlock(tm) device? :~)-

Hiding messages within messages (4, Informative)

Bender Unit 22 (216955) | more than 11 years ago | (#5418091)

Hiding messages within messages are used often in many contexts, like the radio broadcasts in WW2 sending "birthday greetings" among other things [slashdot.org]

Difficult part, code, data, format (2, Interesting)

peope (584706) | more than 11 years ago | (#5418107)

The most interesting and difficult part I get from this is how can you be sure that the modifications are not done in DATA or in executable format headers (ELF eg).

I would recon you would need to be able to disassemble the whole thing before being able to make modifications. Otherwise you could touch static data (vars initialized in the code) or the executable format (some of the metadata about the executable, the ARCH field in and ELF binary eg).

Re:Difficult part, code, data, format (4, Interesting)

Oswald (235719) | more than 11 years ago | (#5418209)

I would recon you would need to be able to disassemble the whole thing before being able to make modifications.

Yes, it does that.

Self-signing? (1)

salimma (115327) | more than 11 years ago | (#5418110)

Err. Presumably you can not actually sign the parts of the code that Hydan is changing (those integer additions), unless you convert all of them back to standard addition before doing the checksum.

Then when verifying the signature, you have to *revert* all the negative subtractions back to additions before re-doing the checksum and comparing the results. Ouch.

Unless you use a block checksum like rsync, of course. Imagine doing this on a huge executable - how big is word.exe anyway? Have not used it for years.

Regards,

Alternate Article (1)

Solitary Angel (641049) | more than 11 years ago | (#5418124)

Links down so other article here [theregister.co.uk]

--
SA

moron hides saycrud message... (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5418127)

inbytewean terabytes of annoying gibberish, in order to circumveNT va lairIE's patentdead PostBlock(tm) device.

what a waste of time. the source forgerIE i mean.

lookout bullow. the Godless phonIE payper liesense stock markup scam, has been eXPosed for what it really is, not.

What I find amazing is that.. (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5418138)

Timothy has friends. AThey're obviously not /.'ers

compiling this program for windowsXP (0)

Anonymous Coward | more than 11 years ago | (#5418140)

Let's assume (correctly) that I know no more than an idiot about compiling such a program. Could someone point me to a newbie "step-by-step" for compiling on Windows?

Thanks for your l33t sk1LL5,
A.C.

Re:compiling this program for windowsXP (0)

Anonymous Coward | more than 11 years ago | (#5418261)

1) Buy Visual Studio.NET
2) Rewrite the program in C#
3) Compile the new program

Re:compiling this program for windowsXP (0)

Anonymous Coward | more than 11 years ago | (#5418271)

ok moron, I asked for a NEWBIE way to do it. I don't think "Rewrite the program in C#" qualifies. try again

Only for use by terrorists (2, Interesting)

nurb432 (527695) | more than 11 years ago | (#5418152)

Just kidding, but you KNOW that's how it will be viewed by the 'outside'..

I bet the get shut down, under the patriot act, before you can say 'what's that knock at the door'..

~0 byte files whopido! (0)

Anonymous Coward | more than 11 years ago | (#5418171)

Yey, the day had to come. Make an executable with only the needed header,
and add the rest in those 0 byte comments?
If this ain't flamebait, nothing is!

Re:~0 byte files whopido! (0)

Anonymous Coward | more than 11 years ago | (#5418211)

AFAIK the correct term is "whoop de doo".

Yes, it can be done... (4, Funny)

CoderByBirth (585951) | more than 11 years ago | (#5418190)

...but why?
Why would I want to hide messages in my executable files?
Because I'm a secret little squirrel who just in general likes to hide stuff, like INSIDE other stuff?

In other news . . . (-1, Offtopic)

Pike65 (454932) | more than 11 years ago | (#5418191)

If you play Quake III with the levels in reverse order, you get a message from Bill Gates . . .

Use this program... (0, Redundant)

megazoid81 (573094) | more than 11 years ago | (#5418204)

... and the terrorists have won!

How can one release such software without also releasing an antidote secretly to the Total Information Awareness program?

Question: (2)

Oswald (235719) | more than 11 years ago | (#5418222)

I followed the readme file right up until the last item in Future Plans. Can someone explain this to me:
- Replace length fields with two fields (length of length, and length) to avoid attacks on stream cipher.

Attacks on stream cipher?

*great* (-1, Flamebait)

hdcool (175379) | more than 11 years ago | (#5418230)

another trick microsoft can use to spy on us...
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>