Need someone to check this for technical errors & give feedback

[radnomguywfq3]

I'm writing a article about reverse engineering, your feedback would be greatly appreciated. I've just spent a couple hours on it now so it's nowhere near done.

I got really bored of writing about calling conventions so that part is bare of examples. If anyone wants to expand on it, I'd appreciate it.

Anyway, here's the link:
https://*****************/viewer?a=v&p...thkey=CJuW5ekH

* Edit *
Just added a section on SEH and VEH exception handlers; they're fairly brief but are good for a review or reference.

[open|Fire]

nice doc +rep

[why06]

Omg. It looks epic! Plz give me some time to read it. I have to bed now so I can go to work in the morning, but I will definitely be back to comment tomorrow, so don't go anywhere!

[radnomguywfq3]

xd kk; There's still a lot of work to be done on it. It's probably not the easiest thing to read because I got a little lazy in regards to writing it.

You guys can contribute sections if you'd like.

[Melodia]

Have some bus Time later, Will read it and give you feedback :3.

[radnomguywfq3]

Thanks,
I'm going to do a chapter of applied reversing on like Quake or ET; my PC isn't exactly 'high-end' with it's shot onboard graphics mdoule

If you want to suggest any sections, feel free to.

[Hell_Demon]

'As a reverse engineer or hacker you likely won’t be dealing with them too much unless you have to start working with anti-debug stuff'

I use them quite often when exception hooking, for example purposely setting pointers to null in places where the game doesn't check them and they could give me an advantage(render loops etc).
setting pages to not executable and stepping through them(on modern hardware there is barely a performance hit when stepping through them)

[freedompeace]

Awesomez, I'll have a read this weekend =D

Looking forward to this great article!

[radnomguywfq3]

'As a reverse engineer or hacker you likely won’t be dealing with them too much unless you have to start working with anti-debug stuff'

I use them quite often when exception hooking, for example purposely setting pointers to null in places where the game doesn't check them and they could give me an advantage(render loops etc).
setting pages to not executable and stepping through them(on modern hardware there is barely a performance hit when stepping through them)

Alright, I'll look into it. What do you mean by setting pointers to null to catch an exception? Like, to detour the rendering of a specific objects? I would think that be an odd method of doing so but it's interesting and I'll definitely think about changing it. That line was more related to reverse engineering the target opposed to attacking it.

It sounds as though you have a couple interesting ideas when it comes to hacking methods; if you want to write about some of them I'll add them to the section when I start writing it. I'd really appreciate it. (By hacking methods I mean like - installing a HWBP & VEH to detour, buffer overflows, or like what you just explained.)

Thanks for your feed back.

[Hell_Demon]

Modern Warfare 2(1.0.182 executable used for AlterIW):

004D7EC0     68 588A6E00         PUSH iw4mp.006E8A58                        ; ASCII "Shows debug info for glass"
004D7EC5     6A 01               PUSH 1
004D7EC7     6A 00               PUSH 0
004D7EC9     68 DC1B7000         PUSH iw4mp.00701BDC                        ; ASCII "glass_debug"
004D7ECE     A3 B47D7401         MOV DWORD PTR DS:[1747DB4],EAX 
004D7ED3     E8 B818FAFF         CALL iw4mp.00479790
004D7ED8     83C4 28             ADD ESP,28
004D7EDB     A3 087E7401         MOV DWORD PTR DS:[1747E08],EAX ; The address for glass_debug

so 0x1747E08 is the address for the glass_debug cvar.
Find references gives 1 more result besides the one above:

004815A6     8B0D 087E7401       MOV ECX,DWORD PTR DS:[1747E08]
004815AC     83C4 04             ADD ESP,4
004815AF     8079 10 00          CMP BYTE PTR DS:[ECX+10],0
004815B3     74 05               JE SHORT iw4mp.004815BA

Which is part of the rendering code.

Now we can set up an exception handler, set 0x1747E08 to point to NULL and we have ourselves an exception in the rendering loop =)

For extra fun you could even restore ECX to what it was supposed to be and have the game execute like normally =)

[radnomguywfq3]

Modern Warfare 2(1.0.182 executable used for AlterIW):

