My account was hacked through a Second Life texture?

[Perrie Juran]

---

Innula Zenovka wrote:

Cerise, who knows more than most people about technical matters, did say eariler in the thread that

---

A real copy of the imuler back door would have been inserted into your library folder, where it could have an actual effect.

It's a 99.99999% chance that this was only coincidence. The password change probably happened through a different route.

---

---

I have trouble with big numbers.  But yes.

I also have a theory that 99% of the people who are always passing along false virus warnings are the most likely ones to have a virus or trojan on their computer.

 

[161488303349]

---

leon Bowler wrote:

so yes then.

---

no

look again at the 7 pattern. is trivial to know that an attempt to hide data in it has been made. so if i am going to put a trojan onto your computer then am not going to do it this way. not unless i am a scriptz kiddie

also you made a claim that some scriptz kiddie done this to you in a sculpt texture in SL. i ask if you kept an image of it. seems not. if you had of then would be trivial to show for certain if has a actual trojan in it. or not and was a false positive thrown up by your anti-virus

if so and is true then ok we know and linden can take remedials. if not true then your harddrive trashing for some other reason

 

[161488303349]

---

leon Bowler wrote:

If you assume the code is in the image, the image can just be a key, like a picture of Big Ben, it is a static image that is repeated, like a work of art then that could be the key, any image can be the key, the code is in the innocent program as data looking random but when XORed with a certain image could produce code.

So any computer would looked fine and virus free until a certain image was shown on it or on a texture and a segment of code would be made and executed.

---

take a binary program installed in memory as an executable then scramble it with a memory monitor program and see what happens

+

take a binary program and install in memory as an executable so that it can recognise when the image appears so that it can apply it to some other data stored elsewhere to turn it into a disk trasher. or

take a binary program and install in memory and trash the disk

 

with either approach try to hide the program itself and the method of installation

 

[161488303349]

---

leon Bowler wrote:

If you assume the code is in the image, the image can just be a key, like a picture of Big Ben, it is a static image that is repeated, like a work of art then that could be the key, any image can be the key, the code is in the innocent program as data looking random but when XORed with a certain image could produce code.

So any computer would looked fine and virus free until a certain image was shown on it or on a texture and a segment of code would be made and executed.

---

take a program say a disk trashing program. XOR this with a image file of Big Ben

store both of them on your hardrive. open the image of Big Ben

to decode the disk trashing program and install it so it can be executed then you need another program to recognize that the image is Big Ben

how does this other program know it is Big Ben? it needs a key stored in/with the program itself to make a match. and it will need to scan and compare every image displayed so can tell Big Ben from not Big Ben images

+

can understand why you posing what you are. is just that the way you think it could be done is over complicated and actual unnecessary

 

 

 

[Madelaine McMasters]

---

leon Bowler wrote:

If you assume the code is in the image, the image can just be a key, like a picture of Big Ben, it is a static image that is repeated, like a work of art then that could be the key, any image can be the key, the code is in the innocent program as data looking random but when XORed with a certain image could produce code.

So any computer would looked fine and virus free until a certain image was shown on it or on a texture and a segment of code would be made and executed.

---

It doesn't make any difference what is in the image, code or key. Bits is bits and you won't be able to hide very many of them without being apparent in the image.  And you can't just bury bits in the image and expect to retrieve them on the other end because SL uses lossy JPEG2000 compression. You'd have to encode your bits with sufficient redundancy to survive the compression losses. If you can't get out exactly the bits you put in, you can XOR your heart out and you'll get nothing but noise.

You have also not explained how the hidden code in the image would be executed by software which is completely unaware of it. Executing your nefarious hidden code would require a nefarious decoder-loader-executor to already exist on your computer. If that's already there, why on Earth go through all the trouble of getting more code through SL textures when you can simply call China and get bucketloads of it directly? If the nefarious decoder-loader-executor is not already on your computer, the images are just that... images.

@16, you could bury hidden messages in the least significant bits of an image without making them terribly apparent, as you suggest. Rather than having 256 levels of red, green and blue and alpha, the resulting image could have 128 levels, with each 32 bit pixel carrying four bits of nefarious code. If we presume the code is roughly random, the result would be an image which looks a tiny bit noisy (perhaps imperceptibly so). That would give you four million bits (half a megabyte) in a 32Mbit 1024x1024 image, room enough for a reasonably naughty algorithm. As for detecting the hidden bits, camera sensors are noisy and it's not uncommon to see a pixel or more of noise in a digital photograph. So it might be impossible to detect that hidden message, as it could be smaller than, or indistinguishable from, the image noise.

I just read about the F5 steganographic algorithm, which claims to be able to embed messages up to 13% of the size of a large JPEG image while retaining 80% image quality. That's far higher than I expected.

http://www2.htw-dresden.de/~westfeld/publikationen/f5.pdf

My refutation of Mr. Bowler's theory that code is riding in on images is based entirely on the need to have a nefarioius decoder already in place on the target computer. If it's there, the machine is already infected. He must explain how that got there and why it would go through all the hassle of digging more code out of textures.

 

[161488303349]

yes agree about how can widen the area to hide stuff in. was just use the 7 to show stenography done in a trivial way

+

agree also about having the decoder and bootstrapper already on the computer. and how does this program know that "this" image is the trigger

+

sometimes people try to show that steno is a good way to hide stuff. good like secure. and it is if the hidden message is encrypted before is inserted into the image. the image is a carrier for the hidden message

but if encrypted then the decoder program (in this case) now has to also know how to decrypt as well as do the other stuff. while remaining undetectable by the user and/or any sec app

 

[161488303349]

am just going to add here that steno can be used for watermarking of textures

1) take your brandname as plaintext (add salt if you want)

2) encrypt it with a secret password

3) choose one or more areas within your texture that are noisey

4) generate a "random" permutation of unique numbers using the secret password as the seed (knuth shuffle or feistel will do)

5) use the permutation to choose which of the areas and which byte within the chosen area to flip (xor) the lsb

6) for each new texture create a different secret password

+

this is reversible. each password will always decode to the brandname

the strength lie in the permutation. the algo only ever choose a bit in the image once for each bit in the encrypted brandname . and the flip bits chosen are "random" meaning they different for each texture

+

edit: this called distance encoding. is the basic way of doing it. can mod the algo to add more stuff into it. like more rounds if you want

edit more: to crack it even if you have a oracle (like the code). then still have to know the password

edit more more (:

sometimes people say why do it have to be unique? like why cant just use any random string of numbers?

bc random random can make collisions. "random" unique does not ever. for the same set of input parameters