BBC BASIC Programmers' Reference

User Tools

Site Tools

Trace:
hiding_20confidential_20data

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
hiding_20confidential_20data [2018/03/31 13:19] – external edit 127.0.0.1hiding_20confidential_20data [2024/01/05 00:22] (current) – external edit 127.0.0.1
Line 11: Line 11:
   * Delete the files immediately after use. For example if you have one or more library modules that are loaded with **INSTALL**, you can delete them from the disk immediately afterwards. Using that technique the files will be present on the disk, and therefore vulnerable to being read, for the shortest possible time. The code below deletes the file only when the compiled program is run; when running under the IDE it doesn't, to avoid destroying the original:   * Delete the files immediately after use. For example if you have one or more library modules that are loaded with **INSTALL**, you can delete them from the disk immediately afterwards. Using that technique the files will be present on the disk, and therefore vulnerable to being read, for the shortest possible time. The code below deletes the file only when the compiled program is run; when running under the IDE it doesn't, to avoid destroying the original:
 \\  \\ 
 +<code bb4w>
         INSTALL @lib$+"MYMODULE"         INSTALL @lib$+"MYMODULE"
         IF INSTR(@lib$,@tmp$) OSCLI "DELETE """+@lib$+"MYMODULE"""         IF INSTR(@lib$,@tmp$) OSCLI "DELETE """+@lib$+"MYMODULE"""
 +</code>
 If none of these techniques provides adequate protection, consider incorporating the most sensitive code within your main program rather than in resource files. The main program is copied directly from the executable into memory and doesn't at any point exist as an unencrypted file on the local disk, however it is still vulnerable to a **memory dump** attack.\\ \\  If you are concerned about **memory dump** attacks, contact me for a copy of **secure.exe** which is a utility that can effectively protect compiled BB4W executables from such attacks. If none of these techniques provides adequate protection, consider incorporating the most sensitive code within your main program rather than in resource files. The main program is copied directly from the executable into memory and doesn't at any point exist as an unencrypted file on the local disk, however it is still vulnerable to a **memory dump** attack.\\ \\  If you are concerned about **memory dump** attacks, contact me for a copy of **secure.exe** which is a utility that can effectively protect compiled BB4W executables from such attacks.
hiding_20confidential_20data.1522502364.txt.gz · Last modified: 2024/01/05 00:17 (external edit)