Program Hides Secret Messages in Executables 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."
stenography (Score:5, Insightful)
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 (Score:2, Informative)
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 (Score:5, Informative)
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 (Score:4, Insightful)
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 (Score:5, Insightful)
None of your freaking business. Mohammed bin Mohammed is an old friend of mine, he wanted to see a picture of my new kitten.
Freedom of expression, freedom of speech. No?
Maybe a professor's testamony of "high probability" is enough to get you in deep shit over there, fortunately we still have something that reminds of citizen rights, this side of the pond.
Re:stenography (Score:5, Interesting)
You have a point. On November 12th, 2001, a 58-year old Australian woman resident in Helsinki, placed an obituary notice for Mohammed Atta in Finland's daily newspaper, Helsingin Sanomat. She was questioned by police. If I remember correctly, she had met him many years earlier, had no idea he was a hijacker, but had heard that he had recently died. But, when thousands of lives are at risk, suspicious events have to be followed up, even if it's only to eliminate them from enquiries.
Maybe a professor's testamony of "high probability" is enough to get you in deep shit over there, fortunately we still have something that reminds of citizen rights, this side of the pond.
Since you mention Freedom of Speech, a Constitutional right, I'll assume you're on the West side of "the pond". I suggest you look up Jose Padilla's story.
What might have tipped them off... (Score:3, Funny)
Re:stenography (Score:2, Funny)
Because he said something about wanting to get a little pussy before his trip...
-
Re:stenography (Score:2, Insightful)
Re:stenography (Score:2, Troll)
Re:stenography (Score:3, Informative)
Re:stenography (Score:2)
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.
Re:stenography (Score:3, Informative)
I'm afraid this will not work.
Problem is: 'normal' programs will do 'sub 50' instead of 'add -50'. If you don't want to be visible that a message is contained, you cannot change that. But if you don't change that (in about 50% of the cases), you can't hide the information! The only key that would work here would be as long as the message itself!
The technique you propose will work to get a more even distribution of ones and zeros, but not the 'all zeros' (sub 50) distribution that is present in 'standard' programs.
Re:stenography (Score:2)
Now, Steganography, that's also cool, but in a very different and special way.
Re:stenography (Score:3, Informative)
Re:stenography (Score:5, Funny)
"Bring me my +5 Sword of Information Hiding!"
Redundancy? (Score:4, Interesting)
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? (Score:5, Informative)
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) (Score:2)
The thing worls as using add and subtract of signed numbers.
Re:Redundancy? (Score:2)
The meaning (Score:3, Informative)
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? (Score:5, Informative)
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? (Score:3, Informative)
Re:Redundancy? (Score:2)
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? (Score:5, Informative)
Re:Redundancy? (Score:4, Insightful)
The second example has the additional problem of having a different side-effect on AX and possibly stack faulting.
Jump Targets (Score:2)
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? (Score:2, Informative)
Re:Redundancy? (Score:5, Informative)
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.
Re:Redundancy? (Score:3, Informative)
You're confusing redundancy in the program (extra instructions executed) with redundancy in the instruction set (extra instructions available).
The i386 set has add and subtract instructions where only one is strictly needed. From what I've read, this tool works by changing a sub 50 to an add -50, taking advantage of this. (Or a add 30 to sub -30.)
The problem is, no person or complier would write code this way unless they had a particular reason to. Such as hiding something.
But detection should be easy... (Score:5, Insightful)
Novel idea though!
Re:But detection should be easy... (Score:3, Interesting)
And the code looks pretty much like its compiler generated.
Re:But detection should be easy... (Score:4, Interesting)
This is also why the data should be encrypted before hiding it in the message
Re:But detection should be easy... (Score:4, Interesting)
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... (Score:2)
If this encoding technique became popular, then so would the necessary tools to scrabmble the covert channel.
How long... (Score:5, Funny)
Re:How long... (Score:2)
http://www.ntsecurity.net/Articles/Index.cfm?Arti
Dammit, pick a beowulf joke so I get it! hehe
For those who encounter compilation problems... (Score:4, Informative)
First used in a86.com (Score:5, Informative)
Eric Isaacson used the technique to mark executables, so that he could determine if they were created with an unregistered copy of a86.
new compression standard: rm -rf (Score:4, Funny)
Re:new compression standard: rm -rf (Score:2, Funny)
Hiding messages within messages (Score:5, Informative)
Difficult part, code, data, format (Score:2, Interesting)
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 (Score:4, Interesting)
Yes, it does that.
Self-signing? (Score:2)
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,
Only for use by terrorists (Score:3, Interesting)
I bet the get shut down, under the patriot act, before you can say 'what's that knock at the door'..
Yes, it can be done... (Score:5, Funny)
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?
Re:Yes, it can be done... (Score:2)
For more information on the uses of encryption in human rights organizations, read these letters [mit.edu] to Philip Zimmermann [mit.edu] (the creator of PGP).
Re:Yes, it can be done... (Score:3, Informative)
If you want deniability even in the face of torture, you want rubber hose [rubberhose.org] crypto. You might also want to use an authentication method more complicated than a password, so they'll have to torture you in the computer room instead of the dungeon, and they can't break your fingers or damage your higher brain functions.
I know why (Score:2)
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.
Question: (Score:2)
- Replace length fields with two fields (length of length, and length) to avoid attacks on stream cipher.
Attacks on stream cipher?
Messages can be found in games too (Score:4, Funny)
I'm not so sure about hiding messages in executables, but there were two interesting messages hidden in the n64 game The new tetris [ign.com]. 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 [dextrose.com]
Re:Messages can be found in games too (Score:3, Funny)
It's cool to see a scener in game development, though that's where I figured most of them settled. I'm not surprised with his discontent towards the development process; with the amount of ingenuity and dedication that goes into (went into?) intros/demos it's got to be a shock to hit a corporate environment and have somebody tell you "It's good enough as it is" when you're working on your project and ship it out the door.
Re:Messages can be found in games too (Score:3, Informative)
"At the time he got himself and H2O in quite a bit of hot water with Nintendo. He figured it was his small piece of immortality"
He was right
http://www.pridie.org [pridie.org]
The problem is if you have two copies (Score:3, Insightful)
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.
Re:The problem is if you have two copies (Score:2)
You're very close with your second paragraph -- this is basically the correct answer, but I'll just clarify it a bit:
Compilers usually mark the executable with their name. I know GCC does this; I'm pretty sure it's part of the ELF standard. Knowing this, you can tell what code would be generated by the compiler and/or linked-in libraries; any other code in these regions would indicate tampering. Two examples:
1. Check all library functions, including startup/exit and DLL-load functions. If these functions are different, then you've found a steg. Of course, some of these functions (usually those not in pure assembly) will change with compiler versions, so there are multiple non-steg possibilites.
2. Check the function start-up code. If, for example, a compiler adjusts the stack by subtracting a fixed value, then if you ever see it add the negative value here you found a steg. This is so simple, it's unlikely to change between compiler versions.
You could also check the above two regions for self-consistancy. If the function-start code varies between functions, then maybe you've found the steg.
The big exception here is when code from different compilers is linked together. This usually happens only when you've got a closed source library. Summary: "unusual" is easy to detect for a given compiler.
Re:The problem is if you have two copies (Score:2)
Or could it fake a match to "what if this
Re:The problem is if you have two copies (Score:3, Informative)
Re:The problem is if you have two copies (Score:5, Funny)
On second thought, I have another idea: make a huge file that is nothing but stenographic data. Hide an executable in it.
Actually, for stuff like DeCSS, that may not be so farfetched.
Wrong product (Score:5, Funny)
Surely, a declaration of independence should be stored in a non Microsoft product.
We'll be right back... (Score:2)
I do this already! (Score:5, Funny)
I hide all sorts of stuff in my C comments.
Nobody can detect them in my executables.
HA! I'm so sneaky!
Old News (Score:2)
;)
Re:You might have gotten hoaxed. (Score:3, Informative)
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. (Score:5, Insightful)
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. (Score:3, Insightful)
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.
Hydan works. (Score:2, Interesting)
"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
Re:Hydan works. (Score:2)
"The SUB instruction
Which means that the CF stays the same for both instructions since their results are the same.
c:\>debug
-a
104C:0100 xor ax,ax
104C:0102 sub ax, -3
104C:0105 int 3
104C:0106 xor ax, ax
104C:0108 add ax, 3
104C:010B int 3
104C:010C
-g
AX=0003 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=104C ES=104C SS=104C CS=104C IP=0105 NV UP EI PL NZ AC PE CY
104C:0105 CC INT 3
-rip
IP 0105
-g
AX=0003 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=104C ES=104C SS=104C CS=104C IP=010B NV UP EI PL NZ NA PE NC
104C:010B CC INT 3
-
Notice the "CY" and "NC"'s in the two different runs. Just because Intel has defined "overflow" circularly, or in an opposite sense than you might be thinking about for subtraction doesn't mean we can't deduce what is really going by simply running the code for ourselves.
Re:You might have gotten hoaxed. (Score:3, Interesting)
It'll be a strange day in legal history when the _user_ gets arrested/blamed/indicted because his computer crashes.
Re:You might have gotten hoaxed. (Score:2)
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. (Score:5, Funny)
> 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. (Score:5, Insightful)
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.
Re:You might have gotten hoaxed. (Score:3, Informative)
Re:You might have gotten hoaxed. (Score:2)
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.
Re:You might have gotten hoaxed. (Score:3, Insightful)
Re:You might have gotten hoaxed. (Score:2)
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.
Re:You might have gotten hoaxed. (Score:2)
Re:You might have gotten hoaxed. (Score:2)
You have to buy it from the ISO [iso.org], 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 [ansi.org], 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.
Re:You might have gotten hoaxed. (Score:2)
Re:You might have gotten hoaxed. (Score:2)
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.
Re:You might have gotten hoaxed. (Score:2)
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
Re:You might have gotten hoaxed. (Score:2)
Re:You might have gotten hoaxed. (Score:2)
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 :-)
UTF-16 in the Java language (Score:2, Informative)
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.
Re:You might have gotten hoaxed. (Score:2)
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.
Re:You might have gotten hoaxed. (Score:2)
You might have gotten trolled (Score:3, Funny)
I am working on a 36 bits machine. (Score:2)
Re:You might have gotten hoaxed. (Score:3, Informative)
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. (Score:3, Funny)
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. (Score:3, Informative)
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. (Score:2)
Re:You might have gotten hoaxed. (Score:2)
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.
Re:You might have gotten hoaxed. (Score:5, Informative)
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. (Score:2)
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.
Re:You might have gotten hoaxed. (Score:2)
You, sir, are a moron.
Re:You might have gotten hoaxed. (Score:3, Funny)
Re:You might have gotten hoaxed. (Score:2)
If you consider COMPRESSED files, there is a prob (Score:2)
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.
Re:Virus (Score:5, Informative)
Daniel