Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fileinfo crashes during reconstruction of .NET types #458

Closed
s3rvac opened this issue Jan 7, 2019 · 4 comments
Closed

fileinfo crashes during reconstruction of .NET types #458

s3rvac opened this issue Jan 7, 2019 · 4 comments

Comments

@s3rvac
Copy link
Member

s3rvac commented Jan 7, 2019

fileinfo crashes during reconstruction of .NET types in the PE binary below.

Input

Run

$ retdec-fileinfo FILE

where FILE is:

Output

Segmentation fault

Expected output

fileinfo does not crash when analyzing the file.

Output from valgrind

==16969== Invalid read of size 8
==16969==    at 0x2DBA3C: std::vector<retdec::fileformat::AssemblyRef, std::allocator<retdec::fileformat::AssemblyRef> >::size() const (stl_vector.h:806)
==16969==    by 0x2D835E: retdec::fileformat::MetadataTable<retdec::fileformat::AssemblyRef>::getRow(unsigned long) const (metadata_table.h:98)
==16969==    by 0x382320: retdec::fileformat::DotnetTypeReconstructor::createClassReference(retdec::fileformat::TypeRef const*, unsigned long) (dotnet_type_reconstructor.cpp:843)
==16969==    by 0x3802D1: retdec::fileformat::DotnetTypeReconstructor::reconstructClasses() (dotnet_type_reconstructor.cpp:401)
==16969==    by 0x37F853: retdec::fileformat::DotnetTypeReconstructor::reconstruct() (dotnet_type_reconstructor.cpp:227)
==16969==    by 0x2C588B: retdec::fileformat::PeFormat::detectDotnetTypes() (pe_format.cpp:1895)
==16969==    by 0x2C3151: retdec::fileformat::PeFormat::loadDotnetHeaders() (pe_format.cpp:1259)
==16969==    by 0x2BE54D: retdec::fileformat::PeFormat::initStructures() (pe_format.cpp:403)
==16969==    by 0x2BDC93: retdec::fileformat::PeFormat::PeFormat(...) (pe_format.cpp:297)
==16969==    by 0x225ADA: fileinfo::PeWrapper::PeWrapper(...) (pe_wrapper.cpp:96)
==16969==    by 0x19C9D4: void __gnu_cxx::new_allocator<fileinfo::PeWrapper>::construct<...>(..) (new_allocator.h:136)
==16969==    by 0x19C893: void std::allocator_traits<...>::construct<...>(...) (alloc_traits.h:475)
==16969==  Address 0x18 is not stack'd, malloc'd or (recently) free'd

Configuration

  • Commit: bfd6efb (current master)
  • 64b Arch Linux, GCC 8.2.1, Debug build of RetDec
@s3rvac
Copy link
Member Author

s3rvac commented Feb 7, 2019

I have analyzed this. In src/fileformat/types/dotnet_types/dotnet_type_reconstructor.cpp, there is the following piece of code:

842         auto assemblyRefTable = static_cast<const MetadataTable<AssemblyRef>*>(metadataStream->getMetadataTable(MetadataTableType::AssemblyRef));
843         auto assemblyRef = assemblyRefTable->getRow(typeRef->resolutionScope.getIndex());

The problem is that when analyzing the reported files, assemblyRefTable on line 842 is the null pointer, and so the call to assemblyRefTable->getRow() segfaults due to a null pointer access.

@metthal Would returning nullptr from DotnetTypeReconstructor::createClassReference() when assemblyRefTable is nullptr be the correct fix here or is something wrong at an earlier place?

@metthal
Copy link
Member

metthal commented Feb 7, 2019

Yes, returning nullptr when assemblyRefTable is nullptr should be valid fix. That situation when TypeRef records refers to AssemblyRef table while AssemblyRef table is missing shouldn't really happen so something must be wrong with those files.

@JakubPruzinec could you please verify since you are author of this code? Would it for example make sense to set classLibName to empty string?

@JakubPruzinec
Copy link
Contributor

Thx for letting me know. Indeed, the check was missing.
#511

@s3rvac
Copy link
Member Author

s3rvac commented Feb 28, 2019

Fixed by @JakubPruzinec in #511.

@s3rvac s3rvac closed this as completed Feb 28, 2019
s3rvac added a commit that referenced this issue Feb 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants