Hello, I''m new to dtrace, hoping someone can help me. I''m trying to obtain an AT command that is written to a serial device (cellular modem) by an application. Could dtrace enable me to sniff this serial traffic to this device? and could anyone point me towards a resource to help me? Maybe there is a better way to sniff this, but I can''t think of it. thanks in advance. -- This message posted from opensolaris.org
pgjw pgjw wrote:> Hello, I''m new to dtrace, hoping someone can help me. > I''m trying to obtain an AT command that is written to a serial device (cellular modem) by an application. > Could dtrace enable me to sniff this serial traffic to this device?It should be able to; you should be able to interpose on the appropriate ''write'' entry point to the driver and see the data being passed in.> and could anyone point me towards a resource to help me? > Maybe there is a better way to sniff this, but I can''t think of it.dtrace is probably pretty good for this, but you do need to know or infer something about the driver. if you have source, look there first. if not, try "dtrace -l -m <drivername>" to see all the entry points; the right one will probably hop out at you. Then you''ll have to figure out what the arguments are, which could take some experimentation; a kernel debugger can be good for that. For Solaris, for instance, the asy driver is a STREAMS driver, and has an asywput() entry point whose second arg is an mblk_t.> > thanks in advance. > > > -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
At 19:43 -0800 5/11/07, Dan Mick wrote:>dtrace is probably pretty good for this, but you do need to know or infer >something about the driver.Why wouldn''t you just do this by setting pid provider probes on user space side of read and write? S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
Quinn wrote:> At 19:43 -0800 5/11/07, Dan Mick wrote: >> dtrace is probably pretty good for this, but you do need to know or infer >> something about the driver. > > Why wouldn''t you just do this by setting pid provider probes on user > space side of read and write? > > S+Eif it''s a user process doing the writes, then yes, by all means. In fact, who needs dtrace then? truss will suffice.
Sorry guys, I should have been more clear. I''m using Mac OS 10.5 and the old defunct app I''m trying to reverse-engineer is a PowerPC application running under Rosetta (I''m using an Intel Mac). I''ve tried inserting a dylib to dump the syscalls but this doesn''t work, and truss isn''t available under Mac OS 10.5. The dtruss script doesn''t give me anything useful (I''m guessing because of the Rosetta PPC emulation?) and actually just stops working. I don''t have access to a PPC Mac for another few weeks (I''m working in the middle of nowhere at the moment) and I guess I could try the application natively then. Any other ideas? :-) thanks again. -- This message posted from opensolaris.org
At 2:23 -0800 7/11/07, pgjw pgjw wrote:>Any other ideas? :-)It''s very likely that the syscall provider will see these operations, even though they''re coming from Rosetta. It''s also very likely that writes to the serial driver are going through one of the following syscall probes: $ sudo dtrace -l -n "syscall::*write*:" ID PROVIDER MODULE FUNCTION NAME 17598 syscall write entry 17599 syscall write return 17832 syscall writev entry 17833 syscall writev return 17898 syscall pwrite entry 17899 syscall pwrite return 18228 syscall aio_write entry 18229 syscall aio_write return 18384 syscall write_nocancel entry 18385 syscall write_nocancel return 18414 syscall writev_nocancel entry 18415 syscall writev_nocancel return 18420 syscall pwrite_nocancel entry 18421 syscall pwrite_nocancel return It''s hard to be sure exactly which one, but you could set probes on them all, see which ones are hit, and then refine things from there. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware