View Full Version : quick icedump question...
Sab
November 24th, 2000, 21:26
I have been useing procdump and trw2k to dump most my files. However , in this case procdump crashes and trw2k isnt winnt compatible so i cant run the program i dumped in winnt. Anyways heres my question.. when i type /Dump
AddressofOEPHERE(0183EBA2) 172128 C:\my.dll
it comes out to be 200 or so megs? when it is only 172kb... heres some info about what im dumping.. its packed file size is 172kb , its a dll and im dumping it from win9x useing Sice 4.05 and id6016(icedump) Thanks for reading .
Kayaker
November 24th, 2000, 22:51
Hi,
I've had that happen a few times too (like yesterday!), but after repeating the dump it was fine. Just one of those glitches I guess...
Kayaker
The Owl
November 25th, 2000, 06:25
hummm, now that's interesting ;-). the size for /dump comes from the internal winice expression evaluator, i have no control over it. in your case it means it was evaluated as a hexadecimal number, i.e some 1.5 Megs, but that still doesn't quite explain the 200 Megs... in any case, i'd try it with the latest 6.020 or 6.021pre just in case i managed to fix it. also, you'd be better off with /pedump (and its numerous options) if your target is a PE image.
kayaker: what versions did you use and could you reproduce the behaviour? if so, let me know how and i will take a look at it.
Kayaker
November 25th, 2000, 23:11
Hi Owl,
I've had this happen a few times before with earlier versions of Icedump, the latest was when dumping the unpacking project currently being worked on in the Projects Forum using Icedump 6.018. Since I'd seen this before I just ignored the glitch, deleted it, tried it again and it worked OK. I seem to remember the sizes of the faulty dumps being in the 200Mb range as well though.
I tried reproducing it a few times with no luck. If I happen to notice this again, I'll take specifics and dig up the History log to see exactly what was entered.
Regards,
Kayaker
latigo
November 26th, 2000, 21:40
Howdy!
I had this exact problem tonite..
icedump dumped files about 200 megs big!
Coincidentally i had this problem while dumping from erroneous addresses in memory.
When i say erroneous, i mean not the ones i had to dump from.
For example:
I had to dump from RVA 10200 but as i was kinda tired i forgot to add the image base to that number..and the two dumps from address 10200 in memory were too big.
When i corrected the address, i got a normal dump.
I don't know if this was a coincidence or what, but just posted it cos it might be helpfull.
Bye!
Mr Smith
November 28th, 2000, 05:01
I had similar problems with /dump in icedump 6.020. In my case the problem seemed to be that I didn't specify a selector in front of the address. Once I did that (167:41c023) everything worked fine.
Mr Smith
Sab
November 30th, 2000, 18:31
thanks for the help guys i just got back and read the replies im going to go ahead and try the suggestions from all of you and all replies were helpful btw it seems as though i did a little of everything wrong ( :
The Owl
December 2nd, 2000, 12:33
problem found and fixed, wait for 6.021 or its next prerelease. the bug manifests only when you have some non committed pages in the dump area, something that normally does/should not happen.
Sab
December 4th, 2000, 01:00
Cool ( : btw I tried useing pedump and I dont know if its from my lack of knowledge in useing icedump but heres what happened. When i Dump the app useing trw1.22 with MakePE option (MakePE Filename IMTE) it dumps fine and runs under win9x without any protection. However, on winNT i get a tlsfreeinternal error something about a entrypoint. When I dump in trw1.22 it dumps the export/import table and strings basically the whole package ( : however useing pedump in the following form /PEDUMP <imagebaseinmemoryy> <EIPofentrypointandwhereimatindebugger> <C:\some.dll> it dumps fine however when i dissamble it i notice there is no import table.. hrm... anything u notice right off the bat im doing wrong? thanks! (btw glad to hear that that /dump bug will be fixed soon)
The Owl
December 4th, 2000, 17:39
Quote:
However, on winNT i get a tlsfreeinternal error something about a entrypoint.
|
probably incorrect TLS object or incorrect kernel32 imports. on former i can't comment but latter is taken care of by icedump 6.021.
Quote:
however useing pedump in the following form /PEDUMP <imagebaseinmemoryy> <EIPofentrypointandwhereimatindebugger> <C:\some.dll> it dumps fine however when i dissamble it i notice there is no import table.. hrm... anything u notice right off the bat im doing wrong?
|
the entry point parameter must be a RVA, and not a VA (ie, VA-imagebase). but it has nothing to do with imports reconstruction. did you set any special options for PEDUMP (/option p ...)? or perhaps use a /hydra plugin?
Sab
December 4th, 2000, 18:36
ahh i did not calculate rv-imagebase, ill try that and download the new icedump today (just transfered everything to a brand new drive i bought a nice 30 gigor)
Sab
December 4th, 2000, 18:42
va-imagebase rather. also i did not use any special options and i am not useing the hyrda plugin, unless it is set to default but i did nothing to implement anything special just used the the pedump command as it was i will try this all tonight see if it works out. Thanks for all your quick responses owl/others who helped out.
Sab
December 6th, 2000, 01:50
weeeeeeeeeeeeeeeeee ( :
Welp heres what happened i bought a new harddrive(nice 7200 30 gigs they got all over for sale) and reindid my intire machine. I installed softice 4.05 and downloaded a brand new copy of icedump 6021. The dump command no longer does those mean 200 meg files, and the pedump function got me to dump a completly rebuild .exe from the protected one i had been working on. So its safe to say.. the new icedump is great ( : Owl thanks for the help and for a awesome tool for reversers to have. Im gonna try useing icedump instead of procdump just because of the convience of not having to switch screens ( : . Once again thank u kindly
Powered by vBulletin® Version 4.2.2 Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.