Jump to content
saiaapiz

View/Change Register on instruction.

Recommended Posts

Screenshot_2019-07-05-01-18-27-161_com.mediocre.pinout.thumb.png.115a138188ccbd6efe3a980cc95dd420.png

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.

Share this post


Link to post
Share on other sites

Can it be made as a constant?

 

Share this post


Link to post
Share on other sites
1 hour ago, saiaapiz said:

imageproxy.php?img=&key=c81244b44a970cc9Screenshot_2019-07-05-01-18-27-161_com.mediocre.pinout.thumb.png.115a138188ccbd6efe3a980cc95dd420.png

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
3 hours ago, Zig said:

Can it be made as a constant?

 

Yep, u can change any value inside register.

Share this post


Link to post
Share on other sites
1 minute ago, saiaapiz said:

Yep, u can change any value inside register.

cool

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by saiaapiz

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)
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:00000014j
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:0000001Cr
ROM:00000024 _stackaddress   DCD 0xBBBBBBBB          ; DATA XREF: ROM:00000004r
ROM:00000028 _spinlockctl    DCD 0                   ; DATA XREF: ROM:isLockedr


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 by saiaapiz

Share this post


Link to post
Share on other sites
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:00000014j
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:0000001Cr
ROM:00000024 _stackaddress   DCD 0xBBBBBBBB          ; DATA XREF: ROM:00000004r
ROM:00000028 _spinlockctl    DCD 0                   ; DATA XREF: ROM:isLockedr

 

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...