Giter VIP home page Giter VIP logo

asdcplib's Introduction

AS-DCP Lib

Introduction

The asdcplib library is an API and command-line tool set that offers access to files conforming to the sound and picture track file formats developed by the SMPTE Working Group DC28.20 (now TC 21DC).

Support has since been added for SMPTE ST 2067-5 "IMF Essence Component", AKA "AS-02", which was published and is maintained by SMPTE TC 35 PM. The initial draft of this code was donated by Fraunhofer IIS and was created by Robert Scheler and Heiko Sparenberg. It carries additional copyright information which should be listed whenever you link the AS-02 elements of the library. Please look at the top of the AS-02 files to see this copyright information.

Support for ST 20XX OpenEXR was developed and contributed by Bjoern Stresing, Patrick Bichiou and Wolfgang Ruppel, supported by AMPAS. It carries additional copyright information which should be listed whenever you link the AS-02 elements of the library. Please look at the top of the AS-02 files to see this copyright information.

AS-02 support is carried in separate object modules, so unless you #include <AS_02.h> and link libas-02.so you are still using plain old asdcp.

Documentation

This library is intended (but of course not limited) for use by developers of commercial D-Cinema and IMF products and for commercial mastering toolchains. The documentation is terse and sparse.

The API documentation is mostly in AS_DCP.h. and AS_02.h Read those files for a detailed description of the library's capabilities. Read asdcp-.cpp and as-02-.cpp files for library usage examples. The command-line utilities all respond to -h.

Also, of course, the various SMPTE and ISO standards that underly all of this work should be well understood if you want to tinker with anything, or, in some cases, understand what properties are required in a particular supported use case (e.g., selecting audio channel labels.)

Build Procedure Change for Auto Tools

You can ignore this if you are using CMake or one of the win32 build methods.

As of release 2.10.32 the release archive file will no longer contain the result of running autoreconf. This places a new requirement on the target platform, that autoreconf and friends are installed. This should not be an issue for most users. If it is, you can roll your own auto-tooled version by untarring the distribution and running autoreconf in its root directory as follows:

autoreconf -if
./configure --enable-as-02
make
make install

Libraries

libkumu - Platform compatibility layer.

libasdcp - SMPTE ST 429 (DCP) and JPEG Interop DCP.

libas02 - SMPTE ST 2067 (IMF).

libphdr - Dolby Vision track file. Deprecated but maintained.

CLI Programs

Standard Utilities

asdcp-test - DEPRECATED Writes, reads and verifies AS-DCP (MXF) track files.

asdcp-wrap - Writes AS-DCP (MXF) track files.

asdcp-unwrap - Extracts essence from AS-DCP (MXF) track files.

asdcp-info - Displays information about AS-DCP (MXF) track files.

asdcp-util - Calculates digests and generates random numbers and UUIDs.

as-02-wrap - Writes AS-02 Essence Component files.

as-02-unwrap - Extracts essence from AS-02 Essence Component files.

kmfilegen - Writes and verifies large files using a platform-independent format. Use it to test issues related to large files.

kmuuidgen, kmrandgen - generate UUID values and random numbers.

wavesplit - Splits a WAVE file into two or more output files. Used to untangle incorrectly-paired DCDM sound files.

blackwave - Write a WAVE file of zeros.

pinkwave - Write a WAVE file of SMPTE ST 2095 pink noise.

j2c-test - Displays information about JP2K codestreams.

PHDR

An experimental feature, Prototype for High Dynamic Range is a wrapper for the IMF application that allows JPEG-2000 codestreams to be paired with opaque blobs of metadata. AS-02 support must be enabled to build this feature, so --enable-as-02 must be enabled if --enable-phdr is to be used. The following executable programs will be built:

phdr-wrap - Writes AS-02 PHDR Essence Component files.

phdr-unwrap - Extracts essence from AS-02 PHDR Essence Component files.

Historical Notes

This work was originally funded by Digital Cinema Initiatives, LLC (DCI). Subsequent efforts have been funded by Deluxe Laboratories, Doremi Labs, CineCert LLC, Avica Technology and others.

The asdcplib project was originally exchanged by FTP. The project was on SourceForge between 2005 and 2008, when it moved to a release-only distribution via CineCert. As of late February 2019, its new home is on github.

In the earliest days, the project depended upon the mxflib project. Because of its focus on covering the whole of the MXF specifications, mxflib is considerably larger and more complex that what was required for the AS-DCP application. For this reason I developed a dedicated MXF implementation. Special thanks to Matt Beard and Oliver Morgan for their great work and support.

Thanks also to the members of the SMPTE DC28.20 packaging ad-hoc group and the members of the MXF Interop Initiative for their encouragement and support. Special thanks to Jim Whittlesey and Howard Lukk at DCI for proposing and supporting this project.

asdcplib's People

Contributors

arnaudbienner avatar broganross avatar cinetim avatar cth103 avatar dcbullock avatar dtatut avatar imftool avatar jason-elkins avatar jhursty avatar khoshmard avatar kieranjol avatar milla-dolby avatar msheby avatar palemieux avatar radford-for-smpte avatar rossb-dlx avatar s-ker-s avatar thorfdbg avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

asdcplib's Issues

Static builds?

Hello! Is it possible to build these tools (notably as-02-unwrap) as statically linked binaries? This is handy when doing multi-stage Docker builds.

Update RDD 47 Registers XML files to match those in SMPTE Metadata Registers

The files are in:
https://github.com/cinecert/asdcplib/tree/master/registers/dolby

A Submission is being made to the SMPTE Metadata Registers as part of ST 2067-202 (RDD 47 replacement) development.

The XML files in this repo should be updated (or removed) to match those ultimately accepted into the SMTPE Metadata Registers.

Specifically, the DefiningDocument values will need to be updated, and the following:

<Parent>urn:smpte:ul:060e2b34.027f0101.0d010101.01012400</Parent>

corrected to:

<Parent>urn:smpte:ul:060e2b34.027f0101.0d010101.01014300</Parent>

AS_02::IAB::MXFReader does not work properly

I am trying to use the as-02 extension of asdcplib to read IAB frames in IMF IAB. My implementation is similar to this:

AS_02::IAB::MXFReader reader(fileReader);
reader.OpenRead(inputFileName);
AS_02::IAB::MXFReader::Frame frame;
reader.ReadFrame(0, frame);

Then strange thing happens. (const char*)frame.second just gives me something strange. It contains some disorganized byte sequences, and obviously not the content of a IAB frame.

