ASUS ROG BIOS Reset on Lost Battery Power

Update 1: My ASUS laptop is ASUS ROG Zephyrus M GM501GS-EI027T. I’m using the latest BIOS version which is 313 (according to the latest version dated 08/30/2019)

Update 2: Given a CVE-2019-18216

Update 3: ASUS security team gave me the patch for the BIOS vulnerability I posted here and the patch works. I cannot reproduce the vulnerability using the previous technique described below. Thank you to the ASUS security team for a quick response to this vulnerability. Kudos!

A few months ago, I was traveling abroad and brought my superpower laptop, ASUS ROG GM501GS. At that time I departed from Jakarta, I don’t remember how many percents the battery in the laptop, when I arrived at the destination, the laptop was turned off.

Surprisingly, when the charger was plugged in, and the laptop was turned on, the BIOS configuration was reset. I knew when the laptop was turned on, the sound of the ASUS logo whizzing out again (I’ve turned off this configuration in the BIOS).

The laptop was boot normally, then I restarted it again to validate that the BIOS configuration’s correct. And it’s true, the BIOS configuration was reset, maybe because the battery was empty. If the BIOS doesn’t use a separated battery it makes security configuration and BIOS protection useless. Whereas in the BIOS configuration, we can prevent someone from booting using USB, protect the BIOS configuration with a password, configure the system to not boot without entering a password, including the virtualization feature, etc.

After coming from abroad, I made time to reproduce the behavior; this is what I did:

  1. Make sure the battery is in low condition, then access into the BIOS to make a change and save the configuration. The change in configuration can be anything. For example, I turn off the ASUS logo boot audio chime (this is just a sign for me). If the BIOS is reset, the ASUS logo boot audio will chime.
  2. Once configured, boot normally to the operating system.
  3. Use the laptop until it turns itself off; don’t do work things, remember if the system goes down anytime, your data would be lost.
  4. When the battery is completely discharged, plug in the charger, then turn on the laptop and let it boot normally into the operating system.
  5. After normal boot, unplug the charger and leave the laptop turned off until run out of battery. Make sure the operating system isn’t configured in power saving mode to save the battery.
  6. After dead for the second time, try pressing the power button repeatedly to make sure the laptop cannot start.
  7. Wait for about 30 minutes, then plug the charger again, then immediately press the power button.
  8. At this time, the laptop keyboard will light up, the laptop will restart many times, and in the end the ASUS logo boot audio sound will be chime. The chime indicates that the BIOS has been reset.
  9. If it didn’t work, repeat the steps above.

Earlier this week I contacted the ASUS security team and they responded that this was normal. Apparently the power source for the BIOS uses the same battery as the main battery and they told me that it is a new design.

I argue with the ASUS team that in my opinion, this is a vulnerability because the BIOS security configuration is made for security reasons. If this laptop is stolen (with a BIOS security configuration installed), then without the need to disassemble/remove the hard disk, the attacker can easily access the hard disk with USB.

ASUS security team accepts this and will improve the BIOS design in the future. Hopefully this can bring improvements to other laptop maker.

If there are friends and colleagues who use this ASUS ROG GM501GS,
make sure that the laptop battery is always in full condition. Do not travel using this laptop if the battery is low.

For companies, it’s best to use a laptop that has a BIOS battery configuration separate from the main battery to prevent losing the security configuration in the BIOS.

Picture taken from

CDEF Podcast: Head to Head Bug Bounty vs Pentesting

Last week, Indonesia CDEF (Indonesia Cyber Defense Community) invited me to be on their podcast on the night of September 8, 2019. It raised “Head to head Bug Bounty vs. Pentesting.” as the topic.

You can hear the topic on Spotify below (language spoken: Bahasa Indonesia)

CDEF Podcast’s usually held every two weeks and bringing up topics around cybersecurity; Incident Detection & Response, Threat Hunting, Security Hardening, Security Monitoring, Digital Forensics, Security Awareness, Security Policy, etc.. Stay tuned on the next episode of CDEF podcast.

Google Calendar Spam

Some time ago @mubix tweeted about spam that entered Google Calendar, he felt he had never published his calendar, and did not find the e-mail associated with the purchase of iPhone XS Max (according to the tweet). When I saw the tweet, I was intrigued that spammers were getting better at it.

This morning I was surprised by the notification reminder on my calendar (unfortunately I swiped it) that my Samsung S10 was ready to be taken (huh ?!).

Google is aware on this, the Google calendar team responded (in @mubix’s reply)

For recipients of calendar notifications from the spammer, you are advised not to visit the links found on the calendar. The contents of the link usually lead us to a fake form that asks us to provide sensitive information such as email addresses, passwords, telephone numbers, etc.

The malicious link on my spam calendar happened to be inactive, but still, the opportunity for spammers to trick mobile users became more wide open. Stay alert guys.

My Review on Advanced Windows Exploitation course by Offensive Security

For the past few months, I have been preparing for the Advanced Windows Exploitation (AWE) training at one of Asia’s most popular hacker conferences, Black Hat Asia 2019. AWE is one of the training organized by Offensive Security LLC, a Kali Linux distro maker (formerly Backtrack) and the Exploit-DB website (

After waiting for approximately 5 years, AWE was finally held in the Asian region (AWE is usually held in the European and American regions only). I, without hesitation, was immediately registering when in early January 2019, Black Hat Asia team revealed a list of training to be held and AWE from Offensive Security was on the list.

The training was held on March 26-29, 2019 at Marina Bay Sands Singapore. The following stories are my review of the training.

The first day, we as trainees, who filled the training room, were presented with material on how to bypass NX and ASLR in the exploit development process. Morten Schenk explained how to exploit vulnerabilities in Adobe Flash. This process includes how to get read/write primitives, ASLR bypass with the ‘memory leaking’ method, then bypass NX/DEP using ROP technique. On this first day, to be honest, I can only take 40% of the material because of the compact information provided.

The second day of the training continued the rest of the discussion that had not been completed on the first day, namely by bypassing Adobe Flash sandbox and WDEG (Windows Defender Exploit Guard) in Windows 10 Fall Creators Update (as a replacement for EMET that had expired). On this second day, we also immediately changed the case study of a vulnerability in Microsoft Edge. In this case study, we were dealing with a Type Confusion vulnerability that was discovered by the Google Project Zero team and made it exploited. The exploitation process began by analyzing the proof of concept, looking for a way on how to get primitive read/write, bypassing ASLR by ‘leaking the function pointer.’ inside Microsoft Edge.

On the third day, the discussion was even more brutal when we’re dealing with several protections in Windows 10. Morten explained well how to bypass the CFG (Control Flow Guard) and ACG (Arbitrary Code Guard). After successfully bypassing all of these protections, then ROP-based techniques can be used to gain code execution.

The fourth day, we were presented with how memory paging at Intel works, SMEP (Supervisor Mode Access Prevention), how the token privilege works and their relationship with the kernel exploitation.
Alexandru ‘sickness’ Uivalvi explained a very good material using a case study of a vulnerable Windows driver and exploited them under a least privilege user. The ultimate goal of the exploitation is to gain access to NT AUTHORITY\SYSTEM.

Pre-Exam Preparation

I filled out the exam preparation by repeating all the discussion material in the module and doing all the training exercises given. Some exploits that discuss driver exploit:

Some materials and references that discuss Adobe Flash and bypass Windows protections:

As well as several references given by the instructor during the course (I can’t share it here due to possibility of violating legal and agreement against Offensive Security LLC)

About the Exam

The time for the AWE exam is 71 hours 45 minutes; I am sure the Offsec team has well calculated the time provided.
Exam questions consist of only 2 target machines and 2 debugging machines. Unlike the OSCP and OSCE exams (which I got it pretty fast in couple of hours), I just got ‘click’ after 18 hours, really a waste of time. The toughest challenge was finished on the third day when the remaining time is 12 hours left. The second challenge is completed 1 hour before the exam time is over. I use the remaining one hour to review all the work.

The results of the exam were notified via e-mail 3 days later and I passed. I was entitled to OSEE certification, yeay!


At the end of the training, Alexandru and Morten shared that only around 30% of participants usually took the exam to achieve OSEE certification. I tried to complete the entire AWE training series, which was intended to get OSEE certification, the highest certification from Offensive Security.

AWE training is the most brutal technical training I have ever participated in, to be honest, I am very fortunate to be able to take part in this training. Thanks to Alexandru ‘sickness’ Uivalvi and Morten Schenk for the training.

AWE training at Black Hat Asia 2019