Difference between revisions of "Summerschool Aachen 2004/Malware Lab"
m (→The Quiz, Question 1) |
(→Documenting the Lab Session) |
||
| Line 22: | Line 22: | ||
The perl scripts execute the system call with the number 4, sys_write(), supplying a file descriptor of "1", which denotes stdout, the standard address of the ELF header of the binary (probably the perl interpreter) being executed (increased by 1 to skip the leading 0x7f) and an output length of "3". | The perl scripts execute the system call with the number 4, sys_write(), supplying a file descriptor of "1", which denotes stdout, the standard address of the ELF header of the binary (probably the perl interpreter) being executed (increased by 1 to skip the leading 0x7f) and an output length of "3". | ||
The perl script outputs "ELF" on my Linux box. | The perl script outputs "ELF" on my Linux box. | ||
| + | |||
| + | ==== The Quiz, Question 2 ==== | ||
| + | I found out that the "yourtoy" file was a (corrupted) UPX - compressed file pretty fast. But trying to uncompress it with the upx utility didn't succeed as the file seemed to be corrupted in some way.<br> | ||
| + | I then tried upx'ing two other files, creating hexdumps of them and then doing a "diff3" on the hexdumps. I noticed that there were some areas where the other files matched but differed from "yourtoy" so I tried overwriting the corresponding areas in "yourtoy" with a hexeditor with the values found in the other files, but this did not work out.<br> | ||
| + | After that i downloaded the source code for upx and ucl (the library upx uses) and used ddd to debug upx working on "yourtoy". I traced through several function calls until I found the one that finally returned the information "this is not a valid upx file". That function just searched the to-be-uncompressed file for some magic string, which it didn't find in "yourtoy". I then had a look at the other files I had created to find out that "yourtoy" was missing a second occurence of this string, serving as some kind of "end-of-upx" marker, but instead contained another magic string of bovine origin. I replaced that with the correct string and was finally able to uncompress "yourtoy". | ||
| + | |||
| + | -- [[Lutz Böhne]] | ||
[[Category:Summerschools]] [[Category:Hacks]] | [[Category:Summerschools]] [[Category:Hacks]] | ||
Revision as of 14:10, 6 October 2004
Contents
Notes about Presentation
ELF Tools and others
- http://soua.net/elf.py
- http://michael.bacarella.com/projects/sograph/sograph-0.95/elf.py
- http://elfsh.devhell.org/
- http://directory.fsf.org/libs/misc/libelf.html (http://developers.sun.com/solaris/articles/elf.html)
- http://sourceforge.net/projects/elfio/
- http://www.kerneled.org/projects/elf/index.html
- http://www.z0mbie.host.sk/infelf.html
- ELF(5)
- readelf(1), from GNU binutils
Notes about Lab Session
more elf tools
- elfsh - elf shell
small quiz
There is a really small quiz consisting of just one question here.
Documenting the Lab Session
The Quiz, Question 1
The perl scripts execute the system call with the number 4, sys_write(), supplying a file descriptor of "1", which denotes stdout, the standard address of the ELF header of the binary (probably the perl interpreter) being executed (increased by 1 to skip the leading 0x7f) and an output length of "3". The perl script outputs "ELF" on my Linux box.
The Quiz, Question 2
I found out that the "yourtoy" file was a (corrupted) UPX - compressed file pretty fast. But trying to uncompress it with the upx utility didn't succeed as the file seemed to be corrupted in some way.
I then tried upx'ing two other files, creating hexdumps of them and then doing a "diff3" on the hexdumps. I noticed that there were some areas where the other files matched but differed from "yourtoy" so I tried overwriting the corresponding areas in "yourtoy" with a hexeditor with the values found in the other files, but this did not work out.
After that i downloaded the source code for upx and ucl (the library upx uses) and used ddd to debug upx working on "yourtoy". I traced through several function calls until I found the one that finally returned the information "this is not a valid upx file". That function just searched the to-be-uncompressed file for some magic string, which it didn't find in "yourtoy". I then had a look at the other files I had created to find out that "yourtoy" was missing a second occurence of this string, serving as some kind of "end-of-upx" marker, but instead contained another magic string of bovine origin. I replaced that with the correct string and was finally able to uncompress "yourtoy".
-- Lutz Böhne