An earlier version, like commit d417531, works fine. Did I make any mistakes?

Also here is a little question: Why I have to pass a Kumu::IFileReaderFactory when constructing MXFReader? Is it necessary? If not, can we still provide a construction method that doesn't require it like earlier versions to simplify usage? Thank you.

Best Regards.

Incorrect symbols used for Immersive Audio Data Essence Descriptor and SubDescriptor

The library currently outputs:

060e2b34.02530105.0e090603.00000000  len:     120 (PrivateDCDataDescriptor)
             InstanceUID = f6417a2c-80a3-46ad-91a7-e19878fabff9
                Locators:
          SubDescriptors:
  a82aa922-ccf2-4494-8b86-d45a8c6040ba
           LinkedTrackID = 2
              SampleRate = 24/1
       ContainerDuration = 27768
        EssenceContainer = 060e2b34.04010105.0e090605.00000000
       DataEssenceCoding = 060e2b34.04010105.0e090604.00000000

060e2b34.02530105.0e090606.00000000  len:      65 (DolbyAtmosSubDescriptor)
             InstanceUID = a82aa922-ccf2-4494-8b86-d45a8c6040ba
                 AtmosID = 4395698a-3c22-4ab1-b3d4-b6784dba9a65
              FirstFrame = 0
         MaxChannelCount = 10
          MaxObjectCount = 118
            AtmosVersion = 1

Instead the symbols defined in the SMPTE register should be used. For example, PrivateDCDataDescriptor should be IADataEssenceDescriptor and DolbyAtmosSubDescriptor should be IADataEssenceSubDescriptor

Photon validation errors

I'm working with asdcplib to create IMF packages and I'm facing errors when validating them with Photon.

06 May 2021 14:26:54,186 [ERROR] [IMPAnalyzer]: 		ERROR-EssenceDescriptor with ID 9b78ce17-cafd-4347-8abf-75a1dd5b52fe is missing J2CLayout in JPEG2000SubDescriptor [Photon version: 4.8.0]
06 May 2021 14:26:54,186 [ERROR] [IMPAnalyzer]: 		ERROR-EssenceDescriptor with ID 9b78ce17-cafd-4347-8abf-75a1dd5b52fe has invalid combination of ComponentMinRef/BlackRefLevel(64)-ComponentMaxRef/WhiteRefLevel(940)-PixelBitDepth(0) in Image Essence Descriptor [Photon version: 4.8.0]
06 May 2021 14:26:54,186 [ERROR] [IMPAnalyzer]: 		ERROR-EssenceDescriptor with ID 9b78ce17-cafd-4347-8abf-75a1dd5b52fe invalid PixelBitDepth(0) for Color(Color3) as per APPLICATION_2E_COMPOSITION_TYPE [Photon version: 4.8.0]
06 May 2021 14:26:54,186 [ERROR] [IMPAnalyzer]: 		ERROR-EssenceDescriptor with ID 9b78ce17-cafd-4347-8abf-75a1dd5b52fe has Invalid Quantization(Unknown) for ColorModel(YUV) as per APPLICATION_2E_COMPOSITION_TYPE [Photon version: 4.8.0]

The first one has an opened issue on #27

For the three others, it seems having an issue with pixel depth but I can't tell where it is because when I dump the MXF info with as-02-info, the ComponentDepth is well set to 10.

Is it due to missing J2CLayout descriptor ? If I dump header from a MXF created with DaVinci Resolve, I have this:

060e2b34.02530101.0d010101.01015a00  len:     194 (JPEG2000PictureSubDescriptor)
             InstanceUID = 3a7b2882-e19e-4d01-9911-f4434fc21704
                   Rsize = 1060
                   Xsize = 1920
                   Ysize = 1080
                  XOsize = 0
                  YOsize = 0
                  XTsize = 1920
                  YTsize = 1080
                 XTOsize = 0
                 YTOsize = 0
                   Csize = 3
  PictureComponentSizing = 0000000300000003090101090201090201
      CodingStyleDefault = 01040001000503030000778888888888
     QuantizationDefault = 22871e86ea86ea86bc7f007f007ee2774c774c776460036003604567d267d26761
               J2CLayout = Y(10) U(10) V(10)c7f007f007ee2774c774c776460036003604567d267d26761

MXF created with as-02-wrap (using the same tiles) doesn't have J2CLayout

060e2b34.02530101.0d010101.01015a00  len:     174 (JPEG2000PictureSubDescriptor)
             InstanceUID = a92ac74e-0346-4a88-97b5-440c7b871480
                   Rsize = 1060
                   Xsize = 1920
                   Ysize = 1080
                  XOsize = 0
                  YOsize = 0
                  XTsize = 1920
                  YTsize = 1080
                 XTOsize = 0
                 YTOsize = 0
                   Csize = 3
  PictureComponentSizing = 0000000300000003090101090201090201
      CodingStyleDefault = 01040001000503030000778888888888
     QuantizationDefault = 22871e86ea86ea86bc7f007f007ee2774c774c776460036003604567d267d26761

This is the command line used to wrap the MXF:

as-02-wrap -A "16/9" -r '24000/1001' -x 2 -X 1 -D 10 -Y -p 060e2b34.0401010d.04010202.0301020a -q 060e2b34.04010101.04010101.02020000 -n 060e2b34.04010101.04010101.01020000 j2k/ video.mxf

I can maybe try to write a patch for this if you can tell me where to look, thank you

asdcp-unwrap will write timed-text ancillary resources to "/[UUID]" when file-prefix has no path

If <file-prefix> does not include a path portion, asdcp-unwrap will try to write timed-text ancillary resources with a path prefix of "/". On any system that protects that directory, an error will occur. On others, the ancillary resources are written in an unexpected directory.

without path portion

asdcp-unwrap -v ../tt_3d_subs_png_blue_r1_24fps_9c4f6e97-adce-404c-bef4-023306c09611.mxf blue.xml
         EditRate: 24/1
ContainerDuration: 8640000
          AssetID: ac8291bf-cec9-4176-8fd9-07239282281a
    NamespaceName: http://www.smpte-ra.org/schemas/428-7/2014/DCST
    ResourceCount: 4
    9f49bb7e-ea88-4659-a615-617be0065c6f: application/x-font-opentype
    01000001-7eac-4972-a32e-f6bb483db621: image/png
    01000002-451a-447a-b922-215b9ea3f73a: image/png
    01000003-a316-4058-a4d6-25e290743dd8: image/png
Error opening file /9f49bb7e-ea88-4659-a615-617be0065c6f: Permission denied
9f49bb7e-ea88-4659-a615-617be0065c6f | application/x-font-opentype | 895200
Program stopped on error.
File open failure.

with path portion

asdcp-unwrap -v ../tt_3d_subs_png_blue_r1_24fps_9c4f6e97-adce-404c-bef4-023306c09611.mxf ./blue.xml
         EditRate: 24/1
ContainerDuration: 8640000
          AssetID: ac8291bf-cec9-4176-8fd9-07239282281a
    NamespaceName: http://www.smpte-ra.org/schemas/428-7/2014/DCST
    ResourceCount: 4
    9f49bb7e-ea88-4659-a615-617be0065c6f: application/x-font-opentype
    01000001-7eac-4972-a32e-f6bb483db621: image/png
    01000002-451a-447a-b922-215b9ea3f73a: image/png
    01000003-a316-4058-a4d6-25e290743dd8: image/png
9f49bb7e-ea88-4659-a615-617be0065c6f | application/x-font-opentype | 895200
01000001-7eac-4972-a32e-f6bb483db621 | image/png | 13868
01000002-451a-447a-b922-215b9ea3f73a | image/png | 14090
01000003-a316-4058-a4d6-25e290743dd8 | image/png | 14125

ReadFreame method in as_02_IAB.cpp needs re-work

There are two problems with the implementation of this method:

  1. The method relies on the encoding of the IAFrame to find the frame size; IAFrame is described in SMPTE ST 2098-2:2019 and can change independently of SMPTE ST 2067-201:2019. There is no need to tie the two together.

  2. The method uses small read/seek calls that are inefficient and problematic in future cloud deployments. The method should ultimately make one call to read (with possibly no seek if the frames are read sequentially) to ingest the whole frame.

The size of the frame should be determined by looking at the position of the next frame in the IndexTable. The index table is already loaded into memory and will not require any additional calls to the underlying file.

BER Decoding

Is it normal to not support BER decoding for length (or the length) different to 4 or 8 ?
Meaning length starting 0x83 or 0x87 are supported but not others cases...

ADCP-Test MAX_IN_FILES

Hello Everyone, i tried to wrap 16 Sound Channels to one MXF. Because I need the VI on channel 16.
But there is no way to do this because in Line70 of asdcp-test.cpp is written:
const ui32_t MAX_IN_FILES = 16;
and in Line 511 to 515:
if ( file_count >= MAX_IN_FILES ) { fprintf(stderr, "Filename lists exceeds maximum list size: %u\n", MAX_IN_FILES); return; }
but it schould be:
if ( file_count > MAX_IN_FILES ) { fprintf(stderr, "Filename lists exceeds maximum list size: %u\n", MAX_IN_FILES); return; }

I cant correct and compile the asdcp-test.exe by my own. Can sombody fix it an upload new binarie exe files for asdct-test?

Thank you kind regards

HMAC test could be more verbose on failure

ASDCP::IntegrityPack::TestValues

Returns an error code when the compare of expected and found HMAC fails. It would nice if the test provided failure feedback on stdout.

Incorrect clip length

The length of the KLV that contains the clip-wrapped IAB frames should not include the length of the K and L values (24-bytes).

24 bytes should be subtracted from size at:

ui64_t size = static_cast<ui64_t>(this->m_Writer->m_StreamOffset);

Potential bug in TimedText_Parser.cpp under WIN32 when adding subtitle assets

Hey John,
I'm wondering if the below (potential) bug has been fixed in this release?
Having a quick look at the source, I can't see anything different from the previous version.
Cheers,
Steve Q.

If I try and wrap a smpte timed text XML file which contains a font (or any other asset for that matter), the wrap process fails, as font file is not found. Asdcplib returns this error:

result {value=-9 label="The requested file does not exist on the system." symbol="NOT_FOUND" ...} Kumu::Result_t

Looking at the code for the LocalFilenameResolver function (below) in TimedText_Parser.cpp, it appears that on a Windows system, the variable found_list is being declared, but not initialised. I have defined KM_WIN32 so the code in the ifdef is ignored. Therefore, PathList_t found_list; is being declared, and the very next line is being checked for size, which will of course be 0. Consequently, it will not find my font file.

ASDCP::TimedText::LocalFilenameResolver::ResolveRID(const byte_t* uuid, TimedText::FrameBuffer& FrameBuf) const
{
  Result_t result = RESULT_NOT_FOUND;
  char buf[64];
  UUID RID(uuid);
  PathList_t found_list;
 
#ifndef KM_WIN32
  // TODO, fix this for win32 (needs regex)
  FindInPath(PathMatchRegex(RID.EncodeHex(buf, 64)), m_Dirname, found_list);
#endif
 
  if ( found_list.size() == 1 )
    {
      FileReader Reader;
      DefaultLogSink().Debug("Retrieving resource %s from file %s\n", buf, found_list.front().c_str());
 
      result = Reader.OpenRead(found_list.front().c_str());
 
      if ( KM_SUCCESS(result) )
      {
        ui32_t read_count, read_size = Reader.Size();
        result = FrameBuf.Capacity(read_size);
      
        if ( KM_SUCCESS(result) )
          result = Reader.Read(FrameBuf.Data(), read_size, &read_count);
 
        if ( KM_SUCCESS(result) )
          FrameBuf.Size(read_count);
      }
    }
  else if ( ! found_list.empty() )
    {
      DefaultLogSink().Error("More than one file in %s matches %s.\n", m_Dirname.c_str(), buf);
      result = RESULT_RAW_FORMAT;
    }
 
  return result;
}

extract text data

Hi John,

Is this tool extracting textual data from the package? if so, what command should be used?

Thanks!

JP2K Quantization unpacking and QCD data checks

Hi all,

We are seeing that the GuardBit value determined with j2c-test is incorrect. Proposing the following changes to unpack the correct bytes for determining GuardBits:

JP2K.h around lines 164 to 200

      const int SqcdOFST = 0;
      const int SPqcdOFST = 1;

      enum QuantizationType_t
      {
	QT_NONE,
	QT_DERIVED,
	QT_EXP
      };

      const char* GetQuantizationTypeString(const QuantizationType_t m);

      // Quantization default
      class QCD
        {
	  const byte_t* m_MarkerSqcd;
	  const byte_t* m_MarkerData;
	  ui32_t m_DataSize;

	  KM_NO_COPY_CONSTRUCT(QCD);
	  QCD();

	public:
	  QCD(const Marker& M)
	    {
	      assert(M.m_Type == MRK_QCD);
              m_MarkerSqcd = M.m_Data;
	      m_MarkerData = M.m_Data + SPqcdOFST;
	      m_DataSize = M.m_DataSize - SPqcdOFST;
	    }

	  ~QCD() {}
	  inline QuantizationType_t QuantizationType() const { return static_cast<QuantizationType_t>(*(m_MarkerSqcd) & 0x03); }
	  inline ui8_t  GuardBits() const { return (*(m_MarkerSqcd) & 0xe0) >> 5; }
	  void Dump(FILE* stream = 0) const;
	};

