Jump to content

Understanding the HIDE_PAYLOAD command


Go to solution Solved by dark_pyrro,

Recommended Posts

 At power on, duc reads inject.bin and stores in the Atmel uC RAM. The script is executed (or interpreted) from RAM. The DELAY 2000 command what is in the initalisation of nearly all script examples, waits for HID enumeration. After this, it is possible to communicate by script with target PC over HID device.

 Assume any script uses the HIDE_PAYLOAD command in the initialisation. This will erase inject.bin from SD card file system while the copy in RAM is executed further. Inject.bin script is normaly designed to enter infinite loop executing payloads like intended. It is in the responsibility of the user script, to lock into a stalled state in situations like „job done“ or „wrong use“ or „unauthorized input“. Locked state means, the script is simply doing nothing more.

 If script is stalled like this and there is no exit to RESTORE_PAYLOAD command triggered by button or any other means, the script ist still available in RAM but it will be very hard to retrieve, disassemble or restart.

 In case of power off, the script (and its possible parts of its secret login credentials) are pyhsically erased from RAM. Duc will never return to its scripted functionality with next power up as it canot find the inject.bin file. Ordinary method to restore the duc functionality by authorized user is to store a new copy of inject.bin to the SD card and restart the script by power up and enumeration.

Users have to consider, that the duc scirpt functions also stop working in case of accidential power loss.

On the other hand, inject.bin could be probably retrieved (including its possible secret login credentials) using external card reader with tools to access the SD FAT file system.

Can anybody confirm, if delete of inject.bin by HIDE_PAYLOAD is secure or not (only deleted in the FAT directory) ?

 

 

 

Link to comment
Share on other sites

  • Solution

Not really sure why all that text was needed to ask that question, but, anyway...

What is the definition of "secure" in this case? Non recoverable? If that is the definition, then no. Although it depends. Using some kind of file recovery software will most likely find the inject.bin file and be able to restore it.

However, after successfully restoring the file comes the next thing, trying to "reverse engineer" the inject.bin file to readable plain text code which probably will be a challenge for most people.

Link to comment
Share on other sites

so many text as I have not tried the HIDE_PAYLOAD myself before posting. Its only a try to understand the instruction myself.

Restoring inject.bin will not require to disassemble the code as you can simply run it an try out what it is doing. Writing 00 or FF for the inject.bin filesize will make the erase  "secure".

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...