Author Topic: The techniques to guard buffers against overflow  (Read 399 times)

0 Members and 1 Guest are viewing this topic.

Offline SarK0Y

  • /dev/null
  • *
  • Posts: 5
  • Cookies: -11
    • View Profile
The techniques to guard buffers against overflow
« on: October 21, 2014, 04:03:22 am »
Hi there, my Friends. :D

here, i'd like to discuss the possible & the best techniques for subj. 1st & foremost, i would like to share my humble approach to protect buffers.

code: https://sourceforge.net/projects/dasofi
description: http://alg0z.blogspot.ru/2014/10/dabofi.html

perhaps, description seems too short, but i hope code is more verbose  ;)
======================
Thanks a lot in Advance for your contribution.

Offline ande

  • Owner
  • Titan
  • *
  • Posts: 2664
  • Cookies: 256
    • View Profile
Re: The techniques to guard buffers against overflow
« Reply #1 on: October 21, 2014, 09:08:10 am »
I understand you probably dident create all this for EZ or even another forum. But this IS a forum. We would very much appreciate it if we dident have to download a zip and then opening multiple PDF's and code files in various viewers and editors. Make your stuff forum friendly in the future please.
if($statement) { unless(!$statement) { // Very sure } }
https://evilzone.org/?hack=true

Offline SarK0Y

  • /dev/null
  • *
  • Posts: 5
  • Cookies: -11
    • View Profile
Re: The techniques to guard buffers against overflow
« Reply #2 on: October 23, 2014, 01:37:15 am »
I understand you probably dident create all this for EZ or even another forum. But this IS a forum. We would very much appreciate it if we dident have to download a zip and then opening multiple PDF's and code files in various viewers and editors. Make your stuff forum friendly in the future please.
OK, i'll try to be more informative & short as well.  ::) So, the approach is based upon simple idea: access to array must be provided by three parameters:

1. base address of array, i.e. &array[0].
2. offset in array to access to o/& since.
3. size of array.
====================
if we know for sure all-that, we can certainly calculate how many bytes to write in w/o the least risk to overflow. In other words, safe memory shouldn't be accessed Just by arbitrary address.