search

0xrawsec / golang-evtx

GNU General Public License v3.0
158 stars 27 forks source link

panic: interface conversion: evtx.Element is *evtx.BinXMLEOF, not *evtx.Fragment #6

Open phaag opened 6 years ago

phaag commented 6 years ago

While working with golang-evtx as a library I was faced with a panic:

panic: interface conversion: evtx.Element is *evtx.BinXMLEOF, not *evtx.Fragment

goroutine 824 [running]:
github.com/0xrawsec/golang-evtx/evtx.Event.GoEvtxMap(0xb3e8, 0x18800002a2a, 0x499, 0x1d2df942e928695, 0xc4202bd280, 0x1d2df942e928695, 0x0, 0x0)
        /opt/golang/src/github.com/0xrawsec/golang-evtx/evtx/event.go:77 +0x321
github.com/0xrawsec/golang-evtx/evtx.(*Chunk).Events.func1(0xc420284000, 0xc4202bd280)
        /opt/golang/src/github.com/0xrawsec/golang-evtx/evtx/chunk.go:249 +0x11d
created by github.com/0xrawsec/golang-evtx/evtx.(*Chunk).Events
        /opt/golang/src/github.com/0xrawsec/golang-evtx/evtx/chunk.go:244 +0x97

Input is an evtx file on a Win7 system: Microsoft-Windows-ReadyBoost%4Operational.evtx. Unfortunately I can not share the file for privacy reason.

Looking into the code, I see, that you deliberately panic if it's not a evtx.Fragment. Is there a possibility to implement this element, as evtx.BinXMLEOF is already defined in structs.go. Sure - I could use carve mode, but then I loose this content.

Many thanks for providing a parser for evtx files in Go.

qjerome commented 6 years ago

Hi,

I have looked at your issue and it seems that it is located in a part of the code which is not very flexible to change. In fact, it is pretty unusual (and maybe invalid) to have a BinXMLEOF instead of a Fragment. Do you have reasons to think that your file is corrupted (live acquisition, damaged hard disk ...)? Actually, I don't want to patch if I am not sure that the issue is the code and not the file.

Cheers,

phaag commented 6 years ago

It was most likely a live acquisition, however, the question is, if it would be possible to cleanly handle this situation. LIve acquisitions are not uncommon, the file and the file is not damaged. Furthermore, if the code is integrated as a library, it crashes the whole application. Thanks