I'm sorry, but I'm not seeing an issue here. Can you help me understand what it is that constitutes an issue?

Thanks!

Hi @keydet89. This is not an actual issue, but an enhancement request into IPED tool, not into RegRipper.

What is "IPED"?

What is "IPED"?

You can find it into this project Readme.md. Let me know if something is not clear enough.

I would like some opinions:

1. -aT gerenates the report in a different format. Should we:
   -replace the current report format?
   -Add the report as a new subitem?
   -Use the "-aT" output to extract the timestamps only, not adding it?

2. Running the "-aT" in full_report and in the profiles can add the same timestamp twice. Should we run the "-aT" in fullreport only, or only for each profile?

Patrick,

I'll be 100% honest with you...I have no idea what you're asking.

"-aT gerenates the report in a different format."

It creates output in a different format, yes...TLN output. That's the point.

"-Use the "-aT" output to extract the timestamps only, not adding it?"

I'm not sure what this is saying or asking here.

"Running the "-aT" in full_report and in the profiles..."

What profiles? The point of using "-aT" is so that you don't have to use profiles.

Can you elaborate on this?

Another opinion is how could I describe the timeEvent? The output is too heterogenoues, depending on pluggin.
Only the date is in a common format, in the start of the line. Other information from where we could infer the timeEvent is placed on the description, the way the plugin developer chose.

Exs:
For AppCompatCache:
1523489668|REG|||M... AppCompatCache - C:\Windows\system32\odbcad32.exe
1523489687|REG|||M... AppCompatCache - C:\Windows\SysWOW64\chcp.com
1523489699|REG|||M... AppCompatCache - C:\Windows\SysWOW64\prevhost.exe
1541727458|REG|||M... AppCompatCache - C:\Program Files\rempl\sedlauncher.exe
1532953101|REG|||M... AppCompatCache - C:\Program Files\WindowsApps\Microsoft.Windows.Photos_2018.18051.18420.0_x64__8wekyb3d8bbwe\Application

For winlogon_tln pluggin:
|REG|||[GPO Hist] Horario_Verao_Desabilitado - \PROX.GRUPO\sysvol\PROX.GRUPO\Policies{AF2E6E0D-10B4-49BC-A440-F362AC3D3F5F}\Machine (Linked to an OU)
|REG|||[wireless Connect] - Last Connected to DIRECT-GUPC-28QSYB (-----)
|REG|||[wireless Connect] - Last Connected to VIVO-E98C (34-57-60-0E-E9-8C)
|REG|||Adobe Acrobat Update Task key LastWrite time
1537462666|REG|||Task Registration - Adobe Acrobat Update Task
1543861940|REG|||Task Last Run - Adobe Acrobat Update Task
1543861940|REG|||Task Completed - Adobe Acrobat Update Task
|REG|||autopico daily restart key LastWrite time
1543492317|REG|||Task Registration - autopico daily restart
1543848619|REG|||Task Last Run - autopico daily restart
|REG|||GoogleUpdateTaskMachineCore key LastWrite time
1527855018|REG|||Task Registration - GoogleUpdateTaskMachineCore
1543839318|REG|||Task Last Run - GoogleUpdateTaskMachineCore
1543839319|REG|||Task Completed - GoogleUpdateTaskMachineCore
|REG|||GoogleUpdateTaskMachineUA key LastWrite time
1527855018|REG|||Task Registration - GoogleUpdateTaskMachineUA
1543873729|REG|||Task Last Run - GoogleUpdateTaskMachineUA
1543873729|REG|||Task Completed - GoogleUpdateTaskMachineUA
|REG|||OneDrive Standalone Update Task v2 key LastWrite time
1527854105|REG|||Task Registration - OneDrive Standalone Update Task v2
|REG|||OneDrive Standalone Update Task-S-1-5-21-246674189-1450962176-99410399-1142 key LastWrite time
1543494605|REG|||Task Registration - OneDrive Standalone Update Task-S-1-5-21-246674189-1450962176-99410399-1142
1543856037|REG|||Task Last Run - OneDrive Standalone Update Task-S-1-5-21-246674189-1450962176-99410399-1142

I think that I will put as timeEvent the name of the plugging executed that produced the entry, prefixed with "WinReg:".

Okay, thanks.

"The output is too heterogenoues,..."

This is intentional. Not all time stamps reported are key LastWrite times, and as such, the context is heterogenous, so the output must be, as well.

