Category Archives: Uncategorized

DFIRSummit Laugh Track

First, thank you to everyone for humoring me and submitting jokes. If we cannot laugh at ourselves, we are way too serious. Here are some of my favorites from the DFIR Summit. On a positive note – always try to find the humor in the situation. Especially with all that 2020 has thrown our way. Laugh and smile. 🙂

*Due to covid-19 all TCP applications are being converted to UDP to avoid Handshakes..!!

*Bill Gates walked into an APPLE store and farted but it was APPLE’S fault that they had no WINDOWS

*Do you know why I like UDP jokes?” “I don’t care if you get it or not.

*Why doesn’t Tigger have any friends? Because he plays with Pooh!

*What concert costs just 45 cents? 50 Cent featuring Nickelback!

*This graveyard looks overcrowded. People must be dying to get in.

*On a Friday, its a five minute walk from my house to the bar. It’s a 35 minute walk from the bar to my house. The difference is staggering.

*How can you find a blind man on a nude beach” … come on… it’s not that hard.

*What do dentists call their x-rays? Tooth pics

*Why did the first restaurant on the moon go out of business? It had no atmosphere

*Why do ducks have feathers? To cover their butt quacks!

*My friend said he didn’t understand what cloning was. I said that makes two of us.

*A guy walks into a psychiatrist office fully naked and wrapped in saran wrap from head to toe. The Psychiatrist says I can clearly see you’re nuts.

*Where did the software developer go?! I don’t know, he ransomware!

*I once started a band. We were called 999MB. Unfortunately, we broke up because we couldn’t get a gig.

*When does a joke become a ‘dad’ joke? When it becomes apparent.

*Which computer has the best voice? A Dell.

*How do astronomers organize a party? They planet

*I always knock on the fridge door before opening it. I do it just in case a salad is dressing!

*At a job interview I continued filling my glass of water until it overflowed. “Nervous?” asked the interviewer. “No, I always give 110%”

*Why do milking stools have 3 legs? Because the cow has the udder

*Want to hear a construction joke? I am still working on it!

*Did you hear about the guy who invented the knock-knock joke? He won the ‘no-bell’ prize.

*what made the tomato red/blush? it saw the salad dressing

*a pirate walks into a bar. the bartender notices a GIANT ship steering wheel coming out of his pants. the bar tender asks “hey man, whats with the giant wheel?” the pirate answers (in pirate voice): “Yarrr, its driving me nuts”

*I pulled a muscle digging for gold… Just a miner injury

*I would not buy anything that’s Velcro, it’s a total rip off

*Why did Adele cross the road? To say hello from the other side

*What happens when you go to the bathroom in France? European

*One snowman turns to another snowman and says… “Is it just me, or do you smell carrots too?”

*Where did the military hide their armies? In their sleevies

*What do computers and air conditioners have in common? They both become useless when you open windows.

*There was a gorilla in my garden this morning. He stole my gnomes, my gate, my lawnmower. I didn’t want to say anything in case he took offense.

*Does anyone have any good elevator jokes? They’re just good on so many levels!

*I applied to be a doorman but didn’t get the job due to lack of experience. That surprised me, I thought it was an entry level position.

*I tell dad jokes, but I don’t have kids. Does this make me a faux pa?

*How many developers does it take to change a light bulb? None it’s a hardware problem.

*What are you called if you see a crime at an Apple Store? – An iWitness

*Why should you never trust stairs? They’re always up to something.

*What kind of shorts do clouds wear? Thunderpants

*Why did the duck get arrested? For selling quack

*How much do pirate earrings cost? A buck an ear.

*Have you heard the steak pun? It’s a rare medium well done.

*what did the fish say when he hit the wall…dam

*Why don’t ants get sick? Because they have little antibodies

*What do you call an elephant that doesn’t matter? An irrelephant.

*A chicken coup only has two doors. If it had four, it would be a chicken sedan

*I hate when my wife gets mad at me for being lazy. It’s not like I did anything

*What type of shoes do frogs wear? Open toad

*Why didn’t the invisible man take the job? He couldn’t see himself doing it!

*I take an extra pair of pants when I golf, just in case I get a HOLE IN ONE!

*I got fired from my job at an orange juice factory, I couldn’t concentrate properly

*My wife just completed a 40 week body building program this morning It’s a girl and weighs 7lbs 12 oz

*Researchers have discovered a pod of whales playing instruments. It’s an orca-stra

*bought a cute dog a few days ago. Every time when the doorbell rings he goes to the corner….. it’s a boxer

*Don’t worry if you miss a gym session. Everything will work out.

*What do you call it when Batman skips church? Christian Bale

vWhat do you call a cow that just gave birth? Decaffeinated

*What didn’t the toilet paper cross the road? It was stuck in a crack

*What do sprinters eat before a race? Nothing. They fast

*Why are spiders so smart? They can find everything on the web.

*Why did the cryptographer send back his breakfast? Because the hash wasn’t salted.

*How do you make a tissue dance? You put a lil boogie in it

*Why do cows wear bells? Because their horns don’t work.

*How does a computer get drunk? A. It takes screenshots.

*What do you call it when you have your mom’s mom on speed dial? A. Instagram.

*A man was talking with a psychiatrist saying, “I’m a teepee. I’m a wigwam. I’m a teepee. I’m a wigwam.” The psychiatrist said, “Relax man, you’re two tents.

*why can’t you run while camping? You can only ran because it’s past tents

*Why do cows have hooves and not feet? They lactose

*I went camping, it was intents

*Why can’t a nose by 12 inches long? Because then it would be a foot

*I changed all my passwords to Kenny. Now I have all Kenny Loggins

*How do you make holy water? You boil the hell out of it

*It’s hard to explain puns to kleptomaniacs because they always take things literally

*What is the only car that can safely drive over a speedbump at 70mph?A rental car

*How do you get a squirrel to like you? Act like a nut

*Knock, knock Who’s there? Little ol’ lady. Little ol’ lady who? I didn’t know you knew how to yodel.

I hope you enjoyed the DFIRSummit. 🙂

“Life Has no ctrl+Alt+Del” – The New DFIR online Meetup

A DFIR Meetup

Most important – Sign up here:

Working from home, social-distancing, travel restrictions, and homeschooling all related to COVID-19 have changed our lives. The new normal is not always fun, to be honest. This is why “Life Has No Ctrl+Alt+Del” was created. I wanted a forum where we could casually get together, but also include a way for us to stay engaged.

This is an online meetup/show that happens several days a week to enable you to listen, see and share with others in this community. It is not a formal presentation, sales pitch or place to bore you. It’s an open forum where anyone is welcome to speak! This meetup is supported by Cellebrite, but it’s not a Cellebrite centric event – it’s a DFIR event. Curious, join for at least one!

Name: Life Has No Ctrl+Alt+Del

Link to register:

When: March 30th week – every weekday; after that M, W, F weekly

Host: Heather Mahalik (may have subs, if needed)

Guest Stars: Announced Weekly – Each star will decide if they want it to be recorded – all recordings will be shared!

Hashtag: #DFIRatHome

When you think of this show, I want you to imagine having lunch with friends when a cool conversation spikes. It’s literally that relaxed! I hope to see you on the show soon.

Twitter: @heathermahalik

Twitter: @Cellebrite_UFED

2020 Forensic 4Cast Nominations are open!

I have been meaning to get this out for a bit, so here it is. Something has been keeping me busy – you know kids, work, SANS and being all in the same place together 24 hours a day. 🙂

The forensic 4Cast awards by Lee Whitfield have really become quite a “thing” for many. It’s such a great idea and Lee, well done. You , my friend, give people and companies some to strive toward and I love it.

To nominate- click here:

Let’s get right to it. Opinions are my own and for that if you do not like them, no need to worry. Everyone has their own opinions and some simply want recommendations. Do I work for a vendor – yes. Do I sell training via SANS – yes. Do I have my own brain – YES!

I give a brief snippet for some, but not all. If you want to know who I really nominated, ask me. 🙂

DFIR Commercial Tool of the Year

  1. UFED Ultimate
  2. Elcomsoft Cloud Tools
  3. Oxygen Forensic Detective
  4. Magnet AXIOM

DFIR Non-commercial Tool of the Year

  1. iLEAPP
  2. KAPE
  3. Sysdiagnose scripts – Mattia Epifani, Adrian Leong, Heather Mahalik

DFIR Show of the Year

  1. DFIR Summit – Austin, TX
  2. Techno Security
  3. DFRWS

DFIR Blog of the Year


DFIR Article of the Year

  1. – shameless plug, but I put a lot of time and research into this right when it was released. 🙂

DFIR Social Media Contributor of the Year

  1. Heather Mahalik
  2. Alexis Brignoni
  3. Sarah Edwards

DFIR Degree Program or Training Class of the Year

  1. Cellebrite CCO/CCPA
  2. SANS FOR585
  3. SANS FOR498

DFIR Groundbreaking Research of the Year

  1. Cellebrite – checkra1n jailbreak development
  2. Sysdiagnose research – Mattia Epifani, Adrian Leong, Heather Mahalik
  3. Axi0mX – checkm8 –  need I say more?

DFIR Newcomer of the Year

  1. Geraldine Blay – She lives for DFIR, tests for everyone and is starting to blog
  2. Josh Hickman – Blogging, providing public images and staying on top of forensics

DFIR Mentor of the Year

  1. Alexis Brignoni – community contributions and work
  2. Scott Lorenz – EDL support and guidance

DFIR Resource of the Year

  1. Cellebrite Ask The Expert (Tip Tues, ATE series) – Provides snippets of information to make you smarter each week.
  2. Heather Mahalik – Cellebrite 😉 – Yes I am laughing, but again with the busting my butt thing to spread knowledge
  3. Digital Forensics Discord- A. Rathbun created this and it rocks

DFIR Team of the Year

  1. Cellebrite – I love my teammates. My SANS teammates wonder who I love more.
  2. SANS – See item 1
  3. Magnet – I have tons of friends at Magnet and they have good morale

Digital Forensic Investigator of the Year

  1. Mattia Epifani – He researches, blogs, teaches and PRODUCES! This man never sleeps.
  2. Shafik Punja – Continuous support to detecting and reporting bugs to vendors to make DF better for everyone.
  3. Ian Wiffin – Thinking outside of the box and developing tools to fill the gaps that commercial tools have yet to address.

So, some shameless plugs in there, but why not – my opinions right? Some categories were harder than others to pick just one, but you have to go with your guy. You will notice that I didn’t nominate Eric Zimmerman (my good friend) for Investigator of the Year. He is the Meryl Streep of the 4Cast! Time for the Hall of Fame Eric. 😉

Nominate now –

iOS 13 – Summary for those of you who enjoy the cliffsnotes

For those of you who don’t have time to read, here is a mini summary for you.

First – If the backup is NOT encrypted you will not get:

  • Maps
  • Calls
  • Safari
  • Health
  • Keychain
  • Wallet

Apple has upped their game on protection it seems, so you need to encrypt to extract. I used iTunes in my full blog and just testing PA 7.24 Method 1 with encryption and Method 2 is in progress. Worked like a charm and I got what I expected. You lock it up, or you don’t get much. Bottom line. Jessica Hyde wrote a post on protecting yourself from an accidental sync if using iTunes to create a backup: If you are using PA, you are protected from this.

While you are going to be forced to read the long blog for the juicy details, here are the file paths you need to be aware of for iOS 13:

  • Contacts /var/mobile/Library/AddressBook/AddressBookImages.sqlitedb
  • Calls /var/mobile/Library/CallHistoryDB/CallHistory.storedata
  • SMS /var/mobile/Library/SMS/sms.db
  • Maps /var/mobile/Applications/
  • Safari /var/mobile/Library/Safari/History.db
  • Photos Database /var/mobile/Media/PhotoData/Photos.sqlite

The biggest change other than encryption seems to be the use of protobufs, which Sarah Edwards is working on a blog to discuss, settings and how that may determine what is saved to device vs. cloud, Safari artifact storage, and encryption. Please read the full blog for all of the good details and stay tuned for my iOS series, webinars, etc.

Stay tuned for the release of PA 7.24 next week and also for #TipTues on Twitter where I will provide something useful, I hope. 😉

…Won’t you back that thing up: a glimpse of ios 13 artifacts

Don’t lie – the song is already in your head. And if not, maybe it will be by the end. If you know me, titles/taglines, whatever you want to call them, are not my thing. But since testing iOS 13, I feel like I have backed that thing up a billion times! I dump, I examine and then realize something so I then add/delete that “thing” and repeat. Hence the name of this blog!

First things first, Apple didn’t appear to mess with us too much with this update with a few exceptions. First, encryption is everything! Some artifacts moved, while others are back again (pending settings on the device) , some can be controlled by the user and some just stayed the same. For the artifacts that moved – this is where you need to TEST YOUR TOOLS! Do not trust a blog post from a vendor (even one from me) – TRY IT FOR YOURSELF. Testing and validation is so important. There are so many bugs in tool releases and even false claims of support. Try it and then rely on it.

At the time of writing this, Physical Analyzer Method 1 and Method 2 were not supporting iOS 13. A little birdie tells me it will be released next week and I may have seen the beta. For the tools that did acquire, iTunes was used. When this is the case, I just use iTunes so I can control the environment. I like to encrypt my backups because I want Health, Keychain, Safari, Calls, Maps and Wallet, but I did conduct an unencrypted one for comparison and for parsing in one tool that will be discussed in a bit. Did you notice I said Safari, Maps, and Calls in an encrypted backup – yep – stay tuned.

And then I did it again with 13.1 because I didn’t get my blog out fast enough. 🙁 So this blog really covers both, not that I expected major changes in a tiny update.

The backup content looks similar to iOS 12. The major difference was the name of the backup, which is shown below. The top backup is from iOS 13 and the bottom from iOS 12, but the hardware is different.

Bottom line – until I test the full release of Method 1 and Method 2 in PA and fairly compare it, I recommend doing an encrypted iTunes backup and here is why.

Artifact Locations – The good stuff

For this post, I tested my usual suspects of artifacts. The ones that every device should have. Contacts, Call Logs, SMS, iMessage, Maps, Photos, and Safari. Here is what I found:

Artifacts with no path changes or anything drastic:

  • Contacts/var/mobile/Library/AddressBook/AddressBookImages.sqlitedb
  • SMS/iMessage/var/mobile/Library/SMS/sms.db

My buddy Jared, who also enjoys 90s hiphop pointed out something cool to me. Look at the message below. For anyone working distracted driving cases, this could be amazing for you. Look how the messages were sent! I’m in a rush to get this out, so I hope something like this will be a quick #TipTuesday on where it exists in the sms.db. Thanks Jared!

  • Photos/var/mobile/Media/PhotoData/Photos.sqlite (nothing major about the graphics jumped out upon initial review.

I have been asked so many questions about photos.sqlite lately that it will also be a blog of its own. There is so much goodness contained there! I plan to do another blog on deleted artifacts and how to recover, if possible, so watch out for that. For fun – this is a screenshot I took today to share with Paul all for the fun of testing. You never know what I may share, right Sarah? 😉 Honestly, if you cannot make fun of yourself – you need to relax.

Artifacts with minor changes:

  • Calls/var/mobile/Library/CallHistoryDB/CallHistory.storedata

 For Calls, the data remains the same, but you need an encrypted backup to get the data. Additionally, one file was added –CallHistoryTemp.Storedata. Mine had nothing of interest, but keep an eye on this bugger. It was put there for a reason, I just don’t know the exact one yet. I initially thought that AXIOM missed the calls, but realized I gave AXIOM and unencrypted backup so it could handle the file system view.

 It is worth noting that I deleted a call and could not find it in the free pages of CallHistory.storedata. I tried Physical Analyzer, Oxygen (the trash can feature), BlackLight, AXIOM, Forensic Browser for SQLite (Paul Sanderson) and Mari’ Degrazia’s awesome script And guess what – I didn’t find the call. So more on that in another blog. I bet it’s in the cloud… 

  • Health – (yes, I snuck this one in here because it is so valuable) /private/var/mobile/Health – examine the healthdb.sqlite and healthdb_secure.sqlite databases and take note of the new ones. I will write a complete Health blog soon. The tools may not be parsing everything, so refer to the presentation Sarah Edwards and I gave a few years ago:

I do have to call out Oxygen Jet Engine here, who did a nice job on Health. Well done on connecting the device, OS version and locations. See a snippet below. More on this in my Health blog, where I plan to include Android health as well.

Apple switched the path up again – READ this part:

  • Safari/var/mobile/Library/Safari/History.db

IMPORTANT – the history.db is NO LONGER in! See below. Here we have a visual of what is included in mobilesafari for an encrypted backup. The history.db. is no longer here. (NOTE: I would  examine all of these databases for relevant info. Mine didn’t have much, but I prefer Chrome.)

Take note here – at the time of testing, not all tools parsed Safari history! I assume they thought the database would remain in mobilesafari and guess what – that no longer exists. We are back to good ‘ole history.db in it’s first home in the Safari directory. Physical Analyzer, BlackLight and AXIOM parsed all of the searches I conducted in iOS 12 and 13 if an encrypted backup was obtained. NOTE – you will not get safari history in unencrypted backups anymore. You will simply get bookmarks and the dummy login for Safari, as shown below.

Additionally, it appears that Safari has moved all of the history data, which is uncommon. This history included much more data than that of iOS 13 and what is show below is history from May 2019 to present. 🙂 Makes it easier on us. Thank you Paul for sharing yours – again, I use Chrome. 

For the tools that didn’t parse Safari history, the database was there and the searches were as well. So they just need to catch up. I will explain which tools missed the artifacts at the end of this blog.

Something else worth noting is that it seems like Safari wants you to go into Private Browsing when you launch it. If this happens, you won’t find anything in history.db. Verify the setting on the iPhone. The user may not even realize it’s happening, which is what occurred while Paul and I were conducting our testing over the past few days. Screenshot of what this looks like for the user is below. Note, once Private is exited, all history is capture in an encrypted backup or Method 1 in PA.

In summary – for Safari, you MUST have an encrypted backup or an encrypted Method 1 from Physical Analyzer. I know this because we tested the beta of PA 7.24 and it works like a charm.  If it’s not encrypted by iTunes or the tool – you will not gain access to  Safari/history.db.  If the user last used Private browsing and did not close Safari, chances are good you will also get nothing. If you want to find Private Browsing traces – sign up for FOR585 Advanced Smartphone Forensic Analysis In-Depth and we will teach you.  

It’s back – well, depending on your settings!

  • Maps/var/mobile/Applications/  – older searches – pre iOS 11 and /var/mobile/Applications/ – iOS 11 and newer searches

I have spent years on Apple Maps. Literally years… While it’s back, only some tools only parsed history.mapsdata! Again, make sure you use a tool that will parse both history.mapsdata and Geohistory.mapsdata. Verify the source of the data for everything parsed as your first clue. This is super important to ensure you aren’t missing information. Vendors – again, make sure you are doing this correctly. I found major gaps. This is what it looks like when the tool does it’s job.

You should also be able to manually examine the Geohistory.mapsdata file for confirmation.

If you see nothing at all for Maps, the user probably enabled the cloud setting for Maps, which seems to skip saving anything to the phone other than the which stores the last search in Apple Maps and can be found here: /var/mobile/Applications/ If that isn’t the case, you need to choose a tool you know properly parses Apple Maps.

Here is what the setting looks like that may keep Maps from being saved to the device. I have Maps turned off for iCloud, so the data was saved to Geohistory.mapsdata on my iPhone. On Paul’s device, his was turned on and he didn’t have a Geohistory.mapsdata. The settings seem to control what we can extract. You need to pull iCloud information to extract this and Elcomsoft does a fantastic job.


Tool Support

I’m not hiding, I swear!

If you are wondering where I have been, the answer is easy – busy! But I haven’t been ignoring you. Since joining Cellebrite, I have been working on sharing my research through their channels. To be honest, between that and SANS, I haven’t had time to blog on my own. So, here is just my promise to you – I will have another blog on here soon. Most likely on mobile acquisition techniques and iOS 13. I need to update some of the older posts anyway.

If you have missed my work, check out the following new stuff:

Cellebrite Webinar – Mastering the Mobile Device Challenges in eDiscovery – Do not let the term eDiscovery sway you from listenting to this. Here, I provided a preview of Physical Analyzer 7.23 as well as hints on what is coming in new releases. Learn about redaction, advanced searches and Legalview.

CellebriteWebinar – – Fantastic Android Encryptions and How to Defeat Them – ‘nuf said 😉

Cellebrite Blog

Cellebrite Blog

DFIR Summit Presenation – Sarah Edwards and I researched and presented artifacts relating to iOS CarPlay and Android Auto.

Coming soon:

Cellebrite Connect events – San Fran and Chicago –

SANS – FOR585 – updated cheat sheets – waiting on iOS 13 to officially be released – Keep your eye out alumni!

Podcast – Cyber Security Interviews with Doug Brush – (not yet published) – A video series with methods, tricks and just concepts you should know for investigations. I plan to blog for each one of these.

OSDFCON – iOS Sysdiagnose Bugs – Speaking with Mattia Epifani

ICAC NW – Speaking on Smartphones: How to Reach the Summit When You Have a Mountain of Data

DFIRCON 2019 – Teaching FOR585, Running DFIR Netwars with Eric Zimmerman and doing an @Night on A Wild Goose Chase: Hunting For Hard to Find Smartphone Apps and Malware

Published articles – I will tweet about them

A new podcast… just wait for it! I am better at talking when I think of something vs taking the time to write it all down. This is going to be fun!

As always, I will be teaching FOR585 around the world so look out for me. to see where not only me, but the team of instructors who support this are also teaching. We hope to see you there.

How was an iPhone setup?

I’ve realized just how important it is to blog vs just do a webcast when I was completing my course updates. I would stumble upon a webcast, but didn’t have time to watch it, so I looked in another direction. This made me realize that I should write down everything I put into a webcast. Will a webcast hold up in course? Do you have time to watch all of them? Seriously, I am curious about the impact so please let me know.

In 2019 – I am going to write down what I talk about in webcasts. If I have the time, I may try to blog about my speaking events as well (think Keynotes and SANS @Nights). Some blogs may be short and sweet, but this way when someone says, “how can I do X” I will point them to my blog. 🙂

To kick this one off, I am going to simply discuss a file that stores information on how an iOS device was setup. This is a file that I am asked about a few times a week. In many cases, it matters if the user synced from iCloud, started from scratch or restored from iTunes. So here goes!

First, you should be obtaining an encrypted backup at a minimum. If you have the ability to get a full file system dump, even better. Without encryption, I cannot guarantee that all of the files I plan to discuss in upcoming blogs will exist. Make sure your analytical tool of choice will decrypt the data. If you are trying to do this for free follow the steps below.

Creating and parsing an encrypted iOS backup for FREE:

  1. Launch iTunes on your forensic workstation. Update if necessary.
  2. Make sure you Trust the computer on the iPhone.
  3. Create an encrypted backup with a password you will remember (yep, people forget all of the time!)
  4. If you aren’t using a commercial tool or one that supports decrypting the backup, you may have to get crafty. I stumbled upon AnyTrans during my updates and it’s pretty sweet. To use this, you must know the password or crack it (refer to other blog posts in my archives.)
  5. Launch AnyTrans and it will show you if you have locked backups.

6. Select the locked backup (you know it’s locked because the option is to “unlock” it.

7. Enter the password and the backup will be unlocked! The top portion shown below is how the backup directory will look. The original backup remains and the unlocked version is called BackupUnlock. If you peek inside that directory, you will find the backup with the date it was unlocked.

8. From here, you can load the unlocked backup into iBackupBot or your tool(s) of choice (iExplorer, etc.). Note: Some commercial tools HATE this format and will not support it. The free ones seem happy enough!

Now let’s get to that file you care about. Once your backup or image is loaded into your tool, you need to locate the following file: /Library/Preferences/ I normally just search for purplebuddy.

This plist stores the SetupState of the device which will tell you how the device was setup by the user.

If the user selected to restore a backup from iCloud, the will show:

If the user setup the iPhone using iTunes, the will show:

It is worth noting that I am testing on an iOS 12.1.x device and I restored from iTunes in 2 ways to obtain these results. First, I wiped and set up via iTunes and then I also forced a restore of a backup via iTunes. I wanted to be sure the SetupState didn’t change. If you find that the user restored from iCloud, consider pulling cloud data if you are legally capable of extracting that form of evidence. Should you find the user restored from iTunes, you now have to find that host computer to do analysis on other potential backups. This is where the fun begins!

Bottom line, Apple has a ton of plists that are relevant. You need to hunt for them. Do a keyword search, dump your device (yep, use the free way I described above) and VALIDATE!!!

If you want to watch the webcast, check it out here:

CAUTION: iBACKUPBOT and iOS10+ potential issues.

Below I am attempted to do the same thing with iBackupBot, but I ran into iOS version issues.

  1. Launch iBackupBot
  2. Make sure you Trust the computer on the iPhone.
  3. Create an encrypted backup. Notice that the tool is telling you that Backup encryption is turned on? This is good.

4. Select where to save the backup image. I recommend into your case directory for the investigation.

5. The backup will be created and then you can open it in iBackupBot for analysis. Once the backup is complete, it will prompt you to open it. If you have issues, this is an iOS10 error from what I have seen. :/ At this point, revert to iTunes.

Determining when an iOS backup was created

One point of contention in the FOR585 Advanced Smartphone Forensic class is – which files store the correct datetime for when a user created an iOS backup?  I’ve engaged in a few friendly arguments over this topic and it recently popped up again when Lee was teaching in NYC in August. Every time this question comes up, I test it again. I have probably tested this more times than I should have, which is why I am finally putting it in writing.

So, when you are asked – “When did a user last create an iTunes or iCloud backup?” – You can answer with confidence next time.

The first thing to consider is what you are examining. Are you looking at a backup file extracted from a PC or Mac? Are you looking at an iCloud backup? Are you looking at a file system dump created by a commercial or free tool? If you are looking at a backup (iTunes or iCloud) this process is a lot easier. If you are looking at a file system dump created by a tool, this is where the confusion may set in. I hope this blog makes your examination easier by breaking down what is happening for each file. For this test, I used my own iPhone that I use every day. Why? Because I know when I backup and I can then verify dates.

The files we are going to examine for backup datetime activity include:

  • info.plist
  • status.plist
  • manifest.plist
  • device_values.plist

All of these files are important, but the dates inside of each may vary and a smartphone tool may update the date inside of the file. If you are looking at a backup that was extracted from a PC or a Mac, the status.plist will contain the start date and time for an iTunes backup.  The info.plist also stores a datetime and whether the backup was successful (snapshot state), but it is not the start date. It is often the completion datetime and doesn’t state if the backup was successful, which is why I rely on the status.plist, when the file is available. The manifest.plist is more helpful when it comes to dealing with locked backup files that need to be cracked. The date in the manifest.plist is often the same as the date in the info.plist and again this file does not track if the backup was successful or not.

Now here is the tricky part. If you completed a file system dump of an iOS device, the following files will most likely show a date that is NOT when the user created a backup. This date will be when you created the forensic image. This makes people uncomfortable, but it makes sense if you think about it. iTunes (or a process like iTunes) is most likely being used in the background to create the forensic image. It makes sense that these datetimes would be trampled. In this case, I rely on device_values.plist which remains untouched by any tool or method you use to create a forensic image of an iOS device.

At this point I have either confused you or validated what you already know. Either way, let’s take a look at my test.

I dumped my iPhone using Cellebrite Physical Analyzer Method 1. I only did Method 1 because I wanted to make sure that it pulled the device_values.plist and I was doing this test during a lab and didn’t have much time. NOTE: I have noticed in the past that this file may only be pulled using Method 2, so use both just in case. If you are wondering why I recommend both of these extraction methods refer to my previous blog posts. I completed this extraction on August 18, 2018 around 14:20 (I had a few connection issues and had to troubleshoot which is why I state “around”). I did not backup my device at this time other than using my tool to create a file system dump (aka – I did not launch iTunes and create a backup).

The info.plist is shown below. Notice the timestamp matches the extraction completion time and NOT the time the device was backed up by the user? If you used a commercial tool to acquire the device, simply look at the Extraction details to compare extraction time.

Next, I looked at status.plist. Again the date is NOT when the user backed up the device. This is when the extraction completed in Physical Analyzer.

Finally, we look at the manifest.plist. And we see the same date, but a time that occurs before the times in info.plist and status.plist.

I believe this is when Cellebrite scans the phone to determine if the tool should present you with the check box to encrypt the backup, or not, if the device is already encrypted. This is also around the time I started the extraction.  So, this is really just showing you how long the Method 1 extraction took and has absolutely nothing to do with when the user last created a backup. Now we look at the device_values.plist and we get the correct answers.

Not only do we get to see datetimes for iTunes backups, but also iCloud, if the user has ever backed up to cloud under We simply have to decode our datetime stamp for the LastiTunesBackupDate and we get June 4, 2018 at 21:32:42 Eastern Time. (Note: I normally keep it at UTC, but I know when I created my last backup in local time and wanted to compare).

So, in short the forensic extraction methods will update the datetime in status.plist, info.plist and manifest.plist during the acquisition process. If you are conducting analysis of an iOS device image (not a backup) you should rely on the datetime recovered from device_values.plist. If you are dealing with a traditional backup file, use the status.plist for the datetime on when the last successful backup was created.



Forensic Grunt Work

Looking to blog and don’t know where to post it? I am happy to host your thoughts for you. Below is the first guest blog post by a past FOR585 student. If you have something to write about, please let me know. 

by Terrence D. Williams

I have revisited this same post in my mind nearly fifteen times a day. It finally hit me. It hit me a little harder than I expected but the topic was pretty apparent to me. Until I was driving down the road to work, I didn’t understand the purpose of many of the tasks I completed in my early years in the Marine Corps. When I first entered the Corps, I had a lot of functions that seemed purposeless. All these actions are something that I call “grunt work.” Grunt work can be categorized as all the long, tedious days of doing tasks that seem meaningless, but in the future, they become muscle memory.

Forensic grunt work hurt me because I did not understand why I needed to stare at a computer screen day in and day out, learning about various computer technologies. It dawned on me when I was driving down the street how I should have put in the work in the early days of my forensic career. I wanted to build a Python XML parser that could convert the output from one of the live forensic tools utilized by my team. My problem was that I did not know a lick about XML. I mean, I did not know about the root, the children, nor the elements. These are basic terms that are present in the popular XML language. I couldn’t fathom how my biggest problem in the situation is that I didn’t know the basics of XML.

Forensic grunt work helped me because the Marine Corps inadvertently taught me how to develop skills that become muscle memory. Over the course of two weeks, I read possibly twenty different articles about the structure of XML. Once I knew the basics, I began to combine my Python knowledge with my new XML knowledge. I was spending about 4 hours a day playing in Python’s interactive mode trying to see the many ways that I could build the original program that I set out to create back in July. With the help of Stack Overflow and the SEC573 SANS course, I was able to build the program that allowed me to parse the XML output from the tool to make my team more efficient.

How does Forensic Grunt Work work? It is a somewhat simple process. If we only limit the forensics world to Windows Operations Systems, Smartphones, and Network Security Monitoring you are still looking at more than a year’s worth of reading material. If you are a Mike Ross (a USA Suits reference), then this will be an easy task for you. You will be able to read each book and article one time and remember every single detail that you previously read. Unfortunately, you are most likely like me. You will read it once or twice, then use it as a reference book for the future because everything didn’t stick. This is where forensic grunt work comes into play.

2018 is the probably one of the greatest times to learn forensic skills. After reading “The Importance of Deep Work & The 30-Hour Method for Leaning A New Skill” by Azeria, I have developed my process of using Grunt Work to my advantage:

  1. The Prep Work
  2. Pick a skill that I need currently or will need in the future
  3. Open the calendar app in my iPhone, to make me a study schedule of 30 hours. Monday – Friday: 4 hours, Saturday – Sunday: 5 hours
  4. I am a tech junkie, so the best way to establish my schedule is to use technology. When a calendar alert is scheduled, my phone tells me, my watch tells me, my home system tells me, it pops up in my car, and it lets the people I share with that I have something scheduled
  5. I break my daily sessions into 2-hour sessions. One session in the morning and one session at night
  6. I know myself, so 4 hours is not the starting point for me.
  7. During my sessions, I turn off the TV and place my phone on Do Not Disturb
  8. The Grunt Work
  9. Gather the books and articles related to the subject
  10. First 10 hours of the work will be reading and note taking
  11. Build a lab environment
  12. The lab environment is a simple setup that typically involves one or two virtual machines
  13. I tend to use open source tools that are easy to obtainable to not detract from my work

iii. Lab build is 2 hours

  1. Goal setting
  2. I write down the goal from the prep work stage in multiple locations.
  3. The goal is to be able to see it to allow me to stay on task
  4. The Grunt Work
  5. The last 18 hours of my process is dedicated to the skill development
  6. I begin in the lab environment by exploring the environment in relation to the goal

1) If the goal is to understand XML, I open the document in a text editor to see the format. I open the same document with the various tools to see how the tool will present it. Then compare the tools to the text editor.

iii. I begin to replicate the examples I found in the books and articles.

1) If the goal is to build the XML parser, I copy the examples in the books and articles. I slowly transform the examples to fit the current XML file I want to analyze

  1. I now assign some challenges for myself that I think will help me get to the end goal

