I saw it in the documentation but I didn't actually try it because I didn't actually need it.)Ĭrap. These aren't C strings - they're CF strings, which means po works on them just fine, I just didn't recognize the output for what it was.Īlthough to answer my second question, the answer is "memory read" (I think. How can I print out the value at an arbitrary address in memory?Īctually, I was mistaken. How can I print out the C string at an address given in a register? I can use "po " on any register that contains an Obj-C object and get its description. I can get the unsigned long value out of any register by using "print " I can still print out a list of all of the registers and their current hexadecimal values by using "register read"
#Http sniffer ios code
"frame variables" doesn't work because things like variable names and types weren't included when the code was compiled. You'd have to look into the details: man dtrace, Apple's Instruments app, and probably a bunch of tutorials on the web. So maybe there's a way to have dtrace tell you every time AMDeviceCopyValue() is called, and what the args are. It also occurs to me that getting a trace of function calls and parameters is exactly the kind of thing dtrace was designed for. I'd try it on my own test-case target function first, to make sure it worked as expected. I did a quick check of the lldb docs, and they do support breakpoint conditions and commands, so it's worth a try. I haven't tried setting up anything like this in ages, so it may not be possible under lldb. You might also be able to add conditions to the breakpoint. Then add commands to be executed when the breakpoint hits, and have those commands log the function's parameters. Next, maybe you could run the debugger on the iCopyBot executable, and set a breakpoint on AMDeviceCopyValue(). The first thing I'd try is contacting the developer and asking. And since we're talking iPhone here, I really wouldn't be surprised if there were encryption, even if it's just some obfuscation.Ī hardware or hardware/software USB sniffer isn't cheap: ~$400 and up. Not saying they are, just that they could be.
The USB packets could be encrypted, so I wouldn't necessarily think a bus sniffer would show anything useful. I already have run the terminal command strings on both the binary of MobileDevice and iCopyBot, and while it did include some domains and keys that I knew of already (and some I didn't already know of) - none of them were helpful in extracting this data. I was thinking that if I had a USB Sniffer program of some sort, I could see all the values that the program sends over USB to the connected iOS device, and from that, see what domain/key pairs they use to get how many charge cycles are on the iOS device's battery.ĭoes anyone know of such a USB sniffer program that I could use? Or maybe you have another suggestion for how I might get these strings. I've already downloaded and ran the program, and have seen that it works. There's another program, iCopyBot, which can do this ( ). I've been able to find some domains and keys that work online, but I can't find the pair that will tell you how many charge cycles are on the iOS device's battery. It takes two strings as arguments: domain and key.
#Http sniffer ios mac
There's a method in amework (the private framework used to communicate with iOS devices from your Mac over USB) called AMDeviceCopyValue().
0 kommentar(er)
