/ *
* For x86 / ewindows XP SP1 & VC 7
* CL Vulnerable_0.c / Nologo / OS / G6 / W3 / D "WIN32" / D "NDebug" / D "_console" / link / release
* /
#include
#include
#include
#pragma comment (Linker, "/ Incremental: no")
#pragma comment (Linker, "/ subsisystem: console")
INT __CDECL Main (int Argc, char * argv [])
{
UNSIGNED Char BUF [8];
IF (2! = argc)
{
FPRINTF (stderr, "usage:% s
Return (exit_failure);
}
STRCPY (BUF, Argv [1]);
Printf ("% S / N", BUF);
Return (exit_success);
} / * End of main * /
The previous discussed how to interrupt it in the VulneRable_0.exe process space, this time this time this time you use the monitoring point.
Positioning the code point that causes the overflow.
In the << SMB series (11) - Transact2_open processing, there is a remote buffer overflow vulnerability >>
Debugging skills, using Watch function to position code points that cause overflow. WINDBG's BA cannot be in user-level debugging
Use, why is it like this. Softice's BPM breakpoint is equivalent to the gdb's Watch command.
Open Faults ON, let EIP equal to 0x41414141 Softice pop-up:
Break Due To BP 00: BPX # 001b: 00401289 (et = 4.41 seconds)
: BL
00) bpx # 001b: 00401289
: Faults on
: g
Break Due to UnhandledException NTSTATUS = Status_Access_violation
In the current stack top (ESP) at a low position search feature byte, try to locate the stack frame used by the RET instruction:
: S -A ESP & fff0000 L ESP & 0000fffff "Aaaaaaaaaaaaaaa"
Pattern Found AT 0023: 0012F948 (0000F948)
Pattern Found AT 0023: 0012FA60 (0000fa60)
0000000002 Occurances Found
: dB 0012F948 L 20
00241 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAAAAAAAAAAAAAA
0023: 0012f958 0D 0A 00 00 01 00 00 00 00 00 00 00 ................
: DB 0012FA60 L 20
0021 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAAAAAAAAAAAAA
0023: 0012FA70 0D 0A 02 03 02 03 02 03-02 03 10 02 10 02 10 02 ..............
: faults off
: g
Note that there are "/ r / n" at the end of these two, from the source code, you can know that the two must be BUF [], the buffer used in Printf (). Generally, there is no source code for reference, you can only try to write a monitor point in these two outside, find out
This is written to the code point of "aa..aa". Re-execute Vulnerable_0.exe, interrupt in total entry points:
: BD 0
: bpmd 0012F948 w if * 0012F948 == 41414141
: bpmd 0012fa60 w if * 0012fa60 == 41414141
: BL
00) * bpx # 001b: 00401289
01) BPMD # 0023: 0012F948 W DR3 IF (* (0x12f948) == 0x41414141)
02) BPMD # 0023: 0012FA60 W DR2 IF (* (0x12fa60) == 0x41414141)
Remind again that BPM breakpoint disappears with the process space, so it should be interrupted as soon as possible in Vulnerable_0.exe
In the process space, then set the BPM breakpoint, not other moments. G continues to execute, one of them write a monitored life
in:
: g
Break Due to BP 02: BPMD # 0023: 0012FA60 W DR2 IF (* (0x12fa60) == 0x41414141)
: D 0012FA60 L 20
0023: 0012FA60 41 41 41 41 02 03 02 03-02 03 02 03 02 03 02 03 aaaa .........
0023: 0012fa70 02 03 02 03 02 03 02 03-02 03 10 02 10 02 10 02 ................
: D 0012F948 L 20
0023: 0012F948 00 01 00 84 FD 12 00-00 01 00 00 84 FC 12 00 ................
0023: 0012F958 00 01 00 A8 03 00 00 00 00 00 00 00 00 ..............
:
Code is written to 0x0012FA60 to "AA..AA", in this code, F10 is single-step, then discovers the source string
Related to the following code:
001b: 00403C11 8B55F8 MOV EDX, [EBP-08]
001b: 00403C14 FF45F8 Inc DWORD PTR [EBP-08]
001b: 00403C17 8A12 MOV DL, [EDX]
: DD EBP-8 L 4
0023: 0012FE74 003718BC C0BDC4AA 0012FEE4 0040217A ..7 ......... Z! @.
: DB 003718BC-20 L 40
0023: 0037189C 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0023: 003718ac 00 00 00 01 02 01 01-00 01 08 00 41 41 41 41 .......... aaaa
0023: 003718BC 41 41 41 41 41 41 41 41-41 41 41 41 0A 00 00 00 Aaaaaaaaaaa ....
0023: 003718CC 00 00 00 00 00 00 00 00 00 ..............
This time I found that there were 16 'a' at 0x003718B8, and there is one '/ n' behind. Search memory again :: S -A 0 L 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF "aaaaaaaaaaaaaaa"
Pattern Found AT 0023: 0012FEDC (0012FEDC)
Pattern Found at 0023: 00142371 (00142371)
Pattern Found AT 0023: 00142FD9 (00142FD9)
Pattern Found AT 0023: 00370B3D (00370B3D)
Pattern Found AT 0023: 003718B8 (003718B8)
0000000005 Occurances Found
You don't have to search for the 0x80000000 start space, that is the kernel space.
: stack
FrameEBP Reteip Symbol
0012FE7C 0040217A VulnerAble_0! .Text 2C11
0012FEE4 41414141 Vulnerable_0! .Text 117a
Check that the call stack is trained to find a return address has been overwritten to 0x41414141, with memory search results.
Control, apparently we should write a monitoring point under 0x0012FEDC:
: be 0
: BC 2
: BPE 1
: BPMD # 0023: 0012FEDC W DR3 IF (* (0x0012FEDC) == 0x41414141)
: BL
00) bpx # 001b: 00401289
01) BPMD # 0023: 0012FEDC W DR3 IF (* (0x12FEDC) == 0x41414141)
: g
However, this BPM breakpoint is invalid, and 0x0012Fedc has been written, and the process space has disappeared BPM breakpoints
It disappeared. I use the BPE command to set it once, leave it in the command buffer. Next time, only the BPX is interrupted.
The key head finds that the bpm command is reset, it is not necessary to enter a long string. Re-execute Vulnerable_0.exe:
Break Due to BP 00: BPX # 001b: 00401289 (et = 14.80 seconds)
: BL
00) bpx # 001b: 00401289
: BPMD # 0023: 0012FEDC W DR3 IF (* (0x0012FEDC) == 0x41414141)
: BL
00) bpx # 001b: 00401289
01) BPMD # 0023: 0012FEDC W DR3 IF (* (0x12FEDC) == 0x41414141)
: db 0012FEDC L 20
0023: 0012FEDC 00 00 00 00 00 00 00 00 00 ... 1 ... D.Y .....
0023: 0012Feec FF FF FF 00 08 00 00 00 8C 18 FD B1 77 4F 80 ........... WO.
g continues to execute, write monitoring points:
: g
Break Due to BP 01: BPMD # 0023: 0012FEDC W DR3 IF (* (0x12FEDC) == 0x41414141)
: db 0012FEDC L 20
0023: 0012FEDC 41 41 41 41 41 41 41 00-c0 ff 12 00 f9 13 40 00 aaaaaa ....... @.
0023: 0012Feec 02 00 00 10 0b 37 00 00 00 00 00 .... .7.x.7 .....
: stack
Frameebp reteip symbol0012fee4 004013f9 Vulnerable_0! .Text 011b
0012FFC0 77E814C7 Vulnerable_0! .Text 03F9
0012FFF0 00000000 Kernel32! _BaseProcessStart 0023
In the function corresponding to the stack frame 0x0012Fee4 (EBP), there is code that causes its own stack frame to be overwritten, this is the most
Type stack overflow. And we have found code points that lead to overflow:
EAX = 7efefefe EBX = 7FFDF000 ECX = 00370B44 EDX = 41414141 ESI = 00000A28
EDI = 0012FEDF EBP = 0012FEE4 ESP = 0012FECC EIP = 0040111B O D i S Z A P C
CS = 001B DS = 0023 SS = 0023 ES = 0023 fs = 0038 GS = 0000
─────────────────────────Prot32-
001b: 0040111b 83c704 add edi, 04
001b: 0040111e Baffefe 7E MOV EDX, 7EFEFEFF
001b: 00401123 8B01 MOV EAX, [ECX]
001b: 00401125 03D0 Add EDX, EAX
...
001b: 00401150 EBC7 JMP 00401119
001b: 00401152 8917 MOV [EDI], EDX
(Passive) -kteb (8106b240) -tid (0164) - Vulnerable_0! .Text 011B - ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Summarize the whole process:
a. Execute the problem program, EIP is 0x41414141, Softice pops up, search for feature bytes in memory, record
Address, ready for write monitoring points next time.
Use the stack command to see the call stack tracered at this point and get more useful information.
Immediately calculated the program total entry point according to the PE header, set the BPX breakpoint in the program total entry point.
b. Re-execute the problem, Softice pops up due to BPX breakpoints. Depending on the address settings recorded in step a
Monitor point.
g command continues to perform a problem program.
c. Softice popped up due to write monitoring. Search for feature bytes in memory again, and match the stack command.
The covered stack frame and the corresponding buffer start address.
Clear those useless write monitor points to keep BPX breakpoints.
The g command ends this execution.
d. Re-executing the problem, Softice pops up due to BPX breakpoints. According to the address settings recorded in step c
Monitor point.
g command continues to perform a problem program.
e. Softice pops up due to writing to monitor. The code near the EIP is the code we have to find.
This is a step-by-step debugging process. VulneRable_0.c is quite simple, so the approach process is fast. If you touch
There is no source code for reference, it is far away. However, overall abstract ideas
old.
CZY later mentioned that when EIP is equal to 0x41414141, check the ESP-4, ESP-8 positions, he thinks this is
Retaddr, EBP is located. Now discuss this point of view.
The function is __cdecl, __ stdcall, __ fastcall, can not ensure that RET is simple RET, or "RET N" popped up. Before you unclear, you cannot assume that ESP-4 corresponds to Retdr, C
There is this conclusion in style, and the latter two call styles have this conclusion in invisiting. You can only "in the current time when there is no source code"
Top (ESP) at low position search feature bytes, trying to locate the stack frame used by RET instructions. "
By the way, discuss another problem. The program compiled by the VC has BP-BASED FRAME, NON BP-BASED FRAME
The score is that there is an Explicit "Push EBP / MOV EBP, ESP" or Enter instructions at the entrance.
If the two PUSH are "call __seh_prolog" instructions, it belongs to the Non bp-based frame.
According to my reverse experience, the basics of SEH / __TRY blocks in XP SP1 / NTDLL are Non bp-based frame.
Shape, the Stack layout is as follows:
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
Memory velocity direction
[EBP 0x004] Retaddr
[EBP-0x000] _ebp
[EBP-0x004] Trylevel
[EBP-0x008] Scopetable
[EBP-0x00c] Handler
[EBP-0x010] Prev
[EBP-0x014] pexception_pointers / getExceptioninformation ()
[EBP-0X018] HOLD The Final ESP After All The Prologue Code Has Execute
[EBP-0x01c] Ethnical part variable
Memory low site direction
-------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
Hume pointed out that 2000 / NTDLL is a BP-BASED FRAME situation, at which time the top 001 local variables are [EBP-0x004].
The Ida Pro will easily distinguish between these two situations.
The SEH mechanism will be globally expanded after the abnormality. Even if there is no global development, the process reaches a certain
Scopetable [N] .LpfnHandler, there must be a series of stack operations, which will destroy the STACK in the original data.
If you search for the feature bytes in memory after this, you often can't find the desired area (slow spilled)
The flush, covered stack frames). So before I said it needs to be gradually approaching.
But today I discuss this idea when I think about the whole process carefully. Should be such a breakpoint:
: BPX NTDLL! KIUSEREXCEPTIONDISPATCHER DO "DD (* ESP) C L10; DD (* (ESP 4)) 8C L40"
Then search the feature bytes in memory, which seems to be able to keep the stack original, at this time, the most close to ESP
The section may be the area where the area is expected. I have no time to test this now, CZY has time to try
test.
At this time, I remember another problem. By covered _exception_registration structure _EXCEPT_HANDLER
Turn the process, when the process arrives _EXCEPT_HANDLER, there is already some stack operations. Texture attack
This problem is to be realized when template. "Use the SEH mechanism to turn the process steering" The final successful attack template
Compliance with requirements.
Thank you CZY discussion, now understanding this problem deeper.
I used to locate ExceptionAddress at the entrance to KiuseRexceptionDispatcher, and now it is, it should also include searchase in memory at the entrance to KiuseRexceptionDispatcher.
Section.
Czy also mentioned that the general VC written program is called getcommandlinea (), and it is the next breakpoint to it.
Press a few f12 and return to what we are interested in.