Additionally, does anyone know if there is a specific requirement for the QCD Data to match between frames aswell as GuardBits matching, as per the pedantic checks? Different JP2K Encoders potentially use different values here and the pedantic checks prevent these from wrapping frames which have differing values in a single MXF.

Proposing the following changes to highlight a difference of QCD Data (with matching GuardBits), but not to fail the pedantic checks:

JP2K_Sequence_Parser.cpp line ~209 to 226:

//
bool
operator==(const ASDCP::JP2K::QuantizationDefault_t& lhs, const ASDCP::JP2K::QuantizationDefault_t& rhs)
{
  if ( lhs.Sqcd != rhs.Sqcd ) return false;
  if ( lhs.SPqcdLength != rhs.SPqcdLength ) return false;
  
  for ( ui32_t i = 0; i < JP2K::MaxDefaults; i++ )
    {
      if ( lhs.SPqcd[i] != rhs.SPqcd[i]  ){
        printf("SPqcd Component mismatch.\n");
        // TODO: Bypassing this check until we know if it is appropriate
        // return false;
      }
    }

  return true;
}

AddressSanitizer: heap-buffer-overflow on address in ASDCP::TimedText::MXFReader::h__Reader::MD_to_TimedText_TDesc

Title: AddressSanitizer: heap-buffer-overflow on address in ASDCP::TimedText::MXFReader::h__Reader::MD_to_TimedText_TDesc

Description:
I found a heap-buffer-overflow when testing the asdcplib library, specifically in the MD_to_TimedText_TDesc function.

Affected Software:

Software: asdcplib
Version: 2.13.1
Operating System: Debian 11
Kernel: Linux debian 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64 GNU/Linux

Impact:
A heap-buffer-overflow vulnerability can lead to application crashes, data corruption, security vulnerabilities, and system instability.

Steps to Reproduce:

Build the affected software (asdcplib) after enabling AddressSanitizer.
Execute any of the affected binaries (asdcp-info, asdcp-unwrap) with provided poc that triggers the vulnerable code path.
Observe the AddressSanitizer report indicating a heap-buffer-overflow error.

Example Output (AddressSanitizer):

=================================================================
==3302077==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e0000008c9 at pc 0x7f438b4876ae bp 0x7fff15258e00 sp 0x7fff15258df8
READ of size 16 at 0x60e0000008c9 thread T0
    #0 0x7f438b4876ad in ASDCP::TimedText::MXFReader::h__Reader::MD_to_TimedText_TDesc(ASDCP::TimedText::TimedTextDescriptor&) (/mnt/fast/DCP/asdcplib/build-asan/src/libasdcp.so.2+0x38b6ad)
    #1 0x7f438b487ff6 in ASDCP::TimedText::MXFReader::h__Reader::OpenRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (/mnt/fast/DCP/asdcplib/build-asan/src/libasdcp.so.2+0x38bff6)
    #2 0x7f438b48934b in ASDCP::TimedText::MXFReader::OpenRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (/mnt/fast/DCP/asdcplib/build-asan/src/libasdcp.so.2+0x38d34b)
    #3 0x5607797159f7 in FileInfoWrapper<ASDCP::TimedText::MXFReader, MyTextDescriptor>::file_info(CommandOptions&, char const*, _IO_FILE*) (/mnt/fast/DCP/asdcplib/build-asan/src/asdcp-info+0x269f7)
    #4 0x560779703ffa in show_file_info(CommandOptions&, Kumu::IFileReaderFactory const&) (/mnt/fast/DCP/asdcplib/build-asan/src/asdcp-info+0x14ffa)
    #5 0x560779705652 in main (/mnt/fast/DCP/asdcplib/build-asan/src/asdcp-info+0x16652)
    #6 0x7f438ad0fd09 in __libc_start_main ../csu/libc-start.c:308
    #7 0x560779702859 in _start (/mnt/fast/DCP/asdcplib/build-asan/src/asdcp-info+0x13859)

0x60e0000008c9 is located 9 bytes to the right of 160-byte region [0x60e000000820,0x60e0000008c0)
allocated by thread T0 here:
    #0 0x7f438b7c8647 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
    #1 0x7f438b38ccef in ContainerConstraintsSubDescriptor_Factory(ASDCP::Dictionary const*) (/mnt/fast/DCP/asdcplib/build-asan/src/libasdcp.so.2+0x290cef)
    #2 0x7f438b346f1d in ASDCP::MXF::CreateObject(ASDCP::Dictionary const*, ASDCP::UL const&) (/mnt/fast/DCP/asdcplib/build-asan/src/libasdcp.so.2+0x24af1d)
    #3 0x7f438b33de72 in ASDCP::MXF::OP1aHeader::InitFromBuffer(unsigned char const*, unsigned int) (/mnt/fast/DCP/asdcplib/build-asan/src/libasdcp.so.2+0x241e72)
    #4 0x7f438b33d389 in ASDCP::MXF::OP1aHeader::InitFromFile(Kumu::IFileReader const&) (/mnt/fast/DCP/asdcplib/build-asan/src/libasdcp.so.2+0x241389)
    #5 0x7f438b43c97a in ASDCP::MXF::TrackFileReader<ASDCP::MXF::OP1aHeader, ASDCP::MXF::OPAtomIndexFooter>::OpenMXFRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (/mnt/fast/DCP/asdcplib/build-asan/src/libasdcp.so.2+0x34097a)
    #6 0x7f438b431f6e in ASDCP::h__ASDCPReader::OpenMXFRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (/mnt/fast/DCP/asdcplib/build-asan/src/libasdcp.so.2+0x335f6e)
    #7 0x7f438b487cf6 in ASDCP::TimedText::MXFReader::h__Reader::OpenRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (/mnt/fast/DCP/asdcplib/build-asan/src/libasdcp.so.2+0x38bcf6)
    #8 0x7f438b48934b in ASDCP::TimedText::MXFReader::OpenRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (/mnt/fast/DCP/asdcplib/build-asan/src/libasdcp.so.2+0x38d34b)
    #9 0x5607797159f7 in FileInfoWrapper<ASDCP::TimedText::MXFReader, MyTextDescriptor>::file_info(CommandOptions&, char const*, _IO_FILE*) (/mnt/fast/DCP/asdcplib/build-asan/src/asdcp-info+0x269f7)
    #10 0x560779703ffa in show_file_info(CommandOptions&, Kumu::IFileReaderFactory const&) (/mnt/fast/DCP/asdcplib/build-asan/src/asdcp-info+0x14ffa)
    #11 0x560779705652 in main (/mnt/fast/DCP/asdcplib/build-asan/src/asdcp-info+0x16652)
    #12 0x7f438ad0fd09 in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-buffer-overflow (/mnt/fast/DCP/asdcplib/build-asan/src/libasdcp.so.2+0x38b6ad) in ASDCP::TimedText::MXFReader::h__Reader::MD_to_TimedText_TDesc(ASDCP::TimedText::TimedTextDescriptor&)
