PDA

View Full Version : Reverse engineering in WinNT/2000


BlackB
August 7th, 2001, 02:58
Hi all ;-)

Yes I'm still alive. I'm currently working in a bank in Brussels-Belgium to pass my long vacation time (oh yes, being student has a lot of benifits, hehe).
I've got internet access here, so I make it a habit to check the messageboard every morning and afternoon.
I've been out reversing since I started programming Visual C++ 6 mfc, so no time for now. Anyway, I noticed that when working with Win2k there are a lot of disadvantages when cracking such as: no 'bpr' command in softice (can anyone tell me why??), no Frogsice, no /pedump /trace(x) support in icedump, no hmemcpy, and I'm sure that there are lots of other things that I'm not yet aware of. These 'small' things are a major drawback for using an excellent OS as Win2k when reversing....so I thought it would be a good idea to write tools specific for Win2k that would make good solutions for the major drawbacks.
As my programming knowledge concerning reversing matters is about nill, it 's (almost) impossible and too time robbing to make this work. Therefore I'd like to ask if there are people that are willing to work with me. Preferrable people that can code in Visual C++ mfc....NO not pure win32 as this is such a waste of time. It's of course possible to use API's with visual c mfc. The mfc's main framework should save us a lot of time as we don't have to worry a lot about the look of the program (nice visual editor in visual c ). Actually you don't have to worry about anything at all except the program's specific code of course. Just mentioning all this because a lot of reversers don't like visual c mfc, and I really don't see why... :P
So, people interested: let me know. People that can provide me good programming info on reversing tools are also more than welcome!

greets and already thx,

The Blackbird

kill3xx
August 8th, 2001, 17:38
BlackB (08-07-2001 00:58):
disadvantages when cracking such as: no 'bpr' command in softice (can anyone
tell me why??),no Frogsice, no /pedump /trace(x) support in icedump, no
hmemcpy, and I'm sure that there are lots of other things that I'm not yet aware


bpr is implemented hacking ptes P bit and post-chaining the #PF path..
it's a cleaver trick but it's easy to do only when u've to deal with
a relative simple demand paging implementation as in win9x..
when u move on winNT/2k land where the MM is more complex
the implementaion of BPR became more difficult since u've to
deal with IRQL, VADs tree, section&prototypes ptes and so on..
i've done a lot of reversing session on win2k MM and #PF / #GP paths
recently and i can assure u that implemeting things like icedump /protect
(the pax alike part) or BPR isnt a simple task.. (just check MmAccessFault or
MiResolveXXX call tree i u'll see what i mean).. even ntice is using nasty things
like disabling paging via cr0 and other "weird" tricks to left
MM internal out of the door...
/trace or /pedumb are less problematic indeed



[QUOTE]
of. These 'small' things are a major drawback for using an excellent OS as Win2k
when reversing....so I thought it would be a good idea to write tools specific
for Win2k that would make good solutions for the major drawbacks.

some magic words: .. DDK , Viscarola + Nagar + Salomon/Russinovich books,
google/deja .. and a lot of patience with tasty BSODs..
good work/luck



that can code in Visual C++ mfc....NO not pure win32 as this is such a waste of
time. It's of course possible to use API's with visual c mfc. The mfc's main
framework should save us a lot of time as we don't have to worry a lot about the
look of the program (nice visual editor in visual c ). Actually you don't have
to worry about anything at all except the program's specific code of course.

MFC is a waste of time for this kind of prjs - at least for non gui part..
even frameworks like DriverStudio are useless (btw i dont like it).. is better
to spend sometime learning how to code drivers using plain c + DDK


Best regards,

kill3xx

p.s. Elicz and Mamaich are interesting site for ur task