Passwords (not USR02!)

[Jessy5246]

Hi everyone:
I have a general question, which came up in one of Frank's postings. If I have a password or key (e.g., for FTP logon in RSFTP002), which is required in plaintext, I can store it encrypted. But in order to use it, I will have to decrypt it, which means in an open source like ABAP anyone with debug rights can stop at the right line after retrieving and decrypting it, and find out what it is.

While I know that you cannot debug macros, I will need to call a routine / program / function module that does its thing. Single-stepping into the macro would take me there. Can you think of any way to a) store a password and b) use it without compromising it? I would like not to use the 'hide source code' option...

Regards,
Wolfgang

[Ilja583]

Hi Wolfgang,


I am still not sure which rights spy has. If he has "only" debugging-rights I guess the following idea might help you. If he can change your macros then you can't do anything about it if the whole thing should run w/o any user-assistence.

ad a - like you alread suggested: Save the pw in an encrypted form and do the decrypting in the macro.

ad b - Using the pw without compromising it:
Store the decrypted pw in a variable that is not accessible at debuggingtime and never use a copy of the pw, just references to the pw.
For storing the pw I would suggest the field ABDBG-SREPD. It should not be available if someone switches the debugger on and it is long enough to hold most pw.

A little example follows

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. REPORT zss_test.
2.  
3. TABLES: abdbg.
4.  
5. DEFINE testmakro.
6. * retrieve password here before calling - for example "Hallo"
7.   abdbg-srepid = 'Hallo'.
8.  
9.  
10.   call function 'Z_TEST'
11.        exporting
12.             passwort = abdbg-srepid
13.        exceptions
14.             test     = 1
15.             others   = 2.
16. END-OF-DEFINITION.
17.  
18. testmakro.
19. WRITE:/ 'Ende'.
20.  
21.  

GeSHi ©

Try running this code in Single-Step-Mode and in "Normal"-Mode and you see the difference.

[Jessy5246]

Dear Stefan:
Thanks, I will check out your example. But if you single-step into the function module, won't you be able to see the value of 'passwort', even with a macro? And what makes structure ABDBG non-debuggable?

Later,
Wolfgang

[Ilja583]

Hi Wolfgang,

ABDBG seems to hold debug-parameters during debugging.

The moment you switch on the debugger some of the fields from ADBGB will be filled - SREPID is one of them and will be filled with the name of the program that is being debugged at the moment.

That means: When running undisturbed you can use the field to hold your variable and even do some processing with it, but the moment the debugger is switched on the field will be overwritten with something unrelated.

[Willy1492]

But if you single-step into the function module, won't you be able to see the value of 'passwort', even with a macro?

Only if you pass a value instead of a reference.

And what makes structure ABDBG non-debuggable?

I guess it's because SAPMSSY3 is using ABDBG for it's own purpose (for the debugger's screen fields) and will overwrite the contents, if you switch on debugging. But I didn't try it.

[Ilja583]

Hi Wolfgang,

auf der Fahrt nach Hause kam mir noch eine weitere Idee wie du das Problem angehen kannst.

Bevor du mit der ganzen Dekrypterei etc. loslegst wirfst einen Job an, der im Hintergrund läuft. Jetzt musst du natürlich warten, bis der Job tatsächlich gestartet ist, sonst ist es ja sinnlos.
Dieser Job prüft die ganze Zeit über, ob das auslösende Programm noch einen Prozess belegt - wenn nicht kann er sich auch selber beenden.

Und wenn das auslösende Programm in den Debugmodus wechseln sollte löscht dieser Job dann die Session (und kann ja evtl. noch ne nette Nachricht ausgeben warum er das gemacht hat)

Mit dieser Methode muss der User mit Debugberechtigung schon mächtig schnell sein, wenn er noch das PW im Klartext erspähen möchte.

[Jessy5246]

Dear Stefan:
Thanks for your additional thoughts. I am not sure, whether I follow your exact idea, but you made me think about asynchronous processing. I could do my thing in an asynchronous task and wait until it is through. Everything including the password could happen there, and I can check a semaphore to interrupt the process.

Follow-up questions:
- Is there any field in SY that changes, if a process goes to debug mode?
- Can an asynchronous task run in background (batch via external job) in the same manner as when it gets kicked off in foreground/dialog mode, or are there restrictions?
- Can an asynchronous task be picked up from background processing for debugging? If so, where will the debugging begin? The current line (whichever it is), a certain event or only the beginning of a loop? If a debugger gets into the process, it is too late, too.

Could you elaborate a bit on how to monitor a process and its mode (whether debug or not)? My program could run concurrently with itself or others using the same function, so the identification may be tricky.

Anyway, it is not critical, so please don't let your day-job suffer.

Thanks,
Wolfgang

[Ilja583]

Hi Wolfgang,

how about one other possibility.

Do the following 3 things BEFORE you start decrypting:

1st: Check whether program is in debugmode at program start . To do this check the field ABDBG instead of SYST. This answers already one of your questions.

2nd: Run the following code to retrieve all set breakpoints.

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. TYPES: BEGIN OF savbr_breakpoint,
2.         bp_kind     TYPE i,
3.         program     LIKE sy-repid,
4.         cont_offset TYPE i,
5.        END   OF savbr_breakpoint.
6. DATA: l_internal_breakpoints TYPE savbr_breakpoint OCCURS 30
7.                              WITH HEADER LINE.
8. CALL 'DEBUG_CNTL'
9.      ID 'MODE'        FIELD 'R'
10.      ID 'BREAKPOINTS' FIELD l_internal_breakpoints[].
11.  
12.  

GeSHi ©

codesnippet taken from FB "SYSTEM_DEBUG_BREAKPOINTS"

3rd: Check if in ANY of the programs which your program passes through before you can discard the decrypted PW there is a breakpoint.

If you are not in debugmode and there are no breakpoints set (at the moment) continue processing. Now someone has to be VERY fast to try to get into debugmode before you are done with whatever you want to do with your pw.
In the other case just send a message to the user and ask him to clear all breakpoints and to continue afterwards. (This is the first case, where I believe it would be the correct thing to leave a BREAK-POINT statement in the program to give the user the chance to kill all his breakpoints)

[Jessy5246]

Moin Stefan:
ABDBG works nicely. I will experiment with the other call you mentioned.

Moin Frank:

But if you single-step into the function module, won't you be able to see the value of 'passwort', even with a macro?
Only if you pass a value instead of a reference.

I tried it, but even when the parameter is by reference, I can single step into the FM and see the value. Am I missing something?

Later,
Wolfgang

[Willy1492]

Hallo Wolfgang, ich kann es leider nicht reproduzieren. Erst wenn Du mir hilfst.(Hab Dir grad ne dringende e-Mail geschrieben.)