Too many memory mapping

[mingzhu0527]

Too many memory mapping
cannot read memory map
can't find address of mprotect(), error!

Hi crmulliner and everyone,
I came across this error when hijacking an user app process. The target so library is right in the lib folder of the /data/data/ and the target function is an JNI function (aka Java_com___get_).
Anyone knows how to fix it? I tried it on several devices, all turned out the same error. Does the target app have some protection trick? Or hijack tool's issue?
Thanks in advance.

[jduck]

You can try increasing the buffer size of "raw" on line 260 of hijack/hijack.c ... That might alleviate the problem. The correct fix is to rework the way maps are read and stop depending on a fixed buffer size. In lieu of that, try increasing the buffer size. Good luck!

diff --git a/hijack/hijack.c b/hijack/hijack.c
index 733a4be..1af66b2 100644
--- a/hijack/hijack.c
+++ b/hijack/hijack.c
@@ -257,7 +257,7 @@ load_symtab(char *filename)
 static int
 load_memmap(pid_t pid, struct mm *mm, int *nmmp)
 {
-       char raw[80000]; // this depends on the number of libraries an executable uses
+       char raw[128000]; // this depends on the number of libraries an executable uses
        char name[MAX_NAME_LEN];
        char *p;
        unsigned long start, end;

[crmulliner]

yes, this is an old problem.

[animehunter]

I've developed a sane fix for "too many memory mapping" error to replace the previous kludgy fix

amod/jni/hijack/hijack.c | 45 ++++++++++++++++++++++++++++++++++-----------
 1 file changed, 34 insertions(+), 11 deletions(-)

diff --git a/amod/jni/hijack/hijack.c b/amod/jni/hijack/hijack.c
index e0ecf0c..a06648d 100644
--- a/amod/jni/hijack/hijack.c
+++ b/amod/jni/hijack/hijack.c
@@ -259,38 +259,60 @@ load_symtab(char *filename)
 static int
 load_memmap(pid_t pid, struct mm *mm, int *nmmp)
 {
-   static char raw[10485760]; // this depends on the number of libraries an executable uses
+   char path[PATH_MAX];
    char name[MAX_NAME_LEN];
-   char *p;
+   char *raw, *p;
+   size_t raw_size;
    unsigned long start, end;
    struct mm *m;
    int nmm = 0;
    int fd, rv;
    int i;

-   sprintf(raw, "/proc/%d/maps", pid);
-   fd = open(raw, O_RDONLY);
+   sprintf(path, "/proc/%d/maps", pid);
+   fd = open(path, O_RDONLY);
    if (0 > fd) {
        printf("Can't open %s for reading\n", raw);
        return -1;
    }

-   /* Zero to ensure data is null terminated */
-   memset(raw, 0, sizeof(raw));
+   /* start off an initial buffer */
+   raw_size = 1024;
+   raw = malloc(raw_size);
+   if(!raw) {
+       // perror("malloc");
+       return -1;
+   }
+
+   /* zero to ensure data is null terminated */
+   memset(raw, 0, raw_size);

    p = raw;
    while (1) {
-       rv = read(fd, p, sizeof(raw)-(p-raw));
-       if (0 > rv) {
+       size_t rem = raw_size - (p - raw);
+       rv = read(fd, p, rem);
+       if (rv < 0) {
            //perror("read");
+           free(raw);
            return -1;
        }
        if (0 == rv)
            break;
        p += rv;
-       if (p-raw >= sizeof(raw)) {
-           printf("Too many memory mapping\n");
-           return -1;
+
+       /* check to see if we need to grow the buffer */
+       if(p - raw >= raw_size) {
+           char* grown = realloc(raw, raw_size * 2);
+           if(!grown) {
+               // perror("realloc");
+               free(raw);
+               return -1;
+           }
+
+           raw = grown;
+           memset(raw + raw_size, 0, raw_size);
+           p = raw + raw_size;
+           raw_size *= 2;
        }
    }
    close(fd);
@@ -339,6 +361,7 @@ load_memmap(pid_t pid, struct mm *mm, int *nmmp)
    }

    *nmmp = nmm;
+   free(raw);
    return 0;
 }

[jduck]

I can't speak for anyone else, but my uses of ADBI preclude the use of APIs like malloc.

[yan12125]

@jduck Why not malloc? Also there's already many xmalloc invocations in hijack.c.

@animehunter How about fork adbi and push your patch?

[jduck]

@yan12125 I have, in the past, used ADBI to monitor heap operations in the target process. Introducing additional allocations taints the state of the target. It's fine to have heap allocations within the injector side, but I do everything I can to eliminate allocations introduced into the target.

[yan12125]

I see. Maybe alloca is an option?

[jduck]

I think alloca could work, yes. I'd recommend adding the -fstack-check too, just to be safe.