Topic: How to split hex ranges in smaller parts (Read 326 times)

That was my thought about it, too. A normal user would not use the switch -O or -OO or the PYTHONOPTIMIZE environment variable and if he does, then he knows the consequences and hopefully knows exactly what he is doing.

Thanks for your feedback.

Yup, that's the kind of dogma that I was referring to previously. Programmers love saying: "Don't *ever* do this/that" but often what they're talking about amounts to an inconsequential issue (in practice).

If you run your script like this:


Then the assert statements won't make it into the compiled bytecode. So, to make sure that your input validation remains intact, regardless of how your script is invoked, you should replace the assert statements with something more resilient (like if statements that lead to an error message, or maybe your own fail_if function that raises an exception when it's passed something that evaluates to True, etc.)

I often don't bother to do this with my own scripts, but lots of people seem to think it's mightily important, so if you agree with their thinking or you don't want to be nagged about it in the future then you should probably do it.

Don't ignore "best practice", but also remember to cultivate a healthy disregard for it, too; it can easily become a crutch that prevents you from thinking deeply and developing your own style.

@PowerGlove
Thanks a bunch! Really appreciate your feedback, as well as your offered assistance here and also for future questions. That's not a given and so I appreciate it very much. Thank you for your motivating words, which are very helpful.

Yes, absolutely right. I still need to validate the input to avoid weird effects and error messages. EDIT: Done! Thanks for pointing to Python's assertion [1] [2] which was helpful. I am not sure if I did according to best-practice, especially following paragraph in [1] has made me a bit puzzled:


but it seems to work As I said, I'm still in my infancy and there is still a lot to learn.

[1] https://pythongeeks.org/assertion-in-python/
[2] https://wiki.python.org/moin/UsingAssertionsEffectively

@citb0in: Nice job. It's (very) impressive how quickly you're learning Python!

I like the solution you came up with, using the argparse module is sensible, and using the divmod function is a smart choice, too. I think it's clear that you're past the point of needing help (at least with this project). I'm sure that there are a few combinations of command-line arguments that will produce unexpected results (there always are), but I think you're capable of finding/fixing them all on your own (maybe a few assert statements, or similar, after parsing the arguments would help; making sure that some invariants hold, like: start >= 0, end > start, number > 0, number <= (end-start)+1, etc.)

You're doing great. For a conscientious and self-reliant type like you, my only suggestions are to keep doing what you're doing and to be selective about the feedback that you internalize. Programmers are a dogmatic bunch and like to over-critique each other's code — only the really experienced ones seem to be able to restrict themselves to truly meaningful feedback. If someone has a whole bunch of stuff to say about your code then remember to pick and choose what's useful to you and ignore the rest; there's some kind of Dunning-Kruger effect where the least experienced programmers tend to be the ones who are brimming with the most advice.

If you ever get stuck on a programming-related problem and don't feel like posting about it, feel free to PM me.

Hi PowerGlove. Sorry for late reply.

Thanks for pointing that out.

I did so and I understand what you mean, you're right. Also, as far as the big numbers are concerned, it behaves as you said. So I really need to get away from the normal float division and focus on floor division. For this I had studied various help pages on Python floor division. There are several libraries, especially in 'math' that allow to round up or down (e.g. math.ceil, math.floor) or round() and some more. However, I always prefer clean code so that you don't always have to rely on other libraries. So if there is an elegant way without additional libraries, I would prefer it. I stumbled over and noticed the speciality of how floor division behaves with negative numbers and I thought I could possibly take advantage of this to round up (eg (10-1)/5 to get "2" as solution. My initial approach was this one:
But unfortunately I was completely wrong, it doesn't work like that. So I searched further and found various solutions that can effectively and simply determine ranges. My desired goal is that all ranges should have as identical sizes as possible. . The last range can be of any size and should serve as a residual container in which the rest can be placed.


You're basically right, of course. However, I would still prefer this range size for visual reasons, because it is simply clearer and easier to understand for the human eye. With decimal numbers this doesn't seem to be such a big problem, but with hex representation you may not always recognize at first glance whether the range runs without gaps.

Example:


I have tried a few things and ended up with a solution that evenly distributes the values across the ranges. I also changed the parameter query, the suggestion of n0nce was great but I like it a bit cleaner in the code to get rid of the repeating try: except: lines. Pythons' argument parser fitted perfectly. I have therefore modified the program as far as possible and created a first version. My current program allows two ways of execution. The range is mandatory and must always be entered as a parameter so that the program has something to do. By default, the program will use the "n slices" mode, where n is the number of slices desired. If no input is made for 'n', the default value 2 is used.

However, there are also cases where the user wants a certain size of the slices to be generated and doesn't care about the total number of slices to be generated. I integrated this "chunks" mode that can be used with the command line switch -c (for chunks).

Examples:

Range 20 - 90 will be sliced into 15 equal parts

Range 20 - 95 will be sliced into chunks with size 10

The current program version is not yet compatible with hex but only with decimal input. I will soon rebuild this so that interoperability is also ensured and so that the user can enter either decimal or hex and can even mix among themselves. I repeat and emphasize that I am an absolute Python beginner and want to make my first learning steps and gain experience. I also tried to create an account on github so that I can upload and manage code there in the future. Please bear with me if I have made mistakes and bad programming syntax, correct me accordingly so that I can learn and get better. Of course I am open for suggestions and corrections and constructive criticism is very welcome.

==> range_slicer by citb0in @github <==

The parameters need to have the prefix 0x for hexadecimal numbers.

the ranges need to be divisible by the given number, if not it will create an extra range with some values outside of the given range.

And yes I spotted some bug in the ranges, I will solve it

The differences in output you're finding between the programs you're comparing is (mostly) due to how the slice length is being calculated.

One is doing this (in Python):


And the other is doing this (in C/C++):


The first way is using floating point division and the second way is using integer floor division (via GMP), so most combinations of input range arguments will lead to outputs that disagree.

You can tweak n0nce's script to do floor division by changing the / into a // (and maybe remove the two int() calls further on, which will then be unnecessary). This will also have the effect of letting it work with much bigger ranges (right now you'll run into problems if you try it with ranges that strain the limited precision of Python's float type; for example, if you run it with these arguments: 0 0x22222222222222222 2, it will produce "truncated" slices). However, by making this change you'll also ruin a nice property that this script has (automatically sizing the slices so that they always cover the entire input range); try running it with these arguments: 1 10 5, both before and after making the change and you'll see what I mean.

I'm curious about the way the slices overlap in the examples you've shared — are you sure that's what you want? Wouldn't you prefer non-overlapping slices? By that, I mean, shouldn't each slice begin "ahead of" (instead of "on") the previous slice's end value? For example, if I had to divide the (inclusive) range {1..10} into 5 parts, I think it makes more sense to go: {1..2} {3..4} {5..6} {7..8} {9..10}.

In cases where the input range doesn't evenly divide, there's also the issue of what to do with the "remainder". This issue solves itself when using floating point (by automatically distributing it over the slices), but when doing integer divides, you have to decide yourself what to do with the remainder (e.g. ignore it, put it in the last slice, overshoot the input range like that C/C++ program sometimes does, etc.)

I also think it makes more sense to calculate the length of a slice like this:


But that interacts with other design choices and I don't want to overwhelm you with too many considerations. I've given you some stuff to think about, but if you get stuck or would like a more verbose script to look at, let me know and I'll put something together for you.

If I understand correctly you are trying to do this:

https://github.com/geokomplo/PubHunter/blob/4157d8e46902ebed3562a4ab3560e85eb69129b2/address.py#L44

Parallelism is not needed for that particular operation because the action of splitting ranges is usually only done after some other range full of private keys has already been exhausted, so it will not be running frequently.

@COBRAS
can you be more specific please? what do you mean by the link you posted?

EDIT: Oh I understood now. You were referring to the range slicer written in C++ by AlbertoBSD. There it is. Will try it ... thanks for pointing out

I slightly changed the output format of the python script that n0nce provided, so I get pairwise ranges per each line. I added two small functions for later use (converting dec<>hex).


When I compare the output of both snippets, they differ. I have no clue what the reason therefore is. See here ..



When user input is 2 slices the result matches between both programs:



Some more examples ...



here the output matches...



I thought it might be the case when n is even or odd, but I find no relationship between odd/even numbers. See here, n=12 leads to different range pairs



It seems that alberto's slicer tool sometimes creates one more additional range than user input was. Only the first range pair matches always between both programs.

sliser https://github.com/albertobsd/sscodes/issues/1

Thanks for the hint, which certainly has meaning and may seem useful for parallel processing. In my case, however, I only need this in a small Python snippet to quickly build some ranges and manually feed a spreadsheet with them.

The snippet shown by n0nce helped me already, I just have to see how to rebuild it so that it still does INT and HEX output and also displays more info, but I have to learn Python first. The output formatting I would like to improve then, so that not everything is spit out in a line with commas but in a kind of matrix (with INC and DEC values accordingly).

Based on SO posts it seems like you want to iterate over those numbers (key cracking?!) in which case you shouldn't create them like that, you should instead parallelize the process. It all takes one line in C# or two if you want to set the number of cores to use:

Thanks a bunch @n0nce !!! Will try it soon ... meanwhile I stumbled over this, maybe it is helpful, maybe not ?

As script with hex and int parameters:

@n0nce: we cross-posted I was still editing. See my posting again

@NotATether: I'm sure, yes. Unfortunately I'm not good in Python (yet). I have written two small bash scripts that allow me to do dec<>hex conversions using linux command 'bc'. I wish I would be knowledgeable in Python, but it's still on my to-do-list that's why I am asking if anyone is aware of such a small python snippet.

That looks like something that can be easily written in a single Python file. Unfortunately I do not know of any existing implementations.in the wild. If you are knowledgeable in Python then you can make your own script without even knowledge of cryptography being required.

Since splitting a range into equal parts means that the first number in the next subrange is the last number of the previous subrange plus one, means you just need to divide (end-start) / n to get the size of subranges and add it over and over again to get the start of the next subrange.

Example:
Start = 0x1000 = 4096
End = 0x2000 = 8192
n = 2

Calculate subrange size: (0x2000-0x1000)/2 = 2048.
Meaning the first subrange goes from 4096+0*2048 to 4096+1*2048, and the second subrange goes from 4096+1*2048 to 4096+2*2048 = 0x2000.

Is there any tool or python snippet available out there that can split a defined range into equal n parts and outputs the results in hex (omitting the 0x prefix for hex values) but as well as decimal ? It should also work vice-versa, so it should allow inputs in hex or in decimals. When entering 0x it should treat the user input as hex value, in all other cases as decimal value.


Example:
1st argument = start of the range
2nd argument = end of the range
3rd argument = create n equal parts