Best Practice for Returning Errors
Results 1 to 4 of 4

Thread: Best Practice for Returning Errors

  1. #1
    Junior Member
    Join Date
    Mar 2005
    Posts
    5

    Best Practice for Returning Errors

    What is the best way to report an error code to the user when I am not allowing him to access an application? I want to give an obscure error that cannot be searched for in the binary. Does anyone have a clever way of doing this. Lookup tables?

  2. #2
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,190
    I am sorry, but I don't quite understand your question.

    You have an application and you wish to deny a user access and send them an error message?

    You apparently don't want to send an "access denied" message, or use the catch all "an unknown error has occurred"?

    Normally, a compiled executable will have some sort of table or array at the end containing error messages, but these are in plain text, and it appears that you don't want it to be readable?

    Are you up to something naughty here young man?

    I suppose an external look up table would be the most elegant solution? or you could hardcode it into the body of the script and have the program translate it from the binary code. Assuming that the latter is feasible it is not as efficient as picking up and sending a literal string of characters, which is basically how "normal" error messages are handled.

    Presumably the instruction to identify the user(s) being targetted is embedded in the binary gibberish? so you could attach the message to that?

    However, your question implies a user with sufficient knowledge to display the binary object code, so what is to stop them running it through a decompiler and finding both the instruction and the message, or link to the external table?

  3. #3
    Senior Member MadBeaver's Avatar
    Join Date
    Jul 2003
    Location
    Bath, Maine
    Posts
    252
    What I have done in the past is to use a basic numbering system that I have the key to explain where the error occurred. An example would be like an access application I wrote, where it would return an error number like 205 [2 points to a specific form or module and the 05 refers to a sub or a function within the form or module]
    I have a database that I keep these keys in so I can use it for multiple programs that I have written.

    Hope this helps

    [edit] woohoo I hit the 100 post now only 5423 more to catch up to nihil [/edit]
    Mad Beaver

  4. #4
    Senior Member
    Join Date
    Apr 2004
    Posts
    1,130

    Re: Best Practice for Returning Errors

    Originally posted here by Davidlock
    What is the best way to report an error code to the user when I am not allowing him to access an application? I want to give an obscure error that cannot be searched for in the binary. Does anyone have a clever way of doing this. Lookup tables?
    If the application has a external database (such as mssql, oracle, etc) you can store msg on database and retrieve dynamically. But if it is a static application (such as a pc game), you are doomed.
    As a nihil stated, it is pointless try to obscure where the message code is, since the "pratical hacker" wont seek out for those strings; instead he will debug your program until he finds the piece of code that decides if the msg need to be sent or not. After find that part of your program, its is easy (for him of course) create a branch there to bypass your trap.
    But if the user can copy/run the object code outside of the original directory, what is the problem about the user "take a look" at assembly code?
    maybe if you give us more detail, someone here may offer you an alternate elegant solution.
    Meu sítio

    FORMAT C: Yes ...Yes??? ...Nooooo!!! ^C ^C ^C ^C ^C
    If I die before I sleep, I pray the Lord my soul to encrypt.
    If I die before I wake, I pray the Lord my soul to brake.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •