Join Today
+ Reply to Thread
Page 5 of 10 FirstFirst 123456789 ... LastLast
Results 41 to 50 of 95
  1. #41

    Default Re: ezx_sms.cfg (Regarding SMS Messages)

    You mean the things descriptor 6 and 23 points to changes often? Can you observe these changes as they happen with strace? What is the phone doing when they change?
    yeah, if u noticed that file, after the first select call... the first read happens on fd '6' and first write occurs on fd '23'.. yesterday after turning the phone off and switchin it back on.. and then trying it out..ofcourse the filedescriptor is not constant .. i think it changes, even the pid 69 of tapisrv wont be a constant no. it will change i guess....so anyways, although the fd and pid were more or less same even the next time.. but first read was occuring at a fd '4' that points to /dev/mux and a write occur to a fd that points to some socket other then 1257 that was earlier... so it is reading and writing to diff mux and sockets respectively.. however right now i tried couple of times and it is again reading on the fd 6 that points to /dev/mux2 and writing to some socket at 1362...so writing to socket is changing quite often but most of the time it reads from /dev/mux2 .. but sometimes it does differ....

    That is actually very easy. Just loop through all numeric directories in /proc. The one that has the right contents of 'cmdline' is the process
    ok what do you mean by right contents of 'cmdline'..? i saw in quite alot of the /proc directories.. and all processes have 'cmdline' file in it...and if i am not wrong i think all have the same files in it.. so how would i uniquely identify process 69 (tapisrv)
    is there someway though getpid() on some tapisrv file ?

    Is there someone who dares restarting tapisrv and check if the phone still works? (could be a minimal risk of data corruption in db, but then again really must be safe, I mean, they must handle that the battery runs out, so...)
    i think it should be safe .. i will try it if rest of the options fail... but do u think if it works, thats the best option ? cos fooling tapisrv to use our /dev seems hard.. ? also, you r suggesting the same idea as yesterday ryt, in which u wanted to replace /dev/mux2 to /dev/mux2real ... ? something along that line ...?

    I wonder if its the db_daemon that file descriptor 23 of tapiserv points to.
    doesnt 23 point to a socket ? also the num given inside the socket seems to be a port ?

  2. Default Re: ezx_sms.cfg (Regarding SMS Messages)

    yeah, if u noticed that file, after the first select call... the first read happens on fd '6' and first write occurs on fd '23'.. yesterday after turning the phone off and switchin it back on.. and then trying it out..ofcourse the filedescriptor is not constant ..
    Oh, okay, but is it only when you turn phone off and on the in and out filedescriptor changes? (Because then we can just use the info in /proc to determine which file descriptor we need).

    ok what do you mean by right contents of 'cmdline'..?
    I mean, do
    cat cmdline
    and look at the string. This uniquely determines tapisrv.

    cos fooling tapisrv to use our /dev seems hard.. ?
    No, its not really that hard. Here is how it is done:
    1. create a directory /ezxlocal/download/QTDownLoad/FoolTapi
    2. create subdirs that are needed by tapisrv 'dev', 'lib', 'usr'
    3. use mount --bind to mount the things we need,
    mount --bind /lib /ezxlocal/download/QTDownLoad/FoolTapi/lib
    mount --bind /usr /ezxlocal/download/QTDownLoad/FoolTapi/usr
    etc...
    4. copy all the devices we need with tar (cp cannot preserve devices):
    tar -cf - /dev/null /dev/mux <...> | tar -xf -
    5. fake the device we want to play with, perhaps works with a simple named pipe
    mkfifo mux2
    7. create a small c program, or even script, that reads from the real mux2 and writes
    on our faked one
    #! /bin/sh
    cat > /ezxlocal/download/QTDownLoad/FoolTapi/dev/mux2 < /dev/mux2
    8. Write a small c program that just call chroot and then starts tapisrv:
    #include<unistd.h>
    main(int argc, char *argv[]) {
    chroot("/ezxlocal/download/QTDownLoad/FoolTapi/");
    execv("/usr/bin/tapisrv",NULL);
    exit 1;
    }
    9. Well, basically thats it; a few things have to be checked first. Like, are tapisrv normally started with any arguments? (visible in ps or /proc/cmdline). Also, it might not be *this simple* to actually fake the mux2 device, perhaps the information is not one-way. (Do strace ever show tapisrv writing anything to mux2 ?)

    doesnt 23 point to a socket ? also the num given inside the socket seems to be a port ?
    I think socket 23 might be a socket opned against db_server.

  3. #43

    Default Re: ezx_sms.cfg (Regarding SMS Messages)

    hmm i c what you are saying....
    although, as a matter of it does write back to '6' fd.. so it is writing back to mux2...
    i guess i will still try to do it and mess with it.. will get more ideas while implementing...

  4. Default Re: ezx_sms.cfg (Regarding SMS Messages)

    Okay, I have researched this some more...
    We may be able to use pseudo-ttys to get this going. A pseudo-tty is opened with the syscall openpty. The "slave end" of the pseduo-tty look just like a serial port device. Which probably is very similar to the actual mux devices.

    So, someone has to start with writing a dummy pseduo-tty program that connects to a device and just replicates anything in both directions. After we have that running, inserting the spam filter code in there should not be so difficult.
    User friendly installation of native applications: http://www.dewmill.com/linuxphone.html

  5. Default Re: ezx_sms.cfg (Regarding SMS Messages)

    Sorry if me brining up a lot of unrelated ideas is a bit confusing. However, I think now I have an idea of how we actually can pull off the highjacking of the out socket connection.
    But to do that we first must identify what process the output socket is connected to.

    Here is how I think one can do that:
    1) Do an strace of tapiserver to find out which file descriptor is the output SMS descriptor (the one that was 23 in the above traces)
    2) Use the info in /proc/<tapi pid>/fd to find out the socket number of that fd.
    3) Use the info in /proc/net/* to try to dechiper which socket number this socket is connected to
    4) Search through /proc/*/fd/* to indentify which pid owns that socket
    5) Use ps, or check /proc/<pid>/exe to find out which process that is.

    The idea then is then basically to shut down both tapisrv and the other provess. And then start tapisrv, our own process, and the other process in the right order. But I'll get back to the details on that if we can figure out what tapisrv is connected to.
    User friendly installation of native applications: http://www.dewmill.com/linuxphone.html

  6. #46

    Default Re: ezx_sms.cfg (Regarding SMS Messages)

    Excellent Find
    heard it for the first time.. and sounds like a marvellous idea... i am reading online about it.. and seems very much possible.. its basically like taking the control from /dev/mux device, add our spam filter code in b/w and let the process continue... ok here is a small program that i found online ... we might be able to get useful ideas from it if not amend it to our needs...
    i am still going to read a bit more before i program it..

    good work !!!!
    i dont know why its not attaching it..After i click add attachment it says "If you do not want to add an Attachment to your Post, please leave the Fields blank"... anyways, i am puting the code in quotes

    #include <sys/types.h>
    #include <sys/ioctl.h>
    #include <sys/time.h>
    #include <stropts.h>
    #include <termios.h>
    #include <stdlib.h>
    #include <signal.h>
    #include <unistd.h>
    #include <string.h>
    #include <fcntl.h>
    #include <stdio.h>

    #define MAXARGS 32 /* max. cmd. args */

    char *shell = "/bin/sh"; /* default shell */
    char *filename = "scriptfile"; /* default file */
    char *mastername = "/dev/ptmx"; /* pty clone device */

    int master; /* master side of pty */
    FILE *script; /* script file */
    struct termios newtty, origtty; /* tty modes */

    void finish(int);
    int ptyopen(char *, struct termios *);

    int
    main(int argc, char **argv)
    {
    char *p;
    int n, nfd;
    time_t clock;
    fd_set readmask;
    char buf[BUFSIZ];

    /*
    * If an argument is given, it's a new script file.
    */
    if (argc > 1)
    filename = *++argv;

    /*
    * 1. Use the user's shell, if known.
    */
    if ((p = getenv("SHELL")) != NULL)
    shell = p;

    /*
    * 2. Open the script file.
    */
    if ((script = fopen(filename, "w")) == NULL) {
    perror(filename);
    exit(1);
    }

    /*
    * 3. Get the tty modes. We'll use these both to
    * set modes on the pseudo-tty, and to restore
    * modes on the user's tty.
    */
    if (tcgetattr(0, &origtty) < 0) {
    perror("tcgetattr: stdin");
    exit(1);
    }

    /*
    * 4. Grab a pseudo-tty and start a shell on it.
    */
    if ((master = ptyopen(shell, &origtty)) < 0)
    exit(1);

    /*
    * Print a little start message.
    */
    time(&clock);
    fprintf(script, "Script started on %s", ctime(&clock));
    printf("Script started, file is %s\n", filename);

    /*
    * 5. We need to catch signals, now that we're going
    * to change tty modes.
    */
    sigset(SIGINT, finish);
    sigset(SIGQUIT, finish);

    /*
    * 6. Change the user's tty modes such that pretty
    * much everything gets passed through to the
    * pseudo-tty. Set "raw" mode so that we can pass
    * characters as they're typed, etc.
    */
    newtty = origtty;
    newtty.c_cc[VMIN] = 1;
    newtty.c_cc[VTIME] = 0;
    newtty.c_oflag &= ~OPOST;
    newtty.c_lflag &= ~(ICANON|ISIG|ECHO);
    newtty.c_iflag &= ~(INLCR|IGNCR|ICRNL|IUCLC|IXON);

    /*
    * 7. Set the new tty modes.
    */
    if (tcsetattr(0, TCSANOW, &newtty) < 0) {
    perror("tcsetattr: stdin");
    exit(1);
    }

    /*
    * 8. Now just sit in a loop reading from the keyboard and
    * writing to the pseudo-tty, and reading from the
    * pseudo-tty and writing to the screen and the script file.
    */
    for (; {
    FD_ZERO(&readmask);
    FD_SET(master, &readmask);
    FD_SET(0, &readmask);
    nfd = master + 1;

    /*
    * 8a. Wait for something to read.
    */
    n = select(nfd, &readmask, (fd_set *) 0, (fd_set *) 0,
    (struct timeval *) 0);

    if (n < 0) {
    perror("select");
    exit(1);
    }

    /*
    * 8b. The user typed something... read it and pass
    * it on to the pseudo-tty.
    */
    if (FD_ISSET(0, &readmask)) {
    if ((n = read(0, buf, sizeof(buf))) < 0) {
    perror("read: stdin");
    exit(1);
    }

    /*
    * The user typed end-of-file; we're
    * done.
    */
    if (n == 0)
    finish(0);

    if (write(master, buf, n) != n) {
    perror("write: pty");
    exit(1);
    }
    }

    /*
    * 8c. There's output on the pseudo-tty... read it and
    * pass it on to the screen and the script file.
    */
    if (FD_ISSET(master, &readmask)) {
    /*
    * The process died.
    */
    if ((n = read(master, buf, sizeof(buf))) <= 0)
    finish(0);

    fwrite(buf, sizeof(char), n, script);
    write(1, buf, n);
    }
    }
    }

    /*
    * ptyopen - start command on a pseudo-tty and return a file descriptor
    * with which to speak to it.
    */
    int
    ptyopen(char *command, struct termios *ttymodes)
    {
    char *p;
    pid_t pid;
    char *slavename;
    char *args[MAXARGS];
    int nargs, master, slave;

    /*
    * 9. Break the command into arguments.
    */
    nargs = 0;
    p = strtok(command, " \t\n");

    do {
    if (nargs == MAXARGS) {
    fprintf(stderr, "too many arguments.\n");
    return(-1);
    }

    args[nargs++] = p;
    p = strtok(NULL, " \t\n");
    } while (p != NULL);

    args[nargs] = NULL;

    /*
    * 10. Get a master pseudo-tty.
    */
    if ((master = open(mastername, O_RDWR)) < 0) {
    perror(mastername);
    return(-1);
    }

    /*
    * 11. Set the permissions on the slave.
    */
    if (grantpt(master) < 0) {
    perror("granpt");
    close(master);
    return(-1);
    }

    /*
    * 12. Unlock the slave.
    */
    if (unlockpt(master) < 0) {
    perror("unlockpt");
    close(master);
    return(-1);
    }

    /*
    * 13. Start a child process.
    */
    if ((pid = fork()) < 0) {
    perror("fork");
    close(master);
    return(-1);
    }

    /*
    * 14. The child process will open the slave, which will become
    * its controlling terminal.
    */
    if (pid == 0) {
    /*
    * 14a. Get rid of our current controlling terminal.
    */
    setsid();

    /*
    * 14b. Get the name of the slave pseudo-tty.
    */
    if ((slavename = ptsname(master)) == NULL) {
    perror("ptsname");
    close(master);
    exit(1);
    }

    /*
    * 14c. Open the slave pseudo-tty.
    */
    if ((slave = open(slavename, O_RDWR)) < 0) {
    perror(slavename);
    close(master);
    exit(1);
    }

    /*
    * 14d. Push the hardware emulation module.
    */
    if (ioctl(slave, I_PUSH, "ptem") < 0) {
    perror("ioctl: ptem");
    close(master);
    close(slave);
    exit(1);
    }

    /*
    * 14e. Push the line discipline module.
    */
    if (ioctl(slave, I_PUSH, "ldterm") < 0) {
    perror("ioctl: ldterm");
    close(master);
    close(slave);
    exit(1);
    }

    /*
    * 14f. Copy the user's terminal modes to the slave
    * pseudo-tty.
    */
    if (tcsetattr(slave, TCSANOW, ttymodes) < 0) {
    perror("tcsetattr: pty");
    close(master);
    close(slave);
    exit(1);
    }

    /*
    * 14g. Close the script file and the master; these
    * are not needed in the slave.
    */
    fclose(script);
    close(master);

    /*
    * 14h. Set the slave to be our standard input, output,
    * and error output. Then get rid of the original
    * file descriptor.
    */
    dup2(slave, 0);
    dup2(slave, 1);
    dup2(slave, 2);
    close(slave);

    /*
    * 14i. Execute the command.
    */
    execv(args[0], args);
    perror(args[0]);
    exit(1);
    }

    /*
    * 15. Return the file descriptor for communicating with
    * the process to our caller.
    */
    return(master);
    }

    /*
    * finish - called when we're done.
    */
    void
    finish(int sig)
    {
    time_t clock;

    /*
    * 16. Restore our original tty modes.
    */
    if (tcsetattr(0, TCSANOW, &origtty) < 0)
    perror("tcsetattr: stdin");

    /*
    * Print a finishing message.
    */
    time(&clock);
    fprintf(script, "\nScript finished at %s", ctime(&clock));
    printf("\nScript done, file is %s\n", filename);

    /*
    * 17. All done.
    */
    fclose(script);
    close(master);
    exit(0);
    }


  7. #47

    Default Re: ezx_sms.cfg (Regarding SMS Messages)

    hi Rhizod,
    hmm ok i tried one small program which basically makes use of select system call which basically waits for some read (or any sys call) to occur on a set of given FD.. basically monitoring those fd...

    i was monitoring /dev/mux2 .. the thing is if i also use the select call on that.. and tapisrv is using it as well.. then upon sms receipt, both, my program and tapisrv gets confused as to whom to deliver the control.. and it shuts down the FD 6 which is /dev/mux... and then no sms is received obviously although it's there in gsm modem somewhere... next time u restart the phone u receive those sms's...

    hmm, any idea to how to use select so both programs get it...other then ofcourse killing tapisrv...i will do it if i have to though

    secondly, you think the program in the previous post looks good starting point ? didnt hear any comments from your side... ?

    thanks,
    MAQ

  8. Default Re: ezx_sms.cfg (Regarding SMS Messages)

    Okay, lets call this approach the "mux-overtake" approach. In contrast to the "SMS-reroute" approach where one instead takes over the outgoing SMS transmission socket from tapisrv. (Which I actually currently think might be the better alternative...)

    Yes, the program you posted looks like a good starting point. I also googled a little and found something that might be useful. It is a routine that should work on pseduo-terminal file descriptors and just acts as a two-way copier. I found it here:
    http://lists.arm.linux.org.uk/piperm...ry/004719.html
    and the code is:
    Code:
    #include <sys/time.h>
    #include <sys/types.h>
    #include <unistd.h>
    
    #include "error.h"
    
    /* This isn't really a pipe.  What it does is write everything read
       from fd0 into fd1 and vice-versa.  Maybe it's a bi-directional
       pipe? */
    
    void copy(int fd0, int fd1)
    {
      char buf[2][256], *bp[2] = { NULL, NULL };
      int cnt, cc[2], i, maxfdp1, fd[2] = { fd0, fd1 };
      fd_set ibits, obits, ebits;
    
      cc[0] = cc[1] = 0;
      maxfdp1 = (fd[0] > fd[1] ? fd[0] : fd[1]) + 1;
    
      while(1) {
        FD_ZERO(&ibits);
        FD_ZERO(&obits);
        FD_ZERO(&ebits);
    
        for(i=0; i<2; i++) {
          if(cc[i:5ad12e4c16] > 0)
    	FD_SET(fd[!i], &obits);
          else
    	FD_SET(fd[i:5ad12e4c16], &ibits);
          FD_SET(fd[i:5ad12e4c16], &ebits);
        }
    
        SYSERR(select(maxfdp1, &ibits, &obits, &ebits, NULL)); /* XXX: EINTR? */
    
        for(i=0; i<2; i++) {
          if(FD_ISSET(fd[i:5ad12e4c16], &ebits))
    	goto out;
    
          if(FD_ISSET(fd[i:5ad12e4c16], &ibits)) {
    	SYSERR(cc[i:5ad12e4c16] = read(fd[i:5ad12e4c16], buf[i:5ad12e4c16], sizeof(buf[i:5ad12e4c16])));
    	if(cc[i:5ad12e4c16] == 0) /* EOF */
    	  goto out;
    	else /* cc[i:5ad12e4c16] > 0 */
    	  bp[i:5ad12e4c16] = buf[i:5ad12e4c16];
          }
    
          if(FD_ISSET(fd[!i], &obits) && cc[i:5ad12e4c16] > 0) {
    	SYSERR(cnt = write(fd[!i], bp[i:5ad12e4c16], cc[i:5ad12e4c16]));
    	cc[i:5ad12e4c16] -= cnt;
    	bp[i:5ad12e4c16] += cnt;
          }
        }
      }
     out:
    }
    Basically, you wish to modify your program to instead of messing around with keyboards etc, you want to use this routine to just copy between the real device and your ptty.

    the thing is if i also use the select call on that.. and tapisrv is using it as well.. then upon sms receipt, both, my program and tapisrv gets confused as to whom to deliver the control..
    Yes, that is why you have to use, for example, the approach I posted above for fooling tapisrv to connect to your ptty instead of the real device. That is, in short, you build a fake root directory and use the chroot syscall to fool tapisrv to use your fake device. (Or, if you are into playing around with hacked firmwares, the same thing is doable by just renaming the real mux)

  9. #49

    Default Re: ezx_sms.cfg (Regarding SMS Messages)

    ok perfect... i am looking into this ... will get back to u as soon as i have some questions cos i think we might just have to do that....

    anyways to correct myself from the previous post... infact, i changed the program a bit, and this time upon select on /dev/mux2 i do read it in addition to the tapisrv doing its job just fine....

    BUT... ! i am getting back the same crazy encoding that is ..

    output:
    # ./read
    calling read..
    Opened /dev/mux2
    Going Into Wait..
    read 78 from mux:
    +CMT: 24
    07916164260220F004048105003B00507012018084690AF7303D6D7EA1DFF032

    Going Into Wait..
    i did read exactly the same pattern that is in read call right after that select call.... hmm !!

    anyways, i am looking at ur suggestion again... will get back to u with more questions on that...

  10. #50

    Default Re: ezx_sms.cfg (Regarding SMS Messages)

    hi Rhizod,
    ok so i am implementing the above code u provided... i got some questions....

    ok so before calling copy(fd0,fd1) .. i wanna straighten out which one is which... i think fd0 will correspond to my ptty device which i will open like this

    masterfd = open("/dev/ptmx", O_RDWR))
    and fd1 corresponds to the real device (also slave? )... i am not sure...? maybe

    slavefd = open("/dev/mux2",O_RDWR)
    ? also do u think all those commands like "grantpt" "unlockpt" are imp before i call copy() ?

    thanks,
    MAQ


 
+ Reply to Thread
Page 5 of 10 FirstFirst 123456789 ... LastLast

Similar Threads

  1. Storing SMS Messages
    By Avaholic in forum A1200 General Chat
    Replies: 13
    Last Post: 11-14-2007, 06:26 PM
  2. Backing up Text messages / SMS?
    By satnitefever in forum A1200 General Chat
    Replies: 1
    Last Post: 07-20-2007, 12:11 AM
  3. Repeat SMS Messages
    By dusty_nz in forum E680i General Chat
    Replies: 4
    Last Post: 08-15-2006, 08:29 AM
  4. T-Mobile Voicemail and SMS messages
    By chadrickb in forum E680i General Chat
    Replies: 40
    Last Post: 02-04-2006, 12:24 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Single Sign On provided by vBSSO

Search Engine Friendly URLs by vBSEO 3.6.0 RC 1