I'll preface this with "I am not a lawyer" ..

1.  Peter's legal representatives in Belgium and the US have sent letters to Infosec Institute but there is no indication of any response from them, hence his indication that he might wish to escalate matters.

2.  As there was a third party contractor who was responsible for creating the handbook, I am not sure who would be responsible in the event of legal action in view of an alleged infringement of copyright.  My "gut" feeling is that Infosec Institute will be the target of any action and I suspect that they, in turn, could take action against the contractor.

3.  Peter's papers are well known.  I am surprised that the material was not recognised by those responsible at Infosec Institute for delivering the material on the course.  I assume that they are/were instructor-led, rather than self-directed learning.

I'm sure that many are aware of the excellent series of in-depth papers produced by corelanc0d3r dealing with various aspects of exploit development.  I came across a post that he submitted today in which he is appealing for support.  I haven't looked at the documents in detail but, based upon my brief scan through them, they paint a surprising picture.  Obviously, it's down to everyone to decide whether they wish to help him.

Finally, I have no involvement with him or his site but am merely passing on this information.  He asked that this story is kept alive and I am helping to do that by bringing it to members' attention.

Please feed back with your experience.  This is something that I might also try in the lab.

I did it in two halves and, as far as I know, each of the 3 exams contains a similar number of questions.  I was also told by my tutor that going the 2 exam route may mean more in-depth questions (as well as more questions about any weak areas that a candidate might have) than the 1 exam route but I don't know if that's correct.

I would agree wholeheartedly with the idea of hands-on experience.  Quite a few of the questions were simulations where you have to interrogate routers or switches for their current configuration and then change the configuration to make the network function as required.  Only a small proportion were a typical MCQ with a stem and possible responses.  There is a time limit and it's not possible to go back over questions when you have advanced to the next one.

Sure thing MaXe.  I think that everyone here likes the challenge of finding a problem and solving it ... or at least giving it a good thrashing before realising that it can't be solved!

I have made some progress with the code that I uncovered on packetstorm.

Thank you MaXe.

I see that they provide the software but I would like to know how things work and be able to compile then run the software myself!

We had quite a lively discussion a while ago about methods of making meterpreter payloads capable of bypassing AV.  I've been researching further and saw a nice write up of a technique that uses a DLL to write shellcode directly into an executable in memory.  When the executable's shellcode has been updated, it runs the shellcode.  This is the link to the article and accompanying code.  Has anyone else seen this?

I've managed to compile dummyApp.exe file and it's payloadLib.dll but the DLL fails miserably when trying to execute VirtualProtectEx.  The line of code that throws up an error is:


The error code is 487 - "ERROR_INVALID_ADDRESS"

I've seen that some of the code in the package needs some slight tweaks.  My system is Windows XP SP3 and DEP is enabled only for essential Windows programs and services.

Thank you in anticipation for any insight into how to get this fascinating technique to work.

EDIT: after a bit more reserarch

@H1t M0nk3y:  It's gratifying to have guidance from someone who has such a lot of experience under their belt.  We've both shown that the executable works as planned, both within and outside OllyDbg.  I didn't know if the Access Violation when stepping though/over was due to something that I was doing wrong or if it was, indeed, a bug within OllyDbg.  I turn my computer off each night and the executable is standalone, rather than an installation.  I've tried both v1.10 and v2.00.01 with identical results.  I've also tried Immunity Debugger with the same result.  I think I'll hilight this problem to the OllyDbg developer but I didn't want to make a fool of myself in case the behaviour was due to something that I was. or wasn't, doing!

@matugm:  Thank you for the link.  I tried searching for the initial four xor commands but they didn't show up in the main (CPU) window until I hit the memory breakpoint that I mentioned in an ealier post in this thread.

I'm starting to think that there's a bug in OllyDbg.  If I put a breakpoint (F2) on 0040200B, 0040210B and 0040202C and run it to the first breakpoint (F9), it runs without any Access Violation and I can step through/over (F7/F8) as I want.  If I remove the breakpoints and step through/over, the Access Violation recurs.

I'd be grateful if you (or someone else) can try it to see if the behaviour is specific to my system.

If it is a bug, its disappointing because if I had seen the Access Violation, I would have assumed that my code was at fault so would have been chasing my tail to correct it!

Thank you for your assistance.  I can see what you mean, but how do I get OllyDbg to step through my code in the CPU (top left) window?  I see that the memory locations in that window are 00401000 to 00401FFF but my code starts at 00402000.

I stepped into (F7) CALL msgbox.00401020 and continued F7 repeatedly but nothing showed my code in the CPU window and I got bored pressing F7 repeatedly!  Eventually, I pressed F9 and, sure enough, the execution worked perfectly.

Surely there's way of stepping through my code in OllyDbg?  The msgbox code is simple enough but, if it was very complicated and didn't work as planned, I wouldn't be able to just "eyeball" it and see exactly why and where it was failing.

EDIT:

I just set a memory breakpoint at 00402000 by hilighting the first of my instructions in the Memory window then right click -> Breakpoint -> Memory and ran it via F9.  It stopped at my code and displayed it in the CPU window so I thought that I'd cracked it.  However, I pressed F8 repeatedly and, after 4 or 5 (memory location 0040203F - CALL 0040200A), I got an Access Violation.

Can you try it on your system and see if you get the same error?  Do you (or anyone else) have any suggestions?

Thank you for the comments.  Here's a detailed step-through, along with the code that I used.  It's not an exploit, but simply a message box.

I have a laptop with 32-bit XP Pro SP3 (not a VM).  The software is OllyDbg v2.00.01, nasm and mingw.

1)  Put the following code through nasm with <nasm msgbox.asm -o msgbox.bin>.


2)  Extract the 105 bytes of NULL-free shellcode from msgbox.bin and put it into a C frame:


3)  Compile the C code with <gcc msgbox.c -o msgbox.exe>.

4)  Run msgbox.exe from the command line and it pops up the message box, so everything's working as it should.

5)  Open OllyDbg and load msgbox.exe.  It show the Entry Point of the executable (PUSH EBP; MOV EBP, ESP; SUB ESP, 18 etc.).

AIM

Find my code in OllyDbg (XOR EAX, EAX; XOR EBX, EBX; XOR ECX, ECX; XOR EDX, EDX etc.) then step through it whilst watching the registers, stack and memory.

I've tried some ideas:

a)  put several int 3 immediately before the initial XOR EAX, EAX instruction
b)  put "\xcc\xcc\xcc\xcc" at the top of my shellcode before compiling
c)  put an instruction such as MOV EAX, 0ABAABA0 before the initial XOR EAX, EAX in the hope that I could search for that particular command (via ctrl-T in OllyDbg)

unfortunately, none of these has allowed me to find my code in OllyDbg.  I'm starting to think that it's not possible so, if it's not, how do I access code that I want to debug?  If it's very complicated, I'll NEED to be able to see exactly what's happening to the registers, stack and memory so I can correct any errors.

I hope that I've provided sufficient information and I apologise for such a lengthy post!

Thank you.

I've seen Vivek's videos and my problem isn't so much writing the code.  I'm far from an expert and have accessed several sites for code examples.  The problem that I have is being able to load it into OllyDbg (or Immunity) and step through the code, watching what happens in the registers, memory etc. to make sure it does what I want.

I've also seen MaXe's excellent paper which deals with writing shellcode by hand and have worked my way through much of it ... but I still don't know how to stop reliably at MY shellcode within the compiled C Code, which is preceded by a whole load of code inserted by my compiler.

The tricks that I've tried result in an Access Violation when I have been successful in finding the start of my code and have stepped through it.

I've resumed working with assembly language, having "played" around with it many years ago.  I've generated shellcode that I've put into a C Code frame and then compiled using gcc in mingw.  I loaded the executable into OllyDbg and, as expected, it starts at the entry point which is nowhere near the code that I wrote.  I need to be able to find that code so I can step through it.

I've tried setting a register to a specific value (maybe 1357ABCD) at the beginning of my code and then set that as a condition via Ctrl-T (Condition to pause run trace), but it doesn't stop at my code.  I've also tried inserting a few Int 3 instructions at the beginning of my code (or \xcc\xcc\xcc at the beginning of the shellcode).  When I load the executable in OllyDbg and run it, it stops at the Int 3 but, when I step through the code past the Int 3, using F7 or F8, I frequently get an Access Violation which I never saw without the Int 3 instructions.  The code stops dead and I can't go any further.

I've also tried using Immunity Debugger but it does exactly the same.  If I can't find a way of seeing my code in a debugger and stepping through it to make sure it's doing what it's supposed to, I might just as well give up.  I'm so frustrated!

Does anyone have any suggestions?

Thank you don for bringing these videos to everyone's attention and to Raphael for his time and expertise.  I'll set some time aside later this week to digest them then play around with the concepts discussed.

Thank you for the link.  I've seen that paper and have been collecting links to relevant papers, blogs etc.  It was when I saw the paper before, I was spurred into joining your forum as there's a lot of interesting information there!