1. I think -aT should be used just to generate regripper timeline reports temporarily and they should be broken into timestamp subitems of current reports, each subitem referring to one timestamp.
2. I think -aT should be executed just for the full reports

Hi Carvey,

It seems that you are the main developer of RegRipper. This thread is about IPED, a tool that uses the output of many tools like regripper.

About the timeEvent property, ideally it should come from the event description, but the absence of a clear pattern could make it difficult... Not sure if using the plugin name would be good/informative enough to the user...

Wireless Connect (or Last Connected to), Task Registration, Task Last Run, Task Completed seems good timeEvent values (we can remove the spaces). The full event description can be added to another property.

What about taking everything before the hyphen in the event description and using it as timeEvent value at first, run it on some dozens or hundreds of registry files and try to improve based on the results shown in the Metadata filter tab? Storing the full description String in another property can help the results analysis.

patrickdalla,

What is "IPED"? Is there a link?

Carvey, this thread is inside IPED github page. I don't know how you are following this thread. If you are receiving this from github, there should be a link to the thread at the end of the email. If not, this is the link: https://github.com/sepinf-inc/IPED

Well, a version was pushed in RegRipperTLN branch. It uses the before "-" in description approach to name the timeEvent title, and the field. For the field I removed some incompatible characters.

Some RegRipper plugins that extracts important timestamps don't have their TLN counterpart.

Examples:

• Network DateLastConnected, DateCreated (wireless)
• DHCP leate obtain and termination times
• Storage (USB included) FirstInstallDate, LastRemoval, LastArrival
• Computer shutdown time

These are the one's I've noted. But it seems there is more.

So, should I try to parse these dates not parsed by TLN pluggins?

Some RegRipper plugins that extracts important timestamps don't have their TLN counterpart.

That's bad news...

So, should I try to parse these dates not parsed by TLN pluggins?

If it's easy and if there are relevant dates, that would be great!

It is reasonably easy to find timestamps in normal plugins reports as they are formated as ISO 8601, or as perl gmtime result (Ex.:"Thu Oct 13 04:54:34 1994"). It is not easy, though, to associate these dates with the better name to identify the correspondent timeEvent, as these names are not standarized.

For some dates, the preceding string is good enough like ShutDownTime. For AppCompatCache entries, though, the dates are preceded by the file path of the respective cached executable "shim". The AppCompatCache term can be found at the top of the list.

We can make code to treat some exceptions, but as the output are not standarized, the parse will be coupled with specific regripper plugin version.

It is not easy, though, to associate these dates with the better name to identify the correspondent timeEvent, as these names are not standarized.

Yes, that's the challenge. I expected -aT switch would return all timestamps and events in a standard output format...

"I expected -aT switch would return all timestamps and events in a standard output format..."

Such as?

What would that format look like?

The version of RegRipper you're referring to hasn't been updated in almost 3 yrs, due in part to almost no feedback from the community.

"Some RegRipper plugins that extracts important timestamps don't have their TLN counterpart."

Such as? Do you have examples?

"So, should I try to parse these dates not parsed by TLN pluggins?"

If you have examples, perhaps I can assist. If that's what you want.

Hi. I think I could make a parse that was enough, at least for my test case. Timestamps are extracted directly from normal plugins output (full).
The name of the field follows the pattern "WinReg:[pluginname]:[fieldName]" where fieldName is the term before the date in the same line.

I need more test cases to validate the parse.

There are some dates formatted as ISO 8601 that in reality corresponds to just the time info without the date, so the date part remains 1970-01-01 without the date information. Should I ignore them as timestamp entries or include them?

There are some dates formatted as ISO 8601 that in reality corresponds to just the time info without the date, so the date part remains 1970-01-01 without the date information. Should I ignore them as timestamp entries or include them?

For now I think it is better to ignore them. But what plugin is generating them? Maybe that could be an issue and it would be better to check/report it to regripper project.

I need more test cases to validate the parse.

I can provide samples to you when I return back to work.

"WinReg:[pluginname]:[fieldName]"

WinReg:nic2:T1, WinReg:nic2:T2 seems not intuitive, what do they mean? Even appcompatcache and shimcache may not be clear for beginners, I think the executed program name should be put in another metadata in the first case, at least. Not sure, but -aT output seems more descriptive to me at a first sight...

Such as?

What would that format look like?

Hi @keydet89, thank you very much for your comments. I'm just saying my expectation about -aT is that it would output ALL parsed timestamps by regripper plugins. But @patrickdalla said some parsed timestamps present in the default output format are not present in -aT output. He provided examples above in this thread.

