Recently I've changed my story at some social profiles again - to this:
Specializing in: Control systems, software development for measurement data analysis, IT security, troubleshooting and reverse engineering systems with physical (hydraulic) and software (control) components.
I am running a small engineering consultancy together with my husband. We are both physicists, and we focus on designing, programming, and troubleshooting control systems for heating / solar systems, especially heat pump systems with a combination of uncommon heat sources and custom control. For more than 10 years I have implemented, reviewed, and troubleshooted public key infrastructures, and I still do this for some long-term clients.
I am blogging about this and about related science and engineering topics at https://elkement.blog.
In contrast to this blog, this site here is more of an extended profile / About Me page. It is my hand-crafted whoami machine.
I think about my exploration of layers of software. tl;dr: I am gradually moving down / back to the lower levels of software, the ones closer to hardware, electronics, control, field bus systems etc.
I've started out learning about micro-controllers in electronics class as a physics student. Then I programmed sensors and actuators for measuring the low-temperature electrical properties of superconductors as a staff scientist at the university (in Turbo Pascal). Yet I jumped up to the top of the software stack and switched to Microsoft scripting languages: VBA, VBScript, ASP when I went 'from research to IT'. Even the first version of my numerical simulation for our heat pump system was an Excel spreadsheet, then a VBA application using spreadsheets.
It seems I needed to trade 'IT' again officially for 'renewable energies' to be motivated to move down the stack again. When I was a non-traditional 'post-graduate' student in in energy engineering I was always been the 'Excel programmer' in group projects. Buth then I went down rabbit holes: Learning SQL Server and Transact-SQL for analyzing our measurement data. Re-writing the simulation software, now based on Visual Basic .NET, for the first time using a true object-oriented design. To get ready for this, I had re-written this website from scratch in .NET before. My so-called Data Kraken uses a combination of Powershell and SQL scripts today.
I finally learned to utilize all my processors in my simulation, and I fixed lots of performance issues. I read Joel on Software cover to cover to re-live the period I 'was in IT' and to catch up on fundamentals. He pointed me to Structure and Interpretation of Computer Programs which I consider the single best ever lecture / course I've ever 'attended'. It is both so deep and philosophical, and at the same time so useful: My simulations became faster by a large factor.
And all the time, I did reverse engineering and debugging. I think I have done this ever since, but always at the level I understood software at the time. Of all the tasks I had as an IT Security / Public Key Infrastructure consultant, troubleshooting weird issues with X.509 certificates was maybe the best one: Digging deep into network traces, reading up on RFCs. Every time I was theoretically only a user of software and services, I ended up debugging in detail - like using Wireshark to track down a weird compatibility issue between my e-mail client and a mail server, when just trying to sign my invocies via a digital signature solution using SMTP.
Then I finally learned C and C++, and I read about Assembly and the art of reverse engineering and malware analysis - to really appreciate the final chapters of SICP, about the self-referential wonders of compilers and interpreters.
Trying to visualize the stack and what happens to the registers, I picked up a very old book - the one I used decades ago in my electronics class - and I jumped into the chapter about micro-controllers. And then it hit me: Those fundamentals, they have not changed much. Yes, different processors have different instruction sets and you might have 8bit, 16bit, or 32bit. But the explanation about the stack, and how to return from a function - this has always been an eternal truth since that electronics book and SICP had been released.
All falls into place: Understanding C is really the pre-requisite for understanding field bus communications, and that is what control units use. Debugging skills are essential when dealing with abandoned engineering software from the stone age.
So I finally found the most logical connection between physics and IT, the place to be as a physicist in IT or in engineering or whatever.
Onword to Python!
New rules (Yes, Google - I know, I've already done this for my blog, and now you will penalize me for duplicate content as the rules are exactly the same. Not the poem of course!)
- Search for your site on Google: site:elkement.subversiv.at/en
- Pick the first search result in the language of your site
- Pick a chain of words, a contiguous snippet from this Google search result. This becomes the title of your poem.
- Label X: Copy your chosen snippet and search again, now for this phrase.
- Pick the first snippet from the new search results, choose a phrase. This is the next line of the poem; re-arrangement, editing or skipping search results is not allowed.
- Goto X.
not funny though
it often just looked unfocused
while others procrastinate
silently cursing yourself
Much energy is wasted in talking
It can be measured
to answer the following questions
Need an extra hand?
meaning, pronunciation and more
the class of ostensive definitions
words will not be understood
Word of the Day
A rapid scramble down the shattered ridge
All too soon we were on the top
And with you went my dream
I know where I was going
a 1945 romance film
A complete list
clear it to fix issues
There are a number of problems
There is or There are
what to do when it's not so clear cut
Distinctly and sharply defined
A line that represents
Tough and Tricky questions
So you think you're pretty clever?
move forward or backward to get to the perfect spot
the best way
world of dreams
extremely powerful queries
they're a lot more trouble
work you have to do for something
questioning why we don't hold different cards
which basically translates to
which basically means
we're going to take
I often say that my work is basically, most of the time, actually: Reverse engineering, finding out how stuff works, deciphering blackboxes. I refer to both software and physical systems - hydraulics - and to anything in between, control units and their logic.
Even when I was a supposed technical experts for certain (software) products what I actually did was to reverse engineer the product in question - the weekend before I demonstrated my consulting capabilities, allegedly backed up by thorough training and long-term exposure.
So I think it is worth to ponder a bit on what it means to reverse engineer.
Good-enough approach (80-20-style). I had enjoyed reverse engineering because it was different to my former life as an academic scientist. You do not need a complete theory and unassailable arguments to explain to your knowledgable peers about what goes on exactly in the blackbox. You just need to know enough to track down and solve the problem a real human being actually has. That human being might as well be yourself.
I remember the first times I solved computer problems of small business owners - based on hardly any experience and know-how, by my current standards. However, after years of exposure you might as well write an in-depth paper, but you are not forced to present your know-how in this way. You primary mode of operations is to solve problems, not to gain recognition.
Depth and breadth. It may be fashionable to say that reverse engineering certainly requires to think outside the box, and the 80-20 statement seems to imply that you don't need to bother to learn any 'theory' before embarking on a debugging venture. But if you want to become really good at troubleshooting, you better also learn the fundamentals and find a niche(s) you want to specialize in.
You focus on your specialties where you have both deep know-how and hands-on experience, and you add out-of-the box ideas related to other subjects. You stumble upon an interesting aspect and decide to learn more in depth about it. I had specialized in public key infrastructure and digital certificates, and later on heat pump systems and thermodynamics. However, when troubleshooting I might also need to learn something on-the-fly about a special CAN bus networking protocol or about heat pumps without electrical compressors.
Social engineering and no false pride. I like to work on issues that I can solve - without the need to 'escalate an issue' to some support organization in the background. However, I try to keep Geek Honor in check: You do not need to re-invent anything from scratch, and you do not need to disassemble a system in case you find the human beings who built it or at least the documentation created by them.
Social engineering can be part of reverse engineering (both terms meant in a benign way): I had social engineered my way into an organization that kept insider information like manuals or passwords, and I believe learning from your peers is an excellent way to increase your knowledge. The challenge with learning from the community is stay at eye level with your true'peers'. I had my share of encounters with suckers of know-how who only want to take but had nothing to give in return.
Against the green-field. For me, reverse engineering is strongly tied to a culture or re-use and repair, as opposed to a culture of buy and build from scratch. If you want to be creative with what is available, you need to decode the things you already have (... and after a few years of operations you might debug your own creations, no matter how excessive your documentation was.) Knowing what your gadgets do - your software, your heating system, your appliances - puts you in control.
Challenge the experts. This is closely related to the culture of re-use: If a so-called expert, certified and radiating authority tells you flat-out that this will definitely not work (often because the expert is also a supplier of new stuff he wants to sell) then you can only rely on your reverse engineering skills to prove him work.
That is perhaps the most important aspect - in our era of a growing number of interfaces with external services, clouds etc. and where you use shiny and well-sealed blackboxes that ought not to be reverse engineered at legal gunpoint.