Customized rtmpdump binaries with patch file

[RedPenguin]

Originally Posted by KSV

@RedPenguin
your problem seems more like server configuration issue because the same response is accepted by other servers without any problem. anyway i have disabled it in my patches for compatibility reasons.

Thanks again for the info and all your work combined. Still nice to see some folks working on rtmpdump as it seems the official project seems almost stalled, LoL.

Anyway, I figured at first maybe they were trying to purposely break rtmpdump but I think your answer makes more sense.

[Stream Ripper]

Thanks as always KSV

[gorilla.maguila]

More info on the crash I've found:

After deeper debugging, I've found that the crash is happening in calloc:

RTMPPacket_Alloc(RTMPPacket *p, int nSize)
{
  //Crash in calloc
  char *ptr = calloc(1, nSize + RTMP_MAX_HEADER_SIZE);
  if (!ptr)
    return FALSE;
  p->m_body = ptr + RTMP_MAX_HEADER_SIZE;
  p->m_nBytesRead = 0;
  return TRUE;
}

That memory corruption pointed me to run with valgrind, that showed the culprit:

==22473== Invalid write of size 1
==22473==    at 0x4E421DC: HandleInvoke (rtmp.c:3333)
==22473==    by 0x4E4368D: RTMP_ClientPacket (rtmp.c:1361)
==22473==    by 0x4E43849: RTMP_ConnectStream (rtmp.c:1152)
==22473==    by 0x403BFA: main (rtmpdump.c:1374)
==22473==  Address 0x61e1c67 is 0 bytes after a block of size 39 alloc'd
==22473==    at 0x4C2C04B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22473==    by 0x4E42189: HandleInvoke (rtmp.c:3328)
==22473==    by 0x4E4368D: RTMP_ClientPacket (rtmp.c:1361)
==22473==    by 0x4E43849: RTMP_ConnectStream (rtmp.c:1152)
==22473==    by 0x403BFA: main (rtmpdump.c:1374)

Full valgrind output http://pastebin.com/9bAXB9W9

So it seems that the memory corruption exists due to AMF_DecodeInt24 returning incorrect size:

packet->m_nBodySize = AMF_DecodeInt24(header + 3);

and then allocating the memory, the crash occurs.

if (!RTMPPacket_Alloc(packet, packet->m_nBodySize))

Maybe KSV can enlighten me here, but I think the proof is that allocating more memory avoids the crash:

if (!RTMPPacket_Alloc(packet, 2*packet->m_nBodySize))

[KSV]

try updating the relevant block with following code.

          if (code == 302 && RTMP_FindFirstMatchingProperty(&obj2, &av_redirect, &p))
            {
              AMFProp_GetString(&p, &redirect);
              r->Link.redirected = TRUE;

              char *playpath = "//playpath";
              int len = redirect.av_len + strlen(playpath);
              char *url = malloc(len + 1);
              memcpy(url, redirect.av_val, redirect.av_len);
              memcpy(url + redirect.av_len, playpath, strlen(playpath));
              url[len] = '\0';
              r->Link.tcUrl.av_val = url;
              r->Link.tcUrl.av_len = redirect.av_len;
              RTMP_ParseURL(url, &r->Link.protocol, &r->Link.hostname, &parsedPort, &r->Link.playpath0, &r->Link.app);
              if (parsedPort)
                r->Link.port = parsedPort;
            }
        }

[gorilla.maguila]

Originally Posted by KSV

try updating the relevant block with following code.

          if (code == 302 && RTMP_FindFirstMatchingProperty(&obj2, &av_redirect, &p))
            {
              AMFProp_GetString(&p, &redirect);
              r->Link.redirected = TRUE;

              char *playpath = "//playpath";
              int len = redirect.av_len + strlen(playpath);
              char *url = malloc(len + 1);
              memcpy(url, redirect.av_val, redirect.av_len);
              memcpy(url + redirect.av_len, playpath, strlen(playpath));
              url[len] = '\0';
              r->Link.tcUrl.av_val = url;
              r->Link.tcUrl.av_len = redirect.av_len;
              RTMP_ParseURL(url, &r->Link.protocol, &r->Link.hostname, &parsedPort, &r->Link.playpath0, &r->Link.app);
              if (parsedPort)
                r->Link.port = parsedPort;
            }
        }

Thanks KSV, it's SOLVED.

Do you think it's worthy to look at the possible memory leaks pointed out by valgrind, like the

char *url = malloc(len + 1)

Never being freed, or they're false positive?

Thanks again

[RedPenguin]

Originally Posted by flocked

Could anyone please compile it for mac? thanks!!

This has been done, at least if you are running x86 32 or 64.

http://www.mediafire.com/#x4cvp5hl4m9xr (look under Newer - ATV1+MacOS).

I can make PPC versions if necessary but right now my cross-compilers are x86-based.

[KSV]

Changes:

1. added onFCSubscribe response to rtmpsrv to detect more streams
2. show complete debug info in rtmpsuck when connection is closed
3. fixed a small bug in redirect handling (allocating 1 byte less than required)

first post updated with latest package.

[KSV]

Originally Posted by gorilla.maguila

Do you think it's worthy to look at the possible memory leaks pointed out by valgrind, like the

char *url = malloc(len + 1)

Never being freed, or they're false positive?

we are using the same buffer for tcUrl so it can't be freed right away. it will not be worth making a copy because memory consumption would be same in that case.

[alexanderd]

Originally Posted by KSV

no, it has nothing to do with RTMPDump Helper. make sure new binaries are in the same folder as RTMPDump Helper.

I tried capturing on my parents' old computer. And it worked well! The timestamp has been added to filename!
The main difference between my both computer and notebook (the problem is on both) and my parents' comp - is OS. Mine are worked under Win7 Ultimate SP1 (with updates). Parents' - under WinXP.
And what OS do you use, KSV?

[KSV]

Originally Posted by alexanderd

Mine are worked under Win7 Ultimate SP1 (with updates). Parents' - under WinXP.
And what OS do you use, KSV?

it doesn't have anything to do with OS. can anyone else confirm this on a different OS than XP?