1) What if I don’t want all the XML file, how do I alter it?

2) What if I want to have pieces of the file that I will want consistently, how can I loop through it?

  1. Finally, I apply the goal to challenges that others have had with similar goals

1) Go through stack overflow to see the questions that are similar to my goal

2) Can I answer their questions in my lab?

  1. a) If not, revisit the examples and challenge steps above.
  2. Post Work
  3. Save the books, articles, and notes for later reference
  4. Clean the material into an easily searchable format for me

For me, the above process is excellent. For someone else, the process will not be what he or she needs. The goal is not to repeat my process verbatim, but to make you’re 30-hour process in the same way. The process is a condensed Grunt Work model that will be an introduction to a new skill. The overall grunt work process will transform you into a master of the skill the more and more you apply the skill over your career. Challenge yourself to push past your comfort point in learning. To push myself, I will eventually work up to the point where my 30 hours are broken up into 4-hour sessions. Make it work for you. Good luck in beginning the skill learning process of grunt work.

Smartphone Acquisition: Adapt, Adjust and Get Smarter!

June 25, 2018

I have been recently asked by students for a summary on how to handle smartphone acquisition of iOS and Android devices. I have avoided writing it down, like I would avoid the Plague, because mobile changes so quickly and I don’t want people to read something and live by it. I wrote this on my plane ride to Vancouver, so forgive any typos or briefness in this blog.

With that said, these methods are what work for me today. Others may prefer different methods, and that is great. If we were all the same, this would be a boring community, right?

This blog contains what I do on a normal basis when it’s possible. Anyone who conducts mobile device forensics knows that everything changes so quickly and what is possible today may require modification to work tomorrow. We adapt, adjust and are smarter because of it. 🙂

What I decided to do was to focus on Android and iPhone for this blog. Most of you have your favorite vendor tools and that is great. I recommend you use more than one because not one of them is perfect. Don’t become so reliant on one method that you avoid opportunities to test other tools and that you rely so much on a single tool that cannot extract data properly. I am avoiding listing tools specifically that I prefer because I have blogged on that in the past . I am simply defining steps I take that work and you can use the tool of choice to accomplish the following. Remember, it doesn’t have to cost the most to work the best! Sometimes the free methods give you the most data.

Android Acquisition Recommendations

Android devices are becoming increasingly difficult to acquire. We have seen many devices now where basic information (photos, contacts and some calls) are retrieved. Sometimes only data that exists on the SIM is extracted. I am sure many of you have gotten the screen below and it’s disheartening! But we cannot stop trying.

This is not good enough for us to conduct our investigations. We need to get crafty! The first Android running OS 7 that I acquired shocked me. I was getting nothing from the tools! Below is an example of what I pulled – just a bunch of empty directories! Not good…

It was a scary moment for me until I realized that good old ADB was my key to the most data.  I will cut to the chase momentarily, but if you want more information on Android acquisition, I recommend you take vendor training if you rely on a tool and/or take FOR585 Advanced Smartphone Forensics, where we focus on analysis but recently updated the course to include the other options that may work when simple tool acquisition fails.

Things you will need:

  1. Install ADB on your forensic workstation (
  2. Your forensic tools of choice

Android Acquisition Recommended Steps:

  1. ADB Backup (capture both the device (all) and SD (shared))
    • adb backup –all
    • adb backup – shared
  2. Logical Acquisition using a forensic tool – especially if ADB isn’t going well for you
  3. File System Acquisition if more than a backup is offered
  4. Physical Dump if you are aware and don’t care about the traces left behind (i.e. you don’t give the device back and you are not conducting covert operations)
  5. Make sure you acquire the SD card and SIM card if one is present (I like to remove these and acquire separately to ensure nothing is overlooked)
  6. Obtain Google credentials if possible
  7. Extract cloud data – IF YOU HAVE AUTHORITY!
  8. I like to run some ADB commands to the device to ensure I extracted all information and that I am aware of what exists on the Android. Some examples are:
    1. adb shell service list
    2. adb shell pm list packages (shows apps that are installed)
  9. ALWAYS open the extraction to ensure you got what you hoped. If you have a physical dump, Autopsy is the fastest you will gain access to your data! And it’s free. (

Android acquisition leaves traces behind on the device. If you conduct covert operations – tread carefully here. I put these steps in order with you in mind. Don’t go too far without knowing the footprint your tools and methods are leaving behind. These topics are covered more in the FOR585 class. (

iOS Acquisition Recommendations

For iOS acquisition, it’s the same as it has been for years. Yes, there are rumors of the data port lockout. Yes, there are tools that crack into the device anyway. This blog is not focusing on that. It’s focusing on what you should try when you have an iOS device to investigate. You can choose to work on a Windows or Mac. I do both. Honestly, most of my acquisition takes place on my Windows forensic workstation, but I do have a Mac that I use to examine native files to Apple and for jailbreaking because Windows is sometimes flaky when it comes to that.

Things you will need:

  1. Install iTunes if you plan to create a backup
  2. Install iBackupBot (I prefer this tool over the other free ones because of the option to dump the crash logs) (
  3. Your forensic tools of choice

Recommended iOS Steps:

  1. Determine the iOS device type (chances are you will not obtain a physical dump because the device is most likely 64 bit and not jailbroken).
  2. Conduct a File System/Advanced Logical Extraction
    1. If using Cellebrite products, make sure you use Physical Analyzer and conduct both Method 1 and Method 2. I do not use UFED to dump iOS devices. Physical Analyzer is better.
    2. If you use Physical Analyzer and see Method 3 – congrats! You have come across a jailbroken device. 🙂
    3. If using another tool, use more than one to ensure you obtain all potential data from the device.
  3. If you want to be thorough, obtain a logical and/or backup file of the device. I typically stop at the file system dump since it contains the backup if I trust my tool (refer to my old blog or take FOR585 for more info on this topic)
  4. Connect the device to iBackup bot and dump the crash logs
  5. Ensure the tools you used did not enable iTunes encryption by connecting the device to iTunes and making sure “Encrypt Backup” is not selected.

6. Obtain iCloud and Google credentials if possible and extract cloud data – IF YOU HAVE AUTHORITY!

Also – do not guess passwords on the device and risk wiping it. Use a method that you have tested or a service that supports that device. If you are desperate and you are locked out, try the following:

For iOS:

  1. Attempt to communicate with (aka run command to) or pair to the device via libimobile

2. Attempt an iTunes backup

3. If you believe you can obtain iCloud credentials, pull the data from there – many tools support this

4. Try multiple cables

5. Only brute force on your own using a “hacker” box if you are willing to wipe the device.

For Android:

  1. Attempt to run ADB commands to the device. Try to collect as much information as possible.
  2. Remove and acquire the SD card in a write-protected manner, if one exists
    1. If not, attempt to acquire the emulated SD via FTK Imager or a similar tool as a USB Mass Storage Device
  3. Remove and acquire the SIM card
  4. Crack the lock if you can access the require files (*.key, etc.)
  5. Pull Google cloud artifacts, if possible – many tools support this
  6. Try multiple cables and modes (Recovery, Safe, Download, etc.) to see if your extraction is failing due to the device not being in the proper state
  7. If the device is unlocked – make sure you properly enabled all required developer mode settings

Again, we cover other methods and direct ways to interact with the device in FOR585 and I don’t want to, nor can I, give all of those juicy details away. This is simply a guide for things you should consider when faced with these devices. Obviously, we don’t all have time to run through all of these steps, but it’s nice to lay out what may work the best for you. If you want to learn more about smartphone forensics, sign up for FOR585 in DC next month. WARNING: The class is sold out so you can log in LIVE via Simulcast! This means you get to take the live course from anywhere and you get 6 days of action from 9-5 with me. You can ask questions via an online moderator and I will answer them LIVE! It’s not pre-recorded it is not OnDemand. It’s a pretty cool setup and I think you will like it. Check it out