A water softener is a device that removes hardness from water, typically by exchanging calcium and magnesium ions for sodium ions. This process, known as ion exchange, occurs within a resin bed, which is composed of small, porous beads made of a material called ion-exchange resin.
Why is a Water Softener Needed for Well Water?
Well water often contains high levels of dissolved minerals, including calcium and magnesium, which cause hardness. Hard water can create several problems, such as:
Scale Buildup: Hard water can cause scale buildup in pipes, appliances, and fixtures, reducing their efficiency and lifespan.
Soap Scum: Hard water can make it difficult to create a lather with soap, resulting in soap scum buildup on surfaces.
Dry Skin and Hair: Hard water can strip away natural oils from skin and hair, leading to dryness and irritation.
Reduced Detergent Effectiveness: Hard water can reduce the effectiveness of detergents, making it harder to clean clothes and dishes.
Water Hardness Level: The first step in choosing a water softener is to determine the hardness level of your well water. There are several ways to do this, including purchasing a water test kit or sending a sample of your water to a laboratory for analysis.
Flow Rate: Consider the flow rate of your well water system when selecting a water softener. The flow rate is measured in gallons per minute (GPM) and determines the size of the water softener you need.
Grain Capacity: The grain capacity of a water softener refers to its ability to remove hardness from water. The grain capacity is measured in kilograins (KGR) and determines how much hardness the water softener can remove before it needs to be regenerated.
Type of Water Softener: There are two main types of water softeners: salt-based and salt-free. Salt-based water softeners use a process called ion exchange to remove hardness from water, while salt-free water softeners use a different process, such as template-assisted crystallization.
Brand and Reputation: Consider the brand and reputation of the water softener manufacturer when making a purchase. Look for brands that are known for their quality, reliability, and customer service.
Proper Installation: It is important to have a water softener installed by a qualified professional. Improper installation can lead to leaks, damage to the water softener, or ineffective water softening.
Regular Regeneration: Water softeners need to be regenerated regularly to maintain their effectiveness. The frequency of regeneration depends on the hardness of your water and the size of the water softener.
Salt Replenishment: Salt-based water softeners require regular replenishment of the salt supply. The frequency of replenishment depends on the hardness of your water and the size of the water softener.
Maintenance: Water softeners should be inspected and maintained regularly to ensure proper operation and longevity. This may include cleaning the resin bed, checking for leaks, and replacing any worn or damaged parts.
Improved Water Quality: Treated water has a reduced mineral content, improving the taste, smell, and appearance of the water.
Reduced Scale Buildup: This can save you money by extending the lifespan of your appliances.
Softer Skin and Hair: Softened water can help to improve the health of your skin and hair.
More Effective Laundry and Dishwashing: Softened water can improve the performance of detergents and soaps.
Increased Energy Efficiency: Softened water can help to improve the efficiency of water heaters and other appliances that use water.
Conclusion:
A water softener can be a valuable investment for well water users, providing numerous benefits and improving overall water quality. By choosing the right water softener and properly installing and maintaining it, you can enjoy the advantages of softened water throughout your home.
" Ophcrack is an open source (GPL license) program that cracks Windows LM hashes using rainbow tables. The program includes the ability to import the hashes from a variety of formats, including dumping directly from the SAM files of Windows. There is also a Live CD version which automates the retrieval, decryption, and cracking of passwords from a Windows system. Rainbow tables for LM hashes of alphanumeric passwords are provided for free by the developers. These tables can crack 99.9% of alphanumeric passwords of up to 14 characters in usually a few seconds, and at most a few minutes. Larger rainbow tables (for LM hashes of passwords with all printable characters, including symbols and space) are available for purchase from Objectif Securité. Starting with version 2.3, Ophcrack also cracks NT hashes. This is necessary if generation of the LM hash is disabled (this is default on Windows Vista), or if the password is longer than 14 characters (in which case the LM hash is not stored)." read more...
Lets build an app that uses several data-types in order to see how is stored from a low level perspective.
Rust string data-types
The two first main objects are "str" and String, lets check also the constructors.
Imports and functions
Even such a basic program links several libraries and occupy 2,568Kb, it's really not using the imports and expots the runtime functions even the main.
Even a simple string operation needs 544 functions on rust:
Main function
If you expected see a clear main function I regret to say that rust doesn't seem a real low-level language In spite of having a full control of the memory.
Ghidra turns crazy when tries to do the recursive parsing of the rust code, and finally we have the libc _start function, the endless loop after main is the way Ghidra decompiles the HLT instruction.
If we jump to main, we see a function call, the first parameter is rust_main as I named it below:
If we search "hello world" on the Defined Strings sections, matches at the end of a large string
After doing "clear code bytes" we can see the string and the reference:
We can see that the literal is stored in an non null terminated string, or most likely an array of bytes. we have a bunch of byte arrays and pointed from the code to the beginning. Let's follow the ref. [ctrl]+[shift]+[f] and we got the references that points to the rust main function.
After several naming thanks to the Ghidra comments that identify the rust runtime functions, the rust main looks more understandable. See below the ref to "hello world" that is passed to the string allocated hard-coding the size, because is non-null terminated string and there is no way to size this, this also helps to the rust performance, and avoid the c/c++ problems when you forgot the write the null byte for example miscalculating the size on a memcpy.
Regarding the string object, the allocator internals will reveal the structure in static. alloc_string function call a function that calls a function that calls a function and so on, so this is the stack (also on static using the Ghidra code comments)
1. _$LT$alloc..string..String$u20$as$u20$core..convert..From$LT$$RF$str$GT$$GT$::from::h752d6ce1f15e4125 2. alloc::str::_$LT$impl$u20$alloc..borrow..ToOwned$u20$for$u20$str$GT$::to_owned::h649c495e0f441934 3. alloc::slice::_$LT$impl$u20$alloc..borrow..ToOwned$u20$for$u20$$u5b$T$u5d$$GT$::to_owned::h1eac45d28 4. alloc::slice::_$LT$impl$u20$$u5b$T$u5d$$GT$::to_vec::h25257986b8057640 5. alloc::slice::hack::to_vec::h37a40daa915357ad 6. core::slice::_$LT$impl$u20$$u5b$T$u5d$$GT$::len::h2af5e6c76291f524 7. alloc::vec::Vec$LT$T$GT$::extend_from_slice::h190290413e8e57a2 8. _$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$alloc..vec..SpecExtend$LT$$RF$T$C$core..slice..Iter$LT$T$GT$$GT$$GT$::spec_extend::h451c2f92a49f9caa ... Well I'm not gonna talk about the performance impact on stack but really to program well reusing code grants the maintainability and its good, and I'm sure that the rust developed had measured that and don't compensate to hardcode directly every constructor.
At this point we have two options, check the rust source code, or try to figure out the string object in dynamic with gdb.
Source code
Let's explain this group of substructures having rust source code in the hand. The string object is defined at string.rs and it's simply an u8 type vector.
And the definition of vector can be found at vec.rs and is composed by a raw vector an the len which is the usize datatype.
The RawVector is a struct that helds the pointer to the null terminated string stored on an Unique object, and also contains the allocation pointer, here raw_vec.rs definition.
The cap field is the capacity of the allocation and a is the allocator:
Finally the Unique object structure contains a pointer to the null terminated string, and also a one byte marker core::marker::PhantomData
Dynamic analysis
The first parameter of the constructor is the interesting one, and in x64 arch is on RDI register, the extrange sequence RDI,RSI,RDX,RCX it sounds like ACDC with a bit of imagination (di-si-d-c)
So the RDI parámeter is the pointer to the string object:
So RDI contains the stack address pointer that points the the heap address 0x5578f030. Remember to disable ASLR to correlate the addresses with Ghidra, there is also a plugin to do the synchronization.
If we try to get the pointer of each substructure we would find out that the the pointer is the same:
If we look at this pointer, we have two dwords that are the pointer to the null terminated string, and also 0xb which is the size, this structure is a vector.
The pionter to the c string is 0x555555790130
This seems the c++ string but, let's look a bit deeper:
RawVector Vector: (gdb) x/wx 0x7fffffffdf50 0x7fffffffdf50:0x55790130 -> low dword c string pointer 0x7fffffffdf54:0x00005555 -> hight dword c string pointer 0x7fffffffdf58:0x0000000b -> len
0x7fffffffdf5c:0x00000000 0x7fffffffdf60:0x0000000b -> low cap (capacity) 0x7fffffffdf64:0x00000000 -> hight cap 0x7fffffffdf68:0xf722fe27 -> low a (allocator) 0x7fffffffdf6c:0x00007fff -> hight a 0x7fffffffdf70:0x00000005
So in this case the whole object is in stack except the null-terminated string.
In part 1 and 2 we covered re-entrancy and authorization attack scenarios within the Ethereum smart contract environment. In this blog we will cover integer attacks against blockchain decentralized applications (DAPs) coded in Solidity.
Integer Attack Explanation:
An integer overflow and underflow happens when a check on a value is used with an unsigned integer, which either adds or subtracts beyond the limits the variable can hold. If you remember back to your computer science class each variable type can hold up to a certain value length. You will also remember some variable types only hold positive numbers while others hold positive and negative numbers.
If you go outside of the constraints of the number type you are using it may handle things in different ways such as an error condition or perhaps cutting the number off at the maximum or minimum value.
In the Solidity language for Ethereum when we reach values past what our variable can hold it in turn wraps back around to a number it understands. So for example if we have a variable that can only hold a 2 digit number when we hit 99 and go past it, we will end up with 00. Inversely if we had 00 and we subtracted 1 we would end up with 99.
Normally in your math class the following would be true:
99 + 1 = 100 00 - 1 = -1
In solidity with unsigned numbers the following is true: 99 + 1 = 00 00 - 1 = 99
So the issue lies with the assumption that a number will fail or provide a correct value in mathematical calculations when indeed it does not. So comparing a variable with a require statement is not sufficiently accurate after performing a mathematical operation that does not check for safe values.
That comparison may very well be comparing the output of an over/under flowed value and be completely meaningless. The Require statement may return true, but not based on the actual intended mathematical value. This in turn will lead to an action performed which is beneficial to the attacker for example checking a low value required for a funds validation but then receiving a very high value sent to the attacker after the initial check. Lets go through a few examples.
Simple Example:
Lets say we have the following Require check as an example: require(balance - withdraw_amount > 0) ;
Now the above statement seems reasonable, if the users balance minus the withdrawal amount is less than 0 then obviously they don't have the money for this transaction correct?
This transaction should fail and produce an error because not enough funds are held within the account for the transaction. But what if we have 5 dollars and we withdraw 6 dollars using the scenario above where we can hold 2 digits with an unsigned integer?
Let's do some math. 5 - 6 = 99
Last I checked 99 is greater than 0 which poses an interesting problem. Our check says we are good to go, but our account balance isn't large enough to cover the transaction. The check will pass because the underflow creates the wrong value which is greater than 0 and more funds then the user has will be transferred out of the account.
Because the following math returns true: require(99 > 0)
Withdraw Function Vulnerable to an UnderFlow:
The below example snippet of code illustrates a withdraw function with an underflow vulnerability:
In this example the require line checks that the balance is greater then 0 after subtracting the _amount but if the _amount is greater than the balance it will underflow to a value above 0 even though it should fail with a negative number as its true value.
require(balances[msg.sender] - _amount > 0);
It will then send the value of the _amount variable to the recipient without any further checks:
msg.sender.transfer(_amount);
Followed by possibly increasing the value of the senders account with an underflow condition even though it should have been reduced:
balances[msg.sender] -= _amount;
Depending how the Require check and transfer functions are coded the attacker may not lose any funds at all but be able to transfer out large sums of money to other accounts under his control simply by underflowing the require statements which checks the account balance before transferring funds each time.
Transfer Function Vulnerable to a Batch Overflow:
Overflow conditions often happen in situations where you are sending a batched amount of values to recipients. If you are doing an airdrop and have 200 users who are each receiving a large sum of tokens but you check the total sum of all users tokens against the total funds it may trigger an overflow. The logic would compare a smaller value to the total tokens and think you have enough to cover the transaction for example if your integer can only hold 5 digits in length or 00,000 what would happen in the below scenario?
You have 10,000 tokens in your account You are sending 200 users 499 tokens each Your total sent is 200*499 or 99,800
The above scenario would fail as it should since we have 10,000 tokens and want to send a total of 99,800. But what if we send 500 tokens each? Lets do some more math and see how that changes the outcome.
You have 10,000 tokens in your account You are sending 200 users 500 tokens each Your total sent is 200*500 or 100,000 New total is actually 0
This new scenario produces a total that is actually 0 even though each users amount is 500 tokens which may cause issues if a require statement is not handled with safe functions which stop an overflow of a require statement.
Lets take our new numbers and plug them into the below code and see what happens:
1: The total variable is 100,000 which becomes 0 due to the 5 digit limit overflow when a 6th digit is hit at 99,999 + 1 = 0. So total now becomes 0.
2: This line checks if the users balance is high enough to cover the total value to be sent which in this case is 0 so 10,000 is more then enough to cover a 0 total and this check passes due to the overflow.
3: This line deducts the total from the senders balance which does nothing since the total of 10,000 - 0 is 10,000. The sender has lost no funds.
4-5: This loop iterates over the 200 users who each get 500 tokens and updates the balances of each user individually using the real value of 500 as this does not trigger an overflow condition. Thus sending out 100,000 tokens without reducing the senders balance or triggering an error due to lack of funds. Essentially creating tokens out of thin air.
In this scenario the user retained all of their tokens but was able to distribute 100k tokens across 200 users regardless if they had the proper funds to do so.
Lab Follow Along Time:
We went through what might have been an overwhelming amount of concepts in this chapter regarding over/underflow scenarios now lets do an example lab in the video below to illustrate this point and get a little hands on experience reviewing, writing and exploiting smart contracts. Also note in the blockchain youtube playlist we cover the same concepts from above if you need to hear them rather then read them.
For this lab we will use the Remix browser environment with the current solidity version as of this writing 0.5.12. You can easily adjust the compiler version on Remix to this version as versions update and change frequently. https://remix.ethereum.org/
Below is a video going through coding your own vulnerable smart contract, the video following that goes through exploiting the code you create and the videos prior to that cover the concepts we covered above:
This next video walks through exploiting the code above, preferably hand coded by you into the remix environment. As the best way to learn is to code it yourself and understand each piece:
Conclusion:
We covered a lot of information at this point and the video series playlist associated with this blog series has additional information and walk throughs. Also other videos as always will be added to this playlist including fixing integer overflows in the code and attacking an actual live Decentralized Blockchain Application. So check out those videos as they are dropped and the current ones, sit back and watch and re-enforce the concepts you learned in this blog and in the previous lab. This is an example from a full set of labs as part of a more comprehensive exploitation course we have been working on.
