View/Change Register on instruction.

[saiaapiz]

I wish enyby would add this feature into GG, so i can avoid compatibility issue with shellcode.

We can get dynamic pointer by viewing its register, and make cheating more advanced.

[Zig]

Can it be made as a constant?

 

[NoFear]

1 hour ago, saiaapiz said:

I wish enyby would add this feature into GG, so i can avoid compatibility issue with shellcode.

We can get dynamic pointer by viewing its register, and make cheating more advanced.

This using that chainer script?

I haven't tried using it yet. It gives offsets on lib file for modify register?

[Enyby]

2 hours ago, saiaapiz said:

I wish enyby would add this feature into GG, so i can avoid compatibility issue with shellcode.

I do not understand what happens here. Describe in detail.

[saiaapiz]

3 hours ago, Zig said:

Can it be made as a constant?

 

Yep, u can change any value inside register.

[nalcwap]

1 minute ago, saiaapiz said:

Yep, u can change any value inside register.

cool

[NoFear]

@saiaapiz

Is this like debugging? Finding offset in lib to edit? Or not quite? I don't use the script. For I just use gdb to debug and get offsets.

[saiaapiz]

58 minutes ago, NoFear said:

@saiaapiz

Is this like debugging? Finding offset in lib to edit? Or not quite? I don't use the script. For I just use gdb to debug and get offsets.

Yes, it look like when you setting up breakpoint with gdb, where you can view/change register in realtime.
 

3 hours ago, Enyby said:

I do not understand what happens here. Describe in detail.

In short terms, can you add api for PTRACE_SETREGS and PTRACE_GETREGS into GG, So we can view register on any address.

 

4 hours ago, NoFear said:

This using that chainer script?

I haven't tried using it yet. It gives offsets on lib file for modify register?

Nope, Chainer was used to find pointer chain.

Edited July 4, 2019 by saiaapiz

[NoFear]

5 minutes ago, saiaapiz said:

Yes, it look like when you setting up breakpoint with gdb, where you can view/change register in realtime.
 

In short terms, can you add api for PTRACE_SETREGS and PTRACE_GETREGS into GG, So we can view register on any address.

Watch point? (Not break point)

And it does back trace too?

Just find it interesting GG is implementing debugging features when Enyby was/is firmly against it for the last couple years.

[saiaapiz]

9 minutes ago, NoFear said:

Watch point? (Not break point)

And it does back trace too?

Just find it interesting GG is implementing debugging features when Enyby was/is firmly against it for the last couple years.

Not watchpoint support.
Backtrace ? I only can find LR (Address of current function caller.)

I've created shellcode that save R0-R12, LR into stack. Then copy the stack address into my allocated region, so i can read it with script.

ROM:00000000                 STMFD           SP!, {R0-R12,LR}
ROM:00000004                 LDR             R0, =0xBBBBBBBB
ROM:00000008                 STR             SP, [R0]
ROM:0000000C
ROM:0000000C isLocked                                ; CODE XREF: ROM:00000014↓j
ROM:0000000C                 LDR             R0, =0
ROM:00000010                 CMP             R0, #1
ROM:00000014                 BNE             isLocked
ROM:00000018                 LDMFD           SP!, {R0-R12,LR}
ROM:0000001C                 LDR             PC, =0xAAAAAAAA
ROM:0000001C ; ---------------------------------------------------------------------------
ROM:00000020 _returnaddress  DCD 0xAAAAAAAA          ; DATA XREF: ROM:0000001C↑r
ROM:00000024 _stackaddress   DCD 0xBBBBBBBB          ; DATA XREF: ROM:00000004↑r
ROM:00000028 _spinlockctl    DCD 0                   ; DATA XREF: ROM:isLocked↑r

It work like this,
Firstly, i hooked an address that contain interesting info.
Then, i make it jump into this shellcode, After it jump..
Shellcode will save R0-R12, LR into stack. then write the stack address at _stackaddress.
this shellcode will wait for spinlock before continuing execution.

Edited July 4, 2019 by saiaapiz

[NoFear]