004D7EC0     68 588A6E00         PUSH iw4mp.006E8A58                        ; ASCII "Shows debug info for glass"
004D7EC5     6A 01               PUSH 1
004D7EC7     6A 00               PUSH 0
004D7EC9     68 DC1B7000         PUSH iw4mp.00701BDC                        ; ASCII "glass_debug"
004D7ECE     A3 B47D7401         MOV DWORD PTR DS:[1747DB4],EAX 
004D7ED3     E8 B818FAFF         CALL iw4mp.00479790
004D7ED8     83C4 28             ADD ESP,28
004D7EDB     A3 087E7401         MOV DWORD PTR DS:[1747E08],EAX ; The address for glass_debug

so 0x1747E08 is the address for the glass_debug cvar.
Find references gives 1 more result besides the one above:

004815A6     8B0D 087E7401       MOV ECX,DWORD PTR DS:[1747E08]
004815AC     83C4 04             ADD ESP,4
004815AF     8079 10 00          CMP BYTE PTR DS:[ECX+10],0
004815B3     74 05               JE SHORT iw4mp.004815BA

Which is part of the rendering code.

Now we can set up an exception handler, set 0x1747E08 to point to NULL and we have ourselves an exception in the rendering loop =)

For extra fun you could even restore ECX to what it was supposed to be and have the game execute like normally =)

oic what u did thur. Hmmz, interesting idea. I presume then that the handler would unset the zero flag to skip the jump? I never thought of causing exceptions for the purpose of hijacking control of a thread but its a good idea. Why can't you just detour the routine at 0x00479790? It seems that it could be the constructor of the cvar objec\struct(I didn't see enough of the snippet to determine.)

btw: Changed the wording:
"As a reverse engineer studying a target, you likely won’t be dealing with them too much unless you have to start working with anti-debug stuff but because they are an incredibly powerful tool for attacking your target if used appropriately, we will go over them. "

Also added a section on the stack frame which should've been after the calling conventions.

[Melodia]

Modern Warfare 2(1.0.182 executable used for AlterIW):

004D7EC0     68 588A6E00         PUSH iw4mp.006E8A58                        ; ASCII "Shows debug info for glass"
004D7EC5     6A 01               PUSH 1
004D7EC7     6A 00               PUSH 0
004D7EC9     68 DC1B7000         PUSH iw4mp.00701BDC                        ; ASCII "glass_debug"
004D7ECE     A3 B47D7401         MOV DWORD PTR DS:[1747DB4],EAX 
004D7ED3     E8 B818FAFF         CALL iw4mp.00479790
004D7ED8     83C4 28             ADD ESP,28
004D7EDB     A3 087E7401         MOV DWORD PTR DS:[1747E08],EAX ; The address for glass_debug

so 0x1747E08 is the address for the glass_debug cvar.
Find references gives 1 more result besides the one above:

004815A6     8B0D 087E7401       MOV ECX,DWORD PTR DS:[1747E08]
004815AC     83C4 04             ADD ESP,4
004815AF     8079 10 00          CMP BYTE PTR DS:[ECX+10],0
004815B3     74 05               JE SHORT iw4mp.004815BA

Which is part of the rendering code.

Now we can set up an exception handler, set 0x1747E08 to point to NULL and we have ourselves an exception in the rendering loop =)

For extra fun you could even restore ECX to what it was supposed to be and have the game execute like normally =)

Did this with dDI and my hook was nevar detected :3.
Would still verify a few things before giving it a shot with VAC3 Though ( If it's implemented in MW2 Nao, Didn't looked at MW2 Forever D: )

Anyways, Cute from you to contribute ;D.

[why06]

A RUNNING LOG of MY THOUGHTS AS READING THE ARTICLE:

Pictures I nice, I like to see pics, straight text can get boring, unless its well written.

Let see what else, at one part where your talking about LoadLibrary, you assume the reader knows something every other sentence. That's okay if your talking to us, but a nub doesn't know anything, and will be confused.

The pistol clip analogy, might be one of the worst analogies ever, but actually made sense, and even ended up grabbing my attention which makes it a great analogy.

