Minor linguistic fixes + added hint about buffers

problems/15.md

@@ -1,21 +1,23 @@
 # 15. Secure memory.
 
-This is the last official exercise of the workshop. But! That doesn't mean your journey ends here. Lots of more things we can do after to keep securing our bank, but lets get to that later.
+This is the last official exercise of the workshop. But that doesn't mean your journey ends here! There’s lots more we can do to secure our bank further… but lets get to that later.
 
-You may have noticed that the internals of `bank.js` are dealing with a bunch of very sensitive data. Especially the secret keys used are super important to keep secure. When we have things in memory inside applications we tend to forget that, that can be an attack vector as well. Memory might be swapped to disk in plain text or an attacker might force an application to do a core dump and to get access to the memory.
+You may have noticed that the internals of `bank.js` are dealing with a bunch of very sensitive data. Especially the secret keys used are super important to keep secure. When we have things in memory inside applications we tend to forget that, that can be an attack vector as well. Memory might be swapped to disk in plain text or an attacker might force an application to do a core dump and get access to the memory.
 
-Luckily libsodium has primitives that can help us lock down our application memory *completely*.
+Luckily, libsodium has primitives that can help us lock down our application memory *completely*.
 
 Take a look at the `sodium.sodium_malloc(size)` api exposed in sodium-native. This API allows you to make a node buffer that gives you full control over when memory can be accessed or written to. It also makes sure secure memory is never swapped to disk (this is actually protected by your OS kernel!).
 
-Using the `sodium.sodium_mprotect_noaccess(buffer)` api you can mark a secure buffer as unaccessible. This means that if any one is trying to read this memory (your own program included) it will *immediately* crash. You can then use `sodium.sodium_mprotect_readwrite(buf)` to make it readable/writable again. This is a very powerful construct as it gives you full control over sensitive memory in your application
+Using the `sodium.sodium_mprotect_noaccess(buffer)` api you can mark a secure buffer as inaccessible. This means that if anyone tries to read this memory (your own program included) it will *immediately* crash. You can then use `sodium.sodium_mprotect_readwrite(buf)` to make it readable/writable again. This is a very powerful construct as it gives you full control over sensitive memory in your application.
 
 ## Problem
 
-Use secure buffers for all secret keys used by `bank.js`, and make sure to mark them as `noaccess` if they aren't being used to encrypt/sign something
+Use secure buffers for all secret keys used by `bank.js`, and make sure to mark them as `noaccess` if they aren't being used to encrypt/sign something.
+
+Hint: Remember that buffer instances, including those created by `sodium.sodium_malloc(size)` have a `write()` method you can use to write strings into them. Just like `Buffer.from(string, encoding)`, they can accept an encoding like `'hex'`. Also, you can check whether your buffers are protected by sodium by checking the `.secure` property. 
 
 ## Solution
 
-Again test that your application still works and try making your application crash by trying to read from a buffer that is marked with `noaccess`.
+Again, test that your application still works and try making your application crash by trying to read from a buffer that is marked with `noaccess`.
 
 [Continue to extra-credit](extra-credit.md)