[TEC] *.exe Reverse-Engineering

[gap]

Originally Posted by Targor Avelany

... I would suggest you helping reaper to fix it, instead of complaining that he has no idea wtf he is doing... Especially after he admitted that he was wrong in his judgement.

dixi

I think Pintea was complaining about someone else's statements. Please, read carefully the whole discussion

[stoianm]

Originally Posted by Targor Avelany

Stop side-tracking the topic.

butthurt about someone making claims on bad programming for the game? Well, considering that the stadimeter bug does exist and not just "insufficient information/knowledge"... I would suggest you helping reaper to fix it, instead of complaining that he has no idea wtf he is doing... Especially after he admitted that he was wrong in his judgement.

dixi

hey mate... like tdw said the problem was fixed... read careful... Pintea not liked the fact that urfisch said that the romanian programers are bad... very strange if i am thinking at his contact bos from ubi Romania(or maybe that was just a dream)... in my experience i know that are bad and good people all over the world... not depend by nationality... and like sober said read careful... Pintea helped a lot on this forum

dixi and respect

[Shiplord]

Originally Posted by urfisch

...blame the ones who caused this...
dude.

lol, he is one of those responsible who caused this

[TheDarkWraith]

Originally Posted by reaper7

I've done some digging and noticed that the Memory address that I was using for the fix is also being used by not only Range - But AOB, Target Speed and Bearing.

So that explains the Reset to Zero Bug - All these dials are sharing the same Address's to store the value before updating the final value for the relevant dial.

What this sounds like is the programmer assigned each 'variable' to a temp variable so as to preserve the original variable. When the C++ code was compiled (and compiler optimized it) the compiler usually places temp variables on the stack (instead of the heap). Being that it was optimized the compiler probably decided to use the same address (stack address) for each temp variable (to save memory). This is why you are 'seeing' each variable using the same address. This is very common to see and is one reason why RE is very complicated to 'follow and decipher'. If you want to validate my theory then you'll probably notice that the address used for each 'variable' uses offset addressing to 'find' it's contents (ESI+x where x is the offset amount - and ESI could be any of the general CPU registers [EBX,ECX,ESI,EDI,etc.]). In this example ESI would be an address located on the stack (you can find where the stack is located via Olly Debug - EVERY application has at least one stack but usually they have more than this)

[reaper7]

Originally Posted by TheDarkWraith

What this sounds like is the programmer assigned each 'variable' to a temp variable so as to preserve the original variable. When the C++ code was compiled (and compiler optimized it) the compiler usually places temp variables on the stack (instead of the heap). Being that it was optimized the compiler probably decided to use the same address (stack address) for each temp variable (to save memory). This is why you are 'seeing' each variable using the same address. This is very common to see and is one reason why RE is very complicated to 'follow and decipher'. If you want to validate my theory then you'll probably notice that the address used for each 'variable' uses offset addressing to 'find' it's contents (ESI+x where x is the offset amount - and ESI could be any of the general CPU registers [EBX,ECX,ESI,EDI,etc.]). In this example ESI would be an address located on the stack (you can find where the stack is located via Olly Debug - EVERY application has at least one stack but usually they have more than this)

LOL, thats exactly whats happening - I had come to the same conclusion.
I went back to Cheat engine this morning and fired up SH3 (As its quicker to load and easier to trace - but basically the same).

I was able to trace the pointer's all back to the same Base Address - and each of the dials is then written to by means of an offset.

Thanks TDW for confirming this It makes much more sense to me now - and not an issue of bad programming as I first thought. Sorry Devs .
Just a Noob jumping to the wrong conclussions .

[Tomi_099]

Originally Posted by TheDarkWraith
What this sounds like is the programmer assigned each 'variable' to a temp variable so as to preserve the original variable. When the C++ code was compiled (and compiler optimized it) the compiler usually places temp variables on the stack (instead of the heap). Being that it was optimized the compiler probably decided to use the same address (stack address) for each temp variable (to save memory). This is why you are 'seeing' each variable using the same address. This is very common to see and is one reason why RE is very complicated to 'follow and decipher'. If you want to validate my theory then you'll probably notice that the address used for each 'variable' uses offset addressing to 'find' it's contents (ESI+x where x is the offset amount - and ESI could be any of the general CPU registers [EBX,ECX,ESI,EDI,etc.]). In this example ESI would be an address located on the stack (you can find where the stack is located via Olly Debug - EVERY application has at least one stack but usually they have more than this)