Shadow bytes around the buggy address:
  0x0c1c7fff80c0: fd fd fd fd fa fa fa fa fa fa fa fa 00 00 00 00
  0x0c1c7fff80d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff80e0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x0c1c7fff80f0: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa
  0x0c1c7fff8100: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c1c7fff8110: 00 00 00 00 00 00 00 00 fa[fa]fa fa fa fa fa fa
  0x0c1c7fff8120: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c1c7fff8130: fd fd fd fd fa fa fa fa fa fa fa fa 00 00 00 00
  0x0c1c7fff8140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff8150: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c1c7fff8160: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==3302077==ABORTING

POC:
poc.zip

Disclosure Timeline:

Date of Discovery: 26/05/2024
Date Reported to Vendor: 26/05/2024

Acknowledgments:
This vulnerability was discovered and reported by 0xd4n.

Please let me know if you require any further information or assistance.

OpenRead function in as_02_IAB.cpp should be const

as-02-info FileInfoWrapper would need a special method when it is modified to support IAB essence because it relies on OpenRead functions to be const.

The const'ness of OpenRead method is achieved by delegating the implementation of the reading to an internal class (see h__Reader in other implementations).

Apple M1 Silicon Big Sur buiding asdcplib fails

tried to build asdcplib on my mac mini M1 Silicon.

running:

make && sudo make install

I get the following error and output.

ld: symbol(s) not found for architecture arm64
Any help highly appreciated.

[ 50%] Linking CXX shared library libasdcp.dylib
Undefined symbols for architecture arm64:
  "ASDCP::HMACContext::Reset()", referenced from:
      ASDCP::IntegrityPack::CalcValues(ASDCP::FrameBuffer const&, unsigned char const*, unsigned int, ASDCP::HMACContext*) in AS_DCP_MXF.cpp.o
      ASDCP::IntegrityPack::TestValues(ASDCP::FrameBuffer const&, unsigned char const*, unsigned int, ASDCP::HMACContext*) in AS_DCP_MXF.cpp.o
  "ASDCP::HMACContext::Update(unsigned char const*, unsigned int)", referenced from:
      ASDCP::IntegrityPack::CalcValues(ASDCP::FrameBuffer const&, unsigned char const*, unsigned int, ASDCP::HMACContext*) in AS_DCP_MXF.cpp.o
      ASDCP::IntegrityPack::TestValues(ASDCP::FrameBuffer const&, unsigned char const*, unsigned int, ASDCP::HMACContext*) in AS_DCP_MXF.cpp.o
  "ASDCP::HMACContext::Finalize()", referenced from:
      ASDCP::IntegrityPack::CalcValues(ASDCP::FrameBuffer const&, unsigned char const*, unsigned int, ASDCP::HMACContext*) in AS_DCP_MXF.cpp.o
      ASDCP::IntegrityPack::TestValues(ASDCP::FrameBuffer const&, unsigned char const*, unsigned int, ASDCP::HMACContext*) in AS_DCP_MXF.cpp.o
  "ASDCP::AESDecContext::DecryptBlock(unsigned char const*, unsigned char*, unsigned int)", referenced from:
      ASDCP::DecryptFrameBuffer(ASDCP::FrameBuffer const&, ASDCP::FrameBuffer&, ASDCP::AESDecContext*) in AS_DCP_MXF.cpp.o
  "ASDCP::AESDecContext::SetIVec(unsigned char const*)", referenced from:
      ASDCP::DecryptFrameBuffer(ASDCP::FrameBuffer const&, ASDCP::FrameBuffer&, ASDCP::AESDecContext*) in AS_DCP_MXF.cpp.o
  "ASDCP::AESEncContext::EncryptBlock(unsigned char const*, unsigned char*, unsigned int)", referenced from:
      ASDCP::EncryptFrameBuffer(ASDCP::FrameBuffer const&, ASDCP::FrameBuffer&, ASDCP::AESEncContext*) in AS_DCP_MXF.cpp.o
  "ASDCP::HMACContext::GetHMACValue(unsigned char*) const", referenced from:
      ASDCP::IntegrityPack::CalcValues(ASDCP::FrameBuffer const&, unsigned char const*, unsigned int, ASDCP::HMACContext*) in AS_DCP_MXF.cpp.o
      ASDCP::IntegrityPack::TestValues(ASDCP::FrameBuffer const&, unsigned char const*, unsigned int, ASDCP::HMACContext*) in AS_DCP_MXF.cpp.o
  "ASDCP::HMACContext::TestHMACValue(unsigned char const*) const", referenced from:
      ASDCP::IntegrityPack::TestValues(ASDCP::FrameBuffer const&, unsigned char const*, unsigned int, ASDCP::HMACContext*) in AS_DCP_MXF.cpp.o
  "ASDCP::AESEncContext::GetIVec(unsigned char*) const", referenced from:
      ASDCP::EncryptFrameBuffer(ASDCP::FrameBuffer const&, ASDCP::FrameBuffer&, ASDCP::AESEncContext*) in AS_DCP_MXF.cpp.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/libasdcp.2.10.39.dylib] Error 1
make[1]: *** [src/CMakeFiles/libasdcp.dir/all] Error 2
make: *** [all] Error 2

Wrong index frame flags

All index frame falgs are written with value 0x00 for JPEG2000 and ProRes. Value 0x00 is not a valid value for a frame. Correct value is 0x80. See SMPTE ST377-1:2011, table 28, default value.

Compilation error on mac 10.15.2

I got this error when compiling with cmake on macOS Catalina with XCode compiler :

asdcplib/src/MXFTypes.cpp:820:41: error: cannot pass non-POD object of type 'const std::__1::__vector_base<Kumu::ArchivableUi16,
      std::__1::allocator<Kumu::ArchivableUi16> >::value_type' (aka 'const Kumu::ArchivableUi16') to variadic function; expected type from format string was
      'unsigned short' [-Wnon-pod-varargs]
          snprintf(str_buf+(i*3), 4, "%02hx.", Ccap[i]);
                                      ~~~~~    ^~~~~~~

This seems to resolve the issue but not sure if this is the intended output :

-         snprintf(str_buf+(i*3), 4, "%02hx.", Ccap[i]);
+         snprintf(str_buf+(i*3), 4, "%02hx.", Ccap[i].value);

HMAC IntegrityPack failure

Found what appears to be an issue.

Wrap some SMPTE xml into an encrypted mxf:

asdcp-wrap -j 4fe83eac-8834-4653-89c3-b0abcf167c6f -k 3ee9b974d3dcfd5d042f06d879d71fba source/source.xml out.mxf

Unwrap the MXF with 'verify HMAC' option

asdcp-unwrap -m -k 3ee9b974d3dcfd5d042f06d879d71fba out.mxf out/test

which causes:

IntegrityPack failure: sequence is 2, expecting 3.
Program stopped on error.
HMAC authentication failure.

Disabling the '-m' option works fine.

AS_02_IAB OpenWrite conformsToSpec param needs documentation and usage example

In SMPTE ST 2067-201:2019, conformsToSpec Element is defined as required with a value set to

IMF_IABTrackFileLevel0 = urn:smpte:ul:060E2B34.0401010D.01010201.02000000

At the minimum, the function declaration comments must include the definition of this value to ensure the caller does not omit it and creates an invalid IMF IAB track file.

It would also be nice to be able to see a usage of this method in one of the test programs (i.e. as-02-wrap).

As another possibility, this parameter could be removed (no other format exposes this) and its value could be set inside the OpenWrite function to avoid creating an invalid file.

--
/**
* Creates and prepares an IAB Track File for writing.
*
* Must be called following instantiation or after Finalize() call
*
* @param filename Path to the file. The file must no exist.
* @param Info MXF file metadata to be written.
* @param sub IAB Soundfield Subdescritor items to be written. MCATagName, MCATagSymbol, MCALabelDictionaryID, MCALinkID are ignored.
* @param conformsToSpecs Value of the ConformsToSpecifications preface item
* @param edit_rate Frame rate of the IA Bitstream
* @param sampling_rate Sampling rate of the audio essence within the IA Bitstream
*
* @return RESULT_OK indicates that frames are ready to be written,
* otherwise the reader is reset and the file is left is an undermined state.
*/
Result_t OpenWrite(
const std::string& filename,
const ASDCP::WriterInfo& Info,
const ASDCP::MXF::IABSoundfieldLabelSubDescriptor& sub,
const std::vectorASDCP::UL& conformsToSpecs,
const ASDCP::Rational& edit_rate,
const ASDCP::Rational& sampling_rate = ASDCP::SampleRate_48k
);

Separator issue in KM_fileio.cpp and KM_fileio.h on WIndows

Hi,
In my DCP packaging software, I call functions in libasdcp.lib to do wrapping etc.

Whilst MXF wrapping the subtitle assets I ran into a Windows problem in asdcplib. Many of the functions in KM_fileio.cpp define the path separator as ‘/’, for example:

bool PathIsAbsolute(const std::string& Path, char separator = '/'); // true if path begins with separator

The default separator in Windows is ‘\’ so I have had to modify the file KM_fileio.h and change all the separators to '\' for it to work under Windows:

bool PathIsAbsolute(const std::string& Path, char separator = '\\'); // true if path begins with separator std::string PathMakeAbsolute(const std::string& Path, char separator = '\\'); // compute position of relative path using getcwd()

Whilst Windows does not care about whether the separator is a '/' or '\' character, the code in several functions, tests explicitly for the '/' character only. Here's one example:

bool
Kumu::PathIsAbsolute(const std::string& Path, char separator)
{
  if ( Path.empty() )
    return false;

  if ( Path[0] == separator)  //<--- as defined in the header, separator is '/'
    return true;

  return false;
}

This will most likely fail under Windows. The separator '/' character is explicitly being tested for, but under Windows it will most likely be the default '\' character.

I mentioned this back in 2014, and since then I have just been modifying the header file to fix the issue under Windows. So I thought I'd raise this again in case someone wanted to have a look at it.

@jhursty I emailed you on 21/07/2014 at 3:21 PM and I suggested wrapping this around the define KM_WIN32 in your next release, you replied with:

Steve,

That's unexpected. Windows has always been content to have '/' in the path (i.e., either '\' or '/' will do). What version are you using?

And yes, it seems reasonable enough to have the character selected by KM_WIN32. I'll be interested to know more about your experience before committing to this. There may be unpleasant side-effects (e.g., if PathJoin is used to create a URL the result will be incorrect). I will look around to see what may happen...

-jh

I haven't taken this any further due to the potential side-effects @jhursty mentioned.

Anyhow I'm pretty sure this issue still persists, if someone feels like having a play with it!

Cheers,

Steve Q. :-)

CMake Error: variables used, "but they are set to NOTFOUND"

Trying to build using cmake as described in README.cmake. The result is:

$ mkdir build
$ cd build/
$ cmake ..
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Version Number is 2.10.35
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
XercescppLib_Debug_PATH
    linked by target "libkumu" in directory /home/mi/src/asdcplib-master/src
XercescppLib_PATH
    linked by target "libkumu" in directory /home/mi/src/asdcplib-master/src
XercescppLib_include_DIR
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src
   used as include directory in directory /home/mi/src/asdcplib-master/src

-- Configuring incomplete, errors occurred!
See also "/home/mi/src/asdcplib-master/build/CMakeFiles/CMakeOutput.log".

This is on Ubuntu 16.04, using cmake version 3.5.1.

Maybe it's just the instructions in the readme which are incomplete?

Attached is the full src/asdcplib-master/build/CMakeFiles/CMakeOutput.log file.
CMakeOutput.log

Compilation fails on broken optional_container_property template with latest Clang

Since llvm/llvm-project#84050 and llvm/llvm-project#90152, Clang will issue diagnostics about invalid member accesses in a class template, even before the class is instantiated.