Explaining the stack frame, again you assumed the reader knew about Virtual Memory, and that the ESP pointed to a memory location, and that increasing the stack meant decreasing the esp (you said this, and gave a picture, but people get tripped up on this a lot.) Perhaps a step by step picture would be better, because you push DWORD 1,2,3 in execution order, then you have them listed on the stack in the reverse order, then the ESP is points to the last item which is on the top of the picture, but at the same time your telling the reader this is the bottom, and is decreasing, and last but not least, adding 0x4 and 0x8, makes much sense mathematically, and is most likely the way someone might see it in a disassembly, but it may not make sense to the reader in their confused state. Everything is correct, and I could just be overreacting, but IMO, its best to explain more then less.

Mention the EIP in one part, and changing it to the RVA, without explaining either term. Also mention an IIRC, which I don't know what that is, but I'm a bit of a nub myself!
However also assume in this this same segment that the reader has any clue how you know constant from the data segment are being reference in the decryption function. One of the biggest things I dislike in every tutorial, is how often it is assumed, not just that you understand a concept, but understand a thought process, or line of reasoning. Reasoning is usually pretty simple to explain in a few steps, and can help the reader develop that same reasoning, because its not just learning the concepts, but learning to think like a reverse engineer that's important too.

The part about inline calls was nice, I haven't ever seen that explained in disassembly.

The information is good and that's what's important, the good thing is I only have complaints about there not being enough information, but that's understandable, your not writing a freaking book.

Okay, now I've read farther, and you start explaining the stack frame, and calling conventions. I don't know if its a bad thing to explain after the fact, if you give the reader enough information to hold on for a little bit, before you come back to a concept.

One more gripe is that when explaining the important concepts, it seems to get a bit dry, maybe this is because there's not an example we're working with at the moment, like when we were figuring out the function. My eyes tended to glaze over it and I had to reread it several times.

When you started getting into the weapon a sword classes, it felt much more conversational and was easier to read. I'm not saying you should try to be all conversational, but a good mix can liven up the drive spot, and real examples keep me focused like trying to figure out a puzzle.

top of Page 10 "were" should be "where"

sigh... Windows API, should have used classes. Like the digression about mutexes.

One of the most confusing explanations of vtable I ever read, I suppose you were trying to show what the vtable's of each classes, shown in the code earlier, actually looked like, but the was little explanation, and sparse commenting in the code. And I'm just not used to that style of naming conventions, with the underscores and letters in the front and back like you can't make up your mine. I'm better with some Hungarian, but only with better variable names if you going to have that little notation. That's just my opinion, know I'm gonna get flamed for it.

That being said the color coded, image was much better. Something like that with labeling for certain pointers would be ideal. And lol who need obfuscation when you can just turn optimization off and the compiler will do it for you!

Exception, glazin' again, that example wasn't lively at all. The end of the paragraph finally sorta started to get my attention. Yeh start it with why I need to know this, what it can do, and that focuses me in, ofcourse this is all subjective, I could have ADHD or something.

The part on the FS register and TIB, is really interesting and important to me, I would like to read a indepth article on the FS register and how its relates to VEH, SEH, and TIB, but at the same time I'm really starting to glaze over at this point, I glance the one structure over 5-6 times, before I realized it was a just a linked list struct. I get what ur saying just really boring to read.

Wth if handler is a callback function why is it declared like this?

PEXCEPTION_DISPOSITION Handler;

Well I have been reading this for a little over an hour. Yes I am a notoriously slow reader, which is strange since I like reading, and do it often. story books I can read quickly, but technical books, idk... its weird, maybe its because there is so much to understand. Point is is I'm done. Its halftime, will come back and read the last 5 pages later.

[radnomguywfq3]

A RUNNING LOG of MY THOUGHTS AS READING THE ARTICLE:

Pictures I nice, I like to see pics, straight text can get boring, unless its well written.

Let see what else, at one part where your talking about LoadLibrary, you assume the reader knows something every other sentence. That's okay if your talking to us, but a nub doesn't know anything, and will be confused.

The pistol clip analogy, might be one of the worst analogies ever, but actually made sense, and even ended up grabbing my attention which makes it a great analogy.