---------------

Originally Posted by reaper7

LOL, thats exactly whats happening - I had come to the same conclusion.
I went back to Cheat engine this morning and fired up SH3 (As its quicker to load and easier to trace - but basically the same).

I was able to trace the pointer's all back to the same Base Address - and each of the dials is then written to by means of an offset.

Thanks TDW for confirming this It makes much more sense to me now - and not an issue of bad programming as I first thought. Sorry Devs .
Just a Noob jumping to the wrong conclussions .

-------------------------------------------------------

Assembly for NEWBIS ...and more....---Google / Vivek Ramachandran ----


For Start !!
http://www.securitytube.net/video/208





This video is part of the following groups:







1. Assembly Language Megaprimer for Linux ( 11 videos)

• Assembly Primer for Hackers (Part 1) System Organization
• Assembly Primer for Hackers (Part 2) Virtual Memory Organization
• Assembly Primer for Hackers (Part 3) GDB Usage Primer
• Assembly Primer for Hackers (Part 4) Hello World
• Assembly Primer for Hackers (Part 5) Data Types
• Assembly Primer for Hackers (Part 6) Moving Data
• Assembly Primer for Hackers (Part 7) Working with Strings
• Assembly Primer for Hackers (Part 8) Unconditional Branching
• Assembly Primer for Hackers (Part 9) Conditional Branching
• Assembly Primer for Hackers (Part 10) Functions
• Assembly Primer for Hackers (Part 11) Functions Stack

. after then cams ..this !!!

http://raykoid666.wordpress.com/2009...primer-review/


The links to the different parts:
Part 1 (Smashing the stack)
Part 2 (Writing exit shellcode)
Part 3 (Executing shellcode)
Part 4 (Disassembling execve)
Part 5 (shellcode for execve)
Part 6 (exploiting a program)
Part 7 (exploiting a program: demonstration)
Part 8 (return to libc theory)
Part 9 (return to libc theory: demonstration)


Videos 1-4 have to do with basic system calls, mov commands,
you make a hello world program and then video 3 is all about using gdb

(Viveks tutorial is the best i***8217;ve seen)

Videos 5-11 are all about more indepth mov commans, creating variables and examining memory layout and values with gdb.
This is all very useful but just watching the videos is not enough!
You need to go through and do it along with him,
you have to write the programs(even though he says you can download them) and you need to get assembly in your fingers.

Think of great athletes, they didn***8217;t get great by watching sports on TV ***8211;
they went out and did the real thing ***8211;

Exact same concept with computers ***8211;

Practice practice practice.
.

[urfisch]

hey tomi...nice to see you round here!

[kapitan_zur_see]

I've had a look at those vids and indeed, they seems very good. It's especially intersting since i'm absolute beginner to that. However, it seems to me that having a good to strong knowledge of programming in C is a pre-requisite.

Still having an in-depth look though, as this so-called "modding friendly SH5 -oups, I forgot about this GR2 über restrictive sh*t-" is not going to see lots of breakthrough rapidly if we are to rely now entirely on a very very few bunch of coding experts like TDW or Reaper7 who are pretty much alone doing all the new stuffs on the modding scene (apart from few eye-candies here and there and campaign related stuffs).

They have a life of their owns and can't work 24h/7...
Hope I'll be able to help somehow soon. It's been quite some time since I've modded anything since everyone here pretty much covered what can be achieved so far in their own area of expertise with current tools and restrictions. I do for sure miss a S3D for SH5 like that thing allowed you to do for SH4! Wish the devs never relied on that granny GR2 thingy! Such a plague, such a step backward for all the modders community... Talk about reinventing the wheel on and on! And that goblin editor is nothing much of a viewer, really...

Heh I'm a very competent computer scientist and and well versed in MIPS assembly and RE still evades me. It's very tough. Although I absolutely could RE MIPs.

If this was anything but a graphical program I would love to help. But I can barely write a 3d renderer let alone RE one.

I think you would be better off (and save more time) RE all the files and writing your own exe from scratch. You could control more that way. But you have to imagine a huge team of developers worked on this, so only one or a handful at best working on it will take FOREVER.