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

debug/pe: ImportedSymbols returns no symbols #16103

Closed
alexbrainman opened this issue Jun 18, 2016 · 8 comments
Closed

debug/pe: ImportedSymbols returns no symbols #16103

alexbrainman opened this issue Jun 18, 2016 · 8 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@alexbrainman
Copy link
Member

Running this program:

package main

import (
    "debug/pe"
    "fmt"
    "os"
)

func main() {
    for _, v := range os.Args[1:] {
        f, err := pe.Open(v)
        if err != nil {
            fmt.Fprintf(os.Stderr, "can not create PE structure for %s: %v\n", v, err)
            continue
        }
        defer f.Close()

        libs, err := f.ImportedSymbols()
        if err != nil {
            fmt.Fprintf(os.Stderr, "can not get imported symbols: %v\n", err)
            continue
        }
        for _, v := range libs {
            fmt.Printf("%s\n", v)
        }
    }
}

with PsService.zip file as argument, lists no imported dlls / functions. But it should:

$ objdump -x PsService.exe | sed '/The Import Tables/,$!d' | head
The Import Tables (interpreted .rdata section contents)
 vma:            Hint    Time      Forward  DLL       First
                 Table   Stamp     Chain    Name      Thunk
 00026aa4       00026e18 00000000 00000000 00026e7e 000202ac

        DLL Name: VERSION.dll
        vma:  Hint/Ord Member-Name Bound-To
        26e4e       0  GetFileVersionInfoA
        26e64       3  GetFileVersionInfoSizeA
        26e3c      13  VerQueryValueA
$

The reason for this is because debug/pe assumes that imported symbols live in section named ".idata", but it is not always true (as you can see from objdump output). We should use PE "The Data Directory" to determine location of imported info.

Alex

@quentinmit quentinmit added this to the Go1.8 milestone Jun 20, 2016
@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Jun 20, 2016
@rsc rsc modified the milestones: Go1.9, Go1.8 Nov 3, 2016
@mewmew
Copy link
Contributor

mewmew commented Apr 28, 2017

I would be happy to prepare a CL for this, if you haven't started already @alexbrainman.

@alexbrainman
Copy link
Member Author

I would be happy to prepare a CL for this, if you haven't started already @alexbrainman.
👍 1

Please go ahead, if you like. I am fighting with symlinks at this moment :-).
Just a warning - I suspect for this CL we would have to introduce some new exported from debug/pe bits. go1.9 freeze starts soon, so we have very little time to get new exported bits right.

Alex

@mewmew
Copy link
Contributor

mewmew commented Apr 30, 2017

Hi Alex,

Thanks for the heads up. I'll try to tackle it sometime next week. Good luck in your battle with the symlinks : )

Cheers /u

@bradfitz
Copy link
Contributor

bradfitz commented Jun 7, 2017

@mewmew, any update?

@alexbrainman, can you remilestone this to Go 1.10 if this isn't important for Go 1.9? You decide.

@mewmew
Copy link
Contributor

mewmew commented Jun 7, 2017

@mewmew, any update?

I have this mostly working in a local PE parser, which may be cleaned up and adapted for inclusion to the debug/pe package timed for the 1.10 release.

I will try to prepare a CL within the following month.

Cheers /u

@bradfitz bradfitz modified the milestones: Go1.10, Go1.9 Jun 7, 2017
@alexbrainman
Copy link
Member Author

@alexbrainman, can you remilestone this to Go 1.10 if this isn't important for Go 1.9?

You already remilestoned it yourself. Thank you, Brad.

Alex

@rsc rsc modified the milestones: Go1.10, Go1.11 Nov 22, 2017
@gopherbot
Copy link

Change https://golang.org/cl/110555 mentions this issue: debug/pe: parse the import directory correctly

@gopherbot
Copy link

Change https://golang.org/cl/151480 mentions this issue: debug/pe: use ws2_32.dll in TestImportTableInUnknownSection

gopherbot pushed a commit that referenced this issue Nov 29, 2018
Apparently (see
#27904 (comment)
for details) kernel32.dll file is not present on windows/arm, so
use ws2_32.dll instead. ws2_32.dll imports table also lives in
'.rdata' section, so ws2_32.dll is as good as kernel32.dll for
testing issue #16103.

Updates #27904

Change-Id: Ibc72b24eea9a4d85abd371ffdcf00442e711b745
Reviewed-on: https://go-review.googlesource.com/c/151480
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
@golang golang locked and limited conversation to collaborators Nov 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants