'Heap Overflow' Hacking Attack.

Processes & Memory Allocation.

'process' is a running computer program.

for this to happen, a certain amount of computer's memory must be reserved (allocated) for the process. both for code as well as for data.

memory reserved for process is split into 'segments'.

in x86 processor machines, there are following segments:
- 'text segment' is also called 'code segment'. in this segment all of instructions written by programmer are stored in a 'machine language form'. nothing can be written there, segment's size cannot be changed after loading program into memory.
- 'data segment' contains both global variables, as well as declared constants, for example: 'character strings'.
- 'bss segment' contains static variables, as well as uninitialized global variables.
- 'heap segment' has dynamic size - can be resized during program's run; it's used for storing dynamic variables that are created & destroyed by user as programmer allowed.
- 'stack segment' is automatically used by local variables of called functions, storing for example call's arguments. it's similar to 'heap segment' in that it can be resized.

Heap Overflow.

let's look at a following screenshot with code.

Heap Overflow.

to overwrite buf2 we need 16 bytes ... we can see that a 'malloc' function allocates additional 8 bytes, beside what we requested for our variable.

putting 16 'B' characters inside argument passed to a program passess in fact 17 characters - 16 'B' characters & one 'NULL' character, a string's terminator.

next we passed 20 bytes to program ... 19 'B' characters & one 'NULL' byte, a string's terminator.

we can see that we can overwrite a heap variable that way.

if we read this after a 'Buffer Overflow' Hacking Attack article, we can also notice that heap's addressing rises in opposite direction to stack's.

Function Pointer Overwrite.

let's look at a following screenshot with code.

Code with a static function pointer variable.

this code uses static variables, they are put on a .bss segment, just beyond heap segment.

we can see that 'atoi' function converts character strings to a '0' value,

we can also see that too many of 'a' symbols (done using a perl one-liner script) causes memory protection error (Segmentation fault), with a core dump.

let's look at that dump file using gnu debugger gdb.

Code debugged ... yet attack failure happened.

we passed memory address of a 'dv' function to jump to in a little-endian notation, using a perl one-liner.

we got result of '10', while we expected 8 / 2 = '4'.

it seems attack failed, more of debugging neccessary.

Code debugged for an attack ...

it seems that due to hardware-software configuration of my machine, variables are stored in reverse order when compared to looking at source code only.

it seems not much we can do here other than reversing order of the two first 'main' function's lines (with variables declaration) & adjusting attack accordingly.

Succesful attack on modified code.

Function Pointer Overwrite Buffer Overflow Attack.

we did put '000' before '8', to enforce proper length of passed parameter - this way perl one liner that passess memory address to jump to won't be mistaken for a part of '8' number, a parameter to 'dv' function we jump to.

see also if You wish or need ... : Heap Overflow type Attacks, 'Buffer Overflow' Hacking Attack, 'Format String' Hacking Attack.


Stitie Grid.

(article still under construction, it's a scrapbook to be edited & corrected for usability & style).

Grid computing is the collection of computer resources from multiple locations to reach a common goal.

Grid computing differs from cluster computing with that grid computers can have different nodes performing different task(s).

code files of an experiment with Stitie Machine/Space & Grid Computing are available (both client & server - in grid package's comments it's written which files are needed where):

these files allow for code transfer between machines, with execution at target machine.

(a resource folder, 'classdump folder' has to be added to classpath for this to work).

just wrote 'EndpointServer' class, a service that can receive & run a 'LightPoint', or in other words (State, Strategy) pair, an object equivalent.

multiple files can be transferred via network, if neccessary.

'EndpointServer' has a 'router' in a 'Sunsail' component available via getter method, so it can communicate with nearby machines without a neccessity of engaging 'Coordinator' with a 'Stitie Space' model of network. for this to work though, need use 'Sunsail Awareness' code part of a 'Sunsail' & 'Endpoint Server'.

after a little more of work, we can experiment with a 'Stitie Grid' idea.

see also, if You wish or need ... : Stitie Machine (Maszyna Stanikowa Wysockiego), Stitie Machine 1.1 'Sunsail'.

-= Server & Client. =-



1. Introduction.

Certain services require that operations with these adhere to a few of principles.


details in an article named ACID.

to fulfill requirements of 'atomicity' & 'durability' despite failure, data objects have to be 'recoverable'.

when server stops due to hardware or software failure, all of transaction-related data has to be available in a persistent memory, so the data can be 'recovered', preserving effects of 'all or nothing'.

to provide 'isolation', data should be processed in either serial way (one operation after another, without concurrency) or when this is not an option (most services require concurrent processing of multiple operations at once), in a serially-equivalent way.

'consistency' is an issue of transactional service's user, mostly.

transactional services in practice are operations that are contained within a construct called 'transaction', that is, between brackets of 'Open Transaction' operation & 'Close Transaction' operation. 'Close Transaction' can be either 'Commit' (keep changes, all of them) or 'Rollback' (abort changes, all of them).

each of transaction has identifier TID, that allows operation to be associated with transaction with that an identifier.

transactional services might allow for a certain amount of time before 'commit', after that time operation is 'aborted', 'rolled back'.

2. Issues of Concurrency.

2.1. Lost updates.

'Lost updates' is an issue, that can be shown using example with bank-alike operations on accounts A, B & C.

Transaction TTransaction U
accountBalance = A.read();$100
A.write(accountBalance - 4); $96
accountBalance = C.read();$300
C.write(accountBalance - 3);$297
accountBalance = B.read();$200
accountBalance = B.read()$200
B.write(accountBalance + 3)$203
B.write(accountBalance + 4)$204

'Transaction T' & 'Transaction U' use different threads, each of these use private variables & state.

there's issue with coordinating the concurrency of 'conversations' between a 'bank server' & 'clients'.

2.2. Inconsistent reads.

'Inconsistent reads' is also an issue, that can be shown using example with bank-alike operations on accounts A, B & C.

Transaction TTransaction U
accountBalance = A.read();$200
A.write(accountBalance - 100); $100
accountBalance = A.read();$100
accountBalance = accountBalance + B.read();$300
accountBalance = accountBalance + C.read();$300
accountBalance = B.read();$200
B.write(accountBalance + 100)$300


'Transaction T' & 'Transaction U' use different threads, each of these use private variables & state.

there's issue with coordinating the concurrency of 'conversations' between a 'bank server' & 'clients'.

2.3. Serial equivalence.

if all known transactions executed serially give correct result(s), then if there are orderings in which they also give correct result(s), then these orderings are 'serially equivalent'.

2.4. Possible approaches to handling concurrency.

2.4.1. Locking.

Every data object is locked (taken) by a transaction reaching for it.

No other transaction can use that object until first transaction either 'commits' or 'rolls back'.

2.4.2. Optimistic concurrency management.

it's about 'hope' ... in that there won't be any 'conflicts' with data access.

if there's conflict, transaction needs to be aborted & repeated again, probably.

2.4.3. Timestamps.

with this approach, each of transactions has a timestamp.

data objects get these timestamps with each contact.

transaction rollback & recovery happens when they are too late to perform operation on a given object.

3. Recoverability.

transactional services must persist results of all 'committed' transactions & remove traces of 'rolled back' transactions.

there are two issues of 'dirty reads' & 'premature writes', both possible even with 'serially equivalent transaction execution'.

3.1. Dirty reads.

'isolation' property of a transaction requires that transactions won't read 'uncommitted states' of other transactions.

a case of a 'dirty read' is when this undesired occurance happens nevertheless.

'reproductibility' of a transaction occurs when we delay 'committing' a transaction that did a 'dirty read' from other transaction(s).

'cascade aborts' occur when one 'rollback' causes a serie of 'rollbacks' in 'waiting transactions', due to a 'dirty read' & 'delaying commits' as in a case mentioned above.

3.2. Premature writes.

'premature write' occurs when we write in a data object changed by another transaction, before its 'commit' or 'rollback'.

to prevent data inconsistency, to ensure correct results, write operations must be delayed until previous transactions that updated 'same' data objects either 'commit' or 'rollback'.

3.3. Strict transaction execution.

generally speaking, we can say that its neccessary to delay transactions' read & write operations to avoid 'dirty read' & 'premature write' issues.

transaction execution is called 'strict' when services delay both 'read' & 'write' operations on 'data objects' until all of transactions that wrote in that 'data object' are either 'committed' or 'rolled back'.

'strict' transaction execution enforces needed property of 'isolation'.

3.4. Temporary versions.

transactional services should be designed the way that it is possible to delete any of the updates in data objects, when changes are aborted.

to enable this, many of implementations use temporary values' collections, with each of data objects & it's updates stored in a volatile (non-permanent) memory.

when transactions commit changes, state changes are moved into 'data objects', 'persisted' in one step, during which other transactions cannot interact with these 'data objects'.

4. Nested transactions.

transaction can consist of a set of 'nested transactions'.

each of these 'nested transactions' can consist of a similar set of 'nested transactions' & so on ...

for example, there can be 'moneyTransfer' transaction that consists of 'withdraw' & 'deposit' nested transactions.

'nested transactions' are useful because of:

- transactions nested on the same level can be performed concurrently (at the same time) with other nested transaction(s),
- nested transaction may be 'committed' or 'rolled back' independently. a 'rollback' of one or few of 'nested transactions' might not be a cause of parent transaction's 'rollback' yet,
- nested transactions are especially useful in 'distributed systems', because children nested transactions can be performed concurrently on different servers. this should be elaborated in another article.

Source: [13].

See also if You wish or need ... : Parallel & Distributed Systems, Stitie Space.


'Buffer Overflow' Hacking Attack.

Processes & Memory Allocation.

'process' is a running computer program.

for this to happen, a certain amount of computer's memory must be reserved (allocated) for the process. both for code as well as for data.

memory reserved for process is split into 'segments'.

in x86 processor machines, there are following segments:
- 'text segment' is also called 'code segment'. in this segment all of instructions written by programmer are stored in a 'machine language form'. nothing can be written there, segment's size cannot be changed after loading program into memory.
- 'data segment' contains both global variables, as well as declared constants, for example: 'character strings'.
- 'bss segment' contains static variables, as well as uninitialized global variables.
- 'heap segment' has dynamic size - can be resized during program's run; it's used for storing dynamic variables that are created & destroyed by user as programmer allowed.
- 'stack segment' is automatically used by local variables of called functions, storing for example call's arguments. it's similar to 'heap segment' in that it can be resized.

Buffer Overflow.

it's that a 'buffer overflow' is often called a 'stack overflow'.

often 'buffer overflow' affects stack, that's why we'll examine 'stack segment' properly.

'stack' can be imagined as 'tower of blocks', with a constant base, with variables being put on it's top. each of tiers makes this tower higher & higher. both stack & tower have a given size. after reaching critical maximum size tower can be toppled, stack can overflow memory. when we reach for variable on stack, we take topmost one.

operating on stack is possible with two basic commands:

PUSH - is: 'put a value on stack',
POP - is: 'get a value from stack'.

of course system must know a current address of stack's top, to remove variables one by one. processor uses ESP register for that (Extended Stack Pointer).

let's look at a following code, on an image:

code with 'stack' used in a function call.

stack after a call of func(argc) should look as on following image:


when program starts, it stores program's arguments on stack first. we have: 'int argc' & 'char *argv[]' on stack.

then main function is called, next tier (position) on stack is filled with copies of register values of EIP & EBP.

EIP is called 'instruction pointer', it points at next instruction to process during program's run. when we store that register value, we know where to return after completing called function's run.

EBP is 'Extended Base Pointer' stores last stack's top address.

next step in this program's run is calling a function func(argc). we put on stack argument(s) passed to a function, in this case: number of arguments that user passed to program as it was run. next we put EIP & EBP register values - this time they are associated with returning from function func.


a buffer is memory fragment reserved for storing a given amount of data. if programmer won't take care of controlling amount of data, it's easy to overflow a buffer ... leaving an opening for a hacking attack.

if amount of data is more than buffer's maximum size, rest of data is written in another memory area, nearby.

'Buffer overflow' attack.

let's look at another image with another program.

a program vulnerable to a 'buffer overflow' attack.

writing 1 or 10 of '32-bit byte long' characters did not overflow buffer, as buffer is of a size of 10.

'strcpy' function copies character strings without copying an 'end of string' character.

adding one more character did overflow buffer, however ... overwriting variable 'a' with a value of '0x41' of 'A' character.

more exercises,

'Segmentation fault' error as well.

adding too many of characters, however, will result in an 'Segmentation fault' error, meaning that program attempted to write to memory area that was not assigned to it.

how many is enough ?

this depends on a hardware-software configuration, we'll show that with an example.

depending on a 'hardware-software configuration' we can have C language compiler that allocates different amount of 'stack bytes' ... different depending on a mentioned 'hardware-software configuration'.

on used operating system (SSO v2.0) we have a gcc compiler with a preferred-stack-boundary variable, that determines amount of allocated stack bytes.

it's power of 2, so the programs will have stack space allocated equal to n-th power of 2.

by default it's assigned a value of 4, so stack will have 24 = 16 bytes allocated.

we'll show this using a gdb debugger.

stack size is 16 dec = 10 hex.

we can see we have 16 bytes allocated on stack,

a value of 'ceiling' of 24 = 16 & of size of a 'buffer' variable, 10.

lets see another image & lets compare results.

stack size is 16 dec = 10 hex, again.

we can see that assembler code is same as before, with 16 bytes allocated on stack again,

a value of 'ceiling' of 24 = 16 & of size of 'a' variable, 1.

lets change value of preferred-stack-boundary variable to 2, so we have 22 = 4 bytes of stack.

stack size is 4 dec = 4 hex.

we can see we have 4 bytes allocated on stack,

a value of 'ceiling' of 22 = 4 & of size of 'a', 1.

Attack on a 'protected application'.

we'll exploit 'scanf' function's use without checking read string's size.

let's look on image:

a buffer overflow.

we've overwritten an 'ok' variable with non-zero, a truth value.

what if there's no 'ok' variable? let's look at image with a more difficult example.

debugger's use.

we've passed 32 of 'A' characters to first argument of an application.

this resulted in a memory protection error (Segmentation fault).


because EIP & EBP register values were overwritten with 0x41414141 bytes, as a result of putting there 'AAAA' string (0x41 is 'A').

when we call a function, in preparation, there are EIP & EBP register values put on stack. as we did stack overflow, we've overwritten these register values as they were stored on stack. during a return from check_login function, we retrieve these values & use stored EIP to determine where to 'jump' next with software's execution. we were trying to 'jump' to an address 0x41414141, somewhere where we do not have access to - therefore we got an error message, Segmentation fault.

how to use this situation to our advantage ?

let's check where we can actually jump to.

let's disassemble 'main' function.

'main' function disassembled.

conditional instruction if is realized in assembler using using 'test' & 'je' or 'jne' instructions.

in this case, 'je' instruction jumps in a case of 'false' tested value, when an instruction is not executed due to wrong credentials.

we're interrested in jumping to a point after 'je' instruction, where we have a 'case' for 'right credentials'.

it's 0x08048556, but we have to present it in a 'little-endian' form.

a stack overflow with a 'jump to case'.

... but why we did have to pass 32 byte-long characters to program ?

let's examine check_login function body.

'check_login' function disassembled.

we can see there three 'register push' instructions, plus there's EIP register pushed when we call a function.

a Stack.

... so it's 4x four-byte-long registers, plus 16-byte-long login variable, totalling 32 bytes.

'Buffer overflow' with a 'shellcode injection'.

let's look at code on a following image.

Buffer overflow with a core dump displayed in a debugger.

EIP was filled with 0x41414141 value, as in a previous example.

This time, however we do not have any interresting code part to 'jump' to, as application does not use 'execl'.

We have to provide that a code part, with a 'shellcode'.

a shellcode, written in assembler ... displayed with an object file's dump.

this shellcode is explained with details in this post.

looking at dump at right side of the image, we see result of command 'objdump -d shell2' where 'shell2' is name of the program to be dumped.

based on that a dump, we can write shellcode in 'more machine language form', which looks like that:

shellcode, hexadecimal notation form.

now we can write 'exploit' program that 'injects shellcode' into vulnerable application, then overwrites EIP to 'jump to shellcode'.

'exploit' program that 'injects shellcode' into to a program that is vulnerable to a 'buffer overflow'.

see also, if You wish or need ... : Buffer Overflow Attack, 'Heap Overflow' Hacking Attack, 'Format String' Hacking Attack.

source: [14].


Conversation State & Distributed Application.

when two or more objects interact, we can say they are engaged in a 'conversation'.

this a 'conversation' may go according to a 'protocol', or not.

we can talk about a 'conversation state', a record of every interaction of every object involved in the 'conversation' (which object said, what object said, to 'whom' & when).


object(s) can 'talk' to other object(s) in the same computer's memory, as well as to a 'remote machine'.

in latter case, it's a 'distributed application'.

in former case it's either a 'single-threaded' or 'concurrent' application, but not a 'distributed' application.


Why Distributed Systems ?

there are many reasons for using Distributed Systems:

Resources Distribution.

After joining various systems (nodes) with a network, user of one system (node) can use resources available at different system (node).

For example:
- user of node A can use laser printer connected to node B,
- user of node B can use a file stored at node A,
- possibly more.

'Load Sharing' for Speed of Computations.

if a certain computation can be split into a collection of partial computations that can be simultaneously computed, then a distributed system can allow assigning these partial computations to certain systems (nodes), can also allow for their concurrent computations.

there's also possibility of moving a certain 'computing task' from 'overworked node' to 'another node' when/if neccessary.


if/when one of work-stations (nodes) fails, breaks, then other work-stations (nodes) can still continue their work. missing task(s) can be assigned to one or more of remaining work-stations (nodes).


there's possibility of work-stations (nodes) communicating with each other.

either software communicates for a certain task completion, or work-stations' (nodes') users can communicate as well.

source: [12].

see also, if You wish or need ... : Parallel & Distributed Systems, Stitie Space.


Parallel & Distributed Systems, Stitie Space.

- what's the difference between 'Parallel' & 'Distributed' Systems?
- 'Parallel Systems' share processor & memory, while 'Distributed Systems' do not. 'Distributed Systems' are built from 'Units' that contain Processor(s) & Memory.

- is Stitie Space a 'Parallel' or 'Distributed' System?
- it can function as 'Parallel System' that manages 'Distributed Systems'. Each of these systems can be anything including a 'Parallel System' that manages more 'Distributed Systems' recurrentially.

- why it was created?
- because of 'Cubic Totality of Love'.

Source: [12].

See also if You wish or need ... : Kacper Cluster, Why Distributed Systems ?, Conversation State, Stitie Grid, Clusters.



'Format String' Hacking Attack.

(post under construction, more to be written & elaborated later, including 'remote attack').

Reading Memory State.

above code exploits printf(...) instruction's behavior.

to instruction / function call 'printf' there's passed data coming from user, who can pass anything there in this case, including formatting string.

%x in this case means reading 4 of 8-bit bytes, a '32-bit long word', with bit-string data being interpreted as a 'hexadecimal number'.

since we did pass only formatting string, without providing any data as is 'proper', without putting any data on stack, other of our data is examined. program examines stack, including the 'ABCD' part - written in a reverse hexadecimal notation it's read as: '44434241'.

