I first found the Linux command:
$ nm
4. I tried running the Docker image and getting a terminal to interact with the built object.
I used the command
$ docker run --entrypoint /bin/sh -it sha256:c2dc7194677d97676e...
It did not work, `/bin/sh` was missing from the image. Upon investigating the Dockerfile, I saw that this image was built from scratch. Good security, bad for my debugging purposes.
5. I built a new Docker image.
I knew where the path was in the original image, so I wanted to build a new image based on a Docker image having tools to debug. I used the go base image, and copied over the file in the new Dockerfile:
FROM golang:1.21
COPY --from=${ORIGINAL_IMAGE}:${VERSION} ${ORIGINAL_EXECUTABLE_PATH} ${TARGET_PATH}
CMD ["go","tool","nm","${TARGET_PATH}"]
I the built and ran the image.
$ docker build ...
$ docker run ...
No response.
6. I exec-ed into the Docker container.
I used the following command to exec into the newly built image's container:
$ docker run --entrypoint /bin/sh -it sha256:c2dc7194677d97676e...
7. I used the nm command.
$ nm ${TARGET_PATH}
nm: ${TARGET_PATH}: no symbols
Then
$ nm -D ${TARGET_PATH}
nm: ${TARGET_PATH}: no symbols
8. As this did not help me, I looked further and found that Go has its own version.
$ go tools nm
But this did not give me what I needed either.
9. Finally, I found a StackOverflow entry and executed the strings command from it, which literally looks at the strings in a file.
$ strings ${TARGET_PATH} | grep "${VARIABLE_NAME}"
This command finally returned the sensitive values I needed, and I could move on with testing the feature in my local environment.
Normally, I would advise that you ask your colleagues instead of investigating on your own, but you might find yourself in the same trouble as I did. It was still a fun exercise, and it was nice learning about the linker, flags, and the different commands you can use to investigate an executable.