Expo separates shipped values from build server values
An Expo app carries a configuration layer that decides what reaches the package. That layer separates two kinds of value. A value the JavaScript reads at run time has to exist in the app in some form. A value that only the build server used, such as a distribution credential or a store upload key, never becomes part of the artifact you are given. Extraction is therefore a question about which category a key belongs to.
The useful consequence is that the answer usually lies in the JavaScript bundle, because any value the app sends to an HTTP call has to exist on the device.
Public build time values end up inside the bundle
Expo inlines environment values that carry the public prefix into the JavaScript as the bundle is produced. The prefix is the documented signal that a value is meant to ship, and the substitution happens at build time, so the value appears in the bundle as a literal. A string search of the extracted bundle returns it directly and no runtime work is needed.
Configuration declared in the app manifest behaves the same way through the extra field. Values placed there are carried into the app and are readable from the app's own configuration object while it runs, which means they are also readable from the package.
- A shipped key is a string in the bundle. Search the bundle for the value or for the variable name and expect a literal.
- A shipped configuration value is in the manifest the runtime reads. The same value reaches the app through its configuration object, so it exists in the package rather than only on the build machine.
- A build server credential is not in the package. Credentials used to sign or upload the app never reach the device, and no extraction will find them.
Third party keys arrive through native configuration
Some keys belong to a service the native side initialises, and the build stores them the way any Android app stores them: in a resource file, in manifest metadata, or in a service-specific configuration file placed in the package. They ship by design, because the SDK on the device reads them at startup, and the ordinary resource and manifest reading that applies to any APK finds them.
Where the bundle sits in an Expo package
Locate the bundle before searching it. In a release build it is packaged as an asset, it is among the largest files in the package, and its name follows the build output rather than the source tree, so size is the more dependable signal. The app manifest also names the update configuration the runtime uses, and that entry is worth reading first because it tells you whether the packaged bundle is the only code the app can run.
Which copy of the bundle is the running one
An Expo app can receive updated JavaScript from an update service, so the bundle in the installed APK is the first one the device had and not necessarily the one it runs. Pull the current bundle from the app's data directory on the device, and read the update configuration in the package to see where it came from. A key rotated after the APK was built appears only in the newer bundle, which is why reading the packaged copy alone gives a stale answer.
What to do once the keys are out
A key on its own rarely makes a working client. The request also carries a session, a set of headers and often a value computed for that call, and the server may check all of them together. Treat the key as one recovered input and continue with the request construction in the bundle, which is where the endpoint list and the header logic live.
Confirm a recovered key by using it. A key that authenticates one request against the endpoint is real, and a key the server ignores costs nothing to discover. That test is cheaper and more conclusive than reasoning about where the value came from.
Work of this kind is delivered as a Python, JavaScript or TypeScript client with an importable Postman collection and documentation, starting at $120, and most projects finish in 24 to 72 hours.
Related work
Reviewed 28 September 2026 · SReverse research desk