I have had a section called Philosophy on my very first website, and I have maintained a page called Principles or Our Approach ever since. It sounds as if those principles had been decreed at one point in time. As if aliens from outer space had dictated them.
However, I could simply say this: Since decades I play with technology, science, engineering, IT and everything in between. I worked in different industries. Each of them had good and bad aspects - regarding the actual subject matter and re the way of working. My main goal and hidden agenda was to every evolve but keep the good and interesting aspects of each of them. I could spin a story about how everything fits into a grand and big picture, and it is not even wrong.
But it's a good exercise to look at everything as disjointed pieces. At some point in your life that stories should speak for themselves. I am running my own business now for a long time; I don't have to explain and justify how everything fits together - as if it was part of a great plan.
In no particular order, and without aiming at completeness...
Like the Cobol mavericks at the turn the last millennium, I support legacy Windows Public Key Infrastructures. I have migrated them over and over and over. I don't pretend I know all the latest buzz words but it seems I can catch up quickly and connect the dots.
I am herding all the software tools related to sizing heat pump systems, related numerical simulations, and data analysis - the so-called Data Kraken. I could call myself a software developer - I use languages from VBA to C++, and I use pointers and recursion now and then. But I don't mind if somebody insists this on this being 'just scripting'.
I have been doing down-to-earth IT system administration for one small business - my second ever customer, loyal since more than two decades.
I get Ask-me-anything questions related to How Stuff Works and If That Stuff is Secure or If That Stuff Can Work at All. For some of that advice people even want to pay.
If you ask what real physics I actually use, I'd say Heat Conduction. Accidentally (?) it was one my specialties at the university, a long time ago.
I work mainly remote. It's more efficient, it's cheaper for clients, I don't have to travel, everybody is more focused. I don't do political projects (anymore).
I enjoy to find the pragmatic middle ground. I don't take as gospel: Software design patterns, methodologies, engineering standards, compliance guidelines, best practices, 'what everybody says', 'what everybody does just to be on the safe side'.
Taking stock of what I had done so far, I found that two things were part of all my endeavors: Teaching/training and software development. I have also been a student in parallel, most of the time. After I gave an academic lecture about PKI for a few years, I ditched formal teaching, and having completed another master's degree I also stopped collecting degrees and certificates.
Since a while I am catching up on computer science basics in self-study mode, and this year I have discovered the joys of pen-testing.
... on a pentesting platform. that became my main 'social network'!
It feels like the natural progression from my walking down the stack: In the last year I re-lived my history of a physicist in IT or an IT security specialist trained as a physicist. I investigated the security of embedded systems and sniffed network traffic - mostly related to monitoring and control of physical devices for 'generating' or storing energy.
I wanted to fill in gaps of knowledge, I turned to classic introductions to computer science, and I caught up on C/C++ and Python. But trying to hack systems is still another kind of skill: I had been a 'defender' for many years, explaining to others how to secure their systems, but I lacked the skills of an attacker.
After I had dabbled in forensics of unknown files and in using automated testing tools with modest success, I decided I want to learn this craft thoroughly. Or was it? Maybe I just want to play and see how far I can get. It was a surprise that I was actually able to hack the entry challenge for that pentesting platform. Fast-forward: I had hacked more than 80% of the active boxes.
My experiences there are both very humbling and very gratifying. Sometimes I struggle with even getting an exploit tool to run as I lack some basic knowledge of compile switches. But sometimes I discover I can leverage some things I didn't even realize consciously or ancient things buried deep in my memory. Who knew that ASP and VBScript would ever be useful again? And my preferences of Python and C++ (for non-destructive purposes) feels eerie now - I could not have picked the languages for my exploit tools better! My adventures with learning SQL Server a few years ago also come in handy, and what I considered my most unprofessional hacks turned out to be most useful: Stringing together 'applications' from scripts and compiles code in different languages, burying one into the other, not being afraid of loads of different quotes embracing each other. As a side effect, I am also more daring when it comes to my non-malicious code now: I have no problems any more to state publicly that I write an application in C# that adds VBA macros to Excel and executes them!
My immersion in this addictive platform also told me something about my learning preferences ... again. I had known it but it was not that explicit: I want to learn from solving problems. That was my intuitive answer once, when colleague had asked how I make myself familiar with new technologies, a freshly released operating system at that time. I replied that I try to solve one specific problem on that new system (involving X.509 certificates then) - and then expand my knowledge from there. I have pontificated about my love of reading textbooks and immersing myself in abstract theory, and this is not a contradiction: Hadn't I ploughed through the later chapters of Structure and Interpretation of Computer Programs - the ingenious explanation how compilers and assembly works - I might not enjoy my attempts to create buffer overflows that much. Which is a topic I need much much more reading and playing with, by the way.
I know am saying the same things again and again and again - here, on my blog, and on social media. It seems my websites have run their course for the time being - I am not actively trying to search for new content to create, and I feel like writing articles that flow naturally, rather than writing semi-scholarly papers with code and data. So I am leaving this article here, on the site that nobody reads, as a hidden away note maybe.
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.