Decoding a whole project: folders, bulk uploads and the API

A thousand encoded files across nested folders is a different job from one file. How to upload a tree, keep its structure, and script the whole thing.

Decoding one file is a form upload. Decoding an application is a different problem: a thousand files spread across nested folders, where the folder each file came from is part of the information you are trying to recover.

Upload the tree, not the files

Drag a folder onto the dashboard, or use the folder picker, and the structure travels with it. A file that lived at app/Models/User.php comes back at app/Models/User.php — which matters enormously when you are trying to drop recovered source back into a working checkout.

Large trees are sent in batches automatically, so a folder of several hundred files is one action rather than fifty. Watch the counter on the upload area for progress.

Decide what to send before you send it

Not every file in a project needs decoding, and sending fewer files costs less.

  • Skip files that were never encoded. Vendors typically encode their own business logic and leave templates, CSS and third-party libraries in plain text. Those cost a credit each for nothing.
  • Skip vendor/. Composer dependencies can be reinstalled from source; there is no reason to decode them.
  • Strip credentials. Config files with live passwords should be handled separately, if at all — see what happens to uploaded files.

A quick way to find only the encoded files on a server:

grep -rl "ionCube" --include="*.php" . > encoded-files.txt
wc -l encoded-files.txt

Getting the results back with structure intact

Download a whole folder as a ZIP from the folder row, and the archive mirrors the tree — extract it and the layout is the one you uploaded. You can also select individual files across different folders; their full paths are preserved either way, so nothing lands in a flat heap.

Scripting it with the API

For anything recurring — a migration, a CI step, a batch you will repeat — the REST API does the same work without a browser. Create a token in your account, then:

curl -X POST https://decryptioncube.com/api/v1/decode \
     -H "Authorization: Bearer $DECRYPTIONCUBE_TOKEN" \
     -F "[email protected]"

Poll the job until it reports ready, then fetch the result. The API charges the same credits, honours the same retention settings, and refuses the same things the web interface refuses.

The CLI

There is also a zero-dependency command-line tool that walks a folder, submits everything, waits, and writes results next to the originals:

export DECRYPTIONCUBE_TOKEN=dcx_your_token_here
node decryptioncube.mjs ./src --out ./decoded

It exits non-zero if any file failed, so it slots into CI without extra glue.

How long a large job takes

Files are processed continuously rather than strictly in the order they arrived, and work is shared between customers — so a large upload does not park itself in front of everyone else's queue, and someone else's large upload does not park in front of yours. A big project decodes steadily rather than all at once.

Decoding time depends on the file, not the clock: a small class finishes in seconds, a large one can take considerably longer. The CLI waits and reports rather than giving up on a slow file.

Budgeting the job

One file is one credit, and failed decodes are refunded automatically, so a partial run never quietly burns your balance. Count the encoded files first with the grep above, then pick a pack from the pricing page — larger packs bring the per-file price down, which is worth doing before a thousand-file project rather than after.

Try DecryptionCube.com free
Decode one sample file, no account needed.
Open demo
Related articles