This uncovers an issue in asdcplib, which ends up in compile errors like these:

In file included from asdcplib/src/TimedText_Parser.cpp:33:
In file included from asdcplib/src/AS_DCP_internal.h:38:
In file included from asdcplib/src/Metadata.h:35:
asdcplib/src/MXF.h:276:12: error: no member named 'Copy' in 'optional_container_property<PropertyType>'
  276 |             this->Copy(rhs.m_property);
      |             ~~~~  ^
asdcplib/src/MXF.h:284:48: error: no member named 'clear' in 'optional_container_property<PropertyType>'
  284 |           void reset(const PropertyType& rhs) { this->clear(); }
      |                                                 ~~~~  ^
2 errors generated.

The relevant code at hand looks like this:

      // wrapper object manages optional properties
      template <class PropertyType>
        class optional_container_property
        { 
          PropertyType m_property;
          
        public:
          optional_container_property() {}
        optional_container_property(const PropertyType& value) : m_property(value) {}     
          const optional_container_property<PropertyType>& operator=(const PropertyType& rhs) {
            this->Copy(rhs.m_property);
            return *this;
          }
          
          bool operator==(const PropertyType& rhs) const { return this->m_property == rhs; }
          bool operator==(const optional_property<PropertyType>& rhs) const { return this->m_property == rhs.m_property; }
          operator PropertyType&() { return this->m_property; }
          void set(const PropertyType& rhs) { this->m_property = rhs; }
          void reset(const PropertyType& rhs) { this->clear(); }
          bool empty() const { return ! this->m_property.HasValue(); }
          PropertyType& get() { return m_property; }
          const PropertyType& const_get() const { return m_property; }
        };

https://github.com/cinecert/asdcplib/blob/master/src/MXF.h#L266-L288

The this->Copy() and this->clear() method calls do look like a valid error as there are no such members defined here. This hasn't been an issue before as this class doesn't seem to be actually used anywhere.

I can make a PR to just outright remove this unused template class, to fix compilation that way, but would you have a preference to fix the code differently somehow? This code seems to stem from 0291582, and does seem to have the same references to nonexistent members even back then.

Bitrate per component

Hello,

We can easily get the maximum bitrate with the asdcp-info -r options but can we get the max bitrate per color component ?

As the smpte:
For a frame rate of 24 FPS, a 2K distribution shall have a maximum of 1,302,083 bytes per frame
(aggregate of all three color components including headers). Additionally, it shall have a maximum
of 1,041,666 bytes per color component per frame including all relevant tile-part headers.

As I understand, we can test with your tool the overall bitrate but not the "per color". Is that right? Are you planning to add that feature?

Best regards

RuntimeError exception should not be used in as_02_IAB.cpp

Except for a couple of functions that do not return Result_t all other functions do and it does not make any sense to have statements like this one

if (result.Failure()) {
throw Kumu::RuntimeError(result);
}
when all that is required is to just return result;

Such functions like OP1Header() and RIP() could return empty respective structures in case of invalid state. If it is better to detect error state and interrupt processing, these functions could be converted to the following signatures:

From:

virtual const ASDCP::MXF::RIP& RIP() const;
virtual const ASDCP::MXF::OP1aHeader& OP1aHeader() const;

To:

virtual Result_t RIP(ASDCP::MXF::RIP&) const;
virtual Result_t OP1aHeader(ASDCP::MXF::OP1aHeader&) const;

Otherwise, RuntimeError should not use used.

Improve handling of parameterizable ULs

The bytes of some ULs, e.g. MDD_IMF_IABEssenceClipWrappedElement, depend on the ultimate on the contents of the file they are written to.

  • It would be good to have a way to set these bytes in ULs in a systematic way instead of using array subscripts; That makes is a supported library functionality

  • There will be an issue comparing the UL found in the MXF files back with the MDD table definitions. This happens in as-02-info and klv-walk where the ULs are turned into printable strings for human consumption.

See #64 (comment)

General Parsing Crashes

Hi, we are implementing IMF IAB support in asdcp library and we ran American Fuzzy Lop on our parser that includes a version of asdcp. Though our code is based on an older version of the library, I confirmed that the issues we found still exist in later versions of the library.

We identified crashes in these areas:

  1. m_RIP.PairArray.front() is referenced in h_02_Reader.cpp and h__Reader.cpp without checking if it's empty.
  2. KLVPacket::InitFromBuffer() function can set m_ValueLength to extend past the length of the input buffer causing exceptions during parsing. Some of the places where this is an issue:
  • InterchangeObject::InitFromBuffer
  • Primer::InitFromBuffer
  • RIP::InitFromFile
  1. CreateObject function uses exact UL match when looking up Factory methods. But GetMDObjectByType ignores UL index 7 when performing comparison (see UL::operator==). This causes a crash in InitInfo() when we perform static cast in order to call MD_to_WriterInfo().

I am not too savvy with git to know how to create a branch in which I can submit the fixes to the above issues.

Please let me know if you would like me to do that.

Question: Install trouble...

MacOS 12, at this step :/

→ make install
Making install in src
/bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -o asdcp-util asdcp-util.o libasdcp.la libkumu.la -lpthread
libtool: link: g++ -g -O2 -o .libs/asdcp-util asdcp-util.o -Wl,-bind_at_load ./.libs/libasdcp.dylib -L/usr/local/opt/openssl@3/lib /Users/mau/Desktop/asdcplib/asdcplib-rel_2_10_35/src/.libs/libkumu.dylib ./.libs/libkumu.dylib -lpthread
Undefined symbols for architecture x86_64:
"_SHA1_Final", referenced from:
digest_file(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) in asdcp-util.o
"_SHA1_Init", referenced from:
digest_file(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) in asdcp-util.o
"_SHA1_Update", referenced from:
digest_file(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) in asdcp-util.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [asdcp-util] Error 1
make: *** [install-recursive] Error 1

Null Pointer Dereference in ASDCP::KLVFilePacket::InitFromFile Function

Description:

A null pointer dereference vulnerability has been identified in the ASDCP::KLVFilePacket::InitFromFile function of the asdcplib library. 
The vulnerability arises from a lack of proper validation of the mxf input file, which allows a null pointer to be dereferenced. 
This results in a segmentation fault, causing a potential denial of service (DoS).

Affected Software:

Software: asdcplib
Version: 2.13.1
Operating System: Debian 11
Kernel: Linux debian 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64 GNU/Linux

Steps to Reproduce:

Build the affected software (asdcplib) after enabling AddressSanitizer.
Execute any of the affected binaries (asdcp-info, asdcp-unwrap) with provided poc that triggers the vulnerable code path.
Observe the AddressSanitizer report indicating a null pointer dereference error.

Valgrind output:

==413847== Memcheck, a memory error detector
==413847== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==413847== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==413847== Command: ./asdcp-info ../../../ASDCP-WRITE.mxf
==413847== 
==413847== Invalid write of size 8
==413847==    at 0x4919BE8: ASDCP::KLVFilePacket::InitFromFile(Kumu::IFileReader const&) (src/KLV.cpp:245)
==413847==    by 0x4919970: ASDCP::KLVFilePacket::InitFromFile(Kumu::IFileReader const&, ASDCP::UL const&) (src/KLV.cpp:193)
==413847==    by 0x49227A1: ASDCP::MXF::RIP::InitFromFile(Kumu::IFileReader const&) (src/MXF.cpp:124)
==413847==    by 0x4981DFC: ASDCP::MXF::TrackFileReader<ASDCP::MXF::OP1aHeader, ASDCP::MXF::OPAtomIndexFooter>::OpenMXFRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (src/AS_DCP_internal.h:253)
==413847==    by 0x4981722: ASDCP::h__ASDCPReader::OpenMXFRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (src/h__Reader.cpp:75)
==413847==    by 0x49972F0: ASDCP::PCM::MXFReader::h__Reader::OpenRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (src/AS_DCP_PCM.cpp:269)
==413847==    by 0x49981A8: ASDCP::PCM::MXFReader::OpenRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (src/AS_DCP_PCM.cpp:435)
==413847==    by 0x432AF2: FileInfoWrapper<ASDCP::PCM::MXFReader, MyAudioDescriptor>::file_info(CommandOptions&, char const*, _IO_FILE*) (src/asdcp-info.cpp:323)
==413847==    by 0x4306B9: show_file_info(CommandOptions&, Kumu::IFileReaderFactory const&) (src/asdcp-info.cpp:554)
==413847==    by 0x4365DF: main (src/asdcp-info.cpp:703)
==413847==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==413847== 
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==413847==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000004919be8 bp 0x000000000015 sp 0x001ffefff220 T413847)
==413847==The signal is caused by a WRITE memory access.
==413847==Hint: address points to the zero page.
==414057== Warning: invalid file descriptor 1024 in syscall close()
    #0 0x4919be8 in ASDCP::KLVFilePacket::InitFromFile(Kumu::IFileReader const&) /mnt/data/DCP/asdcplib/src/KLV.cpp:245:11
    #1 0x4919970 in ASDCP::KLVFilePacket::InitFromFile(Kumu::IFileReader const&, ASDCP::UL const&) /mnt/data/DCP/asdcplib/src/KLV.cpp:193:36
    #2 0x49227a1 in ASDCP::MXF::RIP::InitFromFile(Kumu::IFileReader const&) /mnt/data/DCP/asdcplib/src/MXF.cpp:124:36
    #3 0x4981dfc in ASDCP::MXF::TrackFileReader<ASDCP::MXF::OP1aHeader, ASDCP::MXF::OPAtomIndexFooter>::OpenMXFRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /mnt/data/DCP/asdcplib/src/AS_DCP_internal.h:253:26
    #4 0x4981722 in ASDCP::h__ASDCPReader::OpenMXFRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /mnt/data/DCP/asdcplib/src/h__Reader.cpp:75:81
    #5 0x49972f0 in ASDCP::PCM::MXFReader::h__Reader::OpenRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /mnt/data/DCP/asdcplib/src/AS_DCP_PCM.cpp:269:21
    #6 0x49981a8 in ASDCP::PCM::MXFReader::OpenRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const /mnt/data/DCP/asdcplib/src/AS_DCP_PCM.cpp:435:20
    #7 0x432af2 in FileInfoWrapper<ASDCP::PCM::MXFReader, MyAudioDescriptor>::file_info(CommandOptions&, char const*, _IO_FILE*) /mnt/data/DCP/asdcplib/src/asdcp-info.cpp:323:23
    #8 0x4306b9 in show_file_info(CommandOptions&, Kumu::IFileReaderFactory const&) /mnt/data/DCP/asdcplib/src/asdcp-info.cpp:554:24
    #9 0x4365df in main /mnt/data/DCP/asdcplib/src/asdcp-info.cpp:703:16
    #10 0x5145d09 in __libc_start_main csu/../csu/libc-start.c:308:16
    #11 0x40e659 in _start (/mnt/fast/DCP/asdcplib/build/src/asdcp-info+0x40e659)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV /mnt/data/DCP/asdcplib/src/KLV.cpp:245:11 in ASDCP::KLVFilePacket::InitFromFile(Kumu::IFileReader const&)
==413847==ABORTING
==413847== 
==413847== HEAP SUMMARY:
==413847==     in use at exit: 378,926 bytes in 5,927 blocks
==413847==   total heap usage: 8,877 allocs, 2,950 frees, 581,139 bytes allocated
==413847== 
==413847== LEAK SUMMARY:
==413847==    definitely lost: 0 bytes in 0 blocks
==413847==    indirectly lost: 0 bytes in 0 blocks
==413847==      possibly lost: 0 bytes in 0 blocks
==413847==    still reachable: 378,926 bytes in 5,927 blocks
==413847==         suppressed: 0 bytes in 0 blocks
==413847== Rerun with --leak-check=full to see details of leaked memory
==413847== 
==413847== For lists of detected and suppressed errors, rerun with: -s
==413847== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)

POC:
poc.zip

Disclosure Timeline:

Date of Discovery: 31/05/2024
Date Reported to Vendor: 31/05/2024

Acknowledgments:
This vulnerability was discovered and reported by 0xd4n10.

Please let me know if you require any further information or assistance.

Mastering Display Color Volume Metadata is not supported

Mastering Display Color Volume Metadata, as specified in ST 2067-21, Annex B is not supported.

060e2b34.0101010e.04200401.01040000 GenericPictureEssenceDescriptor_MasteringDisplayMinimumLuminance
060e2b34.0101010e.04200401.01030000 GenericPictureEssenceDescriptor_MasteringDisplayMaximumLuminance
060e2b34.0101010e.04200401.01020000 GenericPictureEssenceDescriptor_MasteringDisplayWhitePointChromaticity
060e2b34.0101010e.04200401.01010000 GenericPictureEssenceDescriptor_MasteringDisplayPrimaries

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.