# The techniques to guard buffers against overflow.



## SarK0Y (Nov 26, 2014)

Hi there, my friends 

Actually, I'd like to discuss here whatever methods are available for what the subject of this thread says. First and foremost, I'm going to share my humble solutions for it:

http://alg0z.blogspot.com/2014/10/dabofi.html
http://sourceforge.net/projects/dasofi/

Thanks a lot in advance.


----------



## J65nko (Nov 26, 2014)

In the 1980's when I programmed in Forth professionally, I created a package that implemented text strings manipulations.

The first byte contained the maximum length of the string buffer, and the second byte the actual length of the stored string. The string was stored immediately after these two bytes. Then I implemented routines like taking a substring of concatenating strings. I never had a string buffer overflow


----------



## SarK0Y (Nov 26, 2014)

J65nko said:


> In the 1980's when I programmed in Forth professionally, I created a package that implemented text strings manipulations.
> 
> The first byte contained the maximum length of the string buffer, and the second byte the actual length of the stored string. The string was stored immediately after these two bytes. Then I implemented routines like taking a substring of concatenating strings. I never had a string buffer overflow


Yes, it's the best format for strings plus it makes operations faster. _H_owever, strings a_re_n't the only data to  run into overflow troubles. Actually, I have developed a uniform solution against overflows and always have wondered why such schemes have not been implemented from the very start of IT.  They are nothing extraordinary to take that long.


----------



## SarK0Y (Nov 27, 2014)

Actually, I would like to see the happy end of this funny and doleful story about overflow troubles. The bad side of my solution is, it takes a lot of legwork to re-write the bulk of all unsafe code. Meanwhile, here we can get in some kind of compromise: for instance, it seems quite workable to use so-called proxy daemons to perform ToRAs (table of right addresses) through them. In the original approach, it needs to pass the base address of an array to the writing function in order to calculate a safe length for operation. Classical codes use arbitrary addresses. So, a base address could be estimated as being the closest one from an arbitrary address to ToRA's record. 

Let's say we have function write(char *src, char *dst) and ToRA consists of bases {0x12, 0x40, 0xA5B}. Thereby the proxy daemon takes dst (for example, 0x27) and tries it against records in ToRA. Then, in our case, the base will be taken at 0x12. Obviously, some binaries shall fail entirely because a developer may use bases that are too far far calculating offsets and/or bases from different directions. In other words, a developer could be a true anarchist with memory


----------

