I've been approached once by a Café manager to fix his Point-of-Sale (PoS) system. I think it presented a very good opportunity to learn so I was curious and I took the job.
So, I was provided with a bunch of files that were somehow extracted from an old Point-of-Sale (PoS) gig, the Point-of-Sale (PoS) gig had a printer, monitor and a computer case.
The files that were provided to me contained some random files and an install.sh and uninstall.sh So I assumed it had something to do with the system that they're trying to fix.
I inspected the install.sh script and noticed that it had something to do with some Driver for the printer that is attached to the Point-of-Sale (PoS) Setup, "TM Printer", it had installation packages for different architectures and different distributions etc., so I thought it was more of an Abstract Factory Pattern sort of Installer, it would check the system to see which driver is suitable to be installed.
Now I knew that install.sh wasn't the bigger problem here.
I paused for a second and went to actually check the Point-of-Sale (PoS) System Computer and try to log in. The computer itself was running an old version of Ubuntu Linux and the login passwords and usernames were lost.
so the Manager/Workers were basically locked out and can't access it.
See if this computer was remote and not next to me physically then I would have assumed that it would be much more difficult to reset/change the passwords or perform any other max-privilege operation. But I did have physical access and I already knew that there must be some kind of way to gain access, I looked up online and found out that booting into recovery mode when the PID 1 becomes the shell itself, would give it absolute power to do anything we want.
So I did just that, I got full access, passwd user didn't work properly at first because the filesystem was in read-only mode so I booted with read-write mode and I was able to successfully change the password and I logged in.
I had gone back on my computer to check the remaining files, I saw some HTML files, opening them did nothing visually, it showed nothing at all, just a blank page, I checked the Network Traffic (API Calls etc.) and I noticed that the Javascript files of that local webpage were trying to send API calls to a specific endpoint running on http://localhost:8069, the responses were that the Endpoint was unreachable.
this made me realize that the Application backend code responsible for this isn't in the folder provided, it's on the Point-of-Sale (PoS) Computer itself somewhere.
I opened the same webpage files on the Point-of-Sale (PoS) Computer itself and this time the API calls were getting a response from some backend endpoint and the webpage was showing a welcoming text and two inputs for the Login Credentials (to the PoS software itself, not the Ubuntu OS).
So I tried random passwords and default passwords and the result was the same every time, there was a Response from the backend endpoint that the credentials are wrong.
I copied the Port that the backend process is running on, and I began looking for which process is actively listening on that port.
I found that it's a Python Interpreter interpreting some file, this led me to try to find out which python file is being interpreted. I tracked it down to some file related to "odoo", it imports a package called "odoo.addons", which means this is probably a framework and not a custom solution backend, I then realized "odoo" is installed independently and it has its own config file
the HTML Interface is the only thing custom here, the login page interface at least.
If there is a backend then it almost certain that there is a data store, a database specifically in this case, a Postgres Database. I was able to see a server of it running, which gave me an idea that the data is stored there, including the credentials of users.
I searched for the specific port and then I accessed it as root, found a couple of users after I understood (roughly) how odoo works and what schema it uses, I changed the user with id = 1 to have the credentials admin:admin so I could login the panel, I was able to log in but the issue is that one button in the interface didn't work at all, I didn't understand it at first but when I did inspect the console messages and the HTML loaded, I realized that it's some UI that hadn't loaded fully, it showed errors in console, I found some command to restart odoo's libraries, then it worked !
I found that the management side is counter-intuitive, apparently the Odoo framework itself is about 10 years old.
But yeah at the very end it was fully operational despite being this legacy.
Top comments (0)