Explaining the stack frame, again you assumed the reader knew about Virtual Memory, and that the ESP pointed to a memory location, and that increasing the stack meant decreasing the esp (you said this, and gave a picture, but people get tripped up on this a lot.) Perhaps a step by step picture would be better, because you push DWORD 1,2,3 in execution order, then you have them listed on the stack in the reverse order, then the ESP is points to the last item which is on the top of the picture, but at the same time your telling the reader this is the bottom, and is decreasing, and last but not least, adding 0x4 and 0x8, makes much sense mathematically, and is most likely the way someone might see it in a disassembly, but it may not make sense to the reader in their confused state. Everything is correct, and I could just be overreacting, but IMO, its best to explain more then less.

Mention the EIP in one part, and changing it to the RVA, without explaining either term. Also mention an IIRC, which I don't know what that is, but I'm a bit of a nub myself!
However also assume in this this same segment that the reader has any clue how you know constant from the data segment are being reference in the decryption function. One of the biggest things I dislike in every tutorial, is how often it is assumed, not just that you understand a concept, but understand a thought process, or line of reasoning. Reasoning is usually pretty simple to explain in a few steps, and can help the reader develop that same reasoning, because its not just learning the concepts, but learning to think like a reverse engineer that's important too.

The part about inline calls was nice, I haven't ever seen that explained in disassembly.

The information is good and that's what's important, the good thing is I only have complaints about there not being enough information, but that's understandable, your not writing a freaking book.

Okay, now I've read farther, and you start explaining the stack frame, and calling conventions. I don't know if its a bad thing to explain after the fact, if you give the reader enough information to hold on for a little bit, before you come back to a concept.

One more gripe is that when explaining the important concepts, it seems to get a bit dry, maybe this is because there's not an example we're working with at the moment, like when we were figuring out the function. My eyes tended to glaze over it and I had to reread it several times.

When you started getting into the weapon a sword classes, it felt much more conversational and was easier to read. I'm not saying you should try to be all conversational, but a good mix can liven up the drive spot, and real examples keep me focused like trying to figure out a puzzle.

top of Page 10 "were" should be "where"

sigh... Windows API, should have used classes. Like the digression about mutexes.

One of the most confusing explanations of vtable I ever read, I suppose you were trying to show what the vtable's of each classes, shown in the code earlier, actually looked like, but the was little explanation, and sparse commenting in the code. And I'm just not used to that style of naming conventions, with the underscores and letters in the front and back like you can't make up your mine. I'm better with some Hungarian, but only with better variable names if you going to have that little notation. That's just my opinion, know I'm gonna get flamed for it.

That being said the color coded, image was much better. Something like that with labeling for certain pointers would be ideal. And lol who need obfuscation when you can just turn optimization off and the compiler will do it for you!

Exception, glazin' again, that example wasn't lively at all. The end of the paragraph finally sorta started to get my attention. Yeh start it with why I need to know this, what it can do, and that focuses me in, ofcourse this is all subjective, I could have ADHD or something.

The part on the FS register and TIB, is really interesting and important to me, I would like to read a indepth article on the FS register and how its relates to VEH, SEH, and TIB, but at the same time I'm really starting to glaze over at this point, I glance the one structure over 5-6 times, before I realized it was a just a linked list struct. I get what ur saying just really boring to read.

Wth if handler is a callback function why is it declared like this?

PEXCEPTION_DISPOSITION Handler;

Well I have been reading this for a little over an hour. Yes I am a notoriously slow reader, which is strange since I like reading, and do it often. story books I can read quickly, but technical books, idk... its weird, maybe its because there is so much to understand. Point is is I'm done. Its halftime, will come back and read the last 5 pages later.

I couldn't agree with you more.
Regarding your last point about the handler: I thought the same thing, lol. It was what a pulled from serveral undocumented NT internals websites(windows doesn't have an official documentation.) I really should change it to void* or something I just wanted to remain consistant with the other documentations.

It is a very dry read, agreed. I think I'm going to go over it and try to make it more interesting. Once I get to the section where we actually go through the process of reversing a target it will be a hella more fun.

Naming conventions are always dependant on what the developer's taste is; so I understand your prespective on that.

I will also try to jam more background information to avoid confusing the reader. It's just there's a lot which would need to be discussed.

I guess when you write a piece of code you always look at it as if it were self-explanatory but you make a good point and the vtable should be explained more.

[why06]

Well its obviously nothing bad, much better then I could hope to even have the attention span to do. Your just one person it would be impossible to cover everything, but even pointing out hints on what the reader is expected to know will help too, such what you did with the OOP section.