Watch variable write access about bit-slicer

[zorgiepoo]

It triggers when the target executes an instruction that writes to the address you're watching.

Two edge cases I can think of it not working:

1. Since Bit Slicer does this by watching accesses on every thread of the process, new threads may be created later after you begin watching. As a simple workaround, Bit Slicer polls and fetches an updated thread list every short interval, but this may not catch some cases. This could be improved in the future..
2. When the process writes to the address in an indirect way, say through the kernel (e.g., mach_vm_write, memory allocation related functions).

Or there is the case that nothing is writing to it, but that can be somewhat verifiable by adding a variable with its address to a search window.

[zorgiepoo]

Afraid I don't have the game on me.

If you're feeling adventurous and have lldb installed, try adding a watchpoint with it to see if it's an issue with Bit Slicer, by doing something like:

lldb
process attach --pid <pid_number_of_process>
watchpoint set expression -x 1 -- 0x103DF80D8
cont

[zorgiepoo]

There shouldn't be a need to run lldb as root using sudo. Other than that, not sure why attaching fails - odd.. Both lldb and hopper (which just uses lldb or gdb) should be able to attach to an already running process.

The screenshot you are showing in Bit Slicer are not actual instructions, so setting instruction breakpoints via the debugger window there doesn't make sense.

[edit]: I suppose though it's possible there is some detection in the game that can detect LLDB trying to attach, but not Bit Slicer.

[zorgiepoo]

Just for some info, Bit Slicer doesn't actually 'attach' to a process until the it sets its first breakpoint/watchpoint. Debuggers like LLDB and GDB on the other hand use ptrace and are detectable via looking at that flag. Custom wrappers around GL code is pretty common for x-platform games. Glad the application is helping out somewhat =P.

[zorgiepoo]

GDB isn't too supported these days on OS X so that doesn't sound too surprising. Hopper has a button to "Attach to process" but I'm not actually remembering how to get it to work myself right now =. Anyway Hopper just uses LLDB so it's unlikely to help.

Thanks for giving a go at translating the app! I'm actually trying to integrate some Russian translations someone sent me, so this is all the more awesome =). If you've more notes/questions/issues about translating, create a separate issue though. I'll fix that comment with the others languages. Thanks!

[zorgiepoo]

So a friend of mine who had the game was able to indicate why LDLB can't attach to the process, because it makes one or more calls like ptrace(PT_DENY_ATTACH, ...) which will affect LLDB/GBD for attaching.

[zorgiepoo]

You can try having LLDB wait for the process and attach when it launches:

lldb
process attach --name <name_of_game> --waitfor

If this attaches before ptrace is called, this might work. Then you'll have to NOP out calls to ptrace and possibly have it return without error if the game is checking that.

[zorgiepoo]

Did you NOP out ptrace or override it and ret 0 after it attached in lldb and before continuing? Not clear from the output above.

Well it looks like lldb caught the watchpoint so you have some instruction address to look at, at least. Do you think this is a fault in Bit Slicer not catching it, or was it only hit here early on in the process.

[zorgiepoo]

You could also just try using a read & write watchpoint to the address in Bit Slicer (or maybe better yet to a pointer to the address if you can find one), looking around at any area of instructions that might be useful to look at. Either way, good luck.