3 minutes ago, saiaapiz said:

Not watchpoint support.
Backtrace ? I only can find LR (Address of current function caller.)

I've created shellcode that save R0-R12, LR into stack. Then copy the stack address into my allocated region, so i can read it with script.

ROM:00000000                 STMFD           SP!, {R0-R12,LR}
ROM:00000004                 LDR             R0, =0xBBBBBBBB
ROM:00000008                 STR             SP, [R0]
ROM:0000000C
ROM:0000000C isLocked                                ; CODE XREF: ROM:00000014↓j
ROM:0000000C                 LDR             R0, =0
ROM:00000010                 CMP             R0, #1
ROM:00000014                 BNE             isLocked
ROM:00000018                 LDMFD           SP!, {R0-R12,LR}
ROM:0000001C                 LDR             PC, =0xAAAAAAAA
ROM:0000001C ; ---------------------------------------------------------------------------
ROM:00000020 _returnaddress  DCD 0xAAAAAAAA          ; DATA XREF: ROM:0000001C↑r
ROM:00000024 _stackaddress   DCD 0xBBBBBBBB          ; DATA XREF: ROM:00000004↑r
ROM:00000028 _spinlockctl    DCD 0                   ; DATA XREF: ROM:isLocked↑r

 

Ok. I'll stick with gdb for sure. Thank you.

[Enyby]

35 minutes ago, saiaapiz said:

In short terms, can you add api for PTRACE_SETREGS and PTRACE_GETREGS into GG, So we can view register on any address.

It seems that you do not understand what these functions do. They get or set the processor registers in the current state. They can not work "in some memory address."

[added 4 minutes later]

25 minutes ago, saiaapiz said:

Not watchpoint support.

It is exact how to work soft breakpoint in gdb. Except some detail. Gdb place trap instruction, you place trampoline.

In any case I do not interested write another gdb. Use own scripts like this, or use gdb.

[Enyby]

To use these features, you need to be constantly connected to the process. then there cause a stop in the right place. Through a software or hardware breakpoint. And then watch the registers. There is another option with step by step run.
This is how gdb works.
GG does not constantly trace the process. GG connected, searched and disconnected. And that's all.

Therefore, it cannot be a breakpoint debugger.
And you can now write trampolines, through scripts, as you described it.

And when gg ptrace process it is stop on random location so get registers is usually useless.

If you try throw trap without ptrace process - it will be killed by system in most cases.

If GG try ptrace all time process game can easly detect it. Also it is slow down game and have some other side effects.

Also GG memory editor, not debugger. It is connect to random thread of execution. You trap can never be catched if you place it in wrong place. For example you trace thread1, but trap happens in thread2.

You need handle all threads or procces died with uncatched trap. Handle all threads it is not easy. And so on.

It is only few exists problem. Use gdb, where such problems already solved.

[nalcwap]

3 minutes ago, Enyby said:

To use these features, you need to be constantly connected to the process. then there cause a stop in the right place. Through a software or hardware breakpoint. And then watch the registers. There is another option with step by step run.
This is how gdb works.
GG does not constantly trace the process. GG connected, searched and disconnected. And that's all.

Therefore, it cannot be a breakpoint debugger.
And you can now write trampolines, through scripts, as you described it.

And when gg ptrace process it is stop on random location so get registers is usually useless.

If you try throw trap without ptrace process - it will be killed by system in most cases.

If GG try ptrace all time process game can easly detect it. Also it is slow down game and have some other side effects.

Also GG memory editor, not debugger. It is connect to random thread of execution. You trap can never be catched if you place it in wrong place. For example you trace thread1, but trap happens in thread2.

You need handle all threads or procces died with uncatched trap. Handle all threads it is not easy. And so on.

It is only few exists problem. Use gdb, where such problems already solved.

but why the gg not find the regions if attached to the process, is make other process or what?when when no regions

[Enyby]

GG memory map can not open. There is no right or something. And to guess what memory is allocated from 4 GB possible is a little real. And if the system is 64 bit, there will be some more possible memory there.