Fellow RCEs:

I'm trying to figure out this program. This is a "crippled" demo and I'm trying to fix the "bugs" . Anyways, I've succeeded in enabling everything except that for the "Print" and "Save"( this can't be done 'coz I think the code itself is missing) and the 250 packet limit.

This 250 packet limit is interesting. I've bypassed the place where the check is made but still the application stops displaying packets when more than 250. Any tips / ideas on how to go about this?

Signed,
-- FoxThree

Hi there,

I guess you found this snippet:

016F:0040A008 8B8634A90000 MOV EAX,[ESI+0000A934]
016F:0040A00E 817820FA000000 CMP DWORD PTR [EAX+20],000000FA
016F:0040A015 730E JAE 0040A025
016F:0040A017 FF1564925300 CALL [KERNEL32!GetTickCount]
016F:0040A01D 3B8688A90000 CMP EAX,[ESI+0000A988]
016F:0040A023 7215 JB 0040A03A
016F:0040A025 8BCE MOV ECX,ESI
016F:0040A027 E8D4040000 CALL 0040A500
016F:0040A02C 6A00 PUSH 00
016F:0040A02E 6A40 PUSH 40
016F:0040A030 6868085800 PUSH 00580868
016F:0040A035 E85A2D0E00 CALL 004ECD94
016F:0040A03A 8A442417 MOV AL,[ESP+17]

The call made from 40A035 leads to the 250 and 30 seconds messagebox. I also assume you
found out that changing the two jmps at 40A015 and at 40A023 took care of the 250 limitation and teh 30-seconds limitation. But I also found out that the program stops writing out (display) information even though it seems to continue capturing packets.
I dumped the memory of [eax+20] at 0040A00E, only to find out that the displayed memory
address changed every time I ran the program. So I put a read/write bpm on the address displayed, and found out that the proram only once writes some information to this address, but it reads out some information at least seven times.I did this to found out what the program did to write/store hwo many packets that had been read and displayed. I just checked the code everytime Sice broke, and quickly found this code:

016F:00491220 53 PUSH EBX
016F:00491221 8BD9 MOV EBX,ECX
016F:00491223 55 PUSH EBP
016F:00491224 56 PUSH ESI
016F:00491225 8B4320 MOV EAX,[EBX+20]
016F:00491228 57 PUSH EDI
016F:00491229 3DFA000000 CMP EAX,000000FA
016F:0049122E 7209 JB 00491239
016F:00491230 5F POP EDI
016F:00491231 5E POP ESI
016F:00491232 5D POP EBP
016F:00491233 32C0 XOR AL,AL
016F:00491235 5B POP EBX
016F:00491236 C21000 RET 0010

The code at 00491229 looked familiar, and when I changed the jump instruction to always jump, the program continued to write down (display) information beyond the 250 limit.

hobgoblin

Hobgoblin:

Nice work . Yes, exactly. However, I'm not getting the same results as yours.

This is what I did:

016F:0040A015 730E JAE 0040A025
016F:0040A023 90 NOP
016F:0040A023 90 NOP (Noped out the JAE call)

016F:0040A023 7215 JB 0040A03A
016F:0040A023 EB15 JMP 0040A03A (JMP Always)

After this patch, yep, timer is working fine, but after the 250 packet limit neither is the counter incremented in the bottom status bar and neither the Packt Recvd/Packt Filtered is increasing and neither is the Pckt Buffer (If the packet is captured but not displayed the buffer usage should atleast increase, right?)

Infact the address pointed out by you (0049122E) is not getting called at all!!! Strange !

I patched the code as told by you at

016F:0049122E 7209 JB 00491239 to
016F:0040122E EB09 JMP 00491239

Still doesn't break? Any clues.

Anyhow, I'll look into the BPR technique outlined by you to figure out what went wrong. Thanks a lot

Signed,
-- FoxThree

Hi foxthree.
That is strange. I double-checked on my computer, and it works for me.
One thing I noticed while I was looking at this program is that the changes I made in the program during runtime (while I was using Sice) stayed resident in memory until I changed it back or rebootet. I got a couple of surprises there.:-)
Maybe this happened to you too....

hobgoblin

He he hobgoblin:

"Patch and Play" as the +SplAj guru says . Just as I suspected... I'm patching the app under Win2K and the address I found that needs to be patched is @ 4918A5. I think the EtherPeek guys have written some platform specific code where in it calls your address if Win9X and mine if Win2K. BTW, you did the patch on Win9x right?

Also interestingly the behavior you've outlined is a day-to-day-fact under Win2K. Some knowledgable persons tell me that it is because of NTICE which patches CR0.WS and in effect disables Copy-on-Write for good. Clearing the swap file might help (if on Win2K). Else check out this small app I've written to fix this problem.

This app allocates around 60% of your Physical Memory size and then accesses each 4K page in that block. There by forcing Windows to reload its memory cache. This works like a charm on Win2K but haven't really tested it in Win9x.

After modifying the code and getting out of SoftICE, just run this app and then reload the app in SoftICE. Everything should be okay.

BTW, the above operation takes around ~13 secs. on a 551MHz Pentium III m/c. It sure beats a reboot... isn't it

Signed,
-- FoxThree

Hi foxthree,
Seems to be a nice tools.:-)
I'll try it out. Nice to see that you found out what was wrong.

Hobgoblin

Have you taken a look at Etherpeek NX 1.0? Does it use the same methods discussed here?

FoxThree:

this cache memory problem was discussed by the Owl on the Reverce Engineering Forum a couple of days ago. His comments are at:

hxxp://disc.server.com/discussion.cgi?id=37&article=3792

He also suggested a google search of 'unified page and buffer cache' which has some interesting articles.

Looks like you have written a useful program for solving the problem. Did you use GlobalMemoryStatus API (haven't taken your utility apart yet) similar to what DebugLord mentions there?

Keep the good work and the good discussions coming.

Regards.

Or are you just using DebugLord 's machine???

Occasionally, yes! I do

Funny, JMI...

XeNoSiS: No I haven't seen EtherPeek NX ... but the product description looks interesting may be I'll take a look....

Signed,
-- FoxThree

I did check out the NX version of Etherpeek. The protection is identical.

hobgoblin