Slashdot Mirror
Program Hides Secret Messages in Executables
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."
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
> 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.
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?
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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!
So when can we expect our first virus using this code?
where the comment ends and sig begins
...until somebody embeds "seineeW erA sreenignE epacsteN"?
Add -ldl to the LDFLAGS in the Makefile.
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.
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).
so how do i add my 6MB ogg to the 526K ls?
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
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.
A Minesweeper clone that doesn't suck
Nope Im wrong (Ive been doing too much ARM and MIPS)
The thing worls as using add and subtract of signed numbers.
Mouse powered Chips, Open source Processors and Lego
That is one terrific point.. Unless you just go ahead and RTFA, and figure out that it is not that impossible at all.
Maybe you should just read the article?
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)
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.
> 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!
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.
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 on the subject.
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#.
my sig
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.
Hiding messages within messages are used often in many contexts, like the radio broadcasts in WW2 sending "birthday greetings" among other things
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.
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.
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).
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.
This is technically impossible, for two reasons.
You, sir, are a moron.
The first vorbis plugin for Nero is out.
One less thing for the mp3-lUsers to complain abou
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.
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
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.
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.
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'..
---- Booth was a patriot ----
You can use SUB AX, AX in place of XOR AX, AX with no issue (both will set the flags equivalently.)
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.
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!
Your a dumbass, a byte is always 8 bits.
Your thinking of char.
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.
Need a Python, C++, Unix, Linux develop
...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?
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.
From Jargon File (4.3.0, 30 APR 2001) [jargon]:
/bi:t/ n. [techspeak] A unit of memory or data equal to the
byte
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}.
How can one release such software without also releasing an antidote secretly to the Total Information Awareness program?
- Replace length fields with two fields (length of length, and length) to avoid attacks on stream cipher.
Attacks on stream cipher?
And that's only one reason too ;)
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.
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.
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.
No you can't. See above, see the standard, learn, comprehend, become enlightened.
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!).
Why is C the authority on what a byte it? Bytes were around a long time before C.
Dude, get a life. He was making a joke...
Thank you very much kind sir.
Very nice, and stilly totally incorrect as related to the grandparents post, which states that changing the value of a byte changes it's size. In any case, you're confusing the definition of the word "byte" with the byte data type, and then confusing that with the char data type.
Indeed they were, and as an AC points out elsewhere on this thread with reference to the Jargon File; the byte was originally defined as the size of a useful chunk of information on an IBM machine. Back then the byte was smaller than an octet, and its size varied depending upon the size of the information chunk in use. Note further that the jargon file also defines the byte in the same way as the C standard; I just happen to have more respect for ISO than I do for ESR (though Nethack is a fine game), and thought the C99 document to carry more weight than a hacker's dictionary. Perhaps I was wrong on that last count.
But the punchline is strengthened; the byte is defined in multiple sources as the size of a character variable. One use of this form of the word byte has been shown to predate the incorrect definition of a byte as strictly equal to an octet. Case rests.
There is no "byte" data type in C. What does exist is a byte, defined as:
This whole language thing gets a lot simpler when you refer to the dictionary :-)
I'm not so sure about hiding messages in executables, but there were two interesting messages hidden in the n64 game The new tetris. The messages were hidden in 00B8FF90 of the US ROM. They were also in the PAL rom about 2k further. Anyway, here it goes:
****START MARTIST RANT**** I must say, this was a fun time coming down to San Francisco to do The New Tetris. Allthough there were a few problems. First of all being our producer.. D*N, my god.. is this guy useless or what?? I don't hate you D*N.. but you SUCK, and I mean SUCK as a producer. You should go back to testing video games, but I doubt you could even manage that properly. I feel sorry for you. During this project you just sat around and played video games.. starcraft and everquest. Don't even deny that.. when you WERE working, it was making stupid Excel (tm) spreadsheets to try and tell me how many bugs I had left to fix on a graph.. like WTF is that??? who cares.. I have the bug list in front of me, like I need to see it in freaking technicolor. So D*N, I must say this.. hold onto, and fake your job while you can, because once they find out how truely useless you are, you will be out of a job. I cannot think of any skillset you would fit into in this industry, so you better hold on tight. (This guy thought I could save a name in 8.4 BITS.. like umm.. .4 BITS?? WTF is .4 BITS?? its either ON or OFF, not in between... anyhow, Enough about you though. To Nintendo.. It has been nice working with you.. Alot of you are great or were great. Tom 'Snoop Dog' Hertzog - you were great.. one of the nicest people I have ever met at Nintendo. You and your crews bug testing was outstanding and I commend you for the excellent work. Erich Waas - You know we have been friends a long time, but I must say this. After you had accepted the ART form for The New Tetris, and later on your higher ups said it was not UNISEX enough, you slapped the blame on H2O, Chris Bretz in particular. You did not have the balls to accept blame for your mistake, and stuck our entire team under IMMENSE stress and FRENZY. This to save your A$$ from getting in trouble at Nintendo. I still like you Erich, which is more than I can say for the rest of the team that you screwed because of this. But I guess your standing at Nintendo is more important than the friendships you had here. You always knew we had telent and you recognized that. I know you wanted to work with us again one day maybe outside of Nintendo, I think you screwed up those chances though. While I am screaming.. I might as well say this: Niel Voss.. your music is freaking KICK A$$.. you are one really damn talented boy. BUT, you are one of the laziest music guys I think there is You could go far if you wanted to, but you just lack the GO for it. It is a shame. I wish you all the luck and would reccomend you to ANYBODY just because even though everything is last minute, and like pulling teeth, the end result is AMAZING. I am leaving H2O after this project to work at 3DO. I hope this will be a good move for me. I love H2O, As amazingly disorganized of a company it is. I LOVE the people, I have so many good friends there. It will be hard to move on. Of course they will stay my friends. They were more than just co-workers.. they were FRIENDS. They were the people I lived with, spent my days and nights with.. went to bars with, camped with, drank with (alot), did other bad things with (wont elaborate ). They are true great friends, and I love them all and will miss them dearly. Allthough Vancouver is only a 2 hour flight away, I hope I can visit often. My best friends would include. Ross, Max, Scott, Jake, Bretz, Roland, Johnny, Sarah.. these are the people I love the most. And I wish you success. My 4.5 years at H2O were basically, making games.. drinking alot, playing pool alot, going to bars and raves and dancing while really screwed up in the head. THAT HAS TO BE THE MOST FUN I HAVE EVER HAD, and probably ever will. The good old days. These guys are in Vancouver right now because I got stuck finishing this project in San Francisco (Which by all means I LOVE and am staying (hence 3DO)) Well boys and girls, I just thought I would immortalize some thoughts I have at the moment into a rom which will be burned forever. This game sucks. The music is great but the game itself is not how we wanted it unfortunately. I mean, it is a good game, but some things could be polished, as well as sped up. Could use another month to finish this thing off AFTER all the bugs are fixed. oh well, woh is me. I would love to give special loves and kisses to the following. My Girlfriend Amy Bond, My Family (Joy, Allyson, Jon Pridie, Brant Sangster), My really really best old friends Selim Arikan, Cory Haberly, Jason Vasilash, Alfred Huger, Oliver Friedrichs. Goodbye H2O, it was a blast, and I mean that with all my heart. (C) 1999 July 1 David Pridie If you are reading this, you can obviously see this disclaimer. All this material belongs to David Pridie. If you find it and want to post it in ANY media format, you must get my permission or feel my wrath . This text if it is ever read, is intended to be read by hackers whom have dumped the contents of this rom and viewed it. That is ALL it is for. And maybe some of them will remember me from the C64 and PC days, Martial Artist of PE/TDT/RAZOR 1911/INC/FLT/TRN/FBR, I was in them all.. and I made trainers and intros mostly. I thank that scene for teaching me how to program, because without it I don't think I would be where I am today. Well that does it 4.5 years and Two games later (Tetrisphere and New Tetris). Unfortunately I wont be working on Nomans Quest.. but oh well. HAPPY CANADA DAY. ******END MARTIAL ARTIST RANT ******
*****START LUPIN RANT FOR 50 MOST HATED THINGS*****1] Idiot teens hanging out in front of 7'11s, KFC, McDonalds, Jack In The Box etc... Your life REALLY SUCKS if that's the high point of your day...2] A$$holes who spit on the sidewalk.3] Drivers who don't know how to use a turn signal. I can reach mine with my pinky while driving. It's not that hard.4] Teens with their pants around their a$$.5] People with personalized licence plates.6] BMX bikes.7] People panhandling me. Get a job losers! McDonalds is always hiring!8] Bums with dogs. I'm sure the dog loves eating cheese from old pizza boxes.9] The cheeseheads from asia who take a Honda Civic, slap some stickers on it, put a muffler on it that makes it sound like a riding lawnmower, a ridiculous sized fin on the back and think they have a formula 1 racer. 'Devastating Power!' my a$$!10] The same idiots who then drive their 'hot' civic like they are in the Indy 500 through busy traffic.11] The huge complex hairdos on african american women, 5 layers, 6000 curls, 4 sprouting areas, 200 dangling bits, 6000 beads, air conditioning and enough hairspray in it that it wouldn't move if Hurricane George hit it.12] People with Kleenex, plants, knitted blankets, stuffed animals, or lacey things in their cars rear window. I should be allowed to pull over and shoot them.13] People on the bus who talk so loud your forced to hear about their pointless lives.14] Crappy parkers who park their car REALLY close to the painted line so that you have half a foot to get out.15] Those old cars (ie, Cadillacs, Lincoln Town Cars, etc...)usually white for some strange reason... with the acient driver who always drives WAY under the speed limit.16] People who write a cheque for a $2 bag of nachos at Safeway.17] Corvettes, Comaros and Firebirds. Come on, the 80s are OVER!18] A$$hole tailgaters.19] Idiots who think they can pedal a bike as fast as a car, so they ride in the middle of a traffic lane. You should be allowed to run them over, it looks like natural selection to me.20] Teenagers on television news reports expressing their opinions on something. If your under 18 I don't give a sh1t about what you have to say...21] The singer Brandy, Celine Dion, all the divas....22] Twits who wear a huge parka outside when its sunny and a mild 5-10 C. The same thing goes with the whole scarf thing.23] Muni busses that smell like urine. Which is most of them.24] Corporate Broadcasting logos in the corner of the channel your watching.25] Web pages that pop open other pages and windows and then disable your 'back' button.26] People who walk around with a huge 'portable' stereos blaring, sharing their music with everyone around them. Usually crap rap.27] Junk mail.28] Peice of sh1t cars that spew out huge noxious clouds behind them.29] People that throw out huge items on the curb expecting the garbage people to remove it. Like old dirty matresses. They don't of course, and it sits on the curb for weeks.30] Budweiser beer and the people who drink it. I'd rather suck the piss out of a pig... Its time to poison the bud.31] Drivers who turn onto the road RIGHT in front of you causing you to slam on the brakes, even though there is no one for hundereds of feet behind you.32] People who drive 3/4 in one lane and 1/4 in another... what the hell is that????33] Religous people who push their drivel on you when your walking down the street. Or come knocking on your door.34] Dead web page links and 'Document not found' errors.35] Racisist people and the crap they spew out.36] Those stupid add banners from Geocities on the Internet when you hit someones home page going through them...37] All country music.38] Minivans.39] People who spray paint their names on rocks, signs, trees etc, in national parks. Like I care that Bill graduated in 86.40] Small yappy 'feeder' dogs. Like little Yorkies, poodles, etc...41] People in the fast lane who drive just 2 km/hr faster than the guy in the 'slow' lane, dawdling along.42] Film crews making bad movies most people doent want to see blocking the streets and being annoying.43] Big fat bugs that splat on my windshield.44] Those really tight spandex cycling pants on men, they are usually sooooo tight, you can tell if they are cirumcised.45] Those really tight spandex cycling pants on 90% of the women. Big fat a$$es and *wiiiiiiiiiiiiiiiiiide* camel toes.46] Those really annoying commericals from Rogers Cable that tell you all about the 'evils' of satalite tv and how lucky you are to be getting cable for a mere $65 a month.47] Commercials that are SO bad on tv, you have to wonder about the sh1t for brains who thought them up. Like the Old Navy commericals, or the old as hell commercial for Sarah Lee, that is STILL ON THE AIR, 'let them eat cake' and 'But Patrick, I'm to old for life insurance.' Shoot them ALL!48] Losers that listen to totally cheezy radio stations and then slap dozens of their stupid stickers all over thier car.49] Lilith Fair. I say when they are all hugging, listening to the music, sharing tampons, and bitching about how evil men are, toss in a few hundered grenades while recording it on camera. Sell the video as a 'To Hot for TV' tape late at night.50] Cheap a$$ manufacturers of DVDs who list as 'features' chapters, interactive menues, and the time. These arent features. Thats like calling your computers keyboard a 'feature'. Lame a$$ marketing people.51] DVD manufactureres that sell their DVDs for $40 and up, just because they know people will pay for it. DVDs have actually become MORE expensive than when they first came out.52] Nintendo and everything about them.53] Old people who clog up the sidewalk walking super slow when you want to get somewhere.54] Looking at demo-reels at work that are so incredibly bad, that I just want to call them up and tell them to go f*ck their demo reel and to never EVER send another one out to anybody. EVER.55] Spiders. All spiders. Everyone of them.56] How on the Nintendo 64 game machine, half the damn titles for it are called 'miscvidgame 64'. Why not come up with a real name? Why is everyone just slapping a 64 on all the games?**********END LUPIN RANT******** I got these rants from dextrose
13 year old white supremacists are shitty web designers.
>>Second, and most importantly, the size of the file is dependent on the size of the bytes within the file.
The concept of "the size of the bytes" is such a incredible misapprehension of so much it's not clear where to even start. Bytes can have many values, but they're all the same size. Period. No matter how much you understand object code.
Or is this a troll?
Everything I've ever learned the hard way was based on a statistically invalid sample.
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'm surprised you didn't think one second that your grand knowledge of the scheme of things didn't include the knowledge required to understand this thing... you'd rather think everyone here is a fucktard and making up technically impossible stories?
Oh and btw.. anyone who thinks they understand object code and states that bytes inflate and deflate should go take Elementary Computing Principles I.
I guess it's a bit like a word then. As the word is dependant on the processor architecture, the byte is dependant on the data being worked with.
Cool. Where is a link to the C99 standard?
This like any solution is not fool proof. The catch is if you have managed to get hold of both the orginal and the modified copy. A quick MD5 check will reveal that both are different and could lead someone to suspect that something has been done. Now which one is the modified version? You could do this using a statistical method, by finding out which occurrence appears more often on the net. So to achieve the trick correctly you need to make the modification to an executable that does not exist on the net.
Another method to detecting an executable that contains hidden data is to work out whether the executable uses the most unusual method of implementing its assembly.
Of course just like in the film 'A Beutiful Mind', you could just end up seeing encrypted data left right and center, whether or not it is really there.
Jumpstart the tartan drive.
a*b gives the same result as b*a.
Does that mean:
1*5 == 5*1 ?
... I do doubt that he understands object code
Ok. But how do you tell what order they were in in the first place? Are you going to go through the whole file and align all of the multiplies to 0, then flip the proper ones to 1? If a compiler always does it one specific way, and you change it, it's going to be noticable. (Those are unrelated ideas.)
Ripped off from9 9-01/0 091.html ...
http://www.cni.org/Hforums/cni-copyright/19
16 bits 8 bits 2 Mini/Micro Intel,Moto,DEC,DG
24 bits 6 bits 8 PDP?? DEC
24 bits ?????? ? DSPs TI,Moto
36 bits 6 bits 6 1100 Univac/Sperry/Unisys
36 bits 6 bits 6 GCOS 8 GE/Honeywell/Bull
36 bits 9 bits 4 1100/2200 Sperry/Unisys
36 bits 9 bits 4 GCOS 8 Honeywell/Bull
48 bits 6 bits 8 A/B series Burroughs/Unisys
48 bits 8 bits 6 A/B series Burroughs/Unisys
60 bits 6 bits 10 6000 CDC
60 bits 7 bits 8 6000 CDC
How stupid is this? I use a TI-89, and if I wanted to add 10 twos together, I'd just use my brain and say, "ten times two is twenty," then I'd use one of my cool assembly programs to do something Fourier related with the calc.
Besides, it's common knowledge that to use an HP calculator, you have to program in either Forth or PostScript (stack based languages).
(Q-B).(E+10).(D).
Ummm... I am thinking you may have gotten your definitions a bit confused.
On a intel processors
Byte = 8 Bits.
Word = 16 Bits.
DoubleWord = 32 Bits.
A ASCII char is stored in 1 byte of space
A Unicode char is stored in 1 word of space
and a lot of assembler commands are stored in 1 doubleword of space.
Having coded a lot of assembler for motorola and intel processors, this is the language that was always used around me. A byte always meant just that 8 bits. While a word and double word mean 16 and 32 respectively.
There is a term for a 64-bit one, but for the life of me I don't remember.
~ kjrose
You have to buy it from the ISO, AFAIK [though it's pretty cheap, 44 Swiss Francs]. Assuming that you're in America (which I have no reason to do whatsoever, but at least it's a start ;-) you can purchase it through The American National Standards Institute, you're looking for standard ISO 9899:1999, "Programming Languages -- C".
It's pretty much a necessity to have a reference copy of this if you intend to be writing any cross-platform C code. While Kernighan+Ritchie only deals with platform-agnostic C code, they don't always tell you where the mistakes that they are avoiding lie.
Surely, a declaration of independence should be stored in a non Microsoft product.
.. you're a genius. Or, if you just read the article: "Hydan could also break programs that are self-modifying or employ other unconventional techniques".
So, uh, "so fucking what?" How have you "outsmarted" it?
...after these hidden messages.
Modest doubt is called the beacon of the wise. - William Shakespeare
I think the term you are looking for is "quadword". I may be wrong, though.
Life sucks, but death doesn't put out at all....
--Thomas J. Kopp
Thanks for the discussion ... IANAP, but I collect compilers and source as if I were [g] ...Now tell me if I'm imagining things, but didn't some really ancient system (like early mainframe days) define a byte as two bits?
~REZ~ #43301. Who'd fake being me anyway?
In fact, it strikes me as not very different to something I did to a program some years ago. This little utility used a loader that called a bunch of annoying little advertising applets (and mind you, this was a DOS app!) and it complained if one simply did away with the ad applets.
One day I took a notion to dig thru the loader, and noticed that the name of each applet was preceded by the same binary string. So I fired up my handy hex editor and typed zeros over the top of each such string. Voila, no more calling ad applets, and it still worked fine otherwise.
Anyway, that's a real primitive example, but does demonstrate "tampering with an original" without the use of a virus.
~REZ~ #43301. Who'd fake being me anyway?
;p
A code magpie :-)
Most of the early IBM mainframes were pertty two-bit, yes. Actually the byte as in what IBM are going to call this lump of data varied from one to six bits according to that AC post earlier in the thread, until they decided on EBCDIC as a character coding when it became eight bits. It's likely that if they had some process that had three or four output levels (e.g. OK, garbage in input, run out of cards, printer on fire) then they would have referred to its output as a byte and used two bits to store it.
I hide all sorts of stuff in my C comments.
Nobody can detect them in my executables.
HA! I'm so sneaky!
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
Yep, we like bright shiny things :)
:)
So I wasn't imaginging the two-bit byte after all! Must be something I recalled from my high school's IBM1620, which we abused with amateur Fortran incantations. One of 'em must have induced brain-burn (akin to screen burn
~REZ~ #43301. Who'd fake being me anyway?
Redundancy was the problem and redundancy was the answer. Microsoft realized that their operating system was simply a 32 bit GUI bolted onto a 16 bit extention of an 8 bit OS. Their code, when viewed in this light was massivly redundant and users could fit their data inside the code itself! They could even fit code within code this way. So, in this way, the engineers have saved the company from the marketing department without confrontation.
It's a joke, laugh.
Friends don't help friends install M$ junk.
Ahhh! If my byte moved from 8 bits to 16 bits, did my nibble become 8 bits instead of 4? Did my bit beceome 2 bits? If my bits can double, I'm in trouble! - Head Explodes -
Friends don't help friends install M$ junk.
Those guys of SecurityFocus must be really stupid, since cavity virus have been around for ages.
There is no "byte" data type in C
There are distinct "byte" and "char" data types in the Java programming language. The "byte" is 8-bit as expected in PC-type and RISC architectures, but because the Java programming language's native character encoding is UTF-16 Unicode, "char" is 16-bit.
Will I retire or break 10K?
Is your friend normally in the habit of writing trojans and giving them to the public?
x86 has 2 registers: ADD AX, BX. You don't get to ADD AX, BX, CX in x86.
A word is 36 bits aned a "byte" is 9 bits which leads to a lot of fun for FTP'ing. So much for the 8 bits being the standard.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
"The SUB instruction
Which means that the CF stays the same for both instructions since their results are the same.Is the same as:So, "Hydan" works.
-j
The same size executable, and it still works doesn't mean the CRC is the same. The executable will have a different footprint and will be seen by any virus scanner nowadays.
"two sticks, a dash and a cake with a stick down"
-- 9/11 hijacker Mohammed Atta notifying Ramzi Bin-al-shibh by telephone of the date of the attacks. If I wanted to get a message to someone, using a riddle over the phone is a simple, low-tech solution which worked for them.
I agree. Ninnle is the end-all be-all of Linux distributions. For if we should be without Ninnle, what would the purpose of our existence be? Another question: If Ninnle is so great, then why do bad things happen to good distributions? Hmm. I may have to take a mountain retreat to get in touch with my Ninnilian side. Until then, continue to Ninnle.
I'm sorry, but the word byte is a contraction of "by eight". A byte is 8 bits by definition. You're just wrong, period.
Sheetrock's posting makes no sense unless you he's talking about compressed files. On my windows 2000 machine I keep lots of directories compressed, so if I ran this program over my files, they'd get bigger in actual disk space in compressed size because the amount of redundancy would be less.
Most people have their browsers set to only show the uncompressed size of files even if they have disk compression turned on, so they'd never notice the difference.
Microsoft has been doing this for ages
;)
That would apply a lot more if open-source didn't exist. For example, I've done some hacking on Bind in the past, and still have the modified binaries, but have long since lost the sources, so there's no easy way to see what a clean version would look like - without the steganographic data. It would also be pretty simple to apply this to development snapshots.
IIRC, word refers to the standard size piece of information on the processor. So 8086 are 16 bit chips and have a 16 bit word, and pentiums are a 32 bit chip and have a 32 bit word.
Want to see every step I took to start my company? http://www.rowdylabs.com/blogs/pitchtothegods
I was unaware that IDA went to that kind of depth in its latest versions. I am familliar with their product but have an old version.
Indeed, xor eax, eax, is hard coded into most modern x86 CPUs as a "CLR EAX", but one notable exception is the AMD K6. Because of the issue with artificial dependency chains, it is actually sometimes faster to perform a MOV EAX, 0 for that processor. Furthermore, it is well known that the P6 has branch target alignment issues, so using differently sized instructions can help you align your branch targets -- and in the case of MOV EAX, 0 versus XOR EAX, EAX they are equivalent in terms of performance, only differing in the opcode space they use.
And I am surprised that you didn't read the article before commenting on it...
Does this mean the US goverment will ban the distribution of binary executables and will only allow distribution in sourcecode form?
A byte is a bite of information. However, the word bite can easily be misspelt bit, while byte cannot. The byte is not eight bits by definition, and you blatantly did not read the reference I gave to the correct definition of byte, nor any of the other fine references available. You're not only wrong, but ignorant and I claim my five pounds.
It's easy, and it's fun! Just run the following command:
dd if=/dev/random of=/tmp/encrypted-terrorist-plans.txt.encrypted bs=1024k count=5
If everyone does this on all their network connected machines, it will keep big brother busy. And it'll show those damn courts who's boss when you CAN'T give them the password.
PUSH A000
POP ES
Were you trying to embed a message about children's lollipops?
And when you edit or execute the file the filesystem decompresses it to a useable state. So really your arguement and the one your replying to are still fucking bull shit uninformed uneducated garbage. Shut the fuck up and go home.
The point of a language is to communicate. Virtually everyone uses the word byte to mean eight bits. If you purchased 4 gigabytes of RAM, only to discover the vender redefined byte to mean one bit, you'd be hopping mad.
The picture had a caption that said, "Everytime you masturbate, God kills a kitten... and a plane full of infidels."
About 15 YEARS ago, I was reading the documentation for the A86 assembler. The author warned that any non-trivial amount of code compiled with his assembler could be identified and proven in court from the compiler's unique 'footprint'.
Same concept as this except that it was added by the assembler itself, hiding a simple pattern to identify the compiler, and I think it was a bit more subtle than this example.
Just in case anyone thought this was a new idea...
455fe10422ca29c4933f95052b792ab2
according to important emails that I have been privileged to receive, for a modest amount of money I can get pills that will add 3 inches overnight to my byte !
Are you new here?
Furthermore, there might be cases where it doesn't matter if the program works. So the program crashes or has logical errors. Does that make you 'guilty' of having hidden data in your file?
It'll be a strange day in legal history when the _user_ gets arrested/blamed/indicted because his computer crashes.
Hmm, The comment on stenography is just plain daft. It no more reasonable to claim stenography be 100% undetectable than it would be to claim that an encryption technique must be uncrackable. We have two main techniques available to us throughout history when it comes to transferring information in privacy. One such set of techniques is encryption i.e. the message is in plain view but encoded and stenography in which the message is plainly coded but in some sense hidden.
Actually Unicode characters can vary from 2-5 bytes as I recall. It depends on the encoding.
Don't many EULAs say that you can't alter the binary without prior arangments with the company? You could be charged with dissasembling or reverse-engineering the binary.
http://pixelcort.com/
you're a FUCKING idiot who can't even spell FAHRENHEIT!!!
you're so full of shit. you're probably one of those dipshit americans of 4th or 5th generation german or french decent that refuses to let go of your "heritage" by putting on this facade of being european. stupid dipshit.
Although I agree that the commonly accepted definition of byte is 8-bits (and a nybble is 4-bits), your derivation of byte as a contraction of by eight is apocryphal. The words byte and nybble were adopted from the Old English forms of the words bite and nibble, and refer to chunks of data in 8 and 4 bit sizes, respectively.
Referring to a language specification (such as the ISO C99 spec) or the Jargon File doesn't really work when you're defining words in common use. Although historically the byte has varied in size (as many other posters have pointed out), the commonly accepted definition among laymen and most computer scientists alike is that a byte consists of eight bits of data, and a nybble consists of four bits.
If you open any dictionary such as the OED or Webster's, you'll find such a definition.
To disprove the validity of using a language specification as a proof of how big a data type is defined to be, one only needs to pick up another language specification. I do much of my programming in Java, and in Java, the byte data type is defined to always be a signed, eight-bit number. (In many C implementations, byte is equivalent to an unsigned char; in other C implementations, byte is equivalent to char, and can be signed or unsigned.) In Java, a char is a unicode character, sixteen bits in size, and not at all equivalent to a byte.
In general computer science classes, a byte is treated as an eight-bit entity. It was taught this way at MIT. A nybble was similarly taught to always be a four-bit entity. Then again, at MIT, the CS professors emphasized the distinction between computer science concepts in general and implementation details of languages in specific. Since I have built discrete component computers for the infamous MIT 6.003 course, which rely on ALU chips that process data in discrete nybble (four-bit) sized chunks, I have a pretty solid grasp of what the common parlance is.
The fact that C tries to redefine a byte to be some data size that's processor dependent is interesting, but does not agree with common use among most computer professionals or laymen. Therefore, the more common use should be considered the correct one, regardless of whether you personally agree with this position. That's how dictionaries get written -- consensus and common use.
Back when I was learning C, there was no "byte" data type, only char.
"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." This quote makes no sense. A char does not define a byte, nor does the operating system's choice of how to represent characters internally.
Clearly, in the world of Platonic ideals, there's an entity called a byte that is invariant and unchanging. And then there are crappy implementations of languages and operating systems in the real world, as well as some really questionable fluff in language specifications. Sorry, but I don't buy argument by redefinition. And the later posts that follow up, appealing to the Jargon File and other storehouses of historical trivia, do not in any way reflect common usage, which again should be the arbiter of how language is defined and used. It's nice to know that old IBM machines represented a byte as anywhere from one to six bits, but today, a byte is an octet of data, and that's that.
Get over it and move on. Find a more fruitful battle to fight.
The C standard in no way, shape, or form defines reality outside itself.
The C specification does not force general computer science concepts to conform to itself. Indeed, the reverse SHOULD be true.
"But the punchline is strengthened; the byte is defined in multiple sources as the size of a character variable. One use of this form of the word byte has been shown to predate the incorrect definition of a byte as strictly equal to an octet. Case rests."
This logical fallacy is commonly referred to as argument by appeal to false authority. Your argument doesn't change the fact that most common people, as well as computer science text books, refer to a byte as an octet of data, regardless of whatever historical definitions may or may not have been applied. This is the evolution of language, much as you might not like it.
Neither the Jargon File nor the C specification is a sufficient source of authority to redefine the byte as you see fit.
Furthermore, if a byte's definition is so fluid, what does this say about other units of data width, such as the nybble? (Granted, the nybble is archaic, but those of us who used it remember.)
Hmmm....Think about it....Usenet...
30GB a day of grainy porn...
Why again do the terrorists need encryption?
http://www.fourmilab.ch/stego/
Dan
IYHO. IMHO, the C standard is sufficient, and the independent corroboration from a well-researched source like the jargon file confirms the definition. We'll just have to agree to disagree. BTW if the definition I quoted was a "redefinition", then so is the eight-bit byte. The original use of the word byte by IBM programmers referred to the size of whatever information chunk they were considering.
It leaves them as arbitrary as they always were. It's obvious to anyone who's ever programmed cross-platform (or bought a hard drive) that the only unit of data guaranteed to be the same everywhere is the bit. For instance I wouldn't rely on the eight-bit byte when using a serial port for communication, because it could require sending two chunks of data, if the DTE and DCE were configured for seven bits + chuvmey.
The most advantageous, pre-eminent thing thou canst do is not to exhibit
nor display thyself within the limits of our galaxy, but rather depart
instantaneously whence thou even now standest and flee to yet another rotten
planet in the universe, if thou canst have the good fortune to find one.
-- Carlyle
- this post brought to you by the Automated Last Post Generator...