the trick is knowing how many of '-%x' to put, how to reach to proper memory address.

Locating memory address of a variable.

if we can edit code, we can also see memory address of any variable, with a little of experiments.

(later we'll use a debugger to modify code as it's run).

above code 'looks up' a variable & it's value under a known memory address.

second image uses a program from first image to do a lookup & uses different notation to do 'the same' thing.

there's noticeable change of different memory address of a variable in a program being run - probably new process was assigned different memory space.

in this Hacking School's Operating System (SSO 2.0) this doesn't happen too often, in other Operating Systems it might.

Writing to a Memory.

above code writes to memory.

a value of '5' was written, according to formatting string's '%n' parameter specification: four bytes and a minus '-' character, totally a five of 'byte-lenght characters'.

how to write a larger number ?

depending on how large that number is, a method can be chosen - either simple to understand, remember & use ... or complex, but handling larger of numbers better.

writing a '1000' in an 'i' variable.

'1000' in a decimal notation equals '0x3e8' in a hexadecimal notation.

the above method worked for writing a '1000' number quite well, but perhaps there are various problems associated with writing larger numbers using this method.

1000 bytes were composed of 4 of '32-bit-byte-length' address numbers, 2 of '-' characters & 994 of '32-bit-byte-length' %x signs. each of '%x' signs prints an 'empty character' on screen.

in x86 architecture with 32-bit Linux Operating System, a character variable as minus '-' or 'empty character' for example, has size of 32-bits, a single 32-bit length byte.

%n ($n in this case as well) writes to memory amount of written characters within this printf's instruction call, see a proper 'man page' for details. command to do so is: 'man printf 3' on a Linux shell.

what about the 'better' method ?

for example: let's consider a '0x88664422' = '2288403490' number.

let's look at following images ...

writing first four bytes.

it's 'reverse hexadecimal' notation where least important numbers come first.

first number is 34 - 16 (number of bytes written already, memory addresses) = 18.

we put 18 then before %x%9$n

filling-in with rest of a number.

instead of producing very many characters to be used with %n, we've decided to split an 16-byte-long-number into 4 parts, then fill each part separately.

let's consider another number: '0x22446688' = '574908040'.

writing '0x22446688' into 'i' variable.

let's notice that putting '1' before a '2-digit hexadecimal number' is "shifting 'it' by 16*16 = 256 places" in memory.

for example: '0x166' is '256-places shifted 0x66'.

i've also checked this method with another number: '0x33113399', still works fine.

Attack on a 'protected application'.

let's consider following program, as on image:

'protected application'.

user 'protected' application with login & password, but made error of using 'printf' function in an insecure way.

we've compiled this 'a program' with -ggdb compilation parameter, to enable debugging.

let's check how many 'places on stack' we have to 'get through' to reach a password ...

13 of '%x' signs are needed to get to a password.

... 13th place on main function's stack is 'the password' as is entered by user running this program.

now let's use debugger to locate 'ok' variable's memory address.

we've compiled program with -ggdb parameter, this simplifies that task a bit, otherwise it'd be a little harder.

let's run a debugger with a command: 'gdb fm5'.

debug & attack by overwriting 'ok' variable's state.

after few experiments with format string attack in & around an address of 'ok' variable we've did overwrite of 'ok' variable with a value != 0, a 'truth' value in C.

program was hacked, we've got into protected area.

we've noticed that not always address given by a debugger is accurate, it seems it's two different processes anyway - with different memory addressing.

Attack using a 'shellcode injection'.

let's look at following image, it's mostly debugger use to change program's behavior.

debugger used to change program's behavior.

we've changed a value of EIP (instruction pointer) register as it was put on stack & displayed with 'info frame' debugger command.

this enabled us to change return address from main function to an address pointed by a 'shellcode' variable, with another debugger command, as on image.

the 'shellcode' program was ran & it caused hacked code to run a command shell, instead of just ending the application's run 'as it should'.

(to complete this article, have to learn something from book [14] ... chapters 6, 7 & 8 are neccessary to understand chapters 9 & 10. will do this now & share progress in a separate post).

post under construction, more to be written & elaborated later, including 'remote attack').

see also if You wish or need ... : About 'format string' attacks, 'Buffer Overflow' Hacking Attack, 'Heap Overflow' Hacking Attack.

source: [14].

(still having mental blocks preventing me from learning that way of hacking).

Abstraction Levels in Programming.

in programming, abstraction levels are understood as:

high abstraction level instructions (Java, C++, Smalltalk, ...) are :
- easier to understand by human,
- complex, consisting of many simpler instructions of lower-level language,
- more sophisticated, allowing for better performance in coding in certain cases,
- allow to do more with a single simple instruction than low-level programming allows, cutting down software development time & other costs,

low abstraction level instructions (Pascal, C, Assembler, ...) are :
- closer to the machine & hardware; hard to understand by a beginner,
- simpler, less complex, consisting of few or one instruction in machine language,
- allow for hacking & fine-tuning details of performance.

instructions have cost measured in processor cycles they cost to perform them ... they operate on memory and / or processor registers (also form of memory, just very scarce & expensive).

simpler, low-level instructions take little of processor time by themselves.

occassionally it's better to use more sophisticated instruction however, than using too many simpler instructions.

for example:
- it's better to use mathematical power function to calculate something than rely or very many additions in loops.


High-Level Prototype, Low-Level Port.

i think it's interresting metodology of devving software.

first create a high-level prototype in a high-level programming language.

that type of code is easier to understand, easier to change, easier to develop complex solutions.

it's a 'proof of concept' as well.

it's also less costly programmer-time wise than low-level programming attempt.

then once we have working high-level prototype, we can commence with a low-level port.

we rewrite high-level prototype in low-level programming language, as 'Ansi C' with 'Assembler' inserts, for example.

that way we have low-level optimization as well, i think both memory-cost wise, as well as processor-time wise.

algorithmic optimization is also there easier, with a high-level prototype construction, preferably using Object-Oriented Programming Paradigm.

bottlenecks can be optimized with that methodology as well, i think.

see also, if You wish or need, ... : Object Oriented Programming in Ansi C.


Object Oriented Programming in Ansi C.

at Uni (MIMUW) i've learned that Object Oriented Programming is not limited to 'Object Oriented Languages'.

it's just a methodology, a pattern.

here's how this can be done in Ansi C: OOC (found in the Internet).

if neccessary & available, i'll buy this a book.


that's how Stitie Machine 1.1 'Sunsail' with Stitie Space can be ported to Ansi C, as a part of low-level optimization effort.

perhaps it'll work, i'm willing to risk, as low-level programming is part of hacker's way in my opinion, anyway ...

it should also help in 'Ola AH' Programming Language development.


Repository & Teamwork.

'software repository' is a software that keeps programmers' work in many versions in a single place.

'software repository' allows multiple users to 'download' code to their computers, work simultaneously, then upload, commit changes - so rest of the team can access updates, changes, corrections.

it's both an 'archive' as well as 'team management tool', perhaps more ...


'Ola AH' Programming Language should have 'custom software infrastructure', including 'custom repository' for certain security reasons.

there's '4GL IDE', 4th Generation Language Integrated Development Environment, planned perhaps as well.


i am not sure if i'll have enough of time to do all the work alone, during 30 years i have planned for Dragonfly Algorithm's work.

i'll just do as much as i can, alone or not.

if/when people will join 'the project', we'll think how to distribute & coordinate our work.


'AH' mode of 'Ola AH' Programming Language.

AH stands for 'AH' Mantra for speech.

AH also stands for 'Anti-Hack' mode of 'Ola AH' Programming Language.

i think that both 'interpreter' as well as 'compiler' of 'Ola AH' should consist of a Set of 'interfaces', managed by 'manager', not sure in which language(s) for now.

given certain parameters, either compiler or interpreter, can load 'replacement(s)' for existing modules, as long as these replacement(s) are coded to a proper interface(s).

using language that way would require proper declarations in code, as well as security measures that prevent code modification as it stays in repository, as well as security for compilation, or running in an interpreter.

it's a form of 'Idiomatic' <-> 'Hacky' slider ...

depending on a position of that slider more or less of a 'compiler' or an 'interpreter' modules can be replaced.

... how far You can go into hacky mode depends on permissions, digital certificates, code owner's decisions.

there can be also many sliders, or a hierarchy-tree of sliders, many being a precondition for other slider.


'AH mode' is also about a 'different instructions set', more instructions, low-level programming for experts, perhaps tiered as well.


see also if You wish or need, ... : Agile Transformation of Information State.