Researching I found that T1 and T2 are in fact not timestamps, but a delay, a time lapse. I think they can be let out. So, I made a rule to let out all dates that starts with 1970-01-01 00:00:00, I can change this, and let out all dates from year 1970, as they probably are representation of time lapses, or, if not, some misinformation as I think in 1970 there were no window registry format :-).
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc978471(v=technet.10)?redirectedfrom=MSDN

About the description: I've made a parse of RegRipper output, so, little detailed info from there won't be complemented, and improvement should also be asked in RegRipper.
For appcompatcache, for example, the only description that exists is "(System) Parse files from System hive AppCompatCache", even in TLN output. Shimcache is, actually, the same appcompatcache info parsed with a different name. They are generated because there are "duplicate" plugins, one that exports using the name appcompatcache, and the other shimcache.

The parser only read info from RegRipper output, and I think that any other more detailed info should be asked from RegRipper also. At least, that was what I thought was the only purpose of this implementation.

The parser puts as the "title" and "timeEvent" of the item any preceding terms in the same line of the timestamp. As the content of the item, the entire line is put. For some output, as appcache and shimcache, the preceding terms are paths to files, so they would generate to much distinct timeEvents, one for every file, and for these plugins I omitted this on title or timeEvent fields (they are included in item content).

AFAIK, the TLN pluggin counterpart is a pl script file with the same script file name suffixed with "_tln". If I am right, there are 258 script files without their TLN counterpart. I don't know how many of them parses timestamp key values.

I also created a category specific for these extracted timestamp entries:

"AFAIK, the TLN pluggin counterpart is a pl script file with the same script file name suffixed with "_tln". If I am right, there are 258 script files without their TLN counterpart."

The assumption that there is a one-to-one correlation between regular plugins and "_tln.pl" plugins is incorrect. That simply does not make sense.

Take the Run key, for example. The only time stamp available is the Run key LastWrite time value. Individual values beneath the key do not have associated time stamps.

Keys that contain MRU listings are different, clearly. Keys such as the UserAssist subkeys, which have values whose data includes a time stamp, are different, as well. These can be included in a timeline, which is why they have "_tln.pl" plugins.

Keys such as the Run key are covered for inclusion in a timeline by regtime.exe.

" I don't know how many of them parses timestamp key values."

I'm sorry, but I have no idea what "timestamp key values" is meant to refer to...

As you have said, every key has at least a "LastWrite" time value. Maybe this can be considered forensically irrelevant, and for this reason there is no TLN counterpart plugin and no one-to-one relation.

As I've said before, for the case I am evaluating these are some dates that I could not find the correpondent entry in the "-aT" TLN output:
Plugin: winver.pl - InstallTime, InstallDate
Plugin: usbstor.pl - FirstInstallDate, LastRemoval, LastArrival
Plugin: shutdown.pl - ShutdownTime
Plugin: heap.pl - LastDetectionTime
Plugin: diag_sr.pl - SrCreateRp(enter) and SrCreateRp(leave)

@patrickdalla, how many timestamps you got with your last approach (parsing default regripper output) and with the first approach (parsing -aT output)?

Also, for networklist.pl there is a networklist_tln.pl counterpart, but the TLN script could not parse the dates of network entry creation and network last connection, although the networklist.pl presents these dates.

"Maybe this can be considered forensically irrelevant..."

It's not about being "forensically irrelevant".

"...for the case I am evaluating these are some dates that I could not find the correpondent entry..."

From the point when RegRipper was originally released in 2008, it was intended to be a community-based project. This means that if you see something that's "missing", or find something that you would like added to it, you can either do so yourself and add it back to the project, or ask for assistance in getting it added.

You're looking at what's publicly available. No one has asked for anything to be updated in almost 3 yrs...and that's just based on the time stamps in Github; in reality, it's been longer than that. During this time, I've been continually and regularly updating RegRipper v4.0.

So, if you're evaluating the tool and see that need for something to be added, do so, or ask for help in doing so.

@patrickdalla, how many timestamps you got with your last approach (parsing default regripper output) and with the first approach (parsing -aT output)?

There were 304 additional timestamps not found in TLN "-aT" output.

There were 304 additional timestamps not found in TLN "-aT" output.

And the totals?

"Maybe this can be considered forensically irrelevant..."

It's not about being "forensically irrelevant".

"...for the case I am evaluating these are some dates that I could not find the correpondent entry..."

From the point when RegRipper was originally released in 2008, it was intended to be a community-based project. This means that if you see something that's "missing", or find something that you would like added to it, you can either do so yourself and add it back to the project, or ask for assistance in getting it added.

You're looking at what's publicly available. No one has asked for anything to be updated in almost 3 yrs...and that's just based on the time stamps in Github; in reality, it's been longer than that. During this time, I've been continually and regularly updating RegRipper v4.0.

So, if you're evaluating the tool and see that need for something to be added, do so, or ask for help in doing so.

Right, no problem. This thread is about IPED. And we are trying to parse the maximum we can from RegRipper current used release output.

There were 304 additional timestamps not found in TLN "-aT" output.

And the totals?

2315 total timestamps extracted from normal plugins output, and 2011 from TLN output.

"Then why not seek or develop a means for getting more from RegRipper?"

Yes, sure. Any improvement would be great. IPED is a tool to parse and present info from many sources and formats. We are trusting on RegRipper as good tool as a source of registry info. Personally I don't know perl to help efficiently.

Hi @keydet89, thanks for your insights here. I totally agree that if something is missing or if some issue is found in RegRipper, that should be fixed into RegRipper.

During this time, I've been continually and regularly updating RegRipper v4.0

Is RegRipper-4.0 open source and available publicly somewhere?

2315 total timestamps extracted from normal plugins output, and 2011 from TLN output.

Thanks. Have you checked the opposite, if all TLN time stamps were got by the new approach? And do you think the descriptions of the new approach are better than those got parsing TLN output?

Actually I'm not too concerned about getting as much timestamps as we can, but about providing meaningful timestamp information to the user.

"Have you checked the opposite" - yes, they were all parsed (my case) in the normal report parsing approach.

"do you think the descriptions of the new approach are better than those got parsing TLN output?" - I didn't analyse all TLN pluggins output, as my test cases is small. But the description was similar.

"Actually I'm not too concerned about getting as much timestamps as we can, but about providing meaningful timestamp information to the user." - providing meaningful timestamp information for these entries should require some "library" with these details, as there are many different timestamps context. I think it would be better to search for these details on other sources/internet.
I think useful to find as much timestamps as we can. In a timeline analysis, if an not too detailed entry is found, but in a relevant time interval, the analyst can do the research he need to infer if that info is relevant.
And also, some of the found TLN output missing dates seems potentially useful to me: ShutDownTime, Usbstor, SO install date.

Certainly the best option would be a well formatted output with all these dates.

The date info itself could be not too detailed, but once easily found, the analyst can detail it by searching other artifacts.

Hi @lfcnassif ,
After some improvements in code to extract and parse the maximum possible timestamps from RegRipper reports from the file set you have sent me, I write the some intermediary findings:

1 - Parsing timestamps from standard RegRipper reports resulted in 640.552 items. From TLN resulted in 352.745.
2 - It was more difficult to parse a good term to represent the timeEvent metadata from TLN description than from standard reports. In Standard report, plugin name always is shown after a line with '-' chars, used as sub report separator, so this name is used with some other info associated with the timestamp, and is somewhat descriptive. In TLN, there is no standard on where this plugin name is described.
3 - Some plugins seems to parse same info, creating redundancy. ShimCache and AppCompatCache is one case. Both have TLN reports, so, the redundancy occurs also for this kind of report.
4 - SystemCache standard report parses USN Journal ID as a date. I don't know if this is correct or why it was implemented this way. Even TLN systemcache report (there is the counterpart) doesn't parse this info as date.
5 - Because this lack of pattern in timestamp description, the code is becoming too coupled with the specific version output. Any regripper pluggin code change can cause inconsistencies.

These were the parsed timeEvents from standard RegRipper (some little few strage descriptions remain):

For the timeEvents padronization from TLN reports, lot of work remains.

1. That's a big difference!
2. I see.
3. Maybe this is caused because we added some regripper 2.8 plugins to the 3.0 package when upgrading to regripper 3.0 (#331 regripper3 upgrade #1316). If it's the cause, we should remove the redundancies caused by that merge.
4. I think this should be reported to RegRipper-3.0 project.
5. I see. Since it is much more difficult to parse meaningful event descriptions from TLN output based on your tests (I thought it would be the opposite originally...) and since it is giving half the number of events, I think we can stick just with the regripper default output parsing only, so we would need less maintenance efforts.

I finished a good enough PR, please test it.

I have reported RegRipper-3. As soon as they improve and fulfill our necessity